Talk pages consultation 2019/Phase 1 report/ja

2019年トークページの協議 (TPC) は第1フェーズを終了しました. ウィキトークページを投稿者がどう使っているか、また皆さんが経験した問題をグローバルなコミュニティと協議しました. このレポートでは皆さんの発言と私たちの学びをまとめ、プロジェクトの方向性の提案ならびに第2フェーズ用にいくつかの設問を提示しています.


 * 文責：トークページ協議チーム一同：Danny Horn、Benoît Evellin、Sherry Snyder、Thomas Meadows、Marshall Miller. 

はじめに
ウィキテキスト版トークページはソフトウェアの産物ではありません. さまざまな文化が持ち込まれ、編集初心者を煩わせ、熟練した編集者はときに戸惑うことがあります. 返信のインデントを正しく調整するにはコロンの数が合っていないとだめだし、署名はチルダ記号で付け、参加しているセクションではなくトークページ全体を見通すべきで、簡単に返信できるリンクはない – 一方ではこれらの点は誰にとっても面倒です.

その他方で、ウィキテキストだからこそ、うまく機能する点もたくさんあります. 何も書いてない編集ウィンドウを開いた人々は、非常に柔軟で適応性のあるテンプレートや技術を発明する自由を得てきました. 会話の内容は誰からもどの段階でも見えるようになっています. 編集差分や昔の改訂記録にリンクを張ると、そのページで行われた活動の内容やいつ、誰が行ったか確認できます. 15年間にわたり、百科事典の記事の共同編集を100万件単位で補助してきた機能性は、簡単に終わりにすることはできないはずです.

ウィキメディア財団製品チームが以前、開発に取り組んだオンウィキのコミュニケーション用ツールにはLiquidThreads (2006年着手) と Flow/Structured Discussions (2012年着手) が含まれます. これら2つのプロジェクトは両方とも多くのウィキで問題なく使用されている反面、どちらも批判も非常に多く浴び、最大のウィキ群ではまだ広く支持されないままです.

貢献者なら、だれでもウィキ上でお互いに連絡を取り合ってもらいたいと考えています. 質問をしたり見解の違いを調整したり、プロジェクトの企画や意思決定をするためです. コンテンツの奥行きも品質も、私たちのコミュニティの健全性も、コミュニケーションが重要な要素です. すべての知識の総計を自由に共有するという私たちの目標達成には、このプロジェクトは不可欠です.

トークページの協議は2019年3月に始め、20件のウィキと利用者グループ空間で第1フェーズの協議をグローバルに催しました. これには15言語のウィキペディアに加え、コモンズ、ウィキデータ、ウィクショナリー2件、さらに利用者と面談を行いました. それぞれの議論は各コミュニティでメンバーがまとめて、担当のTPCチームではウィキ上のすべての議論を読んできました. 同チームはまたUserTesting.comでユーザーテストを2回、実施し、ウィキペディアはよく読むけれど、やり方が分からないせいで投稿したことがない利用者を対象にしました.

第1フェーズは4月末に終了、このページのレポートは5月に公表しました. 発見のまとめ、プロジェクトの方向性の提案と、第2フェーズ用の質問リストを以下に示しました. その後に、協議と利用者テストの結果を長文で詳しくご紹介しています.

基本
ウィキテキスト版トークページの改善で必要と皆さんが共通して同意したのは3点あり、返信とインデント、署名でした. これら基本のしくみは、新人利用者にとってはわかりにくいし、やる気を失わせる要素です. インデントと署名は、たとえ経験が長い利用者でも、間違えやすいのです. トークページの改善には返信がしやすく、インデントと署名を自動化する使いやすいツールを追加しなければなりません. (以下の#インデント、#返信、#署名節もご参照ください. )

経験の長い貢献者
非常に活発で複雑な議論やワークフローに参加する貢献者はウィキテキスト形式で構造化されていない会話ページを、オープンで柔軟だと支持しています. これらの人々にとって、ウィキテキスト形式のページのオープンさは自由そのものです. その場のニーズに応じて議論やページの構造を変えることが可能だからです. 既存のウィキテキスト形式の継続を強く望んでいます. Flowを使用してきた場合を含め、多くのウィキで編集者がこの見解に同意しています. (下記の#安定性、#ウィキテクスト節もご参照ください. )

経験の長い貢献者がトークページに追加してみたいと思う他の機能がたくさんあります.
 * 特定の議論をウォッチする機能. これにより、利用者は記事やトークページへの全ての編集について通知されるのではなく、1つの議論を見て回ることができます. (#ウォッチリスト)
 * もっと安定的に過去ログ化と検索ができる機能があれば、利用者がもっと簡単に特定のトピックに関する過去の会話を探しやすい. (#過去ログ化と#検索節もご参照ください. )
 * より一貫性のある通知（ping）機能があれば、特定の人に議論について警告しやすくなり、ウィキの内外の両方で明確な通知を受信しやすくする. (#通知節をご参照ください. )
 * 特定の会話の履歴を閲覧でき、特に過去ログから検索する方法. (#履歴節もご参照ください. )
 * 会話ページをモバイル版でもっと自由に使いこなしたい. (#モバイル版利用者節もご参照ください. )

英語版ウィキペディアの一部の編集者はメタデータテンプレートを話題にしました. 記事のトークページで使い、指示や警告、品質評価やウィキプロジェクトでの所属、さらに記事に関するその他の情報を表示します. 同様のツールが他のウィキで使われています. このトピックは重要ですが、第1フェーズでは特に注目を集めませんでした. このトピックに関する詳細情報を第2フェーズで集めます. (#Metadata節もご参照ください. )

新人貢献者
新人貢献者にとって、構造化せずウィキテキスト形式のページはわかりにくく、使いづらいものです. ウィキメディアで提供される会話用ツールは、インターネット上で使い方を覚えたツールとかなり異なっています. この違いこそ、人々がコミュニティに参加して積極的なメンバーになることを妨げています.

オンウィキの協議に加え、編集初心者になる可能性のある被験者10人を対象に、新人利用者テストを実施しました. 全員、読者としてウィキペディアの利用に慣れていて、編集の方法に関心を抱いています. テストでは以下の各点を観察しました.


 * 回答した利用者は全員、トークページを探すのにさんざん迷いました. 記事の節見出しと並んだ「」をクリックすれば、その節の議論のフォーラムに進むはずと思った人がほとんどでした.  記事の編集に関する質問はどこでするか尋ねると、（右方向書記の英語版の場合） ページ左上にある「」タブに気づいた人はたった十分の一です.  おおかたの人はページ右上の（利用者本人のトークページに飛ぶ）「」 リンクを開くと、質問をする場所に行けると予想したそうです.
 * テストの途中で「」タブに誘導された回答者は、誰もがきっと見慣れたメッセージボードか議論のフォーラム形式で表示されたページが開くと思ったようです. 多くの場合、トークページの構成に戸惑いました.  トークページと記事ページのそれぞれの構成が見た目によく似ていることから、きっと記事ページは節見出し単位でトークページに専用の見出しがあるのだと推察したとのことです.
 * The users struggled with "the basics" described above: replying, indentation and signatures. Some users thought that the "" link in a user's signature was the reply button. Only three of ten could figure out how to add a signature. Most of the users could figure out how to use colons for indentation from looking at previous posts.
 * This test was done with copies of talk pages from the English Wikipedia. Article talk pages there often contain templates about the article (example). For most users, the templates at the top of the talk page seemed out of place. Several users became so focused on the template boxes that they didn't scroll down to the discussion without being prompted; they seemed to believe that the templates themselves were the full extent of the talk page. (新人利用者テスト節もご参照ください. )

これらの発見は、ウィキ上の議論におけるコメントでも見られます. 新人ユーザーはトークページでの返信は方法がわかりにくく、そのとまどいのせいで多くのユーザーがあきらめていると報告しました. 多くの経験豊富なユーザーは、編集初心者は現在のデザインと機能性に苦労しており、それが参加のバリアになる可能性があると述べました. (#編集初心者) New users reported that responding on a talk page was confusing, and that confusion leads many users to give up. Many experienced users said that newcomers struggle with the current design and functionality, and that it can be a barrier to participation. (#Newcomers)

重要なテーマ
このプロセスでは、重要な2つのテーマが浮上しました.


 * Clear design and appropriate tools: Right now, article pages and talk pages are very similar in their appearance and functionality. That appearance is misleading and makes it more difficult for people to learn how to use talk pages correctly. People are meant to use a talk page in a different way than an article; it's a different form of content. A core principle of product design is that the tool should help the user understand what they're supposed to do. It should be easy to use a product correctly. A good product design minimizes the opportunities for users to make mistakes. While experienced wiki contributors have learned to live with limited product design – and are justifiably proud of the workarounds they've developed to compensate – it's not fair to allow badly designed tools to be a barrier to participation for knowledgeable and passionate people who want to join the communities and contribute knowledge.
 * Features vs Flexibility: The desire for talk page improvements is not limited to newbies. In fact, experienced contributors are the ones who know best how inadequate the existing tools really are. Experienced users want to participate in a single discussion on an active talk page, without wasting time looking at irrelevant edits in other sections on the page. Experienced users want to be able 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 separate from other edits on the same page. That may require making some changes that limit the endless flexibility of an open wikitext page. Those changes need to be carefully considered and agreed upon, and changes that limit flexibility need to connect to a visible, positive improvement in functionality. That's what we want to discuss in Phase 2 of this consultation: How should we approach finding that balance between long-requested features and flexibility?

製品の方向性の提案
これら発見に基づき、ウィキテキスト版のトークページは改善が必要で、継続するべきと提案したいと考えています.

Experienced contributors in the larger communities have built a very large number of important workflows based on the ability to manipulate wikitext, and the list of use cases is long and intimidating. LiquidThreads and Flow both involved replacing talk pages with a new system, which then had to handle all of those use cases before they were fully adopted. In complex ecosystems like this, it's better to start with a product that works (called a "minimum viable product"), and then make improvements that can be built and released over time, learning more with each release. As flawed as wikitext talk pages are, they've powered wiki discussions for more than 15 years, and that's a minimum viable product.

Our idea is to build a new design on top of wikitext talk pages that changes the page's default appearance and offers key tools – the "clear design and appropriate tools" described above. 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 to respond to an existing discussion or to a specific message within that discussion. It should add the signature automatically, and place the message in the correct nesting order.

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

The caveats: as we said above in "Features vs Flexibility", improving talk pages may require small-to-medium changes in wikitext conventions and practices.

例:


 * To build the ability to watchlist a single discussion, the system will have to be able to tell the difference between one discussion and the next. The page can't just be a pile of unconnected edits. That might mean changing the wikitext convention for a discussion header. Maybe editors would type  instead of , or  . (These examples are purely for illustration, not actual suggestions.) Experienced people would still be able to use wikitext, but they'd have to learn a new convention.
 * To make the new features work, and not interfere with non-discussion pages, it may be necessary to specify where they are enabled. We could have them work only on pages in the "talk" namespaces (such as,  ,  , etc.). If so, then some existing project-wide discussion pages (such as the deletion discussions at some wikis) would have to relocate from   to   pages, to be able to use these tools. Another possibility is that the features work automatically in the talk namespaces, and that people could turn them on for other individual pages with a wikitext magic word. Or maybe they'll work anywhere, as long as you use the   prefix. (Again, purely for illustration.)
 * To build the ability to move a discussion to an archive without breaking links to it, it may be necessary to create a unique ID for each discussion. This could mean that you need to use one of the new tools to create a new thread, merge two threads, or archive an old thread.
 * To improve page history, we may have to make some decisions. Some experienced contributors talked about the need for a complete history for the whole page. Others emphasized the need for a thread history, for individual discussions. (Right now, wikitext talk pages have a page history but not a thread history; in Flow, it's the other way around.) It would be ideal to provide both page history and thread history. We'll have to think and talk about how to make that possible.

The intention is to only make changes that are necessary, in order to enable functionality that's worth making the change. Ideally, the result should be approximately the same amount of work or less for contributors. For example, if you want to move a discussion from one page to another without breaking people's watchlist, you might need to click a new "move discussion" link and enter the name of the target page, so the system can keep the permalink active. That would be a new habit to learn, but moving a thread by cutting and pasting wikitext takes just as long.

The inspiration for this approach was the eager adoption of the ping feature, which was created around six years ago and is now widely used by experienced users. To send someone a notification that you'd like them to look at a discussion, you have to post their user name in brackets, or use a specific template, such as  or. But the ping only works if you sign that edit with. If you misspell the person's name, then you have to fix the error, and sign the message again, on a new line. That's a new set of wikitext habits to learn and remember, but lots of people have happily switched their habits, because it enables a feature that's incredibly helpful.

The adoption of the ping feature demonstrates that it's possible to make widely accepted small-to-medium changes in wikitext conventions, as long as we can find that balance between the trouble it takes to learn and use the new convention, and the value that users get from a new feature. It will take serious thought and discussion to find this balance for each stage of the project. We're willing to think and talk and try new things, in order to make talk pages easier to learn and use. We hope that many of you are willing to join us as we figure out how to make this work.

第2フェーズの質問リスト
このレポートの公開はトークページ協議の第1フェーズ終了のしるしであり、別途、第2フェーズという協議と調査の開幕を告げます.

An important part of Phase 2 is to hear your responses to the proposed product direction. That can begin right now on the talk page of this report, for people who would like to share their thoughts, ideas, and questions there. We will also ask groups that participated in Phase 1 to tell us what they think.

第2フェーズの協議では、以下の質問をします.
 * 1) 提案された製品の方向性について、どう思いますか？
 * Context: The Wikimedia Foundation proposes building a new, clearer design on top of existing wikitext talk pages. It will offer simpler tools for replying, indentation and signatures. You could continue to use wikitext on talk pages, if you prefer that. It should also be possible to participate in a discussion without using wikitext.
 * 設問: この製品の方向性についてどう思いますか?
 * 1) 別々の議論を区別する
 * Context: People want to watch individual sections on the talk page. They want better notifications, archiving, and search. To do any of this, we may need to create a more structured definition of what counts as a single discussion. This may 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.
 * 設問: そのアプローチの優位な点と不利な点はなんですか？
 * 1) 編集初心者がトークページを見つけやすくする
 * Context: Newcomers have difficulty finding talk pages. During user tests, only one person out of ten found the  tab. Most testers looked for a  tab on the opposite side of the page, where all of the other tabs and links are. Many people also expected to see links to discussions about specific sections in the article. We may want to move the link to the talk page to the opposite side of the article page. We might add discussion functionality connected to individual sections.
 * 設問: 記事の内容と議論の結びつきをもっと明白に示した場合、有利な点と不利な点はそれぞれなんですか？
 * 1) 協議用ツールの表示位置
 * Context: Currently, 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 where discussions happen, so that it can display the new tools in those discussions, and not display them on other pages. There are several potential ways to do this. One of them is to move all discussions to a talk namespace.
 * 設問: それを実行すると、有利な点と不利な点はそれぞれなんですか？
 * 1) 履歴表示の矛盾
 * Context: Sometimes, you need to see the history of the entire page. Other times, it would be more helpful to see the history of only a single discussion thread. It would be ideal if we could provide both, but we're not sure how to do that.
 * 設問: ページの完璧な履歴と特定のスレッドの履歴には、それぞれどんな利点と不利点がありますか？
 * 1) メタデータの表示位置
 * Context: Some wikis place templates 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.
 * 質問: そのアプローチの長所と短所は何だと思いますか？ テンプレートのうち、ディスカッションページの適切な使用に非常に重要なのはどれで、別のページへ移すほうがよいのはどれですか.

レポートの続きは以下にその発見の詳細を載せていますが、まずはここで、皆さんがローカルのコミュニティとして、あるいは個人として、第2フェーズの協議に参加する方法をご紹介します.

では、コミュニティから第2フェーズの設問に関して、協議を主催する申し出を受け付けています.

Here are the current consultations:



w:pl:Dyskusja Wikipedii:Konsultacje w sprawie stron dyskusji w:ru:Википедия:Форум/Предложения 

w:cs:Wikipedie:Konzultace_diskusních_stránek_2019 w:de:Wikipedia:Projektdiskussion/Globale Konsultation zum Thema Kommunikation 2019/Phase2 w:en:Wikipedia:Talk pages consultation 2019/Phase 2 w:fr:Wikipédia:Consultation sur la communication 2019/Phase 2 w:nl:Wikipedia:Overlegpagina's raadpleging 2019 w:th:วิกิพีเดีย:สภากาแฟ/อภิปราย/ขอความเห็นการพูดคุยหารือระหว่างผู้ใช้ (2562) ระยะที่ 2 w:zh:Wikipedia:2019年討論頁諮詢/第二階段 

s:en:WS:S 

d:Wikidata:Requests for comment/Talk pages consultation 2019, phase 2

いつも活動するコミュニティが協議を催していないか、調べましょう -- もし行われていない場合は、ぜひ主催者に立候補して実施してください！ 主催者の皆さんにはローカルの協議のまとめをお願いしており、〆切は2019年6月15日です.

個人として参加するには、上記の設問6件の答えを考えてください. 回答はTalk pages consultation 2019/Individual feedback#Phase 2 questions宛てに投稿をお願いします.

2019年5月22日前後には、オフウィキを好む対象者に向けて同じ設問を使ったアンケートをオフウィキで開始する予定です.

第1フェーズ：プロセス
''翻訳に関する注記： 以下の協議の引用部分は機械翻訳により英訳され、原語と英語の両方で公表されました. 長文のレポートであり、翻訳者の皆さんが英語部分を翻訳しなくても構わないと考えています. 上記の節の翻訳に参加してくださっている翻訳者の皆さんに謝意を表します. 皆さまのご協力に心から感謝いたします. ''

トークページ協議の第1フェーズは、運動に参加する人々が互いにどんな方法でコミュニケーションをとるか、情報収集が目的でした. 下記にプロセスを解説し、その後、協議の成果の詳細を述べます.

オンウィキの議論
全体でおよそ450人の編集者や寄稿者、プログラム主催者その他の運動関係者がチームとの情報共有に参加しました.

初心者テスト
現在、活動中の寄稿者に加えて、編集初心者の皆さんの見解も取り入れたいと考えました. まだこれからコミュニティになじむわけですが、将来のウィキメディアンとしてぜひ投稿を期待しています. すでに活動しているウィキメディアンとは、生まれた文化や求める技術も違うかもしれません. 編集初心者に使いにくいコミュニケーションのツールが影響しないようにしたいのです.

編集初心者がウィキの現在のコミュニケーションについて感じることを理解したいので、UserTesting.com を利用しました. UserTesting.com はソフトウェアを試用した時の個人の経験や反応、思考を記録する人々を雇用しています. その試用のため、ウィキの協議に参加したことがない10人の被験者を募集しました. その人々は、ウィキペディアの記事のトークページに初めて参加した時の経験を記録しました.

こちらからはどんなタイプの人がトークページに遭遇するか、予想を記してもらいました. それはある程度の技術的な能力、ウィキペディアになじみがあり、編集したい人かもしれません. To narrow to those people, we asked a series of screening questions, such as "How often do you look something up on Wikipedia?", "Have you ever engaged in a discussion with other users on Wikipedia?", and "If you have not edited Wikipedia in the past, what would you say is the main reason why you have not edited?" We included only people who were familiar with Wikipedia and who seemed likely to become Wikipedia editors in the future.

これら結果のまとめに加え、編集初心者に関するオンウィキの協議の情報は、#編集初心者のこのページに掲載されています. これらのテストの詳細な説明と考察については、新人テストのページをご参照ください.

オンウィキの協議の成果
The purpose of Phase 1 of this consultation was to collect information on how people use talk pages, and the problems they run into. To start the conversations, we asked:


 * 1) When you want to discuss a topic with your community, what tools work for you, and what problems block you? Why?
 * 2) How do newcomers use talk pages, and what blocks them from using it?
 * 3) What do others struggle with in your community about talk pages?
 * 4) What do you wish you could do on talk pages, but can't due to technical limitations?
 * 5) What are the important aspects of a "wiki discussion"?

Approximately 450 users participated in discussions hosted on 20 wikis and usergroup spaces. This included Wikipedias in 15 languages, as well as Commons, Wikidata and two Wiktionaries. People also participated on the central Talk pages consultation page, and another page set up for individual feedback. The consultation team read all of the discussions (using machine translation where necessary), and sorted responses into themes.

There were strong themes that came up often, which are summarized in the following table. The frequency of comments is estimated on a seven-point scale, going from ✎ (some people mentioned it) to ✎✎✎✎✎✎✎ (a very popular topic). It is based on the number of terms used, how often, in which context and also on the overall feeling from community summaries. This isn't a scientific classification, but it helps to summarize the feedback.

All comments have been translated into English, mostly using machine translation. The original text is included. There may be errors in the translations; please feel free to correct a translation if you find errors.

インデント
テーマの一般性： ✎✎✎✎✎✎✎

正しいインデントを設けるため、コロンの数に気をつけなければならないという苦情は、何十件もありました. これが最も頻度の高い苦情でした. 経験の長い編集者は手間がかかり難しいと言い、編集初心者にはさらに難関です.

ウェブ上の他のコミュニケーション用システムではすべて、個別のユーザーごとにメッセージを分類して表示し、利用者に手動で視覚的インデントを設けるように求めたりしません. 経験や能力のレベルに無関係に、編集者は誰もがこのシステムの簡略化と標準化を望んでいます.

解決策がいくつか提案され、Flow もしくは近似のシステムを提供し、自動で正しいコロンの数を割り出し挿入するスクリプトで処理する案もありました. 別の案ではコロンを他のウィキテキストのコードに置き換え (手入力で  ではなく   と打って対応、もしくはコメントの開始と終了を明示する方法を作成) により、ウィキテキストによる議論システムの利用しにくさを解消すると打って述べています.

第1フェーズで回答者から寄せられた代表的なコメントをいくつか、以下に引用します. 書式の自動処理の要望と、コメントの内容そのものに集中したいのに、現状のシステムには混乱しいらいらするという声が上がり、また HTML 構文と使いやすさにもコメントが集まりました.

コメント1件に複数の課題を書いたものが多く見られます. インデントに関するコメントではしばしば #返信と#設計および#ウィキテキストの使用が指摘されました.

返信
Popularity of the theme: ✎✎✎✎✎✎✎

A common challenge for new users is figuring out where and how to reply to messages. Modern internet users are used to typing into a text box to reply, since this is the model used on other websites. Typing directly under someone else's message, in the same way that a Wikipedia editor might add a new paragraph at the end of an article, is a very unusual model for communication.

Experienced users also have trouble with this on long, complex discussions. Editors sometimes want to be able to reply directly to a comment that's in the middle of a thread, but this requires scanning a window full of wikitext, finding the right spot to add the comment, and using the correct indentation. People also use varying ways to respond to a particularly long or multi-point comment.

These quotations from Wikipedia editors represent the common themes related to replying to an existing discussion: although a precisely formatted large discussion can be followed logically when you're reading, when you are replying to a free-form discussion on an unstructured wikitext page, it can hard to find the right place to add your comment and to quote or otherwise indicate which comment or sentence you're replying to. Editors want a tool that allows them to reply in the correct place, with the normal formatting.

Comments about replying often overlapped with concerns about #Indentation and #Newcomers.

署名
Popularity of the theme: ✎✎✎✎✎✎✎

Many users reported that manually "signing" pages by typing  at the end of a typed message is unusual and off-putting. No participants defended the current signature process as an ideal approach. New user testing also identified this system as a stumbling block.

Other related problems include people using signatures that don't correspond to their usernames. Some editors object to distracting decorative elements, such as colored backgrounds or images included in signatures.

These typical comments from participants discuss the unfamiliarity, the non-trivial efforts needed to correct for it, the confusion, the special difficulties for people typing on mobile devices, and the advantages that Flow has in being designed to automatically sign every message.

安定性
Popularity of the theme: ✎✎✎✎✎✎

Many established, highly active editors expressed a desire to minimize apparent changes. They did not exclude having some improvements made, but they wanted any new approaches to be fully compatible with what they're already used to. People who favored stability often commented on the flexibility offered by using blank, unstructured pages.

過去ログ化
Popularity of the theme: ✎✎✎✎✎

Most of the current archiving systems involve copying and pasting older discussions to another page ("archive") for long-term storage. On the largest wikis, this is usually done by bots on some pages, and by hand on others. In smaller communities, it's usually done by hand on all pages. This breaks page histories (for example, the comment is in, but the page history is left in  )  and links to the original discussion, which still point to the original location.

To reduce some of these problems, some wikis use alternative structures, such as creating a new discussion sub-page for each day/week/month. This usually requires a bot to maintain it, and it makes it hard for people to watch new discussions. Others manually archive central discussions by topic, in the hope that people will be able to find relevant discussions more easily.

The quotations here highlight some of the problems that users have encountered: broken archiving bots, different systems on different pages and different wikis, and finding discussions that previously happened on that page.

This point is related to #History and to #Visibility.

通知
Popularity of the theme: ✎✎✎✎✎

The Echo Notifications system has become one of the most popular new software features the Wikimedia Foundation has designed, because it helps experienced contributors communicate more smoothly. Some editors have suggested more extensive notifications, such as the ability to get a message on your phone when someone posts a note on your user talk page, a way to triage notifications, a way to know if a message has been read, and a way to invite someone to a conversation.

The sample quotations here describe making it easier to "ping" (notify) a user during a discussion, the difficulty of following discussions, the inability to find out about messages without first visiting a wiki page, having routine notices mixed up with active discussions, not knowing whether your message was read, a clearer way of requesting an answer, and the need to contact and coordinate work by multiple people, such as members of a user group, WikiProject, or other team.

新人編集者
Popularity of the theme: ✎✎✎✎

Most of the participants in the on-wiki consultation were highly active, highly experienced editors, leading one of them to comment on the irony of "a discussion about talk pages, on a talk page, advertised on talk pages", since that format would bring in comments from people who are able to use this format. Indeed, comments from new and occasional contributors expressed somewhat different concerns, and experienced editors expressed their concerns about how newer editors were struggling with the current system.

Most newcomers to Wikipedia are already regular users of other websites and/or social media apps. The conversation tools that they have already learned to use are very different from the tools we provide. Our software is perceived as difficult and overly technical to use (even for users with technical experience), obsolete, or counter-intuitive. Current practices, like manual indentation and signing, do not feel like natural behaviors to newcomers.

The quotations here express feelings of exclusion, confusion, and frustration, a desire for a more modern approach (for example, automatic indentation or a quick way to reply without opening the full editing environment), the use of Flow or alternative forum-style discussion systems, and the strangeness of the system compared to user expectations.

Other factors that may block newcomers may be the design of the pages|#Design|the design of the pages, the lack of replies|#Replying|the lack of replies, the behavior of some experienced users towards newcomers, and their lack of confidence.

履歴
Popularity of the theme: ✎✎✎✎

Editors and other contributors want to be able to see what was written, when, and by whom. Monitoring discussions history should be done the same way as it is for other pages.

Both wikitext talk pages and Flow threads have a problem with page history. On Flow pages, it's easy to see the complete history of a single thread, but you can't see a diff for the entire page. With wikitext pages, you can see a diff for the page, but the history of a specific discussion is spread across the page history, especially if the discussion is copy-pasted to an archive page.

These quotations show experienced contributors' desire to always be able to see pages as they were in the past, to move discussions between pages without losing the history, and to consider some new features, such as the ability to link an edit in the page history to a specific discussion on the talk page.

This problem area is closely related to archiving discussions|#Archiving|archiving discussions.

検索
Popularity of the theme: ✎✎✎✎

Searching could be improved by adding new features that would help to search on current discussions, filter the results, or to handle meta elements around the conversation (e.g., the status of a question). People noted that the normal search tool doesn't, by default, include discussions in search results.

These sample quotations include easily searching for prior discussions, being able to tag discussions by topic, and the need to fix search in Flow.

Being able to search and find previous discussions is somewhat related to #History and #Archives.

可視性
Popularity of the theme: ✎✎✎✎

Even when someone figures out how to post a message on the talk page, it's possible that nobody will notice the message and reply. Established editors, like those participating in subject-area WikiProjects, need to be able to find unanswered new comments from their field of expertise. Not replying to comments or questions from newcomers and occasional editors may discourage them from trying to contribute further.

On unstructured wikitext talk pages, it is difficult to visually see which topics or comments have been added since your last visit (Flow supports this workflow). There is no signal on the article's page that there are new or unanswered questions on the talk page.

The quotations here cover questions going unanswered, the difficulty of noticing activity on an article talk page, the need to reach people with relevant expertise or interests, and newcomers' problems with finding the article talk page.

ビジュアルエディター
Popularity of the theme: ✎✎✎✎

Both newcomers and established editors requested a non-wikitext editing model for discussions. Some participants preferred updating the visual editor so that it could process discussions; others preferred using Flow, which offers a visual mode with a small toolbar.

These quotations show editors preferring visual editing because it is easier to learn and easier to use.

This theme is related to #Wikitext.

ウォッチリスト
Popularity of the theme: ✎✎✎✎

Editors supported improvements to the watchlist system, especially a way to watch a single section on a busy wikitext-based talk page. This has been a long-requested feature, and it is popular with both newcomers and established contributors alike.

These quotations support being able to follow a single conversation on a busy page, without having to see the other discussions, or a way for groups to find out about new discussions without all of the members putting every page on their regular watchlists.

This theme is related to #Notifications.

とまどい
Popularity of the theme: ✎✎✎

In addition to software design issues, contributors have to figure out many cultural conventions, such as whether a given discussion is a vote, and how the discussion is structured. For example, just at the English Wikipedia, replies are "correctly" placed in the same section as the previous person's comment in most article talk pages, on either person's user talk page if the discussion started on a user talk page, and in your own section for an Arbitration Committee case. As a result of the software limitations and social complexities, the methods for communicating on wiki can generate confusion to both new users and some long-time users, to the point that some even prefer social media to communicating on wiki. (See the section on social media use below.)

These quotations identify several problems: excess difficulty compared to alternatives, unclear social expectations, understanding the discussion format, seeing other people's comments but no obvious place to add your own, and unfamiliarity for people who are accustomed to current web conventions.

モバイル版の利用者
Popularity of the theme: ✎✎✎

At the moment, communication through a mobile device is very difficult. Contributions from the apps and the mobile website are increasing in nearly all languages. Accessibility on mobile devices is needed to make contribution easier for all users, to respond to the particular needs of some users with disabilities, and to increase the number of people who can contribute to discussions. As one user said, it shouldn't be noticeably easier to edit an article than to talk about that edit on the article's talk page.

These quotations include confusion, inaccessibility, the changes needed to make a system work on a mobile device, and the location of the main link to the talk page.

This theme is related to #Confusion, #Signatures, #Indentation and #Visibility.

ウィキテキスト
Popularity of the theme: ✎✎✎

There was an interesting divide among editors about the need to use wikitext in discussions. An insistence that wikitext be the key format was largely found among highly active, long-time editors on Wikipedia. This generally took two forms:


 * 1) that the page itself be unstructured (for example, so that editors could choose to start a new discussion anywhere on the page instead of only at the top or the bottom), and
 * 2) that the canonical representation of the discussions be wikitext (for example, so that different formatting codes could be tested and discussed on the talk page, and then be copied and pasted into an article, where it would produce the same result).

For beginners, contributors to other projects, and among people who primarily make non-wikitext contributions (e.g., using the visual editor, adding information to Wikidata, uploading photos), the necessity for using wikitext in discussions was less obvious.

Among the insights from this theme: Long-time Wikipedia editors assume that newcomers will learn wikitext by editing articles, and that the newcomers will only later attempt to communicate with other editors on wiki. As a result, they assume that newcomers will have already developed some level of skill with wikitext before encountering the talk page, and that it therefore makes more sense for discussions to happen in that recently learned format, rather than using conventions and tools that are widely used across the internet for communication.

These quotations reflect Wikipedians' desire to use unstructured pages, the need for improvements, the importance of being able to talk about and test article formatting in discussions. They also reflect the views of others, who question the need for every contributor to learn wikitext, who want more accessible and user-friendly ways to participate in discussions, and who describe communication problems they have encountered.

This point is related to #Visual editor, #Workflows, and how discussions are structured (#Design, #Indentation, #Replying).

編集の競合
Popularity of the theme: ✎✎

An edit conflict happens when two editors try to change the same part of a wikitext page at the same time. Edit conflicts are common in busy discussions in free-form wikitext discussions, and very rare in any type of fully structured discussion. The difficulty of resolving the conflict sometimes causes people to give up without participating.

Some work has been done to reduce edit conflicts in the past. Edit conflicts are resolved at the level of a single "line" of wikitext (not a section), but if two people try to reply to the same comment at the same time, or if someone changes the immediately adjacent line while you are typing a new comment, an edit conflict will still be triggered. Wikimedia Deutschland has produced a tool that allows editors to resolve conflicts through a more visual process. However, in the end, edit conflicts are painful and need to be minimized.

These comments reflect the universal dislike that editors have for edit conflicts.

This theme is related to #Wikitext, because edit conflicts are part of the price for using free-form, unstructured discussion pages, and to #Newcomers, because newcomers are unlikely to be able to resolve an edit conflict.

設計
Popularity of the theme: ✎

Overall the design of talk pages is outdated, and discussions are structured in a confusing way.

It's generally accepted that when you want different behaviors in different places – for example, writing articles in the mainspace, discussing improvements to them on a talk page, or reporting spam at a noticeboard – then you want the design of those different pages to reflect and encourage their different purposes.

These Wikipedia editors say that the design is visually awkward and outdated, and that it does not help editors collaborate with others effectively.

Design is related to.

メタデータ
Popularity of the theme: ✎

Some wikis use large templates at the top of article talk pages to display instructions and warnings, quality ratings, WikiProject affiliations and other information about the page. This came up several times in the English Wikipedia discussion.

不正行為
Popularity of the theme: ✎

Editors at all experience levels worried about vandalism, harassment, and other destructive behaviors. They want tools to deal with vandalism and related unacceptable behaviors. Identifying and addressing blatant vandalism (e.g., having your vote changed from 'support' to 'oppose') costs time, energy, and goodwill.

These quotations mention people deliberately changing other people's contributions, the way Flow rearranges pages, the need for better anti-harassment systems, and the importance of being able to delete or suppress ("oversight") page histories.

This theme is related to #History and #Newcomers.

ワークフロー
Popularity of the theme: ✎

Additional software tools could improve the handling ways of the complicated workflows that are used on larger wikis, such as the creation and maintenance of Articles for Deletion discussions or counting up votes in a Meinungsbilder on the German Wikipedia or in an Arbitration Committee case at the English Wikipedia. Improving communication tools and systems used by the Stewards, the Global sysops, and the Small Wiki Monitoring Team would also fall into this category. This type of improvement was largely requested by highly active editors at the largest Wikipedias.

Given how important these processes are, and how much effort is required to maintain them, it is somewhat surprising that more editors did not suggest improvements to these complex systems.

These quotations show an awareness that complex systems could be greatly simplified through new tools, and the importance of building tools that scale to the needs of highly active editors.

This theme is related to #Confusion.

Conclusion
Thank you to all of the people who participated in these discussions so far! We hope that this report is a fair summation of the ideas and opinions that were expressed in Phase 1. We're looking forward to continuing the discussion in Phase 2 of the consultation, and hearing your reactions to the proposed product direction. Talk to you soon!