Talk pages consultation 2019/Phase 2 community discussion summaries

On this page are summaries from the different communities that participated in Phase 2 of the talk pages consultation. Please don't edit other participants' summaries (except to fix typos).

FAQ
What is a community summary?

The goal of a community summary is to wrap up the discussions and provide a summary of what your participants said. That way, other communities can learn about your community's needs, concerns, and ideas. We have seen very different feedback on different wikis, and it is time to discover what everyone thinks!

Please include in that summary:


 * every perspective or idea your community had, and
 * how frequent each idea was; for example,
 * how many users shared a given opinion
 * whether an idea was more common among different types of contributors (newcomers, beginners, experienced editors...)

You can add as much detail as you want in that summary.

Can't the Wikimedia Foundation read all the feedback?

We are trying, but we really need your help. For most conversations, we have to use machine translation, which has limitations. This can help us find the most common needs or global ideas. Machine translation is useful, but it does not tell us how people are feeling or what makes your community unique.

Your community summary should be built from your community's perspective, experience and culture. You might also know of relevant discussions in other places, which we did not find (for example, perhaps someone left a note on your user talk page – it is okay to include that!). Your summary is extremely important to us.

What are the next steps?

TBD

Czech community

 * 1) The community discussion participants overall agree with the proposal. It could be challenging for the developers, but the automatic features are considered super-helpful by several participants, especially for older/technical-unexperienced wiki users.
 * 2) There is a positive attitude towards any wikitext/behavioral changes between the participants too. Overall this will be done automatically by the editor, right? Several participants mentioned the new system would save much time, make things easier and make it more clearly arranged, so any markup/behavior changes are completely for a good purpose.
 * 3) This question was the first dispute in Phase 2. Each person has its own opinion where the talk link should be placed. Mostly they supported to leave the link as is. The discussion is important maybe as much as the article itself. Websites usually have the talk under the contents, but this approach could attract internet trolls. There are several people mentioning a link to talk for every article section, but several others were opposing this idea. The reason against should be a user (especially a newcomer) could be flooded/overloaded by so many UI features/links, that (s)he easily overlooks the other UI features. This could also be a reason newcomers can't see the current talk page link! They are just visually flooded/overloaded with other UI features. Also it was mentioned readers are mostly not interested in talk, so they shouldn't be disturbed by such link.
 * 4) Although this is technically possible and can make developing and/or administration easier, several participants mentioned quite important problems with this approach. First, move like this would break Wikidata connections between major talk pages (Village pumps, RfCs, etc.). Several others also mentioned this could break the connection page-talk. Community talk pages (Village pump, RfCs, etc.) sometimes also need talk pages about themselves. As a workaround there were suggested two approaches: a page metadata similar to content model, or a magic word similar to the current __NEWSECTIONLINK__ . The Project namespace also makes the page more striking. This would be a major intervention to the current scheme just for such a few pages. Some pages also don't have any distinguishable line between talk and content (usually WikiProject ones).
 * 5) All participants were positive about seeing/watching a history of just one thread they're interested in in the whole page, because it does really save the time. But also the whole page history is required. But there were various thoughts, that the whole page history does not need to be "standard". For example, the whole page history could feature just thread moves/creations/archivations + the timestamp of the last post + changes since last seen (in a watchlist). Interestingly this makes the third option to the rulette: users should be able to watch only one selected thread, all threads in the page, or a thread actions in the page. Simultaneously and separately. This seems as a good challenge for developers, but for a good prize. Moreover, from the whole page history all the move/archive/hide/fully delete (sysop anti-spam patrol)/lock/search/filter thread tools could be accessible.
 * Several participants mentioned this could be achieved using subpages easily, there already is a technical background (move/rename/delete/API tools) for this option, the whole page history would also be working from the beginning, just the all-threads-in-page history would need to be compiled by software. There was a concern about the name of the subpages/threads, which should be human-readable (mainly because of patrol), but also easily auto-generated. Perhaps these could be borrowed from Growth's help panel?
 * There were minor concerns about automatic mass messages for users. These sections should ideally be separated from the main user talk. Perhaps some separate user page to catch these messages, or one whole-community page, which would ping the subscribed users for each new thread.
 * 1) At this point there were two groups of opinions. Several people would separate the banners into the action=info page, history page, or even to the new namespace. The others think there is no need to split these parts. The banners could be also guiding users through the discussion rules and etiquette. I personally want to point out some interesting suggestions about making the threads and banners visually separate, but still on the same page. There was no clear idea, how to achieve such a thing, but some strong visual eye-leading to what the user looks for would work! There were suggestions to wrap banners, skip banners by a button, but per our community discussion better would be to just leave them as is and isolate them visually. Also there must be a place for talk page metadata (archivation, preferences, etc.), this could be a part of them.

At his point the Phase 2 community discussion created another point, let's call it point 7:


 * 1) Several people mentioned there should be some system of notes. People could add notes to individual lines of articles. These notes could work like threads, but lighter. They perhaps could be in a separate namespace, or automatically posted to talk page as a thread. This would require to link the position in the precise article revision to the thread/note somehow, either on thread/note side (coordinates), or on the article side (anchor). Similar approach works on OSM and also in many programming tools (GitHub). There is no need to move this comments, have the comments history, just they should be archiveable, closeable and removable. This topic has also been discussed with Growth team separately already and it seems Czech community likes the idea.

To sum this all up: The community is ok with any changes, even the major ones, as far as it makes the talk experience on wikis better, more clear, clean, searchable. There could be used so many already existing features and repurposed on discussion pages. But the developers should always think about long-term editors and newcomers, old (technically-unexperienced) and young (chatting all over the internet) users. Extra care should be done to make the product stable and also not completely changed as many long-term editors and novices could become sick of never-ending major changes in talk pages. For the Czech community, Dvorapa (talk) 02:10, 16 June 2019 (UTC)