Talk pages consultation 2019/ar

2Aaw22aas4 The consultation will seek input from as many different parts of the Wikimedia community as possible – on multiple projects, in multiple languages, and with multiple perspectives – to come up with a product direction for a set of communication features that a product team will be able to work on in the coming fiscal year.

غرض الاستشارة
A wikitext talk page isn't made out of software; it's a collection of cultural conventions that are baffling to newcomers and 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.

Desired result from this consultation
One sentence, one paragraph, and one document that describe the overall direction of what we will build.

By the end of this consultation, we'll have an overall product direction for a set of communication features that a product team will be able to work on in the coming fiscal year. We'll have a rough consensus that our contributors agree with that overall approach, including both new contributors and longtime veterans, in multiple languages and across multiple projects.

By the end of the consultation, we'll be able to answer these questions:


 * Are we building one feature, or more than one?
 * Are we improving previous systems, or building a new tool?
 * How will we balance ease of use with the advanced feature set that our most complex use cases require?
 * What are the important open questions that the product team should investigate and test?

The result will not be a complete, detailed product specification. Detailed plans will be developed and revised by the product team over time, informed by design, testing and continued close partnership with our users. But we'll have a solid place to start, and we'll be confident that the team is on the right track.

To encourage trust and good faith, the consultation and ultimate product development will be entirely public and transparent. Every step will be documented on wiki.

Possible solutions
For this process to work, we need to be open to all kinds of directions. It's possible that at the end of this consultation, we end up with any of the following:


 * Building features on top of wikitext talk pages, to make them easier and more efficient.
 * Using Visual Editor on talk pages, with extra features.
 * Building a new software feature that isn't StructuredDiscussions/Flow.
 * Building on top of the existing StructuredDiscussions/Flow feature.
 * Building more than one solution – it's possible that we define separate sets of requirements for user talk conversations, content/project page conversations, common workflows and RFCs, and that there are two (or more) different features.
 * Something completely different that we haven't considered yet.

Non-goals
While we are interested in all good ideas, and might take some up in future, some things are out of scope for the current project:


 * Off-wiki discussion platform – Discussions need to be on the wikis, using Wikimedia accounts.
 * Temporary content – Discussions need to be stored on wiki, so they can be found and referenced later.
 * Tools for a niche audience – Discussions are designed for everyone, with equity in mind. We're not building a tool only for a subset of users (e.g., experience, language, preferred device.)
 * 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.

Participate
We are currently in the planning stage. Please read this page and provide feedback on the overall process for this talk page consultation:

We're also looking for volunteers to be the primary contact for participant groups throughout this process.

You can also help build the list of the many different ways people talk to each other.

Final decisions
The project is led by Trevor Bolliger (Product Manager), Benoît Evellin (Community Relations Specialist), Sherry Snyder (Community Relations Specialist) and Danny Horn (Director of Product Management).

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

Decision criteria
3sA4aq9qqa44 That said, there will be many difficult discussions about trade-offs we need to make. When it comes time to make a decision, all valid options will be weighed by the following criteria:


 * Which option(s) most aligns with our values?
 * Which option is most in alignment with Strategic Direction of Knowledge Equity?
 * Which option serves the most users and use cases as opposed to niche users?
 * Which option will result in more accessible user experience, for anyone on any device?
 * Which option will result in a more sustainable product that will be resilient to changing technologies, evolving use cases, and user expectations?
 * Which option poses the least amount of risk to achieve our project goals?