Talk pages consultation 2019

The Talk pages consultation is a global consultation planned for early 2019, to bring Wikimedians and wiki-minded people together to define better tools for wiki communication. The project is led by Danny Horn, WMF Director of Product Management.

In November 2018, a WMF staff working group will form, to figure out the next steps. Shortly after this, community members will be invited to join the working group as well. The immediate steps will be to figure out a structure for a global consultation, to include as many people as possible.

The consultation will begin in February 2019. The first part of the consultation will be coming to a rough consensus on the problems with wikitext talk pages that we want to solve, and the good things about wikitext talk pages that we want to keep. Once we have general agreement about those, we can build on that shared understanding to talk about possible directions for a feature, and look at what tradeoffs we would have to make if we choose one of those directions. The ultimate goal is to define a feature (or set of features) that will modernize the wiki communication system, making it more accessible for new contributors, and more efficient for active contributors.

Our hope is that by July 2019 (the beginning of WMF's next fiscal year), a product team will have enough direction to be able to start investigating technical solutions. If the consultation takes longer than that to reach a general consensus on product direction, then this date will be pushed back. Finding the right solution is more important than hitting a particular milestone date.

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.

The problem with talk pages
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 who. 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 -- LiquidThreads (started in 2010) and Flow/Structured Discussions (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.

There were two early decisions made in the development of Flow that created problems that we haven't been able to solve. The first was for the initial team to do a lot of research and planning without being transparent about what they were doing. Some contributors were involved in brainstorming and user feedback sessions, but most users found out about the project when it was announced at Wikimania, already defined and named and apparently permanent. Users were told that the train had already left the station along a pre-determined track, and some people felt that the only thing they could do was try to stop the train.

The second early decision was to say that we needed to build one tool that would work for every use case. Flow was supposed to be good for simple user talk page conversations, and the most complicated Requests for Comment. At that Wikimania announcement, users were told that Flow would handle everything, on every talk page. In product development, building one tool to handle every use case isn't always the correct answer, but once the Flow train started, the idea was that every discussion and workflow was going to use the same tool.

Those decisions put a target on the Flow project that years of development have not been able to shake. For several years, the Foundation's strategy was to keep developing Flow until it was so good that everyone would want to use it, on every wiki. That strategy has led us to a deadlock that frustrates pretty much everyone.

What we're doing
We need to go back to the beginning, and do the public, transparent, global consultation that we didn't do before. We need to talk to lots of people, on lots of Wikimedia projects, and come together to define a product strategy that will work for all wikis.

We need to involve people from all parts of the Wikimedia community. This includes all of the wiki projects, reaching people in as many languages as we can.

We need to involve people who have been actively editing wikis for many years, and who were part of the previous Flow conversations.

We need to involve people who run events for newcomers, people who staff the help desks, people who work on mentorship programs and content drives.

We need to involve wiki contributors who communicate with other contributors on off-wiki platforms like email, chat platforms and social networks, because they find wikitext talk pages too difficult.

We're going to organize a huge series of conversations in as many places as we can -- generating ideas, prioritizing and summarizing and synthesizing, entirely in public view. These conversations will help us to establish a rough general consensus that gives the Wikimedia Foundation a direction for one or more talk features that will help newcomers and experienced editors to communicate and collaborate together.

Yes, this is going to be very difficult, and no, we're not exactly sure how we're going to do that. That's what we're all going to figure out together. Please join us.

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 Flow.
 * Building on top of the existing 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.

Stages of the consultation
Over the next couple of months, the working group will develop a plan -- something along the lines of the Movement Strategy process, but on a much smaller scale -- that will help us to progress from one stage to another, with everyone understanding where we are and what's going to happen next.

Each stage should end with a clear summary of what we've decided, and that summary becomes the start of the next stage. People should be able to follow decisions backward, from the current stage to the previous, and the one before that, seeing a clear throughline that explains how the conversation progressed from one stage to another.

First stage: Problems and benefits. Generating the list of communication problems that we want to solve, and the benefits of talk pages that we want to keep. Goal is to come to consensus on problems and benefits, which helps us define a set of requirements and use cases. We should also arrive at a common definition of what "better" means.

Second stage: Directions and tradeoffs. It starts with the set of requirements and use cases. Generating possible directions for where the feature/s could go. This may also involve talking about tradeoffs -- one direction could solve problem A & B but sacrifices benefit C.

Third stage: Choosing a product direction? What does that look like?

Things to figure out

 * Translation / non-English discussions. We want to have as wide a consultation as possible, to include lots of people and ideas. Is there a way to include different languages in the same discussion (using translation), or is it possible to host some conversations in other languages? It would be great to have staff members or volunteers host discussions on a particular stage in a language they know well, and then report back with a summary that can become part of the English-language consultation, as well as links to the original conversations.

Nov 12, 2018
Something to think about: it's clear from discussions on the talk page and in the working group meeting that documenting the past projects is going to be an important part of this process. People want post-mortems, so that we can learn from the past. The question is: how do we assemble that material, knowing that there are varying perspectives on those events? Nemo says on the talk page: "Before asking the community to provide yet another round of feedback on the topic, it would be good to make sure that you have complete knowledge and unbiased summaries of what you already got in the past, which is plenty." Is there such a thing as an unbiased summary of the Flow & LQT projects?

The thing that I (Danny) would like to avoid is creating opportunities for people to re-fight old battles, bringing up missteps and old accusations, and leaving us stuck in the past. At the same time, we can't act like this is magically a fresh start, and that nothing in the past still matters. One thing that occurs to me is that rather than try to fashion a single "unbiased summary", we assemble a collection of people's points of view -- essays that express what each individual wants us to learn from the previous projects. I'd be interested to know what other people think.

Nov 9, 2018
We had the first staff working group meeting for this project yesterday, with 14 people attending. See Talk pages consultation 2019/Staff working group notes. Here's a summary:

This was an introductory meeting, the first time that most of the attendees had talked about the project and goal. There was no structured agenda, just an introduction, and then conversation ran in various overlapping paths. The conversation moved from big picture questions about how we run the whole project to some precise comments about specific technical ideas that we should consider. The next working group meeting, which will happen the week after Thanksgiving (Nov 26-30), will have a more defined agenda, as we start to put a plan together. We also need a dedicated note-taker. :)

In the last five minutes, we did a free-writing exercise to come up with next steps, and questions to consider. Some of the important things that came up:

Documentation is going to be a big deal. We need to collect and/or generate:
 * existing workflows & use cases for talk pages (a lot of this exists already)
 * non-communication use cases for talk pages
 * how different wikis use off-wiki communication
 * post-mortems on the Flow and LiquidThreads projects, with lessons learned

We also need to create a structure for that documentation, so that people can add and organize information.

We need to list key stakeholders, and make a plan to reach them.

A framework for the project is starting to come together -- documentation, outreach, generating ideas and opinions, then finding ways to cluster those ideas and start discussing tradeoffs. We need to talk to Design Research about how this kind of project is done.

Nov 8, 2018
We moved this project page from Meta to Mediawiki, on the advice of the Community Relations Specialists, who say that this wiki is used by more people. Mediawiki uses Flow on its talk pages, but using Flow for this consultation would send the wrong message. :) This page's talk page is a regular wikitext page.

There will be a lot of subpages for this page, and creating a new subpage will give it a Flow talk page. We can turn those back into wikitext talk pages by using Special:ChangeContentModel. That tool is only accessible to people with admin rights; we'll see how that goes and if we need to change that system.

Nov 5, 2018
The Community Wishlist Survey is currently running, and as usual, there are a number of proposals that relate to talk pages. Community Tech won't work on any talk-page-related projects next year, because the changes to talk pages will be determined by the talk pages consultation, and not through the Wishlist Survey. So -- fully aware of the irony here -- Danny is going to reject those proposals and take them out of the Wishlist Survey.

But obviously, those proposals -- and the discussions happening under each one -- are a part of this project, and we shouldn't lose the ideas, the information or the enthusiasm that people are bringing to those conversations. Danny is going to list and link them all here, so they can be part of the record of this process.


 * Add a search and ranking system to structured discussions (originally: "Improve Structured Discussions (Flow)"): "Add a search and ranking system to structured discussions (Flow). Many things could be added and corrected in order to have a better navigation between topics of a discussion page." Proposed by Prométhée.


 * Implement widespread autoarchiving: "WMF should provide community talk page archive bots, with a view to eventually assuming community bot responsibilities. WMF should provide an easy prompt to implement autoarchiving on talk pages (eg duration, number of remaining posts, and desired archive box)." Proposed by Tom (LT).


 * Release VE on Talk pages: "Currently VE is disabled on talk pages without any proper reason. This makes editing, especially for new users, more complicated. It would help a lot with regards for help to n00bs, if all wikipages could be edited in the same way. Now there is an artificial and not technically necessary Division between the article and the talk page." Proposed by Sänger, who also submitted a similar proposal in last year's survey: Release VE on Talk pages 2017. There's discussion on that page too.


 * Renovate all discussion pages - they won't be a wikipages: "turn on talks without wiki-technology in all talkpages (non-multiple-namespaces). Discussions will be like as comments on http://4pda.ru, http://habr.com or other sites with same design of comments. It is simple, laconic and functional. But don't loss the templates with {}, they will work. Ye, it's a rocket science. Renovate all mechanics of discussions! But... Really, we are the most popular site in the Internet, why we will look like a Soviet tractor? We will look like Yandex, Google and other top sites. Don't be a dinosaur!" Proposed by Фред-Продавец звёзд.


 * Reply link for talk pages: "New editors often have trouble understanding how to reply to comments on talk pages, or signing their messages, etc. Especially for editors used to the Visual editor, using talk pages and the conventions of using repeated colons is clearly confusing to new editors. We need a reply link functionality added to each comment, to make it easier for IPs and new editors to reply to comments on talk pages. While Flow was a disaster because it didn't integrate well with the current system in use, there is a much easier solution in the form of a current user script (en:User:Enterprisey/reply-link) which could be implemented globally to great effect." Proposed by Insertcleverphrasehere.


 * Link permanence and archiving: "Discussions on Wikipedia can be quite hard to track, this is especially true for those that took place at least a little while ago. This problem is partly caused because after a while most discussions are moved to archives, which immediately breaks links to sections. Currently to find the linked section, you'll have to extract the link from the URL and then dig your way through archives with the search function and CTRL+F. Doing this for multiple links is very time consuming and when you look at it again at another occasion you'll have to dive in the archives once again. Simplifying this would be especially useful for non-power users who don't know how to adequately search archives. One solution might be when clicking on a link to a section that no longer exists, it no longer redirects to the page but to the search page which includes both the original page as well as the title of the subheading. Of course this would exclude links to articles in the main namespace." Proposed by Kippenvlees1.


 * Make individual threads watchable: "The ability to "watch" individual talk page or forum threads, and receive notifications when people post to those threads, is required for use on forum pages with many active threads, such as the month-by-month sub-pages of https://en.wiktionary.org/wiki/Wiktionary:Tea_room, for example. The way it presently works is hopeless. If, like me, you participate in multiple threads over a period of time, there is apparently at the moment no feasible way of discovering when someone has posted a reply to a specific thread (unless the poster explicitly "pings" you, which usually does not happen), short of checking each one individually, which is clearly infeasible on a regular basis, or subscribing to the whole page and being deluged with irrelevant notifications." Proposed by Mihia.

Nov 4, 2018
This was Danny's scratch page of ideas for a while; it's now in a form that looks like a real project page, so this becomes a "we" project instead of an "I" project. The first staff working group meeting will happen soon, and we'll talk about what we need to do to get started. The working group meeting will be well-documented, with on-wiki meeting notes. Part of the discussion will include how to get users involved in the working group.

Oct 8, 2018
An interesting touchpoint on transparency and traceability, recommended to me by Peter Pelberg: Transparency Is the New Objectivity.


 * "You can see this in newspapers’ early push-back against blogging. We were told that bloggers have agendas, whereas journalists give us objective information. Of course, if you don’t think objectivity is possible, then you think that the claim of objectivity is actually hiding the biases that inevitably are there. That’s what I meant when, during a bloggers press conference at the 2004 Democratic National Convention, I asked Pulitzer-prize winning journalist Walter Mears whom he was supporting for president. He replied (paraphrasing!), “If I tell you, how can you trust what I write?,” to which I replied that if he doesn’t tell us, how can we trust what he blogs?


 * "So, that’s one sense in which transparency is the new objectivity. What we used to believe because we thought the author was objective we now believe because we can see through the author’s writings to the sources and values that brought her to that position. Transparency gives the reader information by which she can undo some of the unintended effects of the ever-present biases. Transparency brings us to reliability the way objectivity used to." (David Weinberger, Joho the Blog)

Oct 3, 2018
One of the big concerns that the working group will have to figure out is the possibility that a small group of very active people will dominate the discussion, and less active/more quiet people will be left out. I think one answer to this problem is to not have one single discussion -- but instead have a constellation of different inputs and bring that together.

Oct 2, 2018
It's time to get this page into a real shape, and turn it into a project page that we can use. It's now the beginning of October; we'll need to form a staff working group and start to plan. Right now, I'm going to write down all the random notes that I've jotted down, and then organize the page.


 * Working groups: We start with a staff working group, to figure out how to structure the process. There are a lot of things to figure out, listed below.
 * When and how can we invite people from the community to be part of the planning process?
 * Full documentation of the process starts with the first staff working group meeting. How do we record things?
 * Bringing people into the conversation who care about the new user experience
 * Hosting conversations in multiple languages
 * Hosting conversations at meetups & regional conferences
 * Designing for mobile as well as desktop
 * Looking at communication that currently happens off-wiki
 * Also: questioning the decisions that have been made so far.


 * Principles of the team
 * Traceability and transparency for all conversations and decisions.
 * Respect for all participants.
 * Sincere desire to learn.


 * The 2 problems with the Flow process that led to trouble:
 * Making decisions outside of the public view, deciding on tradeoffs that we didn't have consensus on.
 * The desire to solve everything with one tool. This is not necessarily the right answer, we may need different tools for different kinds of conversations.


 * Traceability: writing down notes and summarizing each step, making those notes and summaries public, and then making sure that the next part of the conversation begins with the summary of the previous conversations -- without taking ideas out, or making priority decisions outside of the public view.


 * The goal of the consultation, part 1: A clear direction, by June 2019, so a product team can start working on the feature(s) in July. That means an understanding of the different options, with pros and cons, an understanding of the tradeoffs, and a rough consensus that we can start testing and designing and experimenting with.


 * The goal of the consultation, part 2: Trust, broadly construed.


 * Measurement: How do we measure the quality of communication that we want, as well as the quantity? It's easy to come up with quantitative goals for this project -- more people, more conversations, more messages. It's also important to build something that supports intelligent, thoughtful conversation rather than chatter.

Sept 25, 2018
Two problems with the way Flow was introduced: #1) it was presented as a fully-baked concept, #2) it was going to be one tool that worked for all use cases (with modifications). We should approach this consultation with the expectation that different use cases may require different tools. The many conversations about indentation depth were a proxy for whether the tool was going to work for big, complex conversations too.

Aug 9, 2018
A good idea from Sydney P. in an Anti-Harassment Tools meeting -- she's had success bringing people into the discussions about per-page blocking tools using Twitter. Surprisingly, a notice at the top of the Special:Block page didn't work, but social media did. We should make sure we use various social media platforms to bring more people into these discussions.

Aug 6, 2018
Something to think about: lots of people that we met at Wikimania from non-English wikis use social media to communicate with other users -- Facebook messaging, WhatsApp, Google Groups. Why are people using these services, rather than wiki talk pages? We're not going to "win" by making a better chat platform than Facebook; they've pretty much nailed what they do well. But we should explore why people use off-wiki communication systems -- what features are people looking for?

A similar question: on big wikis, I think there's some contention around on-wiki conversation about content vs conversation that's personal and not specifically wiki-related. This is an important area to explore: what are we optimizing for? Marshall knows examples of languages where the conversations shift naturally from wiki to personal and back to wiki. If we make it easier for people to make friends on wiki, then they'll want to be able to get to know each other, without getting slapped for going off-topic.

Filed a ticket for Community Relations support: T201375. Includes a rough timeline, as follows: In September, we'll put a cross-functional working group together and plan the structure of the consultation. Plans will take shape over the course of a few months, including gathering input from various communities on the proposed structure. The first phase of the actual consultation will start in January/February 2019, and will probably run until June. First steps on this ticket will be conversations between Danny and CRs, to figure out the pre-planning and source the cross-functional working group.

July 21, 2018
From conversations at Wikimania: Let's say (for the sake of argument, not a proven fact) that Flow was "better" at one-to-one user talk and project talk conversations, but not "better" at big complex discussions like RfCs. It should be a principle of our work that anything we build needs to be demonstrably better than current wikitext talk for that specific use case. If there's no difference between the current tool and a new tool that we build, then we might as well leave the current tool the way it is. This should apply to each use case.

Also, we obviously need a consensus on what "better" means. That should be part of an early stage (first or second).

July 18, 2018
Creating this project page, so I can talk to people about the project at Wikimania.

June 11, 2018
Talked to Guillaume, who worked on the 2017 Wikimedia Movement Strategy process. The talk pages consultation will be much smaller -- we're not setting up live conferences in various countries. But the big picture is similar -- bringing together a lot of disparate communities, to generate, distill and prioritize ideas, so that everyone's ideas are heard, and we come to a consensus that everyone can support.

People participated because we don't know what it was going to be. First - very open - what will the world look like? People could opt out and go next time. People need some open space, could be completely divergent. Finding commonalities, summarizing -- end up with a list of findings to cluster. Take out irrelevant stuff, cluster everything if you can.

Resources? 19 starting coordinators: 16 with one primary language community, 3 with a few more communities. Get input from not just the usual suspects. Community could have a discussion in their own language and their own style -- coordination was the link between discussion and the central process.

Assuage fears that everything is on the table. Start with difficulties you have in communicating with each other, rather than difficulty with a tool. We want to help the communities, and not just build a tool we want to impose on them.

Traceability is key. The end of one cycle links up with the discussion of the next cycle. People should be able to trace back, go back through the process to see where an idea came from. This gives credibility.

Process advisory committee improves the process, gives legitimacy. Document these discussions, post detailed notes.

One of the outcomes is building trust, the process is also a goal. Had to move slowly sometimes to make sure people are heard. Clear roles and responsibilities, having regular retrospectives facilitated by someone not on the team.

Don't get attached to the baby you're creating. Be more attached to the process.

Be clear -- is this going to be one thing in the end, or multiple based on local communities? Is this something that you have to get on every wiki?

Have some non-negotiable principles, as the basis of discussion. A red line that we won't cross. Not too many.

'''First agree on the principles of the process. '''

The whole movement includes people who aren't yet part of the movement.

Coordinators asked communities when and where they wanted to be included -- some on their own wiki, some preferred on Meta because the village pump was for internal business. Give people as many ways to be consulted, without overwhelming people. Mailing list, weekly message, monthly message -- give people opportunities to set their own appetite for information.

Groups to include: chapters and usergroups. Especially user groups who do training, editathons. They can facilitate discussions with volunteer communities. Summarize conversations and document on wiki.