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)
 * I don't want the real discussions going on off-site where private companies control what can be said and what can't. How do you come to a "neutral" decision about editing an article rather than the decision the company wants?  I'll admit, I haven't been to your forum, but my impression is that Facebook now does a lot of censoring, and that a 'debate' on something like illegal immigration (for example, what sources to use and what incidents to bring up in an article about the controversy) would be extensively shaped by their 'moderators'.  We don't want them administering Wikipedia by proxy, we don't want deluges of "canvassed !voters" showing up to skew votes, and I already wonder whether some of the recent outrages like the lunatic crusade to shut down the Refdesk started on Facebook or some such site.  These sites are a problem, not a solution, they are already an international disgrace at the middle of new schemes to make new Great Firewalls because a hundred thousand censors aren't enough to make up for the stupid way their sites are designed to promote "snowball effects" from the upvoters of PR/troll agencies. Wnt (talk) 11:09, 23 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)


 * I totally agree, that is the best explanation on the subject I have seen so far. The volunteers are the major force that move the Wikimedia projects, not the readers, we don't need any kind of people editing, we need people that understand how a wiki environment works, people that want to fly in the skydive plane. The current wiki talk pages works well because it helps filter the kind of people we need editing wiki. The wiki environment is complex, and always will be, because we need many policies and processes to keep the relative order of the huge amount of public information we provide, and helping to improve and maintain that is not a work that any kind of people can do. Danilo.mac (talk) 16:41, 21 February 2019 (UTC)


 * That is a beautiful way of putting it! Wnt (talk) 11:11, 23 February 2019 (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)
 * Thanks for this comment, I strongly agree with it. I find it absurd that some people are so set in their ways. I understand that wikitext is powerful, but holding a discussion in wikitext is unintuitive and difficult. I stopped editing for a few years partially because of how hard it is to communicate with the rest of the community on Wikimedia projects. I came back this year expecting Flow - or something like it - to finally be adopted, but it hasn't been. It's really frustrating that my ability to contribute to discussions on Wikimedia projects is made significantly more difficult by the current talk page format. Keeping track of discussions, and contributing to them, is unnecessarily difficult with talk pages. Best of luck to the WMF, I sincerely hope you can power through on this. Nicereddy (talk) 22:02, 21 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)
 * +1 Qzekrom (talk) 18:00, 21 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.


 * : I totally agree that we need to make sure that what we build needs to work for power editors and high-traffic pages. I know that when I was working on Flow several years ago, we didn't take the "show me a diff of the entire page of discussions" function seriously enough. Flow had a diff for each thread in the notifications, and we thought that was good enough. It was only after I left the project that I ended up having a series of complicated discussions on a Flow page, and realized how much I wanted a diff of the page. :) That was one of the experiences that convinced me that we need to go back to the first step with this consultation, and take the needs of both power users and new users seriously.


 * One thing that we need to revisit in this consultation is the idea that there has to be one single feature to handle both the simplest use cases and the most complex use cases. A complex wiki discussion isn't just a simple discussion that's longer and involves more people; it's an extra level of complexity that may require different features. We're hoping that this consultation will help us to challenge old assumptions, and figure out a direction that addresses all of these use cases. It won't be easy; I'm glad you're interested in participating. -- DannyH (WMF) (talk) 00:46, 22 February 2019 (UTC)

Hello, I think that the word "talk page" sometimes makes us forget that the "talk page" has much more uses than talk page... What about different pages for different purposes? It is not a natural law that a content page can have only one additional page?

By the way: Sorry if this has been discussed elsewhere, but: Have we ever considered a kind of annotation on the content page? Ziko (talk) 19:01, 22 February 2019 (UTC)

"..as many different parts ... in multiple languages,..."
Ihr sprecht die verschiedenen Wikipedien auf englisch an und erzählt etwas von in vielen Sprachen usw. Möglicherweise ist es noch nicht zur WMF vorgedrungen, aber es gibt eine Welt außerhalb des englischen Sprachraums. Es gibt sogar Leute die allen ernstes kein English sprechen. Wenn ihr euren Satz also ernst meinen würdet, dann würdet ihr euch zumindest bemühen. Natürlich wird es kaum möglich sein alle sprachen abzudecken. aber die großen wie Spanisch, Französisch, Russisch vielleicht auch Deutsch sollten Euch nicht überfordern. .. Wenn doch ist Euer Interesse wohl kaum ein ernsthaftes. ...Sicherlich (talk) 17:03, 21 February 2019 (UTC)
 * : I read your post using Google Translate; here's a link so that you can read my response. Working in many different languages is hard. We asked translators to help us translate the announcement, and we got translations in 13 languages, including Spanish, French, Ukrainian, Japanese and Arabic, but nobody helped us with the German translation yet. We didn't want to wait too long before we let people know about this project, so we posted on the other wikis in English. We are asking volunteers to help host conversations in other languages, and people are signing up on the Participant group sign-up page. If you know people who would be interested in translating or hosting conversations in German, please let them know that we need their help. -- DannyH (WMF) (talk) 01:01, 22 February 2019 (UTC)
 * okay, so at you tried! Thats an improvement 👍 thx ..... and no, I don't know anybody who would be willing ...Sicherlich (talk) 08:55, 22 February 2019 (UTC) For me it seems the reputation of WMF is quit low on de. and it seems its not improving lately. But might be biased as I myself have no confidence in WM ;)

Can we stop wasting money on this?
The reality is over the last 18 years talk pages have expanded to be used for a wide enough range of tasks that nothing short of full blown standard wikimedia editing page is going to support them and any attempt to mess with that just results in crippled mess. Burning yet more donor money to relearn this lesion isn't exactly justifiable at this point.Geni (talk) 12:55, 22 February 2019 (UTC)
 * And if not everyone thinks like you, what are they supposed to do?
 * I do not find this to be an acceptable situation, just for the new contributors who are struggling to ask for help. Even for mobile contributors. On frwiki, our newcomers' talk page uses StructuredDiscussions/Flow and it's less complicated to try to help them. Nevertheless, yes, the tool help new contributors, but it is incomplete for regular contributors. Lofhi (talk) 22:22, 22 February 2019 (UTC)

Non-goals is a good start, but let's think about them

 * The current non-goals include some useful points:


 * Off-wiki discussion platform – Discussions need to be on the wikis, using Wikimedia accounts.

Having discussions on Wikis is great. But that means that


 * Every page has a WIKI SOURCE. I don't click "edit source" and get an error message, and it doesn't take any brand new code to get to a diff.
 * The source implies a flat text file that can be readily downloaded, viewed, copied, manipulated by anything that works with wiki text on or off wiki.
 * Wiki markup WORKS on the wiki. (That's kind of axiomatic, ain't it?)


 * Temporary content – Discussions need to be stored on wiki, so they can be found and referenced later.


 * This is good, but let's bear in mind that INFINITE SCROLLING DOES NOT MEET THIS CRITERION. PERIOD!  "Found and referenced" means I have a hard URL that goes exactly to the discussion I want and the text doesn't move and the page doesn't change in any way other than by additions and perhaps edits of existing text, i.e. there's no ?page=47 in the URL.  (As if infinite scrolling would allow that anyway, given that its whole point is to hide stuff and make discussions inaccessible.  I respect lawyers who defend drug dealers, but I don't respect software developers who use infinite scrolling because I think their intentions are dishonest.)  (DO NOT DO THIS, where the poor fool trying to follow the link that I get after hitting "load more" three times still has to hit "load more" three times to see my lousy comment.  Imagine if it was 500 pages...)


 * Tools for a niche audience – Discussions are designed for everyone, with equity in mind.


 * This is inadvertently very insightful. "Equity" should mean that discussions have a low Gini ratio -- everybody has about as much chance of being read as everybody else.  The most important part of the audience are the people who want to at least skim everything about a topic.  Note this is different from the dying culture of commercial social media where they decided the most important part of the writers is the one that gets them the most eyeballs.  That's in part because Wikipedia is looking to maximize the number of pens, not the number of eyeballs, with its discussions, and in part because we're not trying to build a bully's utopia where you have to hire a PR agency to get your ideas read.
 * Note that "upvoting" and "downvoting" are NOT ways of keeping equity in mind.


 * A social network per se – Discussions on Wikimedia should primarily be in service of improving


 * To continue the above, note that ad hominem reading, i.e. "following someone", a key basis of the social media game, here is "Wikistalking" and can be problematic, though admins and anyone thinking of calling an admin will do it on occasion. If we get to a point where most of the "!votes" are based on one person following another in to a discussion, the consensus system will break down into partisan warfare on every issue.  It is and should remain possible, but don't invest a lot of effort trying to make it easier.


 * The other two points I am not very thrilled with:
 * Real-time discussions – Real-time discussions have value, but our current focus is on asynchronous discussions for the reasons mentioned in points above.
 * "Real time discussion" and "fixing edit conflicts" are conceptually related. If you can have a system where other person's typing during your own can be unobtrusively noticed this might be useful, though it also needs to be readily disabled (due to deliberate abuse by trolls etc.)


 * The status quo – Leaving talk pages exactly as they are.
 * This is remarkably nonspecific. Is it just that you need the hours?  Or is there something about them that you can't tolerate, and if so, what?


 * Additional Do Not Want items:


 * "Mandatory Javascript". Wikipedia runs much faster and with fewer security worries without Javascript, and you get a better overall view of pages (no absurd image hiding and also no concealing the massive bloat of infobox spam tagged on to the end of many articles).  Requiring Javascript is occasionally unavoidable (the pretty markup in the Lua editor) but it is NOT unavoidable while reading or posting talk page comments.  Go the extra mile to ensure that every aspect does everything it possibly can without Javascript ... and have pity on the poor saps who use it when reading articles when you start adding your new bloat to this site's scripts.


 * Censorship. Using "edit filters" to block postings of sources or other information is already wrong, and any attempt to expand it would be more wrong.


 * Meta-censorship. Wikipedia has gone down the slippery slope from hiding a handful of egregious abuses to having admins "revdeling" even relatively innocent comments.  The next obvious step is to think Gee, having half your revisions being nothing but gray lines and "edit summary removed" looks bad, so let's conceal the fact that censorship ever happens at all!  I'm saying right now NO that is NOT what I want.


 * Other dishonest practices. Worse things (and there is nothing bad that isn't proof of professionalism in Silicon Valley!) include the dreaded "shadow ban" or "downranking" tactics.  No, Wikipedians do not want to wonder if they are on double secret probation, it will drive everybody crazier than they already are.  And there should not be any upvoting or downvoting at all, but there certainly should not be any phantom downvotes from "filters" and AIs and such trying to conceal some kinds of comments at the bottom of 500 pages of infinite scroll without any fixed URLs.  Which is, honestly, exactly what I expect from any talented practitioner of the Dismaler Science today.


 * Hidden data. This is implied in my interpretation of a wiki including wiki source code above, but let's be clear: there should be no place in your talk page system to hold a secret copy of the IP address, user-agent, password token, how long the post was composed, or any other data that isn't directly viewable by any normal person reading the source.  No hidden data, nothing to be compromised.


 * Advertisements. Let's be clear: putting those f/t/things on pages or in any other way privileging specific private companies with links not freely chosen and revised by individual editors, would be intolerable.  I don't care how many lemmings do it.  Maybe companies are willing to advertise them as a quid pro quo, but we should respect ourselves more than that. Wnt (talk) 11:19, 23 February 2019 (UTC)

Where to start?
What are the most wikipedia-specific forms of collaboration and discussion? I have argued before, we should be looking at peer reviews and talk pages of ongoing events currently in the news or other heavily contested topics (I have named examples over on meta). Any product replacing our current talkpage setup will have to excel in those circumstances. And I strongly suspect any product used there will by necessity have to look very different from any other discussion medium or social network currently in use elsewhere. There will e. g. probably be lengthy drafts of article content and interleaving of comments. Some kind of hurdle or unfamiliarity for new users will very likely remain. Whether we can put some restraints on said product to use it in Teahouse-like settings or keep a Flow-derivate around for that, is a discussion to be had later, when we have something to actually test. --HHill (talk) 10:54, 23 February 2019 (UTC)