Talk pages consultation 2019/Phase 1 report/zh

2019年討論頁諮詢來到第一階段的尾聲：此次全域諮詢目的在於瞭解貢獻者如何使用Wiki討論頁以及使用體驗上的問題. 本概要報告總結了貢獻者的說法以及我們所學到的事物，並提出本計畫的方向以及在第二階段想要探討的特定問題.


 * 作者為討論頁諮詢團隊：Danny Horn、Benoît Evellin、Sherry Snyder、Thomas Meadows與Marshall Miller.

簡介
Wiki標記語言討論頁並非由軟體製作而成，而是一種文化習俗的集合，對於新手來說會感到困惑，而對於資深編輯者來說則會感到厭煩. 計算冒號數量來正確進行縮进、使用波浪號簽署您的名稱、必須監視整個頁面而不是您正在參與的討論、沒有簡單的回覆連結──這些問題對每個人來說很頭疼.

於此同時，Wiki標記語言討論頁也有許多運作良好的地方. 這類討論頁的空白編輯視窗可以讓人們自由放置極其靈活、適應性強的模板與技術. 討論當中的會話可以在任何地方與任何時間重新組織. 編輯差異與歷史版本可以顯示某個討論頁在何時、何人與何種方式進行討論. 這樣的討論頁在數百萬篇條目的百科全書上協助人們進行協作長達17年，不應該隨便取消.

在此之前，維基媒體基金會產品團隊曾進行過Wiki網站溝通工具的開發工作，包含LiquidThreads（2006年起）以及Flow/結構式討論（2012年起）. 這兩個計畫成功使用於許多Wiki網站，即使這兩個工具都有強烈的批評，並且沒有在大型Wiki網站獲得廣泛支持.

我們想要讓所有貢獻者能夠在Wiki網站上互相對話：詢問問題、解決差異、組織專題以及做出決定. 溝通對於我們內容的深度與品質，以及社群整體的健康來說，確實至關重要. 我們相信這個專案對於想要達成自由分享我們所有知識總和的目標，也是必不可少.

本次全球討論頁諮詢於2019年3月開始進行第一階段，共計20個Wiki網站與使用者群組主持這次諮詢. 這包含了15種語言的維基百科，以及維基共享資源、維基數據、2個維基辭典以及1次面對面的使用者會議. 這些討論由每個社群的其中一名成員進行總結，而討論頁諮詢團隊閱讀了所有Wiki網站上的討論. 本團隊也在UserTesting.com執行了2輪使用者測試，當中的測試者有閱讀維基百科的豐富經驗，但因為他們不知道如何編輯而沒有進行貢獻.

第一階段於4月結束，而這個階段的報告（即本報告）已於5月發表. 以下是我們的發現、對於產品方向的提案以及第二階段討論的問題列表. 緊接著則是第一階段討論與使用者測試中更豐富與詳細的回顧.

基礎
在Wiki標記語言討論頁方面，有3個基本的元素被一致認為需要改善：回覆、縮排與簽名. 新手使用者對於這3個基本元素的機制感到困惑以及倒胃口. 即便是非常資深的使用者，也會在縮排與簽名上犯下錯誤. 為了改善討論頁，我們需要對於回覆增加一種較為簡單的工具，並且能夠自動縮排以及簽名. （請參閱下面的#縮排、#回覆與#簽名. ）

資深貢獻者
非常活躍的貢獻者在參與複雜的討論與工作流程時，偏好採用具靈活度、開放且尚未結構化的Wiki標記語言討論頁. 對於這些使用者，開放的Wiki標記語言討論頁很自由. 這類討論頁可以允許他們改變某篇討論或某個頁面的結構，用以應對討論當下的需求. 他們強烈希望與現有的Wiki標記語法系統保持連續性. 這些編輯者在諸多Wiki網站上都同意這樣的觀點，包含正在使用結構式討論的Wiki網站. （請參閱下方的#穩定性與#Wiki標記語言. ）

資深貢獻者希望能夠看見在討論頁中新增許多其他特性，包含：
 * 監視特定討論的能力，如此使用者可以追蹤某段對話，而非看到某個條目或整個討論頁的每一次改變. （#監視清單）
 * 某種更具備一貫性的存檔與搜尋功能，協助使用者找到先前特定主題的對話. （請參閱下面的#存檔與#搜尋. ）
 * 某種更具備一貫性的通知（提醒）功能，能讓通知某段討論有關的特定使用者更加簡便，以及更方便在Wiki網站內外接收明確通知. （#通知）
 * 某種觀看特定對話歷史紀錄的方法，尤其是該段對話已移動至存檔頁. （#歷史）
 * 在行動裝置上流暢使用討論頁的能力. （#行動裝置使用者）

在英語維基百科，部分編輯者提到了元数据模板. 這些模板用於討論頁並顯示相關指南、警告、品質評價、相關的專題頁面與其他關於對應條目的資訊. 其他的Wiki網站也使用類似的工具. 這個主題非常重要，但在第一階段中並沒有得到特別的關注. 我們將會在第二階段當中詢問後設資料設定的更多資訊. （#後設資料）

新手貢獻者
新手貢獻者在發現Wiki標記語言討論頁時會覺得困惑以及難以使用. 他們在網路上所學到的溝通工具，與我們所提供的工具有著非常大的不同. 這些差異會阻礙人們參與討論並成為活躍的社群成員.

除了在Wiki網站上的討論外，我們也和10名潛在的新手进行了新使用者測試. 所有這些新手非常習慣閱讀維基百科，並且也表達想要學習如何編輯維基百科的意願. 在這些測試當中，我們觀察到了下列現象：


 * 所有使用者在尋找討論頁時感到很掙扎. 許多使用者認為點選某篇條目中某段章節標題的「」會引導他們進入關於該章節的討論論壇.  當我們詢問何處可以提出關於編輯條目的問題時，10名新手中只有1名注意到頁面左上角的「」標籤（英語，由左至右撰寫的Wiki網站）.  他們一般會搜尋頁面右上角的位置，認為「」連結（也就是自己的使用者討論頁）才是詢問問題的正確位置.
 * 當本測試引導他們到「」標籤時，所有使用者預期會看見典型的留言板或討論論壇. 許多使用者對於討論頁的結構感到困惑. 條目與討論頁中相似的視覺設計，會使得他們假定條目當中的每個章節可以對應到討論頁的章節. 许多人对讨论页面的结构感到困惑.  条目的视觉设计与讨论页面之间的相似性使他们认为条目中的每个部分都对应于讨论页面上的一个部分.
 * 所有使用者對於上面所提到的基礎元素感到掙扎：回覆、縮排與簽名. 部分使用者認為使用者簽名當中的「（）」連結是一個回覆按鈕.  10名新手中只有3名可以理解如何增加簽名.  大多數使用者可以經由查閱以前的留言，來理解如何使用冒號來進行縮排.
 * 本測試是以英語維基百科的討論頁做成副本來完成的. 這裡的條目討論頁通常會包含關於條目的模板（範例）.  對於大多數使用者而言，討論頁上方的這些模板看起來似乎不合適.  許多使用者會開始聚焦於這些模板文字方塊，除非發出提醒，否則他們不會往下拉到討論內容；他們似乎相信模板本身就是討論頁的全部範圍.  （更多資料請參閱新使用者測試. ）

這些發現也在Wiki網站的討論得到相似的回應. 新使用者反應在討論頁進行回應會感到困惑，而且這些困惑會導致許多使用者放棄參與活動. 許多資深使用者說明新手對於目前的設計與功能會感到困惑，並且會構成參與活動的障礙. （#新手）

主要議題
在討論過程中，出現了兩個主要的議題.


 * 明確的設計與適合的工具：目前，條目頁面與討論頁在外觀與功能上非常相似. 這樣的外觀具有誤導性，並且會導致人們在學習如何正確使用討論頁這方面感到更加困難. 他們會打算以不同於條目編輯的方式來使用討論頁；這樣的方式會是一種不同的內容格式. 產品設計的一個核心原則，就是製作出來的工具應當能協助使用者理解他們應該要做什麼. 工具的設計應當能容易正確使用某個產品. 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. 一個良好的工具設計能讓使用者的犯錯次數降到最低. 即使資深Wiki貢獻者已經能學會在最低限度的產品設計環境中生存──他們會以發展變通方法來彌補不足，並以此感到自豪──允許糟糕的設計工具成為一道障礙，對於想要加入社群來貢獻知識，並且具有淵博知識的熱情參與者來說很不公平. 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.
 * 特性與靈活度之爭：對於改善討論頁的期待不僅限於新手. 事實上，資深貢獻者最能瞭解現有討論工具實際上有哪些不足的地方. 資深使用者想要參與某篇討論頁當中其中一段討論，而不想浪費時間在討論頁中的其他章節查閱不相關的編輯. 資深使用者想要能簡單快速找到討論內容，即使這些討論內容已經進行存檔. 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. 為了提供這些特性，討論系統需要能夠訴說何謂「一段討論」──也就是討論頁中的特定部分是一段單一的討論，並與同一篇討論頁中的其他編輯予以分開. 這樣做可能需要進行部分修改，來限制某篇開放Wiki標記語言頁面的無窮靈活度. 這些改變需要仔細考慮以及商討，並且這些限制頁面靈活度的改變需要連結到一個功能上可見並且有正向特質的改善. 這就是為什麼我們需要在第二階段諮詢當中進行討論：我們如何在使用者長期要求的特性與頁面靈活度之間達成平衡？

產品方向提案
基於這些發現，我們提議Wiki標記語言討論頁應當進行改善，而非取代.

大型社群的資深貢獻者，在操作Wiki標記語言能力的基礎之上，已經建立大量的重要工作流程；這些使用案例的列表很冗長而且感到嚇人. LiquidThreads以及結構式討論兩者都涉及取代討論頁成為新的討論系統，這些新工具必須要在完全能夠套用以前，處理所有的使用案例. 在這樣的複雜生態系統當中，最好的辦法是從某個有效的產品（稱為「最低可行性產品」）開始上線，然後隨時間推移產出可以發展與發佈的改進方案，並且在每次發佈時能夠學到更多. 與Wiki標記語言討論頁同樣有缺陷的地方在於，上述兩項方案已經提供Wiki網站討論功能超過15年，但仍然是最低可行性產品.

我們的想法是基於Wiki標記語言討論頁之上建立一套新的設計，用來改變討論頁的預設外觀並提供關鍵工具──也就是上面所述「明確的設計與適合的工具」. 這套新設計應當能與使用者在非內容頁面之處進行討論，並且協助使用者使用這套工具進行合宜的互動. 此設計應當包含如何開始新討論的明確表達，以及能夠在現有的討論或是當中的特定留言進行回應. 此外這種設計應當能自動簽名，並且能將留言放置在正確的巢狀順序.

為了維持現存工具的一致性，新設計將成為預設的體驗模式，並且提供現有成員退出新設計的選項. 經由下面討論的一些注意事項，新設計應當盡可能為使用者保持目前的視覺狀態，並且能夠採用Wiki標記語言而非新工具來進行工作.

注意：如同我們在上面特性與靈活度之爭當中所說的內容，討論頁的改善必須要在Wiki標記語言的慣例與實踐中進行小幅度至中等幅度的改變.

舉例：


 * 為了打造監視某段單一討論的能力，討論系統將必須能夠辨別某段討論與下一段討論之間的不同. 討論頁不能只是一堆沒有聯繫的編輯. 這可能意味著要改變某段討論開頭的Wiki標記語言慣例. 也許編輯者可以輸入「$Example」來取代「$EqualEqual」，或是採用「$example」（這些例子純粹用於描述本概念，而非建議. ）資深使用者仍然可以使用Wiki標記語言，但他們必須要學習新的慣例. 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.
 * 為了能讓新特性可以運作而不會干涉到非討論頁面，我們有必要具體說明要在何處啟用新工具. 我們可以讓新工具只在「討論」命名空間（如$namespace1、$namespace3與$namespace11等）來運行. 如果是這樣，部分已存在的全計畫討論頁面（如部分Wiki網站的存廢討論）必須要從 重新導向至 ，這樣才能夠使用新工具. 另外一種可能就是新特性自動在討論頁運作，然後人們可以使用Wiki標記語法當中的魔術字針對個別頁面來啟用新工具. 又或者，您可以使用 前綴來讓新工具運行於任何頁面（同樣地，這只是純粹的描述. ） 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.)
 * 為了打造出不用破壞連至現有討論的連結而進行存檔的能力，我們可能需要為每段討論建立一組獨特的ID. 這意味著您需要使用新工具當中的某種功能來建立一段新的討論串、合併兩段討論串，或者將舊有討論串存檔. 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.
 * 為了改善討論頁歷史，我們必須要做出一些決定. 部分資深貢獻者提出了瀏覽整個討論頁完整歷史的需求. 其他貢獻者則著重在某段個別討論串的歷史. （目前，Wiki標記語言討論頁有頁面歷史但沒有討論串歷史；結構式討論則相反. ）同時提供頁面歷史與討論串歷史會比較理想. 我們將會思考與談論如何讓這個想法變得可行.

為了能夠實現值得改變的功能，我們的意圖僅止於改變社群所需要的部分特性. 在理想情況下，改變的結果應能讓貢獻者的工作量大致相同或是減少工作量. 舉例，如果您想要將某個頁面的討論移動到另一處而不會破壞其他人的監視清單，您可能需要點選一個新的「移動討論」連結並輸入目標頁面的名稱，這樣系統就能保持有效的永久連結. 這種情況會需要學習新的習慣，但比起討論串以Wiki標記語言進行剪貼移動，所花的時間是一樣的.

上述改善方式的靈感來自於6年前ping特性的熱烈引入與啟用，如今資深使用者廣泛採用了這種特性. 如果您要對您所關注的討論當中的某個使用者發送通知，您必須要在方括號內輸入使用者名稱，或是採用「 」或「 」等特定的模板. 但ping功能只會在編輯時加上「 」之後才會生效. 如果您拼錯了使用者名稱，就必須修正錯誤，然後在新的一行重新簽名. 這種新的Wiki標記語法仍然要學習與記憶，但由於這項特性出乎意料地好用，因此大多數使用者對於這種習慣的轉換抱持快樂的態度.

Ping特性的採用，代表只要我們能夠在學習與使用新習慣所遇到的麻煩，以及新特性對於使用者的價值之間取得平衡，就可以在Wiki標記語法慣例進行小幅度至中幅度改變當中獲得廣泛支持. 為了在這項計畫中的各階段尋找平衡，我們將會謹慎思考並進行討論. 為了要讓討論頁更容易學習與使用，我們也願意思考、對話與嘗試新的事物. 我們希望各位可以加入我們，因為我們想要找出如何能讓這項工作進行下去.

針對第二階段的問題
公布本報告代表討論頁諮詢的第一階段已經結束，並為第二階段揭開序幕；這個階段將會是新的一輪討論以及調查.

第二階段的一個重要的部分是傾聽您對於產品方向提案的回饋. 如果您想要對於本篇報告分享您的看法、想法與問題，現在可以開始在本報告的討論頁進行發表. 我們也將詢問參與第一階段的討論群組對於本報告的看法.

在第二階段，我們想要詢問下列問題：
 * 1) 您對於維基媒體基金會提議的產品方向有什麼想法？
 * 內容：維基媒體基金會提出要在現有Wiki標記語言討論頁面的基礎上，建立一個明確的新設計. 這將會提供簡易的工具來進行回覆、縮排以及簽名. 如果您願意的話，仍然可以在討論頁上繼續使用Wiki標記語言. 這種設計應也能讓參與者不使用Wiki標記語言來參與討論. 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) 為每個獨立的討論進行標記
 * 內容：人們想要追蹤討論頁當中的某段個別討論，並想要有更好的通知、存檔以及搜尋功能. 為了要達到前述的任何功能，我們需要針對「何謂一段單一的討論」建立一個更結構化的定義. 這意味著必須要在討論頁上變更Wiki標記語言的慣例. 舉例，我們需要建立一個新的方式，來決定討論頁標題的Wiki標記語言如何顯示，或是建立一種新的連結方式來用於建立、重新命名或拆分討論串. 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) 協助新手尋找討論頁
 * 內容：新手對於尋找討論頁有諸多困難. 在使用者測試當中，只有十分之一的人可以找到「$Talk1」頁面標籤. 大多數測試者會在原來「$Talk2」標籤所在位置的另一側（也就是「檢視歷史」、「編輯」等其他連結所在的位置）找到「$Talk1」標籤. 大多數人們也希望能看到條目中特定段落的討論連結. 我們想要將「$Talk1」標籤移動到條目頁面的另一側，也會新增在個別段落中增加對應討論連結的功能. 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) 在何處顯示討論工具
 * 內容：目前大多數Wiki網站皆會使用計畫命名空間頁面設定社群討論空間（如「 」或「Wikipedia:」），不會在其討論命名空間頁面（如「 」或「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 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) 討論歷史的平衡
 * 內容：有時候，您會需要瀏覽整個討論頁面的歷史. 其他時候，只瀏覽某個單一討論串的歷史可能會對您更有幫助. 如果我們能提供前面兩種功能，這將會非常理想，但我們不確定要如何做. 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) 後設資料的位置
 * 內容：部分Wiki網站會在條目討論頁的頂端設定多個模板，內容可能是指南、警告或答客問. 這些模板可以維持討論品質、連結至其他相關的專題計畫或顯示過去的討論活動. 許多新手對於在討論頁頂端發現非討論素材的情形感到困惑. 如果將部分或所有這些內容移動到討論頁的其他位置或放在不同的標籤中，可能會有所幫助. 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.
 * 問題：對於這樣的設計有何優點與缺點？哪些模板比較適合用在討論頁，哪些又不適合？

本報告下方的其餘部分將繼續闡述調查當中所發現的細節；但是首先，這裡要告訴您如何以社群成員身份或個人身份參與第二階段.

各個社群可以在登記主持第二階段問題的討論.

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

您可以查看您的社群是否開始主持本次討論──如果沒有，歡迎登記並建立您自己所屬Wiki網站的討論！我們要求所有主持人必須在2019年6月15日撰寫本地討論的總結.

如果想要以個人方式進行參與，請您思考上述6個問題；您可以將答案發佈於2019年討論頁諮詢/個人回饋#第二階段問題.

預計2019年5月22日，我們將會開始進行一份採用同樣問題的非Wiki網站問卷調查，用來服務偏好採用這種調查形式的人們.

第一階段：過程
''翻譯者請注意： 本討論中的引述內容已由機器翻譯成英語，並且將原始語言與英語翻譯同時顯示出來. 本報告較為冗長，我們不期待翻譯志工有時間將英語文本翻譯完成. 我們非常感謝執行上述段落翻譯工作的志工. 謝謝您！''

討論頁諮詢第一階段的目標在於收集維基媒體運動中，使用者彼此之間如何進行溝通的資訊. 以下是本階段過程的執行方法，以及本次討論結果的詳細內容.

Wiki頁面討論
總而言之，大約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.

这些结果的摘要以及关于新手的维基讨论的信息，可以在#新贡献者查看. 有关这些测试的详细说明以及我们观察到的内容，请参阅新用户测试页面.

Wiki頁面討論的結果
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.

縮排
Popularity of the theme: ✎✎✎✎✎✎✎

There were dozens of complaints about counting colons to create the appearance of indentation. This was the most frequent complaint. Experienced editors find it clunky and difficult, and it is even harder for new editors.

All other communication systems on the internet manage to represent the messages posted by different users as individual messages, without needing the users to set a visual indentation level by hand. Editors of all levels of experience and ability would like to see this simplified and standardized.

Some solutions were proposed, including offering Flow or a similar system, scripts that automatically count and insert the correct number of colons. Some editors talked about replacing colons with some other wikitext code (perhaps typing  to indicate indentation instead of , or perhaps creating a method for clearly marking both the start and stop of a comment) as a way to solve the wikitext discussion system's accessibility problems.

Below are some representative quotations from participants in the Phase 1 consultation. They discuss the desire for automatic formatting, the need to focus on the content of the comment, and the confusion and annoyance the current system causes, as well as HTML semantics and accessibility.

Many individual comments related to more than one theme. Comments about indentation often addressed #Replying, #Design, and the use of #Wikitext as well.

回覆
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, 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.

Wiki標記語言
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!