Talk pages consultation 2019/Status updates

These updates are from the planning stages of the 2019 talk page consultation. More recent notes can be found at Talk pages consultation 2019.

Jan 2, 2019 (part 2)
Okay, more updates. Danny met with folks from Community Relations the week before holiday break -- Benoît will be the primary person working on the project, with support from Sherry (Whatamidoing) and others.

We're currently putting together a staffing plan for the project, starting with a list of roles that we need people to fill. This will include a logistics manager, keeping track of the schedule and deliverables -- probably a part-time contractor that we'll hire.

We'll also need people to:


 * organize and update the documentation
 * lead the writing of the post-mortems on LiquidThreads and Flow
 * reach out to wikis and user groups
 * facilitate conversations (multiple wikis and languages, on-wiki and off)
 * collect, summarize and publish notes and takeaways from discussions
 * synthesize themes and produce deliverables for each phase

Those are big tasks, and each will probably be filled by multiple people -- hopefully, a mix of staff, contractors and volunteers. We'll discuss this some more internally, and then put out a call for folks to fill various roles.

Some of the action items coming up include:


 * Define the overall consultation structure, scope and intended output
 * Establish the structure for project pages and documentation
 * Define a code of conduct for the consultation
 * Identify wikis, languages and user groups to reach out to

We're also talking about how to define participation guildelines and a code of conduct for the consultations, so that everyone feels comfortable participating.

That's what we're discussing right now, more info and updates will be coming.

Jan 2, 2019
Coming back after holiday break, catching up and making plans!

Danny posted the notes from the second staff working group meeting: Talk pages consultation 2019/Staff working group notes. Major points include:


 * Medium-term goals: what do we want by the end of the consultation process? The idea is "rough consensus" (actual definition TBD) that we have a product direction that a team can start experimenting with, ideally by July but not bound to that deadline. Major points will be settled -- are we building one thing, or two? is it building something new, or modifying something that exists?
 * Staffing plan: Danny and Benoît will work with Community Relations Specialists, and Toby and Maggie, to define staffing requirements. We will have money to hire a contractor, we need a plan & a job description to begin that process.
 * Post-mortems: We'll need to gather documentation and research on talk pages, Flow and LiquidThreads, and do post-mortems on previous projects. We discussed possible approaches to this; it's still an important open question.
 * Defining stakeholders, and how to reach them: We have a commitment to the 2030 movement strategy, and the Knowledge Equity goal is especially relevant to this project. We need to build tools that break down barriers for diverse communities. That means we have an obligation to include small wikis and big wikis, people who currently use wiki talk pages and people who currently use off-wiki communication tools. We're not building tools for "everyone in the world," but we are building for everyone who wants to contribute to our projects.

Danny also talked the week before Christmas with Benoît, Erica and Quim; notes & action items from those discussions coming soon.

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.