Talk pages consultation 2019/Staff working group notes

November 8, 2018
Attending: Danny Horn, Jason Linehan, Marshall Miller, Quiddity, Trevor Bolliger, Whatamidoing (WMF), Ryan Kaldari, Adam Baso, Joe Matazzoni, Rita Ho, Gergo Tisza, Stephane Bisson, Amir Aharoni, Corey Floyd

Goals:
 * Introduce the project, goals and approach
 * Ask and answer questions
 * Generate more questions and next steps

Introduction: Alchemy

Danny: Alchemy is an ancient protoscientific tradition, which people commonly think of as people trying to turn lead into gold. The thing that people don't understand about alchemy is that they weren't trying to get rich; it wasn't a money-making operation. The alchemists wanted to turn base lead into pure gold because they thought it would purify their souls, taking flawed people and making them spiritually pure.

The "Talk pages consultation" project is an alchemical process. It's about making a better communication tool, and it's also about making us into better people -- more collaborative, more curious, more sincere and more trustworthy. This process is only going to work if we hold ourselves to this higher standard.

Now, historically, alchemy led to three things -- failure, medicine and gunpowder. I'm hoping that we end up with medicine, but you never know.

The ultimate goal is to produce functional conversation tools that work for all the volunteers.
 * Marshall: This is not just about “fixing Talkpages”, but really how to improve communication in general.
 * Corey: +1 prefer broadening the concept to "Communication".

Flow strategy

Danny: The strategy was to enable Flow on the smaller and mid-sized wikis. Improve it on wikis where people want it, in the hope that it would become so good that everyone (e.g., established editors at enwiki and dewiki) wanted it. This strategy is not working.

Two problems in Flow's early development that hurt its acceptance among established editors:
 * The design and development was done in office, with some users involved but not in public. For many users, it appeared out of nowhere, with a "big reveal" at Wikimania.
 * It was supposed to be one tool that fit every use case, but it clearly didn't, the way it was designed. People saw it as something that had to be stopped at all costs, before it bulldozed all of their workflows.

The 2019 talk pages consultation

When: Starting in February 2019. Likely to require multiple years to develop any products.

Who we want to reach, in addition to the existing core communities members:
 * Volunteers who work at Teahouse and other new-user forums
 * We'd like to hear from newcomers themselves, but that group has historically been difficult to reach, so we are hoping that established volunteers who work with them will represent the needs of newcomers.
 * Movement organizers, e.g., people who organize edit-a-thons
 * Editors who use off-wiki communication systems, such as IRC, Facebook, or Whatsapp, in preference to existing talk pages
 * People from as many languages as possible
 * People who use mobile devices
 * Contributors on the non-Wikipedia sister projects, including Commons, Wikisource and Wikidata

Open and participatory product process.

The central project page will be on MediaWiki.org, but this will inevitably involve discussions on other wiki pages and off wiki.

Traceability of decision points. Discussions will be in public and traceable. We'll post notes from any offline discussions (including this meeting).

Possible outcomes: All options are on the table. Editors might need multiple, separate solutions. For example, huge complicated discussions might need a different solution from one-on-one conversations.

Corey: Software-wise, the goals are consistent with some old work: threads, topics, summaries, etc. Are we saying we might throw the existing stuff away?
 * Danny: We could build something on top of existing talk pages. We could build something new. We could build something with parts of Flow, or turn Flow into something. One idea that's appealing to me is that we might find we need different tools to match different use cases.
 * Roan: I feel good about redoing the software. It's got some bad code, and it wasn't designed with incrementalism as a priority. We do need to be able to migrate Flow/LQT discussions to anything new, but everything else is possible.

Product process

1). Define the problem you want to solve


 * What are the problems with existing talk pages that we want to solve?
 * What are the good features of talk pages that we want to keep?

2). Important use cases
 * Researching the existing off-wiki channels might produce useful information about desired features.

Kaldari: The key is understanding the use cases. It will become obvious what the solutions should or could be.


 * Rita: Looking at how other wikis are using offwiki comms channels, we should research how effective they find using it. Opportunity to also connect and speak with newer editors via these places (especially for user testing of whatever it is we end up trying).


 * Quiddity: Partial semi-related list at bottom of Social media plugins


 * Danny: We're not going to be better than Facebook at getting people to talk, but we can definitely learn from them and be better than we are.


 * Corey: Are we planning more market research? We don't necessarily want to invent a brand-new thing. We should learn about existing external platforms.


 * Rita: +1 not just Market research, but if we could also do user research or pull data on how these off-wiki comms channels have impacted contribution and communication on the language wikis that are actively using these other tools (e.g., the Arabic Wikipedia, which uses Twitter, Facebook, and Instagram).

Corey: One difficulty of anyone trying to communicate is finding all the existing comms channels.

Communication has immediate components ("Let's do this today") as well as long-term documentation benefits ("Why did they do that, last year?").


 * Marshall: Social media thoughts: People aren't just using social media because regular talk pages are difficult, but also because "that's where people already are". Maybe in the far-future there's some way to take advantage of somehow integrating, or leveraging the fact these systems and communities exist, as opposed to trying to compete with them. Don't write off any options.


 * Amir: Historic search is crucial part of why onwiki is key.


 * Danny: Consultation steps will be making lists of good and bad points of existing talk pages.

Kaldari: Talk pages are not just for discussions, they are also repositories of information. Making things searchable, archivable. Workflows for facilitating other workflows. We might end up with various tools, with parts that are needed in different situations.


 * Joe: Possibly, some things used on talk pages make move to other systems (e.g. WikiProject categorization). Right now WikiProjects and other classifications are on the talk page. Is that a good thing?


 * Roan: No, it’s a bad thing! It breaks things like searching for content using WikiProject categories, because you’re searching the talk pages instead.


 * WhatamIdoing: There's been a proposal for years to move WikiProject categories and similar data into real metadata. There’s a trade-off with temporary pain at the larger wikis as some tools (such as the ArticleAlerts bot at enwiki) will need to be rewritten, but some of these changes will be better for everybody in the end.


 * David: Wikidata puts Property documentation on the talk page: https://www.wikidata.org/wiki/Property_talk:P18#Documentation

Trevor: Relationship between on-wiki and off-wiki is always difficult for anti-harassment. Whatever we build, day 1, should have a report/take-down/moderation feature(s), absolutely critical.

Stephane: Past research on existing uses of talk pages shows significant diversity.


 * Quiddity: See Flow/Index and other research and especially Flow/Use cases.

Marshall: We can start with listing what people use talk pages for, those can turn into user stories. For example, people use talk pages to display the status of their project, but that doesn’t fundamentally require talk pages.


 * Danny: I want the communities to tell us what they need from talk pages.


 * Amir: One area we can learn from is analyzing which templates are frequently used on talk pages, commonly not the same as the ones used on articles. I don’t know how much template use was analyzed when designing Flow – I think at least some on some wikis, but not very comprehensively.


 * Quiddity: The idea for Flow was initially for it to be a modular system that the communities could use to build workflows. It would have semi-standard components for cross-wiki familiarity and maintenance, but with local adjustments for their particular setups/needs. Smaller wikis could recreate the complex systems that large wikis have, and large wikis could upgrade from community-maintained custom and duplicative tools to something WMF-supported and easier/faster for non-technical people to use and build upon. Small wikis wouldn’t need a technical person, because they would use a wizard to create a wizard. The blocker on enwiki was that it was never gonna be accepted until all workflows that were already taking place on talk pages worked in it.

3). Talk about possible solutions & tradeoffs

For example, an existing solution might use filling in a template or a category, but that could be replaced by a built-in specialty tool. Does everything need to be supported from the beginning, or could a partial approach improve communication now, and more features be added later?

Joe: this sounds like a really big project that would unfold over multiple years. Just maintaining Flow, without adding any new features, took up like a third of a development team’s bandwidth. Because it's an alternative wiki system, it needs to be made to work with all existing systems.


 * Roan: This is like building the Sagrada Familia cathedral. People are still building that cathedral, but they're using it now.  One problem with Flow was it didn't have a plan compatible with incrementalism. Like boiling the ocean:  none of it will start boiling until reached boiling point. Flow had to reach all use-cases before it could be welcomed by some communities.


 * Joe: Thinking about incrementalism, one of the types of things we could think about is Flow modules that can be inserted into existing wikitext talkpages. A hybrid approach.


 * Gergo: There are other communication channels wiki editors use (IRC, email) to cover different use cases like real-time communication. There is no inherent reason those have to happen outside the wiki, they just do because current talk pages are so hopelessly bad at supporting them. Are those use cases within scope?


 * Danny: As our communities scale up, it's like New York City: it's a ton of people, and they all have different interaction methods and different needs and priorities. They have their own ways of dealing with the deluge of information, in every office and street corner.

Do we need mostly small changes or mostly large changes?


 * Roan: Here's a concrete example of iterative way of fixing wikitext discussion: T128535: make pings work with parser-function instead of template-based mentions. I hope this stokes your imagination about the things we could think of doing.

How much emphasis to put on intra-wiki vs inter-wiki communication?

Corey: We have all the different projects, everything is so separate and it's hard to get cross-wiki communication.


 * Quiddity: Cross-wiki topics was an original goal of Flow. Social complexities were the main reason it didn't get past the idea stage, i.e. how (each community would want) to handle the case of someone blocked on wiki A who tried to comment in a discussion that was shared between both wiki A and wiki B.


 * Corey: Content supported by groups like WikiProject Medicine would benefit from better cross-wiki communication support.


 * WhatamIdoing: If we had cross-wiki communication, we wouldn't have needed the Commons Deletion Notification Bot wishlist item. Commons deletion discussions could have been posted simultaneously to all affected wikis in full.

Things we need to figure out

Trevor: I'm thinking about the movement strategy. There were people where all they did was own the documentation process. (Tech writers?) Practically, how should we organize all this information?


 * Joe: We need dedicated notetakers and organizers and ambassadors and facilitators. Will there be contractor budget? Is there money for translation?


 * Danny: Maybe it will be possible to hire contractors. We would need a clear plan in order to ask for such budget.


 * WhatamIdoing: Will there be a specific product manager who will work on this full time?


 * Danny: I'm leading the consultation, hopefully with support from a number of people. When it comes to designing and experimenting with a new feature, it'll have a team, probably starting around July, if things are going well.

Marshall: Along lines of planning, good to consider upcoming community events where we can bring this up? All Hands?


 * Kaldari: Most of us don’t perform complex workflows like archiving discussions or AFD, we have to listen to those who do.

Next steps

Danny: Step 1 of consultation is clear: Getting lists of pros/cons from all the diverse stakeholders. Step 2 is finding possible directions. We need clearer ideas about how to structure Step 2. We can look at the Movement Strategy process, but how else?


 * Joe: Need to make lists of use-cases at same time as problems to solve.


 * Danny: Let's make a list of people to talk to, things to read, or questions to consider.  Just quickly add whatever you think needs to be done.

(The following list was a "free-writing" exercise for the last five minutes of the meeting. People were asked to write down ideas for next steps, and questions to consider.)


 * Document existing workflows/use cases to get a full picture of the “problem”
 * Determine organization structure of documentation, decision making and traceability
 * Consider which scenarios for the use of discussion pages could be moved away from talk pages and unified (at least partly) among different projects (even though the policies may be different at the moment): Page deletion, Administrators appointment, RFC, etc.
 * Do usertesting.com tests with people who are new to wikis and ask them to use a talk page. This will generate clear indicators of where newcomers struggle with talk pages.
 * And check what we already did, e.g. https://www.mediawiki.org/wiki/Flow/Moderated_Testing,_November,_2014:_talk_pages_and_Flow
 * Meditate on the notion that some experienced editors will reject all innovation in any case :)
 * Brainstorm ideas for small interventions to the current talk pages in the meantime? E.g. turning into a parser function.
 * Make detailed list of all key stakeholders, how to reach them, and who will be main contact facilitators.
 * Post-mortem of Flow, to elucidate what we've learned from it so far.
 * Post-mortem of LQT, to detail what we learned from it back then.
 * Start getting the project pages translated and try to get into a rhythm of translating them regularly.
 * Staff can list some of our community contacts who would have good perspective on this from multiple communities.
 * Ask Audiences staff to list the ways in which changes to Talk pages or communication would affect their team’s features and work.
 * Move the page to MediaWiki.org (and disable Flow on its talk page). Done :)
 * Contextualise how this project would fit into existing 3-5yr planning and annual plan outcomes – this would be helpful in determining resourcing and assigning to it to a properly staffed project team
 * Decide on a mobile-first policy for all design and development around this project.
 * Consider making good mobile support one of the central goals for the project.
 * Draft a design/product planning document outlining the goals, use cases, and users for whom we want this new “Fix Talk Pages/Improve onwiki communications” project to solve. Something we can share with the communities relatively early so they can collaborate on it (e.g., help identify use cases we’ve missed).
 * Propose as priority topics for the Design Research Strategy team (Margeigh et al) to research - items listed above such as: post-mortems on past projects, user testing, reviewing off-wiki comms usage on other language wikis, etc.
 * Re-analyze the difficulty of importing existing wikitext talkpages into a half-structured system. - The prospect of Tabula Rasa was a nightmare for the larger wikis. Even if it's only "1 thread into 1 comment", that's better than nothing.

Closing

Danny: It's really nice to see everyone being optimistic and excited about this project. It's going to be big and weird and difficult, and I'm really glad to see that people want to be involved.