Talk pages consultation 2019/Phase 2 report/th

การปรึกษาหารือเกี่ยวกับหน้าพูดคุย พ.ศ. 2562 (TPC) ได้มาถึงจุดสิ้นสุดของระยะที่ 2, ระยะสุดท้ายของการปรึกษาหารือทั่วโลกของมูลนิธิวิกิมีเดีย

ในระยะที่ 1, เราสอบถามผู้สนับสนุนว่าเขาใช้หน้าพูดคุยอย่างไรและอะไรคือปัญหาที่เขาพบเจอ รายงานระยะที่ 1, เผยแพร่ในเดือน พฤษภาคม, เสนอทิศทางให้มีผลิตภัณฑ์ใหม่สำหรับโครงการที่กำลังจะเกิดขึ้น, และโพสต์คำถามเฉพาะสำหรับระยะที่ 2 รายงานฉบับนี้, เผยแพร่ในเดือนสิงหาคม, สรุปว่าสิ่งใดที่ผู้คนพุดถึงและสิ่งใดที่เราเรียนรู้ระหว่างระยะที่ 2, และอธิบายแผนสำหรับปีที่กำลังจะมาถึง
 * โดยทีมปรึกษาหารือหน้าพูดคุย: Danny Horn, Benoît Evellin, Sherry Snyder, Thomas Meadows, Peter Pelberg

Introduction
ในระยะที่ 1 ของการปรึกษาหารือ, เราระบุสองธีมหลัก:


 * ดีไซน์ที่ชัดเจนและเครื่องมือที่เหมาะสม : ขณะนี้ หน้าบทความและหน้าพูดคุยมีความคล้ายกันอย่างมากในสิ่งที่ปรากฏและการดำเนินการ ความคล้ายคลึงกันดังกล่าวทำให้เกิดความสับสน, และทำให้เกิดความลำบากมากขึ้นสำหรับผู้ที่เรียนรู้วิธีในการใช้หน้าพูดคุยอย่างถูกต้อง
 * คุณสมบัติเทียบกับความยืดหยุ่น : ความปรารถนาในการปรับปรุงหน้าพูดคุยไม่ได้จำกัดเฉพาะผู้ร่วมให้ข้อมูลใหม่ ในความเป็นจริงผู้มีประสบการณ์เป็นผู้ที่รู้ว่าเครื่องมือที่มีอยู่ไม่เพียงพอจริง ๆ ผู้ใช้ที่มีประสบการณ์ต้องการติดตามการสนทนาเดี่ยวในหน้าพูดคุยที่ใช้งานอยู่และเพื่อค้นหาการสนทนาอย่างง่ายดายและรวดเร็วแม้ว่าการสนทนาจะถูกย้ายไปยังที่เก็บถาวร เพื่อให้คุณลักษณะเหล่านี้ ระบบต้องสามารถบอกได้ว่า "การสนทนา" คืออะไร – ส่วนที่เฉพาะเจาะจงของหน้านี้เป็นการสนทนาเดียวและมันแยกจากการแก้ไขอื่น ๆ ในหน้าเดียวกัน ที่อาจต้องทำการเปลี่ยนแปลงบางอย่างที่จำกัดความยืดหยุ่นของหน้าเปิด wikitext

ด้วยธีมเหล่านั้นในใจ เราได้เสนอทิศทางผลิตภัณฑ์ต่อไปนี้เพื่อให้ Editing team ของมูลนิธิวิกิมีเดียเพื่อดำเนินการ:

ควรปรับปรุงหน้าพูดคุยของ Wikitext และจะไม่ถูกแทนที่

เราจะสร้างดีไซน์ใหม่ที่บนหน้าพูดคุย Wikitext ที่เปลี่ยนรูปลักษณ์เริ่มต้นของหน้าและเสนอเครื่องมือสำคัญ การออกแบบใหม่นี้ควรสื่อสารกับผู้ใช้ว่านี่ไม่ใช่หน้าเนื้อหาและช่วยให้ผู้ใช้โต้ตอบกับเครื่องมือได้อย่างเหมาะสม ซึ่งควรรวมถึงสัญญาณที่ชัดเจนสำหรับวิธีการเริ่มการสนทนาใหม่และวิธีตอบกลับการสนทนาที่มีอยู่หรือข้อความเฉพาะภายในการสนทนานั้น ควรเพิ่มลายเซ็นโดยอัตโนมัติและวางข้อความในลำดับการซ้อนที่ถูกต้อง

เพื่อให้สอดคล้องกับเครื่องมือที่มีอยู่ การออกแบบใหม่นี้จะเป็นประสบการณ์เริ่มต้นที่ผู้ใช้ปัจจุบันสามารถยกเลิกได้ ผู้ใช้ควรเก็บมุมมองที่พวกเขามีอยู่ในปัจจุบัน และทำงานใน wikitext แทนที่จะใช้เครื่องมือใหม่

อย่างไรก็ตามเพื่อสร้างฟีเจอร์ที่ผู้มีประสบการณ์ต้องการความช่วยเหลือ อาจมีการเปลี่ยนแปลงเล็กน้อยในการประชุมและแนวทางปฏิบัติของ Wikitext ความตั้งใจของเราคือทำการเปลี่ยนแปลงเมื่อเขาได้เชื่อมต่อกับคุณสมบัติที่ผู้ร่วมให้ข้อมูลพบว่ามีประโยชน์

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
ในเรื่องของการสนับสนุนและคัดค้านทิศทางของผลิตภัณฑ์ที่เสนอ: คุณสามารถจินตนาการถึงแนวที่แสดงถึงความรู้สึกของผู้คนเกี่ยวกับการเปลี่ยนแปลงที่หน้าพูดคุย ที่ปลายด้านหนึ่งของบรรทัด บางคนรู้สึกว่าหน้าพุดคุยเป็นสิ่งที่สมบูรณ์แบบอย่างที่เขาเป็น ปัญหาใด ๆ ที่ผู้คนสามารถแก้ไขได้ถ้าคนอื่นจะเข้าใจและทำตามกฏ ที่ปลายอีกด้านหนึ่ง ผู้คนรู้สึกว่าหน้าวิกิคงที่ไม่ควรใช้ในการทำงานของซอฟต์แวร์ฟอรั่ม พวกเขาคิดว่าเราควรเปลี่ยนไปใช้ระบบกระดานสนทนาและสร้างนิสัยใหม่และปรับปรุงกระบวนการทำงานให้ดีขึ้น

ทิศทางผลิตภัณฑ์ที่เราเสนอคือการประนีประนอมระหว่างทั้งสองตำแหน่ง ปฏิกิริยาของผู้คนแตกต่างกันไปอย่างแปลกใจ มีแค่คนกลุ่มน้อยที่พูดว่าหน้าพูดคุยควรจะไม่เปลี่ยนแปลงโดยสิ้นเชิง:

และคนกลุ่มน้อยที่พูดว่าหน้าพูดคุยของ wikitext ควรถูกแทนที่ด้วยสิ่งใหม่ทั้งหมด:

คำตอบส่วนใหญ่อยู่ตรงกลาง มีการสนับสนุนทั่วไปอย่างกว้างขวางสำหรับวิธีไฮบริดในสิ่งที่เราเสนอ

มีข้อตกลงที่ชัดเจนว่าระบบหน้าพูดคุยที่มีอยู่เป็นเรื่องยากสำหรับผู้ใช้ใหม่ ฟังก์ชั่นที่เรียบง่าย เช่น การตอบกลับ การลงชื่อและการวางตำแหน่งโพสต์ของคุณควรทำให้ง่ายขึ้น

นอกจากนี้ยังมีการสนับสนุนจำนวนมากจากผู้ใช้ที่มีประสบการณ์ที่จะไม่เลือกใช้ดีไซน์และเครื่องมือใหม่นี้ และยังคงใช้วิธีแก้ไขที่พวกเขาคุ้นเคย

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:

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.

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.

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.

On Russian Wikipedia, people pointed out that there's an existing userscript that does much of the proposed work:

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.

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:

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.

A wiki page is a wiki page
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.

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 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.

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.

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 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:

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

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

Some people were skeptical about the idea:

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

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

This comment recommends keeping human-readable links:

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.

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.

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.

This response has a good summary of the issues:

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

Another thoughtful take on the question:

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:

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

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:

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

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:

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.

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).