Talk pages consultation 2019/Phase 2 report

The main>Special:MyLanguage/Talk pages consultation 2019|2019 Talk pages consultation (TPC) has reached the end of Phase 2, the final phase of the Wikimedia Foundation's global consultation.

In Phase 1, we asked contributors how they use talk pages, and the problems that they experience. The Phase 1 report, published in May, offered a new product direction for an upcoming project, and posed specific questions for Phase 2. This report, published in August, summarizes what people said and what we learned during Phase 2, and explains the plans for the coming year.


 * by the Talk Pages Consultation team: Danny Horn, Benoît Evellin, Sherry Snyder, Thomas Meadows and Peter Pelberg

Introduction
In Phase 1 of the consultation, we identified two major themes:


 * Clear design and appropriate tools: Right now, article pages and talk pages are very similar in their appearance and functionality. That similarity is misleading, and makes it more difficult for people to learn how to use talk pages correctly.
 * Features vs flexibility: The desire for talk page improvements is not limited to new contributors. In fact, experienced contributors are the ones who know how inadequate the existing tools really are. Experienced users want to follow a single discussion on an active talk page, and to find discussions easily and quickly, even if the discussions have been moved to an archive. In order to provide these features, the system needs to be able to tell what "a discussion" is – that this specific part of the page is a single discussion, and that it is separate from other edits on the same page. That may require making some changes that limit the endless flexibility of an open wikitext page.

With those themes in mind, we proposed the following product direction for the Wikimedia Foundation's Editing team to work on:

Wikitext talk pages should be improved, and not replaced.

We will build a new design on top of wikitext talk pages that changes the page's default appearance and offers key tools. This new design should communicate to the user that this is not a content page, and help the user interact appropriately with the tools. This should include clear signals for how to start a new discussion, and how to respond to an existing discussion, or to a specific message within that discussion. It should add the signature automatically, and place the message in the correct nesting order.

In order to keep consistency with the existing tools, this new design will be a default experience that existing users can opt out of. It should be possible for users to keep the view that they currently have, and work in wikitext instead of using the new tools.

However, to build features that experienced contributors need, there may be some small-to-medium changes in wikitext conventions and practices. Our intention is to only make changes when they're connected to a feature that contributors find useful.

In Phase 2, we asked a series of questions to test different aspects of this approach, essentially asking: what could go wrong with this project? Discussions were hosted on 12 wikis: nine Wikipedia languages – Chinese, Czech, Dutch, English, French, German, Polish, Russian and Thai – plus Wikidata, Meta, and English Wikisource. Individuals also left comments on this wiki at Talk pages consultation 2019/Individual feedback. You can read the community summaries from seven of the Phase 2 community discussions.

The responses that we received have helped us to think about potential drawbacks and create a set of important principles to remember. Below is a summary of our findings, including the five major concerns that we heard, and how those concerns have shaped our understanding of this project.

Conclusion and next steps
The report continues below with the other questions that we asked in Phase 2. Before we dive in, we want to explain what will happen next for the talk pages project.

This is the end of the 2019 Talk Pages Consultation. We have a direction for the product, and a set of principles that will help to guide the work. The project will be continued by the Wikimedia Foundation's Editing team. There's a lot for the team to do: develop a technical approach, work on user interface design, prioritize features, run usability tests, research workflows that surfaced during the consultation, define how to measure the results – and, of course, talk to and collaborate with all interested contributors.

It's very important to the team to continue to be transparent and open about what we're working on. We'll have lots of questions and ideas that we'll want to talk with you about. The main project page will be on Mediawiki.org at Talk pages project. We encourage you to put the Talk pages project on your watchlist, so you will see the updates and ideas in the coming months.

We deeply appreciate the attention and thought that you have all given to this consultation. We have learned a lot from this process, and we look forward to continuing to talk to you and work with you.

Question #2: Marking separate discussions
Question #2 was about creating a more structured definition of what counts as a single discussion, to make it possible to watchlist individual discussions on the page. It would also improve notifications, archiving and search. This could mean making changes to the wikitext conventions on a talk page. For example, we may create a new way that discussion headings look in wikitext, or a new link that you need to use to create, rename or split a thread.

Watching individual discussions is a longtime wish for a lot of people. There was general interest in improvements:

 [en] The ability to watchlist an individual section, and view its history separately as well, would be a huge improvement for busy pages like AN/I. Issues like moves, renames and splits don't seem insurmountable; let's see what WMF comes up with and test it on a few pages first. – Dlthewave, English Wikipedia

But the variations in the way that people use wikitext on talk pages will make it a difficult task:

 [zh] 但一些编辑喜欢用“ ”缩进，一些编辑则使用“ ”. 后者可以附带唯一ID，前者或会被视为页面内容（Content）的普通章节，可能有点问题. – 笔尖留痕, Chinese Wikipedia

 [en] Some editors like to indent with " " and some editors use " ". The latter can be accompanied by a unique ID, the former may be considered a normal part of the page content. This may be a bit problematic. – 笔尖留痕, Chinese Wikipedia

Some people expressed concern that watching individual sections of a page would reduce participation overall:

 [nl] Ik vind sommige discussies nu al moeilijk te vinden, dat wordt nog een stuk slechter als algemene discussiepagina's, zoals de kroeg, niet meer integraal op mijn volglijst verschijnen. De transparantie van Wikipedia is er niet bij gebaat als discussies zich in allerlei nisjes gaan afspelen, met twee, drie deelnemers. – RonnieV, Dutch Wikipedia

 [en] I already find some discussions difficult to find, which becomes even worse if general discussion pages, such as the pub, no longer appear in full on my watch list. The transparency of Wikipedia does not benefit if discussions start to take place in all sorts of niches, with two or three participants. – RonnieV, Dutch Wikipedia

Some people were skeptical about the idea:

 [en] Re-naming threads is frequent, and splitting et al at least occasional. I am somewhat against any change. If and only if it is, it would need to be made extremely user-friendly to do if altered from the current set-up. – Nosebagbear, English Wikipedia

 [en] People say they want this but they probably do not understand the issues. If someone complains about me at WP:ANI I might naively want to watch only the section where I was mentioned. However, that section might be removed and reposted at WP:AN as the more appropriate noticeboard. Or, the section might be collapsed or deleted and the content moved to an earlier section about the same underlying issue. If implemented, watching a section should be on a best-effort basis with no promises. – Johnuniq, English Wikipedia

The Editing team will be looking into the many different suggestions that people offered. Here are two of the suggestions:

 [en] One way I could see this working would be to include a random 128-bit identifier in each new section header. This ID could be used as a secondary anchor to the one generated from the displayed text (allowing edit summaries to link to it), and could also be used in a tagging system so that all edits to the section could be found at a special page (which could be linked from the header itself). This would resolve several different issues, including section linking on multilingual wikis and finding all edits to a particular section. – Jc86035, English Wikipedia

 [en] I use n:User:Gryllida/js/archive-talk.js and I think using something similar at other wikis would be a nice and simple way to go without the complexity of additional identifiers. – Gryllida, English Wikipedia

A number of people said that this concept is currently used on some wikis, using transclusions:

 [en] The best way to accomplish this currently is to have a page for each discussion, and transclude all the discussion pages onto a single main page. Commons does this with deletion proposals for example, and Wikidata does this for property creation proposals. On Wikisource we use this approach for transcluding works, but not for discussions. I think that this would be a good approach for accomplishing this particular goal, but it would have to be streamlined. – Beleg Tâl, English Wikisource

This comment recommends keeping human-readable links:

 [fr] Les hyperliens vers une discussion structurée doivent resté lisible par un humains par l'usage du # comme actuellement sous la forme de "Discussion:Titre de la page#Sujet de la discussion" et non sous la forme de lien url généré aléatoire comme les actuelles discussions structurée ; si besoin rajouter un identifiant final quand des discussions on le même sujet. Pourquoi pas prévoir une double identification des sujet discuter url id et lien lisible par un humain. – ParaBenT, French Wikipedia

 [en] Hyperlinks to a structured discussion must remain readable by humans by the use of the # as currently in the form of "Discussion:Page Title#Discussion Topic" and not in the form of randomly generated url link like the current Structured Discussions; if necessary add a final identifier when discussions on the same subject. Why not provide a double identification of the subject to discuss url id and link readable by a human. – ParaBenT, French Wikipedia

Question #3: Helping newcomers find the talk pages
Question #3 was about making the link to the talk page more visible, so that newcomers discover that talk pages exist. In user testing for this consultation, we asked 10 potential editors to find the article's discussion area. Only one person noticed the Discussion tab.

The responses were lukewarm about the possibility of moving the Discussion link somewhere else. Many people pointed out that the "Article" and "" tabs represent different pages, while the "", "", and "" tabs represent actions that you can take on those pages.

 [nl] Met de tabs links switch je tussen inhoud en overleg, met de andere tabs tussen verschillende functionaliteit van die gekozen optie. Ze meer bij elkaar zetten, lijkt me dat niet beter te maken. Hoe kleurrijker we de tabjes en andere snuisterijen maken, hoe meer het afleid van de inhoud van de encyclopedie. – RonnieV, Dutch Wikipedia

 [en] With the tabs on the left you switch between content and consultation, with the other tabs between different functionality of that chosen option. Putting them together more doesn't seem to make it better. The more colorful we make the tabs and other trinkets, the more distracting from the content of the encyclopedia. – RonnieV, Dutch Wikipedia

There was some interest in an annotation-style feature, to connect a conversation to a relevant part of the article. This isn't a feature that the team will be focusing on right now, but it's an interesting idea that may come back later.

 [cs] To mi připomíná možnost komentářů v různých dokumentech, kterou jsem navrhoval v průzkumu technických přání komunity a která mi byla zamítnuta pro velkou složitost :-) Ale ano, už jen to, kdyby u každého nadpisu byl odkaz [editovat / připomínkovat], který by vedl do diskuse na příslušnou sekci (nebo by ji vytvořil), pomohlo by to. Nevýhodou bude, pokud se změní nadpis, ale to by snad šlo částečně ošetřit nějakou trvalejší kotvou. – JAn Dudík, Czech Wikipedia

<hr style="border: 0;background:none;border-bottom: 1px dashed #ccc;" /> [en] This reminds me of the possibility of commenting in various documents that I proposed in the Community Wishlist Survey and which was rejected for being too complicated :-) But yes, only if there was an [edit / comment] link for each heading that would lead to the discussion on the relevant section (or would create it). The difficulty would be if the title were changed, but it might be partially mitigated with a more permanent anchor. – JAn Dudík, Czech Wikipedia

Question #4: Where to show discussion tools (namespaces)
Question #4 asked about the namespaces where discussion takes place. Many wikis have community discussion spaces in the project namespace ( or  ), rather than in a talk namespace (  or  ). The project namespace is often used for village pumps/cafés, noticeboards, and some workflows, such as Articles for deletion. The system will need to know which pages to display the new tools on. One possibility would be to move all discussion pages to a Talk namespace. Another possibility would be to use a magic word to enable talk page features on a non-Talk namespace.

Some people did not want to move all discussion pages to a Talk namespace, because the project pages sometimes need a talk page to talk about the workflow itself.

<blockquote style="background:white; padding:1em; border:1px solid #999; padding-left: 3em; text-indent: -2em;"> [en] Don't move all discussions to talk space! That would be extremely disruptive, especially where it's useful to have an official discussion plus a less-formal meta discussion (eg RfAs, arbcom proceedings). – Espresso Addict, English Wikipedia

<blockquote style="background:white; padding:1em; border:1px solid #999; padding-left: 3em; text-indent: -2em;"> [en] This sounds like a pipedream. Yeah i want that too, but there is 18 years of archives to think off and a gazillion tools to adapt. Doesn't sound realistic to me. – TheDJ, English Wikipedia

This response has a good summary of the issues:

<blockquote style="background:white; padding:1em; border:1px solid #999; padding-left: 3em; text-indent: -2em;"> [fr] Les discussions qu'on retrouve sur n'importe quel type de page peuvent effectivement donner une impression de désordre. Mais mettre de l'ordre peut avoir des inconvénients : Le plus simple serait, je pense, que le système ajoute les outils de discussion : Cette façon de faire serait, je pense, celle qui s'adapterait le mieux à toutes les situations. – O.Taris, French Wikipedia
 * la perte des liens vers les discussions ;
 * chambouler des choses imparfaites mais auxquelles les communautés sont habituées ;
 * où pourrait être discutée l'organisation de certaines pages de discussion ou pages de requêtes ? (actuellement, c'est dans les pages de discussion des pages de requête par exemple.)
 * 1) dans toutes les pages des espaces Discussion ;
 * 2) dans les pages des autres espaces contenant (au choix des développeurs) un mot clé, un mot magique ou un modèle appelant ces outils de discussion.

<hr style="border: 0;background:none;border-bottom: 1px dashed #ccc;" /> [en] The discussions found on any type of page can give an impression of disorder, but putting things in order can have disadvantages:


 * loss of links to discussions;
 * disrupt imperfect things that communities are used to;
 * where could we discuss the organization of some talk pages or request pages? (currently, it's in the talk page of the request page).

The simplest way would be, I think, that the system adds the discussion tools:


 * 1) in all Talk namespace pages;
 * 2) in pages of other namespaces containing (at the choice of the developers) a keyword, a magic word or a template calling these discussion tools.

This way of doing things would, I think, be the one that best fits all situations. – O.Taris, French Wikipedia

One conversation identified a problem with using magic words and some potential solutions:

<blockquote style="background:white; padding:1em; border:1px solid #999; padding-left: 3em; text-indent: -2em;">

[en] The immediate problem I see with setting or removing the talk-page-interface with magic words is that it opens us up to nuisance changes by vandals. I can't see any use case for a page to change back and forth, and there's a relatively small number of top-level pages that need this interface but aren't already in a talk namespace. Letting it be set by changing the content model seems an almost ideal solution. The big problem I see is if we want to make all RFAs or AFDs or such use that model too: we'd need some way to configure all pages matching "^Wikipedia:Articles_for_deletion/" and so on to default to the talk-page-interface. – Cryptic, English Wikipedia


 * [en] We could have a default based on the namespace, and allow a magic word with an edit filter to restrict addition or removal by non-confirmed or even non-extended-confirmed users. Alternatively, something like the titleblacklist, where admins can use regex to specify a group of pages, or list specific ones individually. – DannyS712, English Wikipedia

Another thoughtful take on the question:

<blockquote style="background:white; padding:1em; border:1px solid #999; padding-left: 3em; text-indent: -2em;"> [en] I think magic words would be a good workaround, but in general I think this should be restricted to article talk. Much of editorial space is built around having a rather vague distinction between talk and non-talk namespaces, and having to opt out so many pages would not be ideal. The main purpose of many of these changes seems to be ease of use for newcomers which is most useful on article talk; by the time new users are seriously contributing in editorial space, they should be familiar with WP:TPG and WP:TPHELP, diminishing the gains in editorial space. – Wugapodes, English Wikipedia

Question #5: History tradeoffs
Question #5 asked about the importance of seeing the history of an entire page, compared to seeing the history of a specific thread. Unstructured wikitext talk pages offer a history of the whole talk page. Flow shows a history for each thread, and a limited history for each page. It would be ideal if we could offer both for unstructured wikitext talk pages, but we aren't sure how to do that. Before we decide how to show the history, we need to understand the advantages and disadvantages.

People said that whole-page histories are helpful for getting a broad overview of the changes that have been made. They find this especially useful for moderation:

<blockquote style="background:white; padding:1em; border:1px solid #999; padding-left: 3em; text-indent: -2em;"> [en] On any page, we (vandalism checkers) need access to the complete page history. Thread histories would be nice, but pretty much worthless unless accurate, which means (due to edit conflicts) unless generated by the software. — Arthur Rubin, English Wikipedia

<blockquote style="background:white; padding:1em; border:1px solid #999; padding-left: 3em; text-indent: -2em;"> [en] My favorite example is the following: Admins, but not just admins, need to know many ongoing discussions. If an admin is away and off-wiki for a weekend and need to catch up, he or she might want to use a diff over a hundred or more versions on high-traffic talk pages such as admin incidents. This works only with one history for the whole page. – H-stt, English Wikipedia

<blockquote style="background:white; padding:1em; border:1px solid #999; padding-left: 3em; text-indent: -2em;"> [en] Individual threads is a nice to have. It's essential to be able to see the history of the whole page for eg vandalism reversion. – Espresso Addict, English Wikipedia

Others said that seeing the history of the entire talk page is necessary in some cases:

<blockquote style="background:white; padding:1em; border:1px solid #999; padding-left: 3em; text-indent: -2em;"> [en] I'm struggling to think of a use case where I'd need to see every edit of every discussion on a single page. If the discussion page history showed only the "highlights" - "User X started a thread entitled Y"; "User A merged threads B and C"; "User I archived thread J", etc. - that would surely be enough, with the individual threads having their own (full) history, linked from that talk page history overview. So I support the thread history approach. – Waggers, English Wikipedia

Focus was one of the main perceived advantages for seeing the history of a specific thread. People liked the idea of being able to track a specific conversation with less effort:

<blockquote style="background:white; padding:1em; border:1px solid #999; padding-left: 3em; text-indent: -2em;"> [es] Si tienes una discusión con uno o dos hilos, no creo que sea muy difícil encontrar lo que buscas. Pero con unas cuantas discusiones es una ventaja clara tener disponibles las modificaciones de una sola sección, simplemente porque no hay que ver todo de todo. Vaya, es muchísimo más fácil encontrar Venta Mina en un mapa de Siete Aguas que en un mapa de Eurasia. – B25es, Iberocoop

<hr style="border: 0;background:none;border-bottom: 1px dashed #ccc;" /> [en] If you have a discussion with one or two threads, I do not think it is very difficult to find what you are looking for. But for a few discussions, it is a clear advantage to have the changes to a single section available, simply because you do not have to see all of everything. Wow, it's much easier to find Venta Mina on a map of Siete Aguas than on a map of Eurasia. – B25es, Iberocoop

However, most people see the history for the whole page as the priority, if they needed to choose between the two approaches:

<blockquote style="background:white; padding:1em; border:1px solid #999; padding-left: 3em; text-indent: -2em;"> [en] I don't see a downside to discussion- or section-specific histories, but it would be a "would be nice"; full-page history really essential. As oversighters, we use it just about every time we use the suppression tool. – Risker, English Wikipedia

<blockquote style="background:white; padding:1em; border:1px solid #999; padding-left: 3em; text-indent: -2em;"> [de] Eine Versionsgeschichte nur eines Abschnitts würde ich begrüßen -- allerdings nur unter der Voraussetzung, dass die Gesamt-Geschichte weiterhin erhalten bleibt. – KaiMartin, German Wikipedia

<hr style="border: 0;background:none;border-bottom: 1px dashed #ccc;" /> [en] I would welcome a version history for only one section – but only on the condition that the overall history remains intact. – KaiMartin, German Wikipedia

This person brings a finer point to the tradeoff by highlighting how the ways in which talk pages can be edited should inform how we approach building tools intended to moderate and track those edits:

<blockquote style="background:white; padding:1em; border:1px solid #999; padding-left: 3em; text-indent: -2em;"> [fr] Il me paraît vraiment important de garder la possibilité de consulter l'historique dans son ensemble, donc je regretterais que l'on introduise un historique par section en enlevant la possibilité de consulter l'historique d'ensemble. Tant qu'il est possible d'écrire dans plusieurs sections de la page, il serait difficile d'avoir des historiques distincts par section. Or je regretterais d'être obligé, si je veux toucher à plusieurs sections, de faire plusieurs modifications. Il faut veiller à gérer la transition entre ancien mode / nouveau mode de discussion. – O. Morand, French Wikipedia

<hr style="border: 0;background:none;border-bottom: 1px dashed #ccc;" /> [en] It seems really important to me to keep the whole history, so I'd be sorry to introduce a section history that removes the ability to look at the overall history. As long as it's possible to write in several sections of the page, it would be difficult to have separate histories by section. But I'd regret being obliged, if I want to touch several sections, to make several edits. Care must be taken to manage the transition from old mode to new discussion mode. – O. Morand, French Wikipedia

Question #6: Metadata location
Question #6 was about the templates that some wikis put at the top of article talk pages. These may show instructions, warnings, or FAQs. They may hold page quality information, link to relevant WikiProjects, or identify past activities. Many new users are confused by finding non-discussion material at the top of an article talk page. It would be helpful to move some or all of that content somewhere else on the page, or under a different tab. We asked which templates were crucial to show on the discussion page, and which could move somewhere else.

The amount and type of metadata on talk pages varies significantly by wiki. There were significant concerns about the volume of the "clutter", especially at wikis that use the talk page to store extensive metadata. However, not everything at the top of a talk page is metadata. Some of it is useful information for people who were using the talk pages.

<blockquote style="background:white; padding:1em; border:1px solid #999; padding-left: 3em; text-indent: -2em;"> [en] This is a double-edged sword. Some of the templates (old GA reviews, WP project affiliations, etc...) are not needed for the average editor, but others (wp:paid) are critical, and should be on their own. Rather than moving to another page, I'd favour ranking each template into critical or non-critical, then minimizing the non-critical into a small icons like we have for GA/FA status, locked, etc... Editors that need to see it, can hover-over and click for details. – Ian Furst, English Wikipedia

The most popular recommendations were to offer another tab for storing metadata or to collapse the metadata by default. Another option is to build true support for metadata in MediaWiki core, which has been proposed in the past (T55508).

<blockquote style="background:white; padding:1em; border:1px solid #999; padding-left: 3em; text-indent: -2em;"> [en] I think a separate metadata page/tab makes a lot of sense. Seeing a bunch of these templates at the top of talk pages is something we've gotten used to, but when you step back and think about it, it's kind of a weird place to put them. I go to Talk:Cleopatra because I want to discuss some question or issue with the content of the article. Given that intent, how does it help me to know that Cleopatra is a level-4 vital article, or that it's a featured article, or that it was "Today's featured article" on June 1, 2019, or that it's of interest to these 13(!) WikiProjects, or to see the article's daily pageview stats? I just wanted to talk about the length of the intro. "Metadata" is a good description for most of these templates - and they would fit better on a separate page. I think they just ended up accumulating in talk pages because there was nowhere else to put them. – Colin M, English Wikipedia

<blockquote style="background:white; padding:1em; border:1px solid #999; padding-left: 3em; text-indent: -2em;"> [en] Instead of actually moving the templates, perhaps this could be implemented as a "show/hide" option in the interface. Users who work with wikiprojects etc. could set all pages to "show templates" by default. A special "override" tag could be added to important administrative notices, making them visible to all users. – Dlthewave, English Wikipedia