Talk pages consultation 2019/zh

討論頁諮詢是一個全球性諮詢計畫，執行期為2019年2月至6月，讓維基媒體人與Wiki思想者一起來定義何謂最佳的Wiki溝通工具. 本次諮詢將盡可能尋求眾多不同的維基媒體社群──包含眾多計畫、語言與各種角度──為產品團隊提供一系列溝通工具產品的方向，以期能在下一個財政年度展開新的工作.

諮詢目的
A wikitext talk page isn't made out of software; it's a collection of cultural conventions that are baffling to newcomers and sometimes annoying for experienced editors. Counting colons to indent a reply properly, using tildes to sign your name, having to watch an entire talk page instead of the section you're participating in, not having an easy reply link – these are headaches for everyone.

At the same time, there are many things that wikitext talk pages do well. The empty edit window has given people the freedom to invent templates and techniques that are extremely flexible and adaptable. Conversations can be reorganized on the fly. Using diffs and revisions means that you can always see what's been done on a page, when, and by whom. The functionality that helped people collaborate on millions of encyclopedia articles for fifteen years shouldn't be dismissed as old-fashioned and useless.

Wikimedia Foundation product teams have worked on communication tools before: (started in 2010) and  (started in 2012). Both of these projects have been used successfully on many wikis, although they've also both been heavily criticized, and neither has gained wide acceptance on many of the largest wikis.

We want all contributors to be able to talk to each other on the wikis – to ask questions, to resolve differences, to organize projects and to make decisions. Communication is essential for the depth and quality of our content, and the health of our communities. We believe that this is essential for us to reach our goal of providing free access to the sum of all human knowledge.

本諮詢之預期成果
'''一个句子，一个段落和一个描述我们将要构建的有关总体方向的文档. '''

在本次咨询结束时，我们将为产品团队在下一财年从事于的一系列沟通功能提供总体方向. 我们将粗略地达成共识，即我们的贡献者同意这种整体方法，包括在多种语言和多个项目新的贡献者和经验丰富的用户.

在咨询结束时，我们将能够回答以下问题：


 * 我们正在构建一个功能，还是多个功能？
 * 我们是在改进以前的系统，还是构建新工具？
 * 我们如何平衡易用性与所需但又最复杂的高级功能集？
 * 产品团队应该调查和测试哪些重要的开放性问题？

结果将不是一个完整，详细的产品规格. 产品团队将随着时间的推移制定和修订详细的计划，设计，测试以及与用户进行持续密切的合作. 但我们将有一个坚实的起点，我们将确信该团队走在正确的轨道上.

为了鼓励信任和诚信，咨询和最终产品开发将完全公开和透明. 每个步骤都将记录在wiki上.

可能的解决方案
要使这个过程发挥作用，我们需要对各种方向持开放态度.

非目标
虽然我们对所有好的想法感兴趣，并且将来可能需要一些好处，但有些事情超出了当前项目的范围：


 * 在维基外的讨论平台 - 使用维基媒体帐户进行讨论需要在维基上进行.
 * 临时内容 - 讨论需要存储在维基上，以便以后可以找到并引用它们.
 * 针对小众观众的工具 - 讨论是为每个人设计的，并且要考虑到公平. 我们不是仅为一部分用户构建工具（例如：体验、语言和首选设备）.
 * A social network per se – Discussions on Wikimedia should primarily be in service of improving content on the wiki.
 * Real-time discussions – Real-time discussions have value, but our current focus is on asynchronous discussions for the reasons mentioned in points above.

参与
我们目前正处于规划阶段.

We are currently collecting responses to the Phase 2 trade-off questions, coming shortly. The end date for feedback is June 15.

Communities are invited to:
 * 1) Translate key elements of the Phase 1 report.
 * 2) Sign up your group to participate in Phase 2.
 * 3) Create a local consultation to answer the Phase 2 questions.
 * 4) Ask your community for feedback.

It is also possible to comment on MediaWiki.org or in a survey hosted at Qualtrics.

最终决定
The project is led by Danny Horn (Director of Product Management), Benoît Evellin (Community Relations Specialist), Sherry Snyder (Community Relations Specialist) and TMeadows (Logistics)

Information from multiple communities and other stakeholders is extremely important. We deeply believe that we can't make a good decision without listening to you and understanding your needs. However, the final decision about what software to support will be made by the Wikimedia Foundation, after due consideration of all the available information, our educational purpose, and the movement's 2030 strategic direction.

决策标准
虽然维基媒体基金会将在2019年的对话页面咨询中做出最终决定，但我们正以诚实的好奇心、没有先入为主的解决方案进入这一过程，我们正在合理地寻求理解我们收到的反馈. 也就是说，我们需要做出许多有关权衡取舍的艰难讨论. 在做出决定时，所有有效选项将按以下标准进行权衡：


 * 哪个选项最符合我们的观念？
 * Which option is most in alignment with Strategic Direction of Knowledge Equity?
 * 哪个选项服务于大多数用户和用例而非小众用户？
 * 对于使用任何设备的任何人，哪个选项可以带来更易于访问的用户体验？
 * 哪种选择将产生更具可持续性的产品，能够适应不断变化的技术，不断变化的用例和用户期望？
 * 哪个选项对实现项目目标的风险最小？