Talk:Talk pages consultation 2019

Put previous feedback into use before asking more
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. For instance, the LiquidThreads component offers experience from a product which has been in large scale usage for several years. Acquiring this body of knowledge would have avoided tons of problems to those who worked on the following projects. --Nemo 11:53, 24 August 2018 (UTC)
 * (Note: This question was answered below; see the bottom of the "Process" discussion.) -- DannyH (WMF) (talk) 08:31, 6 November 2018 (UTC)

Dead horse slip-slidin'
Not sure where to 'raise' this formally now (as main page has no notice-link to the NEW current-issues list)... and not wanting to open old issues/wounds again just for fun... and by the brief text-search of the current Proposals-list as well as a few current Structured Discussions pages and their um, discussions (Can't search ALL most-recent pages since no sort-by-date) this may amount to not just beating a dead horse again, but rather, resurrecting it first, then watching it suffer a long, sad death, and THEN beating it again (though hopefully it can go happily out to pasture instead this time) -- it seems that one rather significant part of the talk-page interface is no longer a point of contention for some reason, though all the objections given here so long ago still apply:

https://www.mediawiki.org/wiki/Topic:Ru6ekdxsuqyyvqpx -- or for those who cannot read MWuIDese... "Infinite scroll is seriously annoying" -- (See post for more refs.)

Note there is at least one external module with a setting to independently determine if it uses this, so it seems it is NOT hopelessly integrated into the base wiki software: $wgPageTriageInfiniteScrolling: "Whether or not to use infinite scrolling in the new pages feed"

Also, it should be kept well in mind that though laptops and phones do have basically the same shape of screen (...NOW, "thanks" to forced 16:9, really ~2x1) they often have completely different orientations: laptops being ALWAYS 2x wider than tall; and phones, when held most conveniently, always 2x taller than wide. (Tablets should do both equally, so not a concern; and desktops are more like laptops here.) Therefore, there will likely ALWAYS be much wasted space or much distortion, or both, no matter what shared interface format a webpage might use, and thus the best plan it seems would be to have strictly separate "desktop" and "mobile" (front-end GUI) formats (like eg: BestBuy.com > "Mobile Site" / "Full Site"), and NOT try to find various compromises between the two (like Structured Discussions, forced infinite-scrolling, horizontal scrolling, Material Design, etc.), which instead just impair or spoil one or both.

Wikicat (talk) 16:16, 16 November 2018 (UTC)


 * Hi : Thanks for your thoughts. I think "infinite scroll" as a solution was meant to address a few problems -- that manual archiving is awkward and haphazard, that it's not always easy to tell which conversations are still active, and that searching for an old discussion is really hard. I agree that that solution came with its own set of problems. This is definitely the kind of thing that we'll be talking about in this consultation. Your point about the mobile/desktop problem is also good; we'll have to talk about that too. Please stick around -- we're still in early planning, but before long we'll need people to help identify as many dead horses as we can find. -- DannyH (WMF) (talk) 17:20, 16 November 2018 (UTC)

Usage of social media
Drawing discussion participants from Facebook, Twitter or other social media, and especially those with algorithmic feeds, sounds like a recipe for disaster: the filter bubble encourages groupthink and lack of diversity in discussions, which is going to bite later when the result eventually needs to reach the real world. --Nemo 11:57, 24 August 2018 (UTC)
 * Hi Nemo, I think that reaching out on social media for participants will give us a wider selection of people to talk to. There are a lot of wiki contributors who use social media to connect with each other -- sometimes instead of using talk pages, which is something that we need to hear more about. English WP takes kind of a dim view of social media, but other wikis are using it a lot -- for example, Arabic WP has links at the top of the main page to the official Arabic Wikipedia pages on Facebook, Twitter, Instagram and YouTube. I think talking to those folks will give us some interesting perspectives on how (and why) they communicate off-wiki. -- DannyH (WMF) (talk) 14:35, 22 October 2018 (UTC)
 * DannyH (WMF) I definitely understand the interest in reaching out to editors who also communicate off-wiki. However I think you underestimate the problem of using social media, with the appearance or actuality of calling in people who don't edit and have no likelihood of ever becoming editors.


 * If you want to target editors who also communicate off-wiki, could you try to find a way to target them with on-wiki advertisements instead of social media? Alsee (talk) 17:34, 22 October 2018 (UTC)
 * Hi Alsee, I think the goal of reaching out on social media would be to reach existing editors who use those platforms. Editors who also use other websites aren't scary intruders; they're still part of us. I've heard a bunch of anecdotal stories about committed editors in various languages who prefer to use other platforms to communicate. I think it's important that we include those people, find out about those stories and use cases, and learn from them. -- DannyH (WMF) (talk) 00:39, 23 October 2018 (UTC)
 * DannyH (WMF) it created confusion when I mixed a semi-related topic into my post. Please review the refactored post above. I think you'll see that that I didn't suggest any editors were "scary intruders", and that I welcomed your goal of contacting them. I only asked you to reconsider the means of reaching out to them. Alsee (talk) 16:05, 26 October 2018 (UTC)
 * In addition to what Nemo bis said, there is also the issue that discussions on Wikimedia projects are not just random chat but serve specific purposes. Their purpose is to get stuff done, not simply to exchange opinions. That means for example that we need ways to get rid of unwanted conversations and ways to close down discussions which have served their purpose but there are other aspects as well. Jo-Jo Eumerus (talk, contributions) 08:43, 7 November 2018 (UTC)

Hello, let me tell where I came from idea-wise. I often prefer communicating about general topics on Facebook ("Wikipedia weekly") than on Wikipedia. Maybe because of the push media features of Facebook, but maybe also because it is moderated by Andrew and there is a much higher level of civility. Also, I don't like to converse with IP users. So, we have to solve on Wikipedia not only a technical issue but also a social one. Ziko (talk) 15:59, 16 February 2019 (UTC)
 * +1 - the on-wiki talk has degenerated into automated templates and adversive direction, not collaboration. no code of conduct. gaming of venues to affect minority policy outcomes. people will go where there are friendly moderators. Slowking4 (talk) 21:02, 20 February 2019 (UTC)

Target audience
(This section split from previous section, to improve clarity)

Consider the following two pictures of airplane cabins:

If you grab five random people off the street and ask them which plane they'd rather fly in, all five are going to point to the picture on the left. That is how the foundation's user-testing often works. And then you run into a problem. Various editors show up, all saying they want the one on the right. Even more mysteriously, all five are ranting against the seats... they want to either sit on the floor or sit on bare benches. I'd like to explain why. The foundation keeps aiming at the wrong target audience. Writing an encyclopedia for fun is a very odd hobby. Kinda like skydiving. If you're running a skydiving-foundation, your userbase is going to choose the picture on the right. The seats get in the way. They don't want a lumbering jumbo jet. They don't want an in-flight movie. They don't care if the cabin looks pretty. They want to jump in, they want to get to altitude, they want have plenty of room to move around and check their parachutes, and they want to jump out.

The picture on the left is Flow/VisualEditor, and the picture on the right is Talk/Wikitext editor. When you survey random people off the street, they point to the picture on the left. But your userbase keeps choosing the picture on the right as the better tool for the job. They get upset when the foundation tells them they're supposed to use the plane on the left. The plane on the left was built to try and bring in new skydivers. Unfortunately that plan hasn't worked. The most luxurious jumbo jet with first-class seating brings in exactly zero new skydivers.

Surveying or user-testing the general public provides bad data. Your target audience are current editors and future editors. Even if you could magically survey future editors, they have no basis to meaningfully answer your questions. Alsee (talk) 17:34, 22 October 2018 (UTC)

Process
DannyH I have serious concerns about the process. I have a million things I want to say, but I'll try not to get too long.

A significant point on the page is trust. I want to start by saying I do trust that people at the WMF has good intentions. What I do not trust is WMF's understanding of how to run a successful consensus process. Previous consultations do not inspire confidence. I'll list some hopefully agreeable points: Alsee (talk) 02:41, 14 October 2018 (UTC)
 * 1) If you want more trust, you also have to trust the community. You said Bringing people into the conversation who care about the new user experience. No matter how politely it's phrased, I hear implicit denigration of everyone who has participated over the years. Please respect that editors were sincerely advocating to protect new users from what they believe was a harmful product. Please respect that they represent the majority mainstream view. Multiple core communities overwhelmingly concluded Flow was harmful, and a WMF survey also yielded results heavily against Flow (despite being massively votestacked with Flow-enthusiasts). Maybe the community did a lousy job explaining their reasons, maybe the WMF did a lousy job listening. Either way, please avoid the ideas that experienced editors don't care about new users, that they're an enemy or obstacle, or that discussions would be more agreeable if you could find someone else to talk to instead. There was also a comment about the usual suspects. Any "usual suspects" who represent prominent or prevailing community views are exactly who you need to engage as key representatives of the community.
 * 2) It is exceptionally difficult to build consensus around a question as vague, important, and contentious as what to do about Talk pages.
 * 3) The community has more experience and expertise in the processes of building, evaluating, and establishing a consensus than the WMF. Please consider that an asset. I am especially concerned about expecting staff to distill one stage into the next. Please don't underestimate the importance or challenges of this task. It's not an easy or common ability to distill the views of others, independent of one's own opinion. I would suggest en:wp:ANRFC as the best place to find people with experience and well-tested aptitude to help in this kind of task. I'd also suggest I'm good at it. Important note: Having things be "traceable" is absolutely worthless if those things never reflected consensus in the first place.
 * 4) You can allocate time, but you can't schedule a genuine consensus on a timetable. Conventional top-down authority structures (including the WMF's internal organisation) have a normal expectation for planning and timelines. When a deadline arrives, someone in an authority-position issues a final decision. Consensus does not work like that. No one will respect a decree by assertion of authority. You'll just end up with another expensive disaster. Consensus is an organic thing. Sometimes there's a latent consensus that manifests as soon as a question is asked. Sometimes it takes extended discussion to narrow down the viable range of potential consensus, and then discussion to build consensus around something specific. Sometimes there's general opinion that the current situation is "bad", but extended discussions manifest no consensus that any of the suggested alternatives are better than the status quo. I urge you to redefine expectations as "We're scheduling X time for this, we'll see how it evolves". The goal is to try to craft a proposal that draws forth a genuine consensus.
 * 5) Regardless of any list of "requirements", you have to actually flesh out a design for proposal. And 'design proposal' isn't just a list of buttons you plan to build. Flow died the moment it was disclosed that it was being build on a Visual architecture and (maybe) partial/broken wikitext support would be glued on. The 2017WikitextEditor similarly imploded when a TEXT editor was covertly designed inside the Visual engine. Those were major and highly relevant design decisions that directly impact the functionality and user-experience of the final product. If there is any aspect of the plan that might be controversial, it's better to get it out in the open as early as possible.


 * Hi Alsee, thanks for writing. I also have serious concerns about this process, so I'm happy to have someone else to talk about this with right now. I think this project is bigger and more open-ended than anything I've done here at the Foundation, and it's daunting, for many of the reasons that you mention. I'm not sure how this is going to end up -- whether we'll be able to find consensus or not, whether we'll get a good sense of direction. Right now, I'm trying to live with that as an open question, and be open to the experience as it develops.


 * I totally understand where you're coming from as far as trust and "the usual suspects". This is going to be a hard thing to do, having people (like you and me) who have been on opposite sides of previous encounters, coming into this process with hope. I don't actually expect either you or I to specifically trust each other right now. Trust is something that you build over time, and the only thing you can do is act in a trustworthy way, and then wait until trust happens.


 * As far as "bringing people into the conversation who care about the new user experience" -- I agree that I was making a distinction there between the people who are automatically going to be a part of this process because they're involved with everything, and people who are specifically working on new user mentoring programs, who don't necessarily show up for every big wiki consultation. I can see how that suggests that the "usual suspects" don't care about new users; I need to keep that in mind, and not make that assumption.


 * I totally agree that the previous strategy for Flow was to leave the communities where people objected to the concept, go find someone else to work with, and then use that progress to make Flow "inevitable" on the wikis that don't want it. That was absolutely part of my strategy when I was working on Flow, and that's the strategy that I don't want us to follow anymore.


 * What I want is to talk to and consult with as many people as possible, in order to come up with a real direction for this problem. More people means more ideas, and more discussion, and I think that will ultimately lead us to good ideas. If you want to be a key representative of the community, then that's okay, but it would be great to actually talk to lots of people, rather than to a representative.


 * Regarding the difficulty of distilling complex conversations into a summary: that's a really good point, that there are people in the community who are especially skilled at that task. I'm glad you pointed that out. Now that you say that, I realize that I don't actually want to be the person who makes those summaries; it's way better for other people to do it. No matter what we do, I want everything to be available -- the original conversation or meeting notes or whatever it is, and the summary -- so that anyone can look at the full content, and correct things, or suggest rewrites. But I haven't thought much about the specific logistics of that yet. Thanks.


 * For the timetable -- yeah, I agree that this is going to take a long time, and I currently have no idea when this is going to come together as a consensus -- or if it's even going to work at all. I have made no promises about that, to anybody. This is a critical problem that we absolutely need to solve, but as you say, big consultations with lots of people on lots of wikis (and hopefully in several different languages) are huge and unpredictable. I don't actually know if this is going to work. I just know that the stuff we were doing before didn't work, and this feels like a more positive direction.


 * For your last point about fleshing out a design for the proposal -- yes. My plan is for every step of this process to be completely open, to a ridiculous and annoying degree, all the way from now until whenever we finish building whatever we build, and beyond. The only way that we're actually going to get anything done is to do this in full public view at every stage. I can't promise exactly how it's going to go, because it's unpredictable and frankly a crazy thing to do, but I can say that there should not be any steps in this project, at any stage, where staff members make decisions that we don't document, explain and have open discussions about. That is admittedly a terrible plan, but I think it's the only way to do this. Thanks again for your thoughts. DannyH (WMF) (talk) 00:57, 20 October 2018 (UTC)


 * DannyH (WMF), thanx. That all sounds good. If possible I'd like to be in the loop when there is further planning.
 * Separate from process planning, I have some (potentially long) thoughts on why the product wasn't well aligned with the community. However I'm not sure if it would be helpful or a distraction to get into the consultation-topic itself during the planning stage. Alsee (talk) 05:06, 22 October 2018 (UTC)
 * Hi Alsee, thanks for the offer of help. My current plan is to get this page into shape over the next few days, have a couple meetings with a staff working group next week, and then start inviting volunteers to join the working group a few weeks from now. If you want to write down your thoughts about Flow, and what you think should be done in the future, feel free -- maybe start a subpage of this page, for now? I hadn't thought of it before, but we could have a section somewhere with a collection of people's essays. -- DannyH (WMF) (talk) 14:07, 22 October 2018 (UTC)


 * No planning, however generic, can start before having studied the past. See above. WMF needs to do its homework, and it's not even that hard: start by reading all the past bugs and discussions, with a more open mind. I suggested to start with LiquidThreads because that's an extension with wider usage and Flow still has strong feelings attached. --Nemo 06:51, 22 October 2018 (UTC)
 * Hi Nemo, I've read most of the discussions on Flow -- I was involved in a lot of them, and I've reread quite a few over the last few months. I haven't read a lot on LiquidThreads; I'll take a look, but unfortunately I don't have the time/patience to read every bug report. :) Do you feel like writing a summary of the important points about LiquidThreads that we should know? -- DannyH (WMF) (talk) 14:07, 22 October 2018 (UTC)

Great
So is this WMF finally accepting Flow aka StructuredDiscussion is literally a super duper epic (put your favorite swear here) failure? :D &mdash; regards, Revi 07:46, 6 November 2018 (UTC)


 * This is the WMF accepting the reality of the situation. There are a number of Wikipedias where Flow has been used successfully for several years. There were also problems with the way that the project was planned and rolled out that made it a non-starter for a lot of active editors on bigger wikis. Whether you call that epic or not is up to you. -- DannyH (WMF) (talk) 08:30, 6 November 2018 (UTC)

Decision-making and discussion quality
(I know this is late, and the consultation is scheduled to start pretty soon, but I just found out about this. Sorry.)

The Wikimedia Community is typically very good at calmly and reasonably discussing topics and coming to well considered decisions after consensus. Contributors enjoy participating, measuring the merit of the various arguments, and bringing up informative relevant points that can be used to refine the collective conclusion.

Unless there is no decision to be made. In those cases, almost everyone wanting to participate in any of the aforementioned steps doesn't show up, and the remaining participants typically consist mostly of those who will try to sway the decisions via other, much less pleasant methods. Basically, this consultation is likely to end really badly, and everyone involved, most especially any relevant staff, are going to have an extremely unpleasant time.

Another point, though one that the WMF might disagree with, is that the community is much more capable of making an informed decision on this topic than the WMF is. I don't think the WMF is likely to let the community be the final decider here, so working within that restriction, here's what I think should happen:

Instead of the current plan for a consultation, there should be a community-directed discussion with the aim of establishing the community's recommendation to the WMF on a strategy for talk pages, in broad strokes. This won't work on as tight a schedule as might be convenient. The relevant WMF staff should participate in this discussion to provide useful information and advice. The WMF mostly directs its own developer resources; it may decide not to follow the community's recommendation exactly. A final product developed by the WMF might diverge from the recommendation, or not be along those lines at all. If the WMF decides not to work on something, the community may decide to build it themselves. If the WMF decides to build something, a Wikimedia project may reject it.

The important thing here is that the discussion be a place where the most effective way to influence the final decision is to participate in a normal community discussion, and not to, essentially, yell at developers. The community knows how to discuss things internally without things getting out of control. The community talking directly to an external entity that's in a position of absolute power tends not to work. --Yair rand (talk) 01:50, 15 February 2019 (UTC)


 * Hi : we agree that the Wikimedia community is very good and discussing topics and coming to consensus, and that's what we're going to be doing here. The plan that you propose -- a community-focused discussion with the aim of establishing a broad recommendation for WMF strategy -- is essentially the plan that we're talking about on this page. We need lots of participants to come and have those discussions, so that we can come to a strategy with as much of a consensus as possible. We've already been through projects where the WMF decisions were made in advance, without listening and engaging with the community. You're right, those are unpleasant discussions, and they end up with plans that won't work. We're doing it in a different way here. Do you have thoughts on what would make the consultation plan more productive? -- DannyH (WMF) (talk) 17:16, 15 February 2019 (UTC)

Who is "the community" who claim to represent my views?
There's always a lot of talk on-wiki about "the community" and what "the community" wants. Yet strangely, despite being a very active editor, very rarely are assertions about what "the community" want (wikitext, Talk pages) reflective of what I want. I like the Visual Editor, I use it a lot (except for templating work which is usually easier in wikitext), I do outreach and train others to use the Visual Editor. I dislike Talk pages and prefer Flow. So I want to challenge the assertion that there is a single "community" that speaks for all active editors. There isn't. The second point I would make is that our existing set of editors aren't the people we are trying to recruit as new editors. Indeed, some existing editors routinely bite newbies with the side-effect that it is very hard to onboard new people. One of the things I know from outreach and training is that newcomers take to Visual Editor much more easily (people struggled to remember the syntax back when I was teaching wikitext) and they don't find Talk natural (partly because they can't use VE on it, they can't easily share a screenshot of a problem they are having, etc). The unnecessary degree of unfamiliarity of the Talk interface and the unpleasant behaviour of some regular contributors combine to make it very difficult for a newcomer to get started. So yes we need to be asking the opinions of people who are outside our regular contributor base as well as within it, but maybe not grabbing random people off the street. But it would be worthwhile to engage where we can with new good-faith contributors because they are the people we need to attract. Kerry Raymond (talk) 03:48, 15 February 2019 (UTC)
 * Hello Kerry, I couldn't agree more. I am always astonished how easily some people talk as if they are the incarnation of "the commuity". In my own experience, students are able to use wiki code, but they don't like it. I have never seen that someone had to explain how to talk on Facebook, but it is obivously necessary on our wikis... Ziko (talk) 08:13, 17 February 2019 (UTC)

talk evolution
two things to make talk pages easier, would be auto-archiving, and VE on talk everywhere. the newbie astonishment at wikicode should not be underestimated. i presume you would say the norms of how users behave on talk is outside your scope. Slowking4 (talk) 17:06, 15 February 2019 (UTC)


 * Those are entirely within scope. The list of possible solutions on the page includes using Visual Editor on talk pages with extra features, and auto-archiving could be one of those features. We're starting this process with an entirely open mind about where we end up. Is there something that we could change in the plan that would help to make that commitment real? -- DannyH (WMF) (talk) 17:20, 15 February 2019 (UTC)


 * thank you. i would suggest that community engagement would require a dedicated team over the long term, separate from technical fixes, more of a program than a project. given the community "turn it off" mentality, opt out should be built in. open source code for a community requires an heroic level of project management, the failure mode of community and WMF talking past each other seems to be the default. small incremental changes over time may well be a way forward. implementation may be more important than the code fix. modeling good talk behavior may require some viral marketing, and coaching. Slowking4 (talk) 12:44, 20 February 2019 (UTC)

two types of communicating
Following from Ziko's comment above, there is a big difference between Talk and User Talk and I think we should regard them differently. Talk (in whatever way it evolves) should remain open to all to discuss an article's development (except perhaps those who are topic-banned) but I think User Talk (in whatever way it evolves) and "email this user" should allow the user a lot more control over who can use it for Trust & Safety reasons. I don't think my current User Talk pageshould be open for random IPs to come and write smutty comments because I am a self-identified woman and I don't think it's OK for people to page-stalk me when I don't welcome it. Nor do I think it acceptable for other people to modify my User page. Naturally admins should have some ability to do such things where necessary to investigating complaints or implementing sanctions or enforcing policy (not using the User page for hate speech), but in general "users in good standing" should have reasonable rights to privacy and control in relation to their User and User Talk pages (or whatever they might evolve to be). We wonder why we have so few women contributors when we do nothing to prevent harrassment, but actively facilitate it (e.g. watchlists on User Talk). There's certainly a few users I'd be instantly blocking from my User Talk page given the chance to do so. Kerry Raymond (talk) 04:44, 17 February 2019 (UTC)
 * Actually I am not familiar at the moment what the Wikipedia rules say about moderating your own talk page, it might be different from language version to language version. Myself, I do decide what I tolerate on my talk page and what not. :-) On other talk pages, I would like to see a moderation that works against off topic comments as much as against purely negative or belittling comments, even if they are not personal attacks in the strict way of the Wikipedia rules. Ziko (talk) 08:16, 17 February 2019 (UTC)

Extension of Thank feature
Hi, I feel that an extension of the Thank feature might be useful. I often just want to say "OK, I have read it.", even if I don't agree with a post, without having to write anything myself. So I don't really want to thank the contributor for it, but I want to let them know that I have read the post. Now I use Thank for that, but more detailed options might be useful. Regards, Yann (talk) 06:16, 19 February 2019 (UTC)


 * It feels funny to say this, but thanks for posting your idea. :) I've been surprised sometimes by how much I appreciate it when someone Thanks me for an edit. It's a powerful thing. -- DannyH (WMF) (talk) 15:54, 20 February 2019 (UTC)

Post mortem from Flow
Have you done a post mortem from the Flow disaster? Does your planning include to adopt the experiences from Flow when determining the MVP? Because I would like to repeat two big issues that absolutely must be included in any discussion about talk pages and their potential replacement: Both functions are mandatory and need to be implemented in the first rolled out version, because anything else would destroy the workflow of our power users. Wikipedia depends on our power users. --H-stt (talk) 16:27, 21 February 2019 (UTC)
 * Full rendering of wiki syntax: Talk pages (both article talk and user talk) are not some flashy discussion place, but have only one purpose: a space to work on Wikipedia articles. Therefore we need to collaborate there on wikitext, including any ugly css-hack or misappropriated templates. Any project, that does not allow to collaborate on wikitext is not a MVP.
 * High traffic pages and power users: I have some 4000 pages and their talk pages on my watch list on deWP. I need to be able to work with this and to watch high traffic discussion flows. My old example is still valid: “A lively discussion with -say- 400 contributions by -say- 25 different editors in -say- 15 subchapters all stemming from one root posting? Now multiply that by 8 current threads plus 15 older ones. And imagine I have been away over the weekend and now try to catch up. The current system can deal with this situation. And I can, too. Does Flow?” my Edit from 27 August 2014 Wikipedia talk:Flow/Archive 13 Any project, that does not cope with high traffic and power users is not a MVP.