Talk pages consultation 2019/Phase 2 report/ja

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

はじめに
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 versus 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 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. 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:

and a minority of people who said that wikitext talk pages should be entirely replaced with something new:

Most responses were in the middle. There was broad general support for the hybrid approach that we proposed:

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.

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.

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
提案した製品設計にはおおむね賛同していただけてよかったです. しかしながら第2フェーズに期待したのは私たちの結論の評価以上のものでした. 批判や反対意見を聞いて、そこから学びたかったのです. この節ではあちこちの議論から、もっとも広く聞かれ、強く提言された心配ごとを取り上げます. それらの心配ごとにより、このプロジェクトに対する担当部署がどのように取り組み方を修正したか、ご説明します.

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.

結論と次の段階
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.

質問 #2: 議論の論点の切れ目を示す
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:

質問3: 編集初学者がトークページを探しやすくするには
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.

質問4: 議論ツールの表示場所 (名前空間)
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:

質問5: 変更履歴の折りあい
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:

質問6: メタデータの配置
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).