Talk pages consultation 2019/Phase 2 report/it
 | This page is obsolete. It is being retained for archival purposes. It may document extensions or features that are obsolete and/or no longer supported. Do not rely on the information here being up-to-date. See Talk pages project for the follow-up project. |
The 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 what problems 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, Peter Pelberg
Introduzione
Nella fase 1 della consultazione, abbiamo identificato due temi principali:
- Design chiaro e strumenti adeguati: In questo momento, le pagine degli articoli e le pagine di discussione sono molto simili nel loro aspetto e funzionalità. Questa somiglianza è fuorviante e rende più difficile per le persone imparare a usare correttamente le pagine di discussione.
- Funzionalità contro flessibilità: Il desiderio di miglioramenti della pagina di discussione non si limita ai nuovi collaboratori. In effetti, i contributori esperti sono quelli che sanno quanto siano inadeguati gli strumenti esistenti. Gli utenti esperti vogliono seguire una singola discussione in una pagina di discussione attiva e trovare discussioni facilmente e rapidamente, anche se le discussioni sono state spostate in un archivio. 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 stay consistent 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.
Summary of findings
On the matter of support and opposition to the proposed product direction: You can imagine a line representing people's feelings about making changes to talk pages. At one end of the line, some people feel that talk pages are perfect exactly the way that they are. Any problems that people have could be solved if other people would simply understand and follow the rules. At the other end, people feel that static wiki pages shouldn't be used to do the job of forum software. They think we should just switch to a discussion forum system, and build new habits and better workflows around that.
The product direction that we proposed is a compromise between those two positions. Unsurprisingly, people's reactions varied. There was a minority of people who said that talk pages should be left entirely unchanged:
[de]
Eine Wikiseite ist eine Wikiseite ist eine Wikiseite. Das große Problem von LQT und FLOW war die Einführung einer künstlichen Grenze zwischen Diskussionen und dem Wiki, es wurde eine Seite kreiert, die ein völlig anderes Look-and-Feel hatte als der komplette Rest des Wikiversums (die beiden Hintergrunddatenbankprojekte WD und Commons mal ausgenommen).— Sänger, Wikipedia in tedesco
A wiki page is a wiki page is a wiki page. The big problem with LQT and FLOW was the introduction of an artificial border between discussion and the wiki, creating a page that had a completely different look and feel than the rest of Wikipedia. — Sänger, Wikipedia in tedesco
[de]
Die "grenzenlose Flexibilität einer offenen Wikitext-Seite" ist exakt das, was nicht angetastet werden darf, weil sonst die ohnehin eingeschränkte Offenheit der Diskussion technisch noch weiter eingeschränkt wird.— Mautpreller, Wikipedia in tedesco
The "boundless flexibility of an open wkitext page" is exactly what must not be touched, because otherwise the already limited openness of discussion will be technologically limited even further. — Mautpreller, Wikipedia in tedesco
and a minority of people who said that wikitext talk pages should be entirely replaced with something new:
[en]
Wiki pages as a discussion forum are a failure, and quite frankly embarrassing, considering that proper tools for facilitating a discussion forum (i.e. forum software) have existed for decades. You now propose to pour a huge amount of work into making wiki pages function both as wiki pages and discussion forums. I guess you might succeed at it, but why reinvent the wheel?— Silver hr, Wikipedia in inglese
Le pagine Wiki come forum di discussione sono un fallimento, e francamente imbarazzanti, considerando che da decenni esistono strumenti adeguati per facilitare un forum di discussione (ovvero il software del forum). You now propose to pour a huge amount of work into making wiki pages function both as wiki pages and discussion forums. I guess you might succeed at it, but why reinvent the wheel? — Silver hr, Wikipedia in inglese
[en]
Really, this whole thing has badly needed repair since day one.— Rollo, Feedback individuale
Really, this whole thing has badly needed repair since day one. — Rollo, Feedback individuale
[en]
A design "on top of existing wikitext pages" is a pretty disappointing prospect, to be honest. If "replying, indentation and signatures" need to be improved, which I do not have any doubts about, then all of this should be handled by the software exclusively, without the possibility of interferences by users. Yes, this would break existing workflows much more than anything on top of wikitext pages, but otherwise we will not even remotely come close to a "discussion board" feeling for newbies.— MisterSynergy, Wikidata
A design "on top of existing wikitext pages" is a pretty disappointing prospect, to be honest. If "replying, indentation and signatures" need to be improved, which I do not have any doubts about, then all of this should be handled by the software exclusively, without the possibility of interferences by users. Yes, this would break existing workflows much more than anything on top of wikitext pages, but otherwise we will not even remotely come close to a "discussion board" feeling for newbies. — MisterSynergy, Wikidata
Most responses were in the middle. There was broad general support for the hybrid approach that we proposed:
[en]
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.— Dvorapa, Czech Wikipedia community summary
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. — Dvorapa, Czech Wikipedia community summary
[en]
Most people would welcome a better usability of talk pages. Signatures for instance could be added automatically, without relying on other users, or bots. Appropriately identing the paragraphs with colons is unnerving. There should be an 'answer' button below each post, other people's posts should be protected, and WYSIWYG editing on talk pages would be a good thing. Some people added their own experiences with ennumerating syntax, changing subject lines, and so on. Especially strong endorsement came from people who are active in introductory courses and OTRS. Most participiants opted for new and better tools, some even pressing for a complete software turnover, to get rid of dead wood. On the other hand en:Wikipedia:Flow is still in bad memory, having no remaining proponents at all.— MBq, German Wikipedia community summary
Most people would welcome a better usability of talk pages. Signatures for instance could be added automatically, without relying on other users, or bots. Appropriately identing the paragraphs with colons is unnerving. There should be an 'answer' button below each post, other people's posts should be protected, and WYSIWYG editing on talk pages would be a good thing. Some people added their own experiences with ennumerating syntax, changing subject lines, and so on. Especially strong endorsement came from people who are active in introductory courses and OTRS. Most participiants opted for new and better tools, some even pressing for a complete software turnover, to get rid of dead wood. On the other hand en:Wikipedia:Flow is still in bad memory, having no remaining proponents at all. — MBq, German Wikipedia community summary
[en]
Glad that the foundation finally accepts the need for autosigning on talkpages. Interesting to hear that newbies find it difficult to get to talkpages, but if we don't have to tell all newbies about the need for four tildes, maybe we can update some welcome messages to tell people how to get to article talkpages.— WereSpielChequers, Wikipedia in inglese
Glad that the foundation finally accepts the need for autosigning on talkpages. Interesting to hear that newbies find it difficult to get to talkpages, but if we don't have to tell all newbies about the need for four tildes, maybe we can update some welcome messages to tell people how to get to article talkpages. — WereSpielChequers, Wikipedia in inglese
[de]
Klar muss Wikipedia nutzerfreundlicher werden und mit der Zeit gehen. Hätte man in den 20er Jahren gesagt, "ein Automobil ist ein Automobil ist ein Automobil" hätten wir auch noch die Technik von vor 100 Jahren. Die Wiki-Technik hat sich seit 20 Jahren nur punktuell verändert, inzwischen werden aber ganz andere Anforderungen an benutzerfreundliche Internetseiten gestellt.— Berlinschneid, Wikipedia in tedesco
Chiaramente, Wikipedia deve diventare più user-friendly e al passo con i tempi. Se negli anni '20 si fosse detto che "un'automobile è un'automobile è un'automobile", avremmo ancora la tecnologia di 100 anni fa. La tecnologia Wiki è cambiata solo sporadicamente da 20 anni, ma nel frattempo vengono posti requisiti completamente diversi su siti Web intuitivi. — Berlinschneid, Wikipedia in tedesco
There was strong agreement that the existing talk page system is difficult for new users. Simple functions like replying, signing and positioning your post should be made easier.
[fr]
Le wikicode est génial, mais c'est une catastrophe du point de vue de l'expérience utilisateur (UX) pour la très grande majorité des utilisateurs. Il y a des gens très brillants, compétents dans la rédaction scientifique ou la vulgarisation qui abandonnent leurs projets d'édition dans Wikipédia en raison de son interface atypique (je peux témoigner là-dessus).— Mathieugp, Wikipedia in francese
Wikitext is great, but it is a disaster from the point of view of the user experience (UX) for the vast majority of users. There are some very bright people, skilled in scientific writing or popularization, who abandon their editing projects in Wikipedia because of its atypical interface (I can testify about that). — Mathieugp, Wikipedia in francese
There was also strong support for experienced users being able to opt out of the new design and tools, and keep editing the way that they're used to.
[en]
I like how "this new design will be a default experience that existing users can opt out of". Different editors have different levels of comfort regarding changes to software they regularly use. Having the option to opt out of the new interface would allow editors who prefer the improved interface to take advantage of the new features, while editors who do not think the changes are worthwhile can continue to use the interface that they are familiar with.— Newslinger, Wikipedia in inglese
I like how "this new design will be a default experience that existing users can opt out of". Different editors have different levels of comfort regarding changes to software they regularly use. Having the option to opt out of the new interface would allow editors who prefer the improved interface to take advantage of the new features, while editors who do not think the changes are worthwhile can continue to use the interface that they are familiar with. — Newslinger, Wikipedia in inglese
There was a wider range of opinions about the possibility of changes to wikitext conventions, which is understandable. It's hard for people to agree with changes that haven't been defined yet. There were many comments along these lines:
[en]
I do want to be able to watch a specific section and not be bombarded by updates every time a very large page like an ANI page gets edited. But I don't want to support any big changes without knowing what unforeseen ways they might affect things I already like.— Usedtobecool, Individual feedback on MediaWiki.org
I do want to be able to watch a specific section and not be bombarded by updates every time a very large page like an ANI page gets edited. But I don't want to support any big changes without knowing what unforeseen ways they might affect things I already like. — Usedtobecool, Individual feedback on MediaWiki.org
People also wanted to make sure that we understand the importance of keeping continuity with the mechanics of moderation and maintenance. For example, changes should be reflected in history pages, with a diff for every change. Changes should be reflected in a user's contributions. Admins and oversighters need to be able to revert, delete or suppress changes, on the level of an individual edit.
[en]
With respect to this new clearer design on top of existing wikitext talk pages, please ensure that every element of the checklist I drafted is included; aside from the obvious "must be in a public log", being able to delete/revision-delete/suppress is mandatory (think of the nasty things someone could write on a BLP talk page), and these edits need to show up in the CU log as well.— Risker, Wikipedia in inglese
With respect to this new clearer design on top of existing wikitext talk pages, please ensure that every element of the checklist I drafted is included; aside from the obvious "must be in a public log", being able to delete/revision-delete/suppress is mandatory (think of the nasty things someone could write on a BLP talk page), and these edits need to show up in the CU log as well. — Risker, Wikipedia in inglese
Aside from the expected high interest in auto-indent and signatures, people also expressed a lot of interest in being able to watch sections (specific discussions) and being able to receive notifications when someone replies in those discussions.
[en]
I also think it would be very worthwhile to make section watchlisting possible with either opt-in or opt-out. The editors who are most likely to use section watchlisting are also more likely than average to choose the opt-out option.— Tryptofish, Wikipedia in inglese
I also think it would be very worthwhile to make section watchlisting possible with either opt-in or opt-out. The editors who are most likely to use section watchlisting are also more likely than average to choose the opt-out option. — Tryptofish, Wikipedia in inglese
[pl]
Często zdarza mi się pisać coś w dyskusji użytkownika, który ma zwyczaj odpowiadania w swojej dyskusji, ale nie ma zwyczaju ping-owania rozmówcy przy odpowiedzi. Zależałoby mi na otrzymaniu powiadomienia o odpowiedzi, ale już niekoniecznie informacji, że odpowiedział komuś innemu (w innej sekcji), lub że ktoś inny zadał my kolejne pytanie. Funkcja taka przydałaby się też na stronach, gdzie prowadzonych jest wiele dyskusji w kilkudziesięciu sekcjach, podczas gdy mnie interesuje jedna z nich.— Ankry, Wikipedia in polacco
I often write something on a talk page of a user who usually responds on their own talk page, but doesn't usually ping the interlocutor when responding. I would like to receive a reply notification, but not necessarily information that they replied to someone else (in another section), or that someone else has asked another question. Such a function would also be useful on pages where many discussions are conducted in dozens of sections, while I am interested in one of them. — Ankry, Wikipedia in polacco
[en]
I understand that there may be some technical difficulties in doing this, and questions over whether to use the header or a permanent identifier. I want to say that if this is all too complicated, or so complicated that it would take like a year, I'll be ok with a messier version I can opt into that makes false positives and all that. The utility of just watchlisting certain sections would far outweigh the costs of having to manually check.— Prometheus720, Wikipedia in inglese
I understand that there may be some technical difficulties in doing this, and questions over whether to use the header or a permanent identifier. I want to say that if this is all too complicated, or so complicated that it would take like a year, I'll be ok with a messier version I can opt into that makes false positives and all that. The utility of just watchlisting certain sections would far outweigh the costs of having to manually check. — Prometheus720, Wikipedia in inglese
There was some interest in viewing section histories, but not at the expense of giving up being able to watch the whole page and view the page history.
[fr]
L'idée de pouvoir consulter l'historique d'une seule section est extrêmement intéressante. Elle facilitera grandement la tâche des contributeurs expérimentés, qui recherchent les origines de modifications problématiques.— Cedalyon, Wikipedia in francese
The idea of viewing the history of a single section is extremely interesting. It will greatly facilitate the work of experienced contributors, who are looking for the origins of problematic changes. — Cedalyon, Wikipedia in francese
On Russian Wikipedia, people pointed out that there's an existing userscript that does much of the proposed work:
[ru]
В рувики это уже не актуально, потому что есть скрипт Участник:Jack who built the house/Удобные дискуссии. Его бы в гаджет переделать и убрать некоторые баги.— VladXe, Wikipedia in russo
In ruwiki, this is no longer relevant, because there is a script -- User:Jack who built the house / Convenient Discussions . [This project] would be a remake of the gadget and remove some bugs. — VladXe, Wikipedia in russo
The Convenient Discussions gadget by Jack who built the house is a great model. It is a major inspiration for the new product direction. This opt-in userscript adds a large set of new features that make wiki talk pages easier to read and participate in, including reply links, indentation, tracking which comment is a reply to another, and single-section watchlisting. The tool is currently only available on Russian Wikipedia.
The Editing team is definitely going to learn a lot from User:Jack who built the house's work. If you want to read more about the tool in English, we have a Convenient Discussions notes page on MediaWiki.org, with some screenshots and information.
Major concerns and core principles
It was good to see that there was general support for the proposed product direction. However, we wanted more from Phase 2 than just validating our conclusions. We wanted to hear criticisms and objections, and learn from them. This section is about the most common and most strongly expressed concerns across the discussions. We also describe how those concerns changed the way that we plan to approach this project.
Forum or workspace
Talk pages exist in a variety of namespaces on wiki. Each context has a distinct purpose that contributors have defined and agreed upon over time. In Phase 2, contributors emphasized these distinctions.
[en]
Wikis are tools designed to capture knowledge with the least possible friction, not necessarily to have long conversations...we have separate pages specific for that purpose, but these pages are also given functions in addition to just threaded conversation. That's why in my comment above I distinguished between project space, which do have more forum-like dynamics, and Talk pages which are often much closer to traditional wiki-style collaboration.— Diego Moya, Feedback individuale
Wikis are tools designed to capture knowledge with the least possible friction, not necessarily to have long conversations...we have separate pages specific for that purpose, but these pages are also given functions in addition to just threaded conversation. That's why in my comment above I distinguished between project space, which do have more forum-like dynamics, and Talk pages which are often much closer to traditional wiki-style collaboration. — Diego Moya, Feedback individuale
Contributors drew particular attention to the use of article talk pages. Talk pages places for contributors to work together and to discuss changes to the corresponding content pages. These talk pages are not, and should not become, catch-all discussion forums to chat about the subject of the article. This concern was common in conversations about making talk pages more visible and accessible to people who use them infrequently, and who might arrive with their own expectations for how these pages are used:
[en]
More feedback is good but we do need to explain the purpose of Talk: to new commentators, and to clarify that it's not a social medium for venting our POV about the subject of the article.— Certes, Wikipedia in inglese
More feedback is good but we do need to explain the purpose of Talk: to new commentators, and to clarify that it's not a social medium for venting our POV about the subject of the article. — Certes, Wikipedia in inglese
[en]
There's a fundamental problem that readers-who-are-not-editors are likely to assume (based on other internet venues) that the talk page is intended as a discussion forum, and moreover (having never tried to edit) will find it difficult to understand their actual purpose. If people are encouraged to participate, they are likely to feel discouraged if their desired form of participation is unwelcome – and doubly discouraged if they manage to raise an appropriate query but fail to receive any response.— Espresso Addict, Wikipedia in inglese
There's a fundamental problem that readers-who-are-not-editors are likely to assume (based on other internet venues) that the talk page is intended as a discussion forum, and moreover (having never tried to edit) will find it difficult to understand their actual purpose. If people are encouraged to participate, they are likely to feel discouraged if their desired form of participation is unwelcome – and doubly discouraged if they manage to raise an appropriate query but fail to receive any response. — Espresso Addict, Wikipedia in inglese
[en]
Giving more prominence to a tab that the thoughtful can find relatively easily runs the risk of encouraging unfocused posts, blogging, soapboxing to the extent that Wikipedia could become seen as a discussion forum.— Dreamwoven, Wikidata
Giving more prominence to a tab that the thoughtful can find relatively easily runs the risk of encouraging unfocused posts, blogging, soapboxing to the extent that Wikipedia could become seen as a discussion forum. — Dreamwoven, Wikidata
Comments like these highlight something fundamental about article talk pages: they are workspaces. The purpose of article talk pages is for editors to work together to improve articles. The team recognizes that the software needs to promote these productive use cases. To ensure this, the team will watch how their changes affect people's use of talk pages, especially as more people – with less experience – use them. It is one thing to make certain workflows "easier" (i.e., replying to comments, indenting, and signing your name), but it is another to make sure those changes amount to contributors working together more effectively. We will talk about some initial ideas for measuring this impact below and at Talk pages project.
Una pagina wiki è una pagina wiki
Another theme that came up in the Phase 2 conversation is the question of how to understand simplicity and complexity. Some people said that this project would interfere with the simplicity of the wiki software. This was expressed by several people as "a wiki page is a wiki page". Every page starts the same way. Every page begins as an empty sheet of paper, whether the page will be used for a Wikipedia article, a discussion, or a list of instructions. People who already know how to edit articles don't have to learn new software tools to join a discussion.
[de]
Im Anschluss an ein bekanntes Diktum von Gertrude Stein: Ein Wiki ist ein Wiki ist ein Wiki, und das gilt auch für die Diskussionsseiten.— Aschmidt, Wikipedia in tedesco
Following a well-known dictum by Gertrude Stein: A wiki is a wiki is a wiki, and that applies to the discussion page, too. — Aschmidt, Wikipedia in tedesco
[en]
It appears the team is still in the mindset of building talk page features. I think it may help if you can think from the viewpoint that "a page is a page". You're not building talk page features, you're building page features. In some ways it narrows down the options that make sense, and in some ways it may make some of the issues vanish.— Alsee, Wikipedia in inglese
It appears the team is still in the mindset of building talk page features. I think it may help if you can think from the viewpoint that "a page is a page". You're not building talk page features, you're building page features. In some ways it narrows down the options that make sense, and in some ways it may make some of the issues vanish. — Alsee, Wikipedia in inglese
[de]
Für mich gibt es hier eigentlich nur eine Frage: Wird das offene, nicht eingegrenzte Diskutieren erleichtert oder erschwert? Alles, was die Diskussion durch irgendwelche Formalisierungen, Konventionen, Ausschlüsse etc. zusätzlich erschwert, sollte grundsätzlich unterbleiben. Alles, was dies erleichtert, sollte umgesetzt werden. Absolut tabu sollten alle technischen Restriktionen welcher Art auch immer sein.— Mautpreller, Wikipedia in tedesco
For me, there is really only one question: Is the open, unrestricted discussion made easier or more difficult? Anything that further complicates the discussion by any formalizations, conventions, exclusions, etc. should be avoided in principle. Everything that makes this easier should be implemented. Absolutely taboo should be all technical restrictions of whatever kind. — Mautpreller, Wikipedia in tedesco
[fr]
Je doute que l'outil créé soit plus simple pour répondre étant donné que le système actuel est on ne peut plus simple.— O.Taris, Wikipedia in francese
Dubito che lo strumento che verrà creato renderà più semplice la risposta, poiché l'attuale sistema non potrebbe essere più semplice. — O.Taris, Wikipedia in francese
The definition of "simple" and "easy" that people are using here is that the system is simple if you can type in an empty edit window, with a minimum of links, buttons, clicks and taps. If you want to rearrange a discussion, you open the edit window, select the wikitext, cut it, paste it in a different place, and hit the Pubblica le modifiche button. For experienced contributors, this is indeed simple, because it's the same way that it works on article pages, and they've done it hundreds of times before. How to do this is already inside their heads. If the system changes so that you have to click a link next to the section you want to move, and then type into a little pop-up form to say where you want it to go, that would be adding extra complexity to the process. How to use the new tool is not already inside their heads.
In an open wikitext field, all of the knowledge about how to use it has to be inside your head, because the software isn't giving you many clues about how to interact with the page. For the less experienced contributor, a blank wikitext field is not simple at all. And understanding what to do on a talk page is important, because there are a lot of differences between an article page and a talk page.
Imagine what would happen if someone followed the typical talk page rules in a Wikipedia article:
- If you're adding a new section to an article, always add that section to the bottom of the page.
- Sign and date the content that you add to the article.
- Don't change content that someone else wrote, except under very unusual circumstances.
- Once you post some text in an article, don't change it. If you want to clarify or change what you added to the page, you should write a new paragraph.
- If you disagree with something that another person wrote, write your objections and questions directly below what they wrote, and add a colon to visually separate your contribution from theirs.
- If it's a long article with a lot of sections, it's okay to remove sections that haven't been edited in a long time, and paste them into a separate sub-page.
Experienced contributors wouldn't even think of behaving that way on an article page, even though there are no technical constraints in the software to stop an editor from doing this. Each person has to learn the cultural conventions and taboos, often by making mistakes and getting an exasperated response from someone who thinks it's simple.
When people have learned how to edit a Wikipedia article page, they still don't have the knowledge and skills that they need in order to contribute successfully on a talk page. They need to learn how to use the same software differently. The current software doesn't help them understand that. We're requiring them to have these rules "inside their heads", instead of making those rules plain in the software. This can be frustrating and intimidating. A wiki page is not a wiki page, if you have to learn how to use it twice.
But there is a very important concern that's behind the "wiki page is a wiki page" concept, which we'll talk about in the next section: the importance of being able to get the job done.
Mastery and fine control
For experienced contributors, having that knowledge and expertise in your head is satisfying. That expertise helpful when you need to do something unusual or complex on a talk page. A typical content contributor uses talk pages once in a while, but doesn't need to do anything fancy with them. Experienced contributors, like admins or people involved in moderation workflows, need to do a lot of special functions: closing and summarizing a discussion, transcluding subpages on a noticeboard, setting up an arbitration page with separate headings for each participant, or just cleaning up something strange on the page.
These moderation actions require a level of fine control over the contents of the page. Having to use a "simplified" tool could get in the way. People who have mastered the current system already know exactly what they need to do to achieve their goals. They just need to get into the wikitext and do it. People don't want to be stopped from doing something complex to make things easier for someone else. That just keeps them from getting their work done.
This idea needs to be a core principle of our work on this talk page project: As we make changes, the person who has mastered the system has to retain the fine control that they need to get the job done.
Templates, transclusion and bots
One theme that came up in Phase 2 was a caution not to disrupt the workarounds that communities have painstakingly developed.
[nl]
In de richting zie ik wel wat, maar ik zie twee gevaarlijke opmerkingen: het verplichte gebruik van de nieuwe tools om een discussiedraadje te starten én om er eentje te verplaatsen. Velen hier maken gebruik van een bot om afgesloten discussies te laten verplaatsen naar archiefpagina's. Dat moet echt mogelijk blijven.— RonnieV, Wikipedia in olandese
I see something in the direction, but I see two dangerous comments: the obligatory use of the new tools to start a discussion thread and to move one. Many here use a bot to move closed discussions to archive pages. That must remain possible. — RonnieV, Wikipedia in olandese
[en]
Watchlisting discussions - this is a solved problem. It's already possible to just make a new page for each discussion and transclude it. Changes to end user syntax are not needed. This is current practice on many, but not all, en-wp maintenance boards and should simply be adopted more widely - all that's actually needed is to change the implementation of the " " button from new section to new transclusion. Done.— Samsara, Wikipedia in inglese
Watchlisting discussions - this is a solved problem. It's already possible to just make a new page for each discussion and transclude it. Changes to end user syntax are not needed. This is current practice on many, but not all, en-wp maintenance boards and should simply be adopted more widely - all that's actually needed is to change the implementation of the " " button from new section to new transclusion. Done. — Samsara, Wikipedia in inglese
The reason why communities have created these complex hacks and workarounds is because MediaWiki software doesn't offer the features that people need. Community-created bots are a symptom of the insufficiency of the software. They are not necessarily the best cure for it.
That said, it's important to the team working on this project to respect the function of the bots, templates and other workarounds. These tools make many workflows possible, and we are not dismissing them. We don't want to disrupt existing solutions unless we offer features that do the same job, even if it's not in exactly the same way.
Lowering barriers to participation
Finally, there were some concerns about whether the proposed changes would attract promising new contributors.
[de]
Wikipedia ist einfach, ein klein wenig muss man sich überall mit den Verhältnissen auseinandersetzen. Wer das nicht kann oder will ist für Wikipedia zu doof, und für Diskussionsseiten erst recht.— Cimbail, Wikipedia in tedesco
Wikipedia is simple; but you do have to make a little effort to come to grips with the various circumstances. Someone who is unable or unwilling to do that is too stupid for Wikipedia, and especially for the talk pages. — Cimbail, Wikipedia in tedesco
[en]
Sorry to be a wet blanket but the last thing the community needs is comments from people who cannot find the talk page.— Johnuniq, Wikipedia in inglese
Sorry to be a wet blanket but the last thing the community needs is comments from people who cannot find the talk page. — Johnuniq, Wikipedia in inglese
[de]
Wer bei diesem Projekt Hand anlegen will, muss (oder sollte) sich früher oder später sowieso mit der Wiki-Technik auseinandersetzen. Zudem sehe ich in dieser "Kompliziertheit" (?) der Wiki-Struktur in gewissermassen auch einen indirekten Spam-Schutz.— SwissChocolateSC, Wikipedia in tedesco
Anyone who wants to get involved in this project must (or should) deal with wiki technology sooner or later anyway. Furthermore, to some extent I see this "complexity" (?) of the wiki structure as indirect spam protection. — SwissChocolateSC, Wikipedia in tedesco
[en]
People, who are unable to find a link labeled "discussion", will never become useful contributors to an encyclopedia. Some people simply are not cut to be Wikipedians. In fact, most people are not cut to be Wikipedians. Even more: Only very few bring the personality and the intrinsic motivation to be volunteers in the projects.— h-stt, Wikipedia in inglese
People, who are unable to find a link labeled "discussion", will never become useful contributors to an encyclopedia. Some people simply are not cut to be Wikipedians. In fact, most people are not cut to be Wikipedians. Even more: Only very few bring the personality and the intrinsic motivation to be volunteers in the projects. — h-stt, Wikipedia in inglese
The suggestion that we should intentionally keep a confusing software interface to discourage people from contributing to Wikipedia and other projects is quite a radical idea. It is counter to both the principles of good software design and the principles of the movement.
For new users, the amount of effort that they're willing to invest in learning a system increases as they start to find value in their participation. If they encounter a frustrating or confusing blocker early on, when they aren't invested as much in the system, then they're much more likely to give up. A confusing talk page design is likely to weed out people with value to add. These people can think of many valuable ways to spend their time rather than wrestle with our interface.
But, these comments highlight an important principle that we agree with: we don't want to design a talk page system that generates useless chatter that harms contributor productivity. The team can't just have "more conversation" as a goal, measured by or the number of posts or the number of people posting. We also have to look at the quality and outcomes of the conversations that people are having. One way to do that is to look at how many threads get replies. Another way is to see whether conversations successfully "complete the loop": Person #1 asks a question, Person #2 responds, and Person #1 comes back to read the answer and improves the page. Another is to look at the revert and deletion rates on talk pages. We'll have to do a variety of tests and get a lot of feedback, to make sure that we're building a system that promotes useful contributions.
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 Progetto pagine di discussione. We encourage you to put the Progetto pagine di discussione 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.
Grazie.
Further discussion on questions 2 to 6
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, Wikipedia in inglese
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, Wikipedia in inglese
But the variations in the way that people use wikitext on talk pages will make it a difficult task:
[zh]
但一些编辑喜欢用“：”缩进，一些编辑则使用“*”。后者可以附带唯一ID，前者或会被视为页面内容（Content）的普通章节，可能有点问题。— 笔尖留痕, Chinese Wikipedia
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, Wikipedia in olandese
I already find some discussions difficult to find, which becomes even worse if general discussion pages, such as the Village pump, 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, Wikipedia in olandese
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, Wikipedia in inglese
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, Wikipedia in inglese
[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, Wikipedia in inglese
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, Wikipedia in inglese
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, Wikipedia in inglese
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, Wikipedia in inglese
[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, Wikipedia in inglese
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, Wikipedia in inglese
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
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 rester lisibles par un humain 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ées ; si besoin rajouter un identifiant final quand des discussions ont le même sujet. Pourquoi pas prévoir une double identification des sujets discutés : URL-ID et lien lisible par un humain.— ParaBenT, Wikipedia in francese
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 have the same name. Why not provide a double identification of the subject to discuss: url-id and link readable by a human. — ParaBenT, Wikipedia in francese
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 "Discussione" tabs represent different pages, while the "Leggi", "Modifica", and "Cronologia" 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, Wikipedia in olandese
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, Wikipedia in olandese
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, Wikipedia in ceco
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, little help would be 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, Wikipedia in ceco
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 (Project: or Wikipedia:), rather than in a talk namespace (Project talk: or Wikipedia talk:). 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.
[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, Wikipedia in inglese
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, Wikipedia in inglese
[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, Wikipedia in inglese
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, Wikipedia in inglese
This response has a good summary of the issues:
[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 :
- 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.)
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.
- dans toutes les pages des espaces Discussion ;
- 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.
— O.Taris, Wikipedia in francese
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:
- in all Talk namespace pages;
- 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, Wikipedia in francese
One conversation identified a problem with using magic words and some potential solutions:
[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, Wikipedia in inglese
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, Wikipedia in inglese
- 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, Wikipedia in inglese
Another thoughtful take on the question:
[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, Wikipedia in inglese
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, Wikipedia in inglese
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:
[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, Wikipedia in inglese
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, Wikipedia in inglese
[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, Wikipedia in inglese
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, Wikipedia in inglese
[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, Wikipedia in inglese
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, Wikipedia in inglese
Others said that seeing the history of the entire talk page is necessary in some cases:
[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, Wikipedia in inglese
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, Wikipedia in inglese
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:
[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
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:
[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, Wikipedia in inglese
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, Wikipedia in inglese
[de]
Eine Versionsgeschichte nur eines Abschnitts würde ich begrüßen -- allerdings nur unter der Voraussetzung, dass die Gesamt-Geschichte weiterhin erhalten bleibt.— KaiMartin, Wikipedia in tedesco
I would welcome a version history for only one section – but only on the condition that the overall history remains intact. — KaiMartin, Wikipedia in tedesco
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:
[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, Wikipedia in francese
It seems really important to me to keep the whole history, so I would regret it if a section history was introduced but removed 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, Wikipedia in francese
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.
[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, Wikipedia in inglese
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, Wikipedia in inglese
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 (phab:T55508).
[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, Wikipedia in inglese
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, Wikipedia in inglese
[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, Wikipedia in inglese
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, Wikipedia in inglese