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)
 * Not really. Nemo 08:42, 24 February 2019 (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)
 * if you do not want talk going off-wiki, then what action steps are you prepared to do to welcome a civil discussion? who will moderate talk pages? the companies do not control the discussion, the admin of the group does. (except for censoring things like ) you already have off-wiki canvasing administering wiki by proxy. talk is a ghost town, except to announce the decisions arrived at elsewhere, such as OTRS, or flash mobbing RfC. these sites are a symptom, not a problem.Slowking4 (talk) 12:53, 25 February 2019 (UTC)
 * +1 Excellent moderation, yes, also a variety of expertise that makes it a good venue for problem-solving, but the lack of anonymity precludes significant diversity participation. Avery Jensen (talk) 01:48, 24 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)


 * Agree. We are looking for the best talk page system for encyclopedia writers and we must keep this particular group in mind. Doc James (talk) 09:22, 24 February 2019 (UTC)


 * Totally Agree!... This is the best explanation I've read so far... Alcohkid (talk) 11:03, 25 February 2019 (UTC)


 * So in your opinion, you and your friend rather like to work together on a helicopter gunship, than on any kinds of planes? If yes, then it's unlikely that you will win, because your foes are users that can control many kinds of λ-Drivers, not just only one. --Liuxinyu970226 (talk) 13:21, 25 February 2019 (UTC)


 * Oh, brother. This is the sort of elitist thinking that has taken Wikipedia from 60,000 editors 10 years ago, to less than 10% that number now. The current number of editors is not enough for the many millions of pages that currently exist. Please, continue in this line of elitist thinking, and keep driving the number of editors even further down. Someone who no longer edits Wikipedia. — Preceding unsigned comment added by 71.33.135.121 (talk • contribs) 02:48, 27 February 2019‎
 * One, your 'elitist' quip is an inappropriate personal attack. Two your data is grossly incorrect. Three, your logic is grossly faulty. Four, your conclusion is wrong. But aside from that... your lack of signature makes me wonder if you have any experience at all to competently comment on the subject.
 * Your data is grossly incorrect: According to WMF statistics the number of active monthly accounts (normally defined as 5 edits) has declined by 13% over the last ten years, however that decline is concentrated among people who make minimal contributions. The decline in monthly edits is 6%. Given the natural random variation in activity, that's almost the margin of error of no change at all.
 * Your logic is grossly faulty: 2007-2008 was the peak in an unsustainable spike in activity when Wikipedia became famous - everyone-and-their-brother heard about Wikipedia and logged in to try a half-dozen edits before quitting. Once the social buzz wore off there was an inevitable and natural decline and stabilization in the editing population. And of course blaming wikitext for any decline is nonsensical, as the exponential growth of Wikipedia occurred when wikitext was the only editing environment. It makes no sense to try to blame any decline on wikitext, when there was no change relating to wikitext at the time. If you want to engage in any sort of rational comparison between wikitext and VisualEditor we of course must look at what has happened after the VisualEditor project was initiated.
 * 2018-10 Wikimedia editing interface retention.png Your conclusion is wrong: In 2011 the Foundation undertook a strategy to quote: "deprecate wiki syntax as the primary input method". This involved a two part strategy: VisualEditor to deprecate wikitext on article pages, and Flow to deprecate wikitext on Talk pages. Both projects suffered severe design flaws due to the assumption that wikitext was being deprecated, but I'll focus on the immediate topic. Flow suffered the more catastrophic failure, being rejected by several major wikis and ultimately being uninstalled from hundreds more. VisualEditor suffered a more soft failure in that it utterly failed to achieve any of its positive goal at all, coupled with a diffuse cloud of negative impacts. The Foundation's documentation pages for VisualEditor were filled with text singing the glorious praises of a VisualEditor helping new users, increasing user retention, and ushering in a flood of new contributors. The Foundation's biggest worry is that the existing community may be overwhelmed by the glorious flood of new users brought in by VisualEditor. However the June 2013 study: VisualEditor's effect on newly registered editors showed this early version had a severely negative impact. Over the next two years continued development would bring VisualEditor up to high quality. The May 2015 study: VisualEditor's effect on newly registered editors finds that releasing VisualEditor side-by-side with the wikitext editor has almost no effect, other than some arguably negative effects (much slower editing and worse edit-failure rates). VisualEditor helps an addition zero people make a first edit, VisualEditor increases user retention by zero, VisualEditor increases total contributions by zero. VisualEditor utterly fails every rationale for building it. The Foundation then spent another six years doing all it could to promote and pressure VisualEditor as a primary editor. The last time I checked, about 2% or 3% of edits on EnWiki were made using the VisualEditor. It's an utterly insignificant secondary editor. Global usage rates of VisualEditor are only marginally higher. Even on wikis where VisualEditor is shoved onto new users as the default, the new-edits-feed showed VisualEditor only accounted for a minority of edits by new users on those wikis. When new users are shoved into VisualEditor as the default, they either soon stop editing or they heavily switch to wikitext as the primary editor. Just look at the image above. The Foundation's own data shows the retention rate for the VisualEditor is about HALF of the retention rate for the wikitext editor. That's a horrendous figure. Given all of these facts, the absolutely undeniable fact is that the editing community overwhelmingly considers wikitext to be the better tool for the job. Alsee (talk) 14:42, 28 February 2019 (UTC)
 * That all came as a surprise to me. I've been editing English Wikipedia since 2006, so I was well acquainted with source editing by the time VE was introduced. When it was, I tried it, but found it slow to load and clunky to use, so disabled it. More recently (July 2018) I decided to give it a second chance. This time, I liked it. Now I make a good portion of my edits visually. I find it quicker and more convenient because I don't have to find the place in the source code that corresponds to where I wanted to make my edit, and because I can easily keep reading the subsequent text, as I was before I initiated editing, to see if there are more changes I want to make in the same edit. This results in me making more edits that I would not have bothered to make otherwise. Regarding talk pages, all I want at the moment is to be able to use VE on them.
 * Slightly off topic: I maintain (though not very well) a small MediaWiki-powered wiki, and am thinking of launching another in the near future. I have been thinking about installing VE on these, to make editing easier for new users. Your retention data initially made me think I might be wrong to do that, but then I noticed in a section below that another person reported personal experience that students find VE easier to learn, so I think maybe I'll just have to try it, and figure out how to measure user satisfaction and retention. (It probably helps that the current small wiki I mentioned is for a community where we often meet and talk IRL.) PointyOintment (talk) 17:47, 28 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)
 * I already made summaries on the issue tracker. It's your job to read the issue tracker. Nemo 08:43, 24 February 2019 (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)
 * I am often asking my wife to help me figure out how to get Facebook to "work". And even when "working" IMO it makes no sense.
 * With respect to VE, it has high support and is much liked by new users. We should be using it on talk pages. The great thing about VE is that those who do not want to use it do not have too.
 * If we allow its use on talk pages, that will be win win. Those who want to stick with the old system can. Those who want VE can use it too. Doc James (talk) 09:26, 24 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)


 * The list is all technical solutions, but the problems have not been defined. We can teach newbies old technology or new technology, they will pick it up either way, especially if there could be some effort at communication with outreach prior to implementation, but that is not what is turning off engagement. Avery Jensen (talk) 02:29, 24 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)
 * +1 I do not know any woman editor who has edited any length of time and has not been stalked, or targeted with vandalism and disrespectful language. "Just deciding what to tolerate" does not seem to be an option without the ability to set edit filters. Moderation is non-existent on any page that is not under the technical coc.  Avery Jensen (talk) 02:59, 24 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)
 * +1 Espresso Addict (talk) 21:36, 23 February 2019 (UTC)
 * The ability to mark a "thank" as read, so you don't keep getting the same notification, some of them are bots from different language wikis. Avery Jensen (talk) 03:03, 24 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)
 * Ziko, yes, we discussed inline comments or annotations after the successful GPLv3 consultation by FSF, about ten years ago. There was later an attempted implementation at Extension:Annotator. Nemo 18:27, 26 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)


 * , thanks for posting your thoughts; they'll be really helpful for Phase 1, when we start collecting everyone's thoughts on what they do and don't need. Right now, in "Phase 0", we're talking about the consultation process. I think the only question in your post that's about that is the "status quo" question, which I answered below in the "Non-goal" thread. -- DannyH (WMF) (talk) 20:22, 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)

Non-goal
Why is leaving pages exactly as they are a "non-goal"? Effectively, this says that people who are happy with things as they are get excluded from having their opinion heard, even if they are the majority. (Please ping me if responding, I don't maintain a watchlist on this wiki.) - Jmabel (talk) 17:24, 23 February 2019 (UTC)


 * The reason why "status quo" is listed as a non-goal is that there are requests for changes even by people who like the existing talk page system -- like being able to use VE on talk pages, or being able to follow individual threads. There are also a good number of people who find the status quo hard to use. We don't have a pre-determined result for this consultation, but we're pretty sure that leaving things exactly as they are won't work for all the use cases we want to support. There are a lot of possibilities on the table; where we end up depends on everyone's participation. -- DannyH (WMF) (talk) 20:13, 23 February 2019 (UTC)


 * I see where you are coming from here, but it does come over as blankly dismissive of those of us who are very happy with the current talk pages. Could you not just delete this 'non-goal' altogether? Espresso Addict (talk) 03:56, 24 February 2019 (UTC)
 * It is "blankly dismissive", as WMF always has been. I like the status quo. New editors need to learn our system; the learning curve is an important filter. I, as a regular contributor, should not have my desires placed beneath the supposed desires of some future editors for a project that is ultimately a way to waste money on coding that will never work. Chris Troutman  ( talk ) 11:28, 25 February 2019 (UTC)
 * You refuse to realize that this kind of discussions are ignored by most of the editors until it is too late. And on top of that you are limiting the discussion from the beginning. So we will likely end with a fiasco like the mw.toolbar removal - dozens of volunteers waste time trying to patch the problems WMF created, small wikis lose valuable editors but you get your paychecks and start writing new action plans about retaining editors. --Nk (talk) 20:09, 25 February 2019 (UTC)
 * I raised the same issue at Meta. MarcoAurelio (talk) 10:13, 26 February 2019 (UTC)

The status quo is always one option you need to consider. I feel that a change juts to have a change is no option. I feel further that the pre-determined result is already fixed inside the WMF. Sorry, you have played this game too much with the communities. --Bahnmoeller (talk) 14:36, 25 February 2019 (UTC)
 * DannyH (WMF) the last version of the page written by you contained far better messaging than the current version of the page. The "status quo" text is inadvertently and needlessly troublesome. The community considers it an important principal that the status-quo is the essential outcome if a consensus fails to materialize. In particular, the current top community request is section-watchlisting, which the Foundation has been rejecting for at least the last five years. If the Foundation continues to reject what the community does want then the "no status quo" text implies the message: "Something must be done, the foundation wants to do something the community doesn't want, that's something, therefore it must be done". I don't think that is the message you intended to send. Deleting the status-quo text would be a very easy step to improve your messaging.
 * Beyond the "status quo" line, the page was also re-written to cast engagement in an overlord-and-peasants model rather than partners. I don't know if that's the model and message you intended here. I had a glimmer of hope that the WMF was trying to move forwards from that view of community engagement. Alsee (talk) 20:52, 26 February 2019 (UTC)


 * Okay, I removed the "status quo" line, because I think it was coming off stronger than we intended. 's comment directly above is a good example -- we're thinking about "wikitext talk pages are the same, but we add section watchlisting" as not being the status quo. I think even the most devoted wikitext talk page users want some improvements, and that's a possible direction. But I understand why it came off as anticipating a pre-determined result -- as says above, "Sorry, you have played this game too much with the communities." An important part of this process for us is to build more trust and tell the truth. -- DannyH (WMF) (talk) 21:51, 26 February 2019 (UTC)

"What are the important aspects of a "wiki discussion"?"
I tried to answer this in the English Wikipedia RFC. I still don't really understand the question. It's quite vague. Are community members being asked to write about how on-wiki discussions are different to discussions everywhere else? (And is "wiki discussion" in quotes because its meaning in the question is different to its implied meaning without quotes?) Jc86035 (talk) 17:35, 23 February 2019 (UTC)
 * Jc86035 I believe the idea is that they want to know what important things about existing pages they would need to duplicate or otherwise address in order to build a replacement. Imagine we gave them a checklist which would allow them to build anything they'd like to build, implemented in any way they want to implement it, so long as they successfully run down the checklist satisfying each of the requirements on our list.
 * Unfortunately the short answer to their question is "It's a generic wikipage". Unfortunately the Foundation has a really hard time understanding why that is the answer. Also unfortunately, any long answer turns into a rambling blob of goo about how a wiki works. Alsee (talk) 00:17, 27 February 2019 (UTC)

Re Intro of "Purpose of the consultation"
''A wikitext talk page isn't made out of software; it's a collection of cultural conventions that are baffling to newcomers and annoying for experienced editors. Counting colons to indent a reply properly, using tildes to sign your name, having to watch an entire talk page instead of the section you're participating in, not having an easy reply link – these are headaches for everyone.''

I can't speak for newcomers, but I don't think many experienced editors actually find very much of this annoying or headache inducing at all. The only thing that I've seen discussion over would be being able to watch a section of a talk page. The Foundation needs to be careful that in its rush to welcome new editors it doesn't alienate the existing long-term contributor base. Espresso Addict (talk) 21:06, 23 February 2019 (UTC)
 * I agree with Espresso Addict. I do not feel annoyed by wikitext talk page and I think the same is for the most of experienced editors, but most of newcomers probably are. --Daniele Pugliesi (talk) 20:25, 25 February 2019 (UTC)

Question regarding translation
Both the Consultation structure and Status updates section is in another subpage rather than in the main page, this means it will be hard for other translator to find that subpage and do the translation. Is it possible to merge all the updates back to the main page so that translators can add translation tag with consistency? VulpesVulpes825 (talk) 21:56, 23 February 2019 (UTC)
 * Hello VulpesVulpes825
 * The updates are going to change quite often. This is why they aren't marked for translation. Regarding the Consultation structure, it may be moved to the main page, even if they are subject to changes, depending on how the consultation goes. Trizek (WMF) (talk) 08:18, 25 February 2019 (UTC)

Proposals

 * default new editors to autosign: By far the biggest problem on talkpages, the one that we have to put into all welcome messages to newbies, and the one that newbies do not find at all intuitive, is the need to type ~ . There is an easy partial solution to this, we give everyone a user option to autosign their posts, and after a certain date we default all new editors to autosign on talkpages. If you are opted into this your talkpage edits default to having ~ appended. Yes there will be people who need to click the "don't sign" button when they amend their own post, and people who get into things like wikiproject template tagging will need the option to set autosign off. But the single most unintuitive feature of this site, a barrier to newbies almost as big as captchas for those adding references and edit conflicts, is that every talkpage comment needs to end ~ . If the only thing that this talkpage review achieves is to fix that one problem, then this will be a successful project. WereSpielChequers (talk) 22:00, 24 February 2019 (UTC)


 * Watch section not page: On many talkpages I have watched I am only really interested in a response to a particular section. If I could watchlist specific sections rather than the whole page then that would make a big difference to my use of talkpages. WereSpielChequers (talk) 22:04, 24 February 2019 (UTC)


 * Unanswered talkpage queries: There have been many times when I have put a query on a talkpage and no-one has been watching that article. Or at least no-one responds, sometimes for months. It would be helpful if there was the option for a wikiproject to set up a potential query list - a list of talkpages tagged to that wikiproject where there were open queries - either new sections with only one contributor or even thread not marked as Ideally it would work with the proposal above, so members of the wikiproject could mark certain talkpage sections as not relevant to their project. So an article on a mountain might be tagged under botany, vulcanology, skiing and mountaineering. A new section about the impact of skiing on damage to trees might be of interest to both the botany and skiing wikiprojects, but someone from mountaineering would just unsubscribe their wikiproject from that section. It would also be useful if there was some central page that listed outstanding talkpage queries. Perhaps with a flag for ones by newbies. WereSpielChequers (talk) 22:15, 24 February 2019 (UTC)

Community social expectations
In aid of hopefully averting the type of events that happened last time around, I would like to point out this essay that I wrote in 2016 as a guide to the general expectations and standards that editors are likely to have for the WMF in these sort of circumstances. Much of it is necessarily specific to the English Wikipedia, and certain parts are specific to the time period in question, but I would venture it is likely to be useful reading regardless. Sunrise (talk) 00:01, 25 February 2019 (UTC)


 * Thanks for the link, I hadn't seen that before. I agree that the standard for communication is (appropriately) high for WMF staff. I think the points about deflection are especially well put. -- DannyH (WMF) (talk) 22:50, 26 February 2019 (UTC)

A two stage solution? First VE then something else
It makes a lot of sense to me have one tool to learn (Visual Editor) to both contribute to Wikipedia articles and communicate with the community, so I would thoroughly support implementing VE on talk pages. However this feels like it doesn't address many of the issues with talk pages that were identified which led to Flow being being developed. If there is a new solution decided on that needs significant development (which I assume would take years not months to develop) then it would be great to have VE on talk pages as a stop gap (assuming that it can be implemented within months not years).

It would also be really great to find a way to implement VE on Wikiproject pages (blocked because Wikiproject pages share a namespace with admin pages) as they often act as discussion spaces where tables (which VE makes a million times easier) are commonly used.

Thanks

John Cummings (talk) 13:18, 25 February 2019 (UTC)


 * Unfourtunatly the VE is not behaving well in all situations. For example: It adds "nowiki" somewhere in the wikitext. --Bahnmoeller (talk) 14:39, 25 February 2019 (UTC)


 * , having bugs in such a large piece of software is understandable and I'm sure it can be addressed, can you link the Phabricator ticket for this issue for context? Thanks, --John Cummings (talk) 21:31, 26 February 2019 (UTC)


 * Yes, the things that you've mentioned are possibilities on the table. This process could result in putting VE on talk pages, or VE + some other improvements. -- DannyH (WMF) (talk) 22:58, 26 February 2019 (UTC)

Annoucement on German WIkipedia
Can someboby give me when the information about this consultation was communicated to the german speaking wikipedia? I first read about it today on Wikidata.

Was the german speaking community too critical on prevous issues? --Bahnmoeller (talk) 14:51, 25 February 2019 (UTC)
 * Hello Bahnmoeller and thank you for your message.
 * Your wiki got the message too, maybe you haven't seen it there yet.
 * The message has been posted on the Kurier page and on Wikipedia:Fragen zur Wikipedia. Also, 24 users listed as Tech ambassadors have received it.
 * If some pages that are critical for global announcements are not on our lists, please edit them.
 * I hope that you will help to host that conversation on your wiki.
 * Trizek (WMF) (talk) 15:00, 25 February 2019 (UTC)

Could you please clarify whether this is "Talk" pages or any type of discussion page
I've been commenting directly at the Enwiki page for this consultation. It seemed obvious to me, based on the frequent use of the word "discussion" in the header, that the intent here was to seek consultation on all types of pages in which discussion takes place (which could be quite variable, dependent on the project). However, now that I look again, the consultation title specifically refers to "talk" pages only. So:
 * Please confirm whether this is about all discussion-type pages or only talk pages
 * If it is only about talk pages, could you please explain the reason for artificially separating out talk pages from other types of discussion pages? It is counter-intuitive to make this separation, particularly if the intent is to improve usage and accessibility for new users.

Thanks, Risker (talk) 21:16, 25 February 2019 (UTC)


 * This is intended to cover all types of pages in which discussion takes place. We mean "talk pages" as the common shorthand; if it looks, works and quacks like a talk page, then it's included in this consultation. :) -- DannyH (WMF) (talk) 22:41, 26 February 2019 (UTC)

Where is
Where is the place to submit a proposal? -Usergnome (talk) 00:19, 26 February 2019 (UTC)


 * Hi : We're looking for volunteers to host conversations on their wiki, or with user groups that they work with. The current list is here: Talk pages consultation 2019/Participant group sign-up. If your wiki or group isn't listed there, would you be interested in hosting a conversation? :) -- DannyH (WMF) (talk) 22:53, 26 February 2019 (UTC)
 * Is there a general place for those who don't really have specific groups, or whose home wiki is in fact this one, to leave comments/feedback/discuss things? This whole process seems quite complicated and confusing; while this is needed to some extent simply due to how large and complicated the global projects are, I'm a bit unclear if there's also supposed to be some sort of central place where individuals can comment as well. (I'm not actually sure if I want to, as I'm a little concerned about potential internal ramifications of bringing up my own experiences, but that's a separate issue.) -— Isarra ༆ 15:41, 27 February 2019 (UTC)
 * As the user who started the discussions on both English Wikipedia and Wikidata... just copy and paste some or all of the introductory text that I wrote somewhere ( Commons, Meta, this wiki – none of these projects have pages yet) and link that page on the list of discussions and on the Wikidata item. As long as you advertise the page (e.g. I used this text) then some users with nothing better to do (and/or an axe to grind) should start the discussion in due time. Presumably the central page is this page, so if you put feedback here it might be considered? I've haven't said much here, though, because I've put most of it on the English Wikipedia. Maybe a subpage could be created for this wiki (Talk pages consultation 2019/Local discussion or something like that?). Jc86035 (talk) 10:19, 28 February 2019 (UTC) edited 14:45, 28 February 2019 (UTC)
 * Edited again, because I created the page on Commons. Jc86035 (talk) 16:02, 28 February 2019 (UTC)

Status quo
We are told that "all the options are on the table" but that "Leaving talk pages exactly as they are" is a "non-goal". Which is true? The status quo works well. It is not broken. It does not need to be fixed or replaced. Editors have stated time and time again that it is what they want. If the WMF wishes us to continue donating our time to Wikimedia projects, it would be unwise to remove one of our most useful and popular tools. Certes (talk) 02:25, 26 February 2019 (UTC)
 * +1 I don't see the need to convert Wikipedia into a message board. Even today we have a lot of misplaced posts on talk pages, like general questions or mails intended for the company the article is about. The last real issue authors complained about a lot were edit conflicts for every edit on the same talk page - but this was resolved years ago. Since then everyone seemed to be fine with the way it was. Maybe I just don't get what this is about. The whole thing sounds rather vague. Like "we want to do something - we just don't know what, but we're bored". Maybe write a new media viewer instead? :P --StYxXx (talk) 03:30, 26 February 2019 (UTC)
 * Why you are happy with current system? What is bad in other systems? --wargo (talk) 09:57, 26 February 2019 (UTC)
 * Here are a few reasons for keeping the current talk page system. Some of them are specific to enwiki, which is where I make 99% of my edits.  If you feel that enwiki or wikipedias in general are a special case, please exclude those projects from this exercise and press on with your changes for the rest of Wikimedia only.
 * It's reliable. There's no fancy new software to behave unexpectedly.
 * It's familiar. Everyone on Wikipedia knows how to use a talk page.
 * It's easy. There are no signs that newcomers have difficulties, and they need editing skills to update articles anyway.
 * It's consistent. Editing a talk page is just like editing an article, whether you use VE or traditional text or some other editor.
 * It's integrated. When I add an article to my watchlist, its talk goes on too.  When I search, I can look in both namespaces.
 * It's flexible. It's just text.  With a few simple templates, we can add features without wasting developers' time or queueing for their services.
 * It's multi-purpose. Most enwiki talk pages have tags and categories which relate to the article but shouldn't appear in it, such as WikiProject banners.
 * It's cheap. Developing the system I propose will take zero hours, cost zero dollars and have zero bugs, with zero risk of overspend.
 * It's popular. If that needs a citation, have the courage to add "status quo" to the available options and see how many votes it gets.
 * Wikimedia software is important, but so are the editors. The tool we need to do our job is already available.  If your carpenter brings a chisel, don't take it away and offer a screwdriver. Certes (talk) 13:02, 26 February 2019 (UTC)
 * Numbers two and three are your believes and far from reality (but the magic word enwiki is an excuse). Matěj Suchánek (talk) 16:52, 26 February 2019 (UTC)
 * 'Came here to say the same thing. If we can say that wikicode is simple and elegant for a newcomer, it's probably because we lost our memories of being a new contributor in the first few months. And I find it very problematic to be happy with this contributor filter. We help them contribute with a visual editor, but we let them down with our old discussion pages... Lofhi (talk) 18:13, 26 February 2019 (UTC)
 * "Since then everyone seemed to be fine with the way it was." I think you have a very warped view of "everyone"..... —Th e DJ (Not WMF) (talk • contribs) 10:22, 27 February 2019 (UTC)
 * I came here to say what Certes and others have already said. It's also very weirdly phrased - leaving talk pages as they are is a "non-goal"? Is this a mangled way of saying "we have been mandated to change talk pages by upper management"? Honesty and clarity are needed here. — Scott  • talk  16:56, 26 February 2019 (UTC)
 * Regardless of the fact that the system appears to be working reasonably well for existing contributors, the MediaWiki discussion system is fairly unique, and thus has a relatively difficult learning curve; and because of the use of list formatting to indent comments, MediaWiki discussions generate syntactically and semantically invalid HTML, and can be difficult for screen reader users to navigate.
 * While I agree that it would have been acceptable to many current users for the WMF to leave talk pages alone, given that e.g. even other English Wikipedia users have already noted several things that could be improved about talk pages, I think it's reasonable to say that the discussion software could and should be improved in some way after the consultation (regardless of the scale of the improvements). I think that explicitly stating that the status quo wouldn't be an option was a bit tactless and preconceived, though, even if the developers/staff had already identified issues that they would want to fix (particularly since the page doesn't actually cite anything that actually shows people having issues with talk pages). Jc86035 (talk) 17:59, 26 February 2019 (UTC)
 * Okay, I took the "status quo" line off the page -- it was coming off stronger than we intended. I think that even the most devoted wikitext talk page users want some improvements. One of the possible directions could be "wikitext talk pages, but add section watchlisting and a signature button", which we're considering not the status quo. Still, I understand why people would see that line as "tactless and preconceived", so I took it out. -- DannyH (WMF) (talk) 22:17, 26 February 2019 (UTC)
 * I interpreted an ambiguous statement as ruling out the status quo before the consultation even began. Thank you for clarifying that this was not the intention.  As I understand it, a main argument against the status quo is poor accessibility from mobile devices.  Interfaces such as those prototyped at Reading/Web/Advanced mobile contributions may be a good way forward.  If new mobile-friendly tools can view and edit talk pages in the current format in an accessible way, we can promote those for new editors, whilst keeping the traditional interface as an option for Luddites such as myself. Certes (talk) 10:49, 27 February 2019 (UTC)
 * +1 just leave it, as it is. We don't need a fancy Facebook, Twitter, Instagram, WhatsApp, Tinder or what ever like discussion system. It is working for those, who do most of the relevant contribution. But WMF and their local chapters do anything to antagonize their reducing loyal voluntary workers in their effort to recruit erratic new contributers. Science is difficult, period. A cilized ambitious discussion is difficult and needs rules and a certain formal procedure, period. Who do you want to write your encyclopedia?... --84.150.117.148 19:27, 27 February 2019 (UTC)

Scope of participant groups
Several users have offered to have personal discussions with other people on their user talk pages and through other means such as Instagram accounts. Are these reasonable ways of hosting a participant group? Jc86035 (talk) 18:06, 26 February 2019 (UTC)
 * It's certainly an effective way to ensure that a silent majority can promptly be enlisted to support whatever predesignated outcome! Nemo 18:31, 26 February 2019 (UTC)
 * We're interested in collecting information and ideas from any interested wiki contributors that people can find. As we compile all the incoming information, it's crucial for us to note where and how the discussion happened, so that everyone knows the source of the feedback. -- DannyH (WMF) (talk) 22:37, 26 February 2019 (UTC)

I've moved Manupriy Ahluwalia's row to the bottom of the page, since his Instagram account is private and his talk page here is empty. Jc86035 (talk) 10:01, 28 February 2019 (UTC)
 * I see, thank you Jc86035. That user surfaces the need of having a way to contact different people than the usual ones that participate to every discussion. We will soon send a message to the consultation hosts with some advice to reach at newcomers. If you have any idea, please let me know! Trizek (WMF) (talk) 18:08, 28 February 2019 (UTC)

Distinguishing between conversation and page metadata
I want to highlight that talk pages serve a variety of functions right now: conversation, and then contextual data that describes or responds to the page in question (such as Archives, WikiProject templates, on Wikidata a series of definitions and queries that directly apply to that property or item,etc). Any solution, in my opinion, that approaches the talk page needs to have a clear roadmap for handling this second kind of data in addition to the conversation component. Multicontent revision should allow us to build these new slots for storing the data in conversation with both the talkpage and the content page, so its mostly a matter of deciding what should be stored where, not if we can create other kinds of content. Personally, I think backing a series of Wikidata-like statements into an item, which can describe the state of the content (if it belongs to a WikiProject, if it needs maintenance of a certain sort, where the archive is for the talk page, etc) would allow many more projects to organize their work without the huge overhead required now on EnWiki and some of the other projects to maintain and collect data on article quality, importance, needs for references, etc. Sadads (talk) 18:41, 26 February 2019 (UTC)


 * This is a very good point, IMO. We could have a Metadata: or About: namespace, and corresponding User Metadata:/User About: and so on. These could hold the templates currently used on the talk pages (though I think the Wikidata suggestion is also worth pursuing). Then the talk page would be just for talking about the page. (But that would result in nobody ever ambiently looking at the metadata when going to the talk page (though they probably don't much anyway), which could be detrimental, unless there was a way to surface it (such as a notice in the MediaWiki interface at the top of the page when viewing the article), which would probably be made easier by having it on either Wikidata or a separate page from people talking.)
 * A related improvement to MediaWiki, and one that could be adapted to implement the above as well as being more widely useful, would be to have the option for site owners of having two talk pages, or a talk page and some other kind of discussion page (like LiquidThreads or Structured Discussions), for each content page. This wouldn't necessarily be useful as such for Wikimedia wikis, which are deliberately not forums for discussion of the things they describe, but it could be good for other wikis that do want to be forums for discussion of the things they describe. For example, I'm thinking of establishing a wiki website about a certain class of products, where each model will have an article. We'll need some kind of talk pages to talk about the actual articles and coordinate work on them, but I'd like to also have a separate page for product owners or potential owners to discuss the products themselves. The current best solution I've found (recommended on this very wiki, IIRC) was to embed Disqus or similar at the bottom of the article.
 * This leads me to think maybe the Talk: namespaces should be renamed to Coordination: or similar, and the tab (as seen in MonoBook and Vector at least) should be renamed from Discussion to Coordination, while new namespaces would be added called Forum: or similar (renameable as desired by site owners), with a tab at the top of the page as well. So the tabs would be Article, Coordination, Forum. These would be separately configurable to use wikitext, LiquidThreads, Structured Discussions, or any future talk page implementation, so one could use one and the other another. Forum could be renamed to Metadata or About on Wikimedia wikis, to implement that suggestion. (Though maybe other wikis want to use both metadata pages and separate coordination and forum pages, so… hmm.)
 * You know, maybe MediaWiki should support a (per-content namespace) configurable number of talk/metadata/whatever pages associated with each content page, with the namespace, tab name, and content management system (wikitext/LT/SD/future software) of each one being configurable. I think I might create a new section on this talk page for this (or anyone else is welcome to, if they want to discuss this idea) so as not to derail this section too much.
 * I'm not sure what you meant by "multicontent revision"—do you mean editing metadata in and then editing it out to hide it in the page's history?—but what it reminds me of is branches in a git repository. Specifically, if you're using GitHub, you can create a  branch in your repository that contains webpages, and GitHub will display them on the web. This doesn't interfere with the actual code of your project, which is in the   branch and other branches. So that makes me think that rather than using their own namespaces, talk pages/metadata pages/forum pages/whatever could be implemented as branches of the content namespace they're for, somehow. (AFAIK, no "branch" concept exists in MediaWiki, so it would have to be implemented anew and would not necessarily resemble the concept in git.) (I also just had the thought that they could also be implemented as subpages, but that would get very messy and would require subpages to be enabled in all namespaces, while they're currently disabled in some (Main: at least) by default, for good reasons.) PointyOintment (talk) 17:51, 1 March 2019 (UTC)

Workflows
I recall the presentation on 'structured workflows' at Wikimania Mexico City 2015 (slides embedded here) as both innovative and inspiring on this general topic, it's one of my all time favourite wikimania talks. I really hope the team decides to reinvestigate that work - it was scalable, extensible, modular... - and I see that user:DannyH (WMF) was involved in that AND this so there's some organisational memory of that work. However... having got all inspired by that, and then seeing it immediately disappear, and having watched wmf run hot-then-cold on so many pieces of software that it declares super-important one day, the quietly shelves he next day... I don't wish to get emotionally invested again only to have my hopes dashed. Is this the 3rd? 4th? time that 'let's fix talkpages' has been a priority? So - I wish you well, but I've been burned by wmf 'crying wolf' about its software priorities too many times to believe you again this time. Nothing against your team, or the significance of this issue, but I just don't have faith that wmf won't just re-org this project right out existence within 6 months, once again. Good luck, I wish you well, and hope you don't suffer the fate of so many other wmf software 'priorities'. Wittylama (talk) 13:22, 27 February 2019 (UTC)


 * I understand what you mean, and I appreciate your good wishes. -- DannyH (WMF) (talk) 15:54, 27 February 2019 (UTC)
 * Workflow is an idea were I've always seen a potential for great benefit and enthusiasm. However the project would need to be divorced from the original Flow-based-model. It would have to be recast in terms of our existing work environment (wikitext&wikipages), and it would have to be firmly driven by a community vision of desired functionality. As starting design point I envision functionality that would allow us to replicate&replace Twinkle, such as the AFD process. Details of further capabilities would require in-depth examination. Alsee (talk) 20:22, 27 February 2019 (UTC)

Outsourcing to external microblogging
Those who can't handle the format of MediaWiki talk pages should just use Dissenter. It exists for situations like this where organizations can't get their act together to come up with decent comment sections. Our problem isn't just with the technical aspects; there's also the censorship aspect. Setian~mw (talk) 07:21, 28 February 2019 (UTC)
 * To make this actually work within the existing community would probably require some sort of software development to inform everyone else about these conversations in some way (if most of the prospective users are actually incapable of using talk pages but also want to edit articles), which I think would probably be more trouble than it's worth, if this is a remotely serious suggestion. The article's mention of Gab – as the first word in the title, no less – is also an immediate red flag. Jc86035 (talk) 09:55, 28 February 2019 (UTC)
 * It's not especially nice or useful to advertise proprietary services on MediaWiki.org (we'd never consider Disqus either). It's possible to embed external conversations/comments on blogs and websites since ancient times, it's a completely unremarkable feature: Mastodon is highly used for the purpose and it's trivial to do so. Nemo 16:45, 28 February 2019 (UTC)

Speedup of systematic editing tasks
I'm working on a spell checking project for the English Wikipedia. One of the big problems we have is coordinating the fixing of typos. I have scripts that produce text files that list errors on specific pages, but the best way I have to publish those is just to dump them into wikitext and have people edit them as they fix things. (See en:Wikipedia:Typo Team/moss.) In some cases there are really huge lists across many pages, like en:Wikipedia:WikiProject Missing encyclopedic articles. In other cases, we use categories and bots to track work (see examples under en:Category:Wikipedia maintenance categories sorted by month).

It would be a lot more efficient and maybe more fun for editors to have a UI like Citation Hunt where problems could be presented one at a time, along with instructions, and ideally with an integrated UI for fixing them, so editors don't have to waste time opening an article. This would be particularly handy for a spell checker like mine, where you only need a sentence or paragraph of context, and you really just want to type the correct spelling or click on "proper noun" or a handful of other reasons to ignore the typo. -- Beland (talk) 08:01, 28 February 2019 (UTC)

Wikimedia projects talk pages vs. "external" tools
I think that an issue that needs to be addressed is the division between technical-minded contributors who discuss technical issues at the Phabricator site (and, I think, something called Gerrit for MediaWiki software development, if I understand it correctly) on the one hand, and on the other hand content contributors who (like me) find these sites rather confusing to navigate and understand, and don't feel comfortable trying to report issues there. Personally, I never visit Phabricator - if I have a technical issue, I try to find a page in "my" project (German-language Wikipedia or Commons, mostly) where I hope that one of the "techies" will read my report (and then they're reporting it to this Phabricator thingy or wherever). I think we have a lot of people like me who would like to report their technical issues on the wiki where they work on, and expect the technical people who can fix issues to frequent appropriate wiki pages - also to be told of changes that could disrupt our workflow. A recent example of communication between the tech side and the content contributor side not working very well was the (perceived) sudden disappearance of a special characters bar from the regular wikitext editor that is important to German-language editors. It was then fixed by the local techies, but only after quite a bit of uproar and heated discussion. Another example of how it shouldn't be, in my opinion: Commons:Upload Wizard feedback says in the box at the top of the page: "This page is a place for you to share issues you encounter when using the Upload Wizard interface. However, this page is not frequented by developers." It's called "Upload Wizard feedback" but the Upload Wizard developers don't actually read that feedback? That's a bit strange. So, I think that we need to improve communication between these parts of the community; somehow create a better flow of information in both directions. Gestumblindi (talk) 21:31, 28 February 2019 (UTC)

Disruptive editing is against all workflow or constructive discussion
The European Parlament is trying to disruptive regulating free speech on internet sites like YouTube or Instagram allegedly pretexting copyright issues. Since February 2016 the is a German law, rating any opinion as a cyber attack and abuse the German military fighting it. What affects Wikipedia? In the German Wikipedia a lost of contributing editors is recognized. Recent news in Germany reported the Wikipedia is getting outdated and not adequate maintained. Practical experience showed, the are opinion making accounts active, waiting to fight or participate on third opinions. Checkuser inquiries are blocked. This behavior is supported by administrators. Examples of such forced opinions, enforce references set to place advertising of irrelevant companies into the project. As a result of such disruptive editing, activities of reputation management agencies may not impossible, replacing real contributing editors or misleading discussions to personal range. It is impossible to declare such activities as "workflow". To get successful mentioned by Wikipedia or mentioned the own products there, it appears only to be a question which agency to choose. Advertising, propaganda or reputation management seem to be dependent to choose the agency having the most administrators in the project. A recent judgement allowed to name a disruptive editor due public interests, which means also leaking the so-called "Wikipedian" points to the correct individual. Fading out reliable information is a way to rewrite history, because any news agency or press having descend paying customers eases research by consulting Wikipedia a no cost. If the information is outdated or biased by paid editing, Wikipedia becomes an instrument of propaganda, advertising, product placement, or pillory for important people that do not pay a leading agency. Basic knowledge is being fighted and excluded to place paid content of products in Wikipedia. This is the point we really should discuss. Discriminating editors from contributing may be the primary cause of such activities. Interviewing Wikipedia contributors also showed experts getting blocked or disrupted in contributing. Also disruptive editing is granted in numerous cases. -- Hans Haase (有问题吗) 12:38, 28 February 2019 (UTC)
 * (not a response to the comment's content, which may deserve a proper reply) The above user is currently under a one-month block on the German Wikipedia for "violation of [the no personal attacks policy]; block escalated". Jc86035 (talk) 16:22, 28 February 2019 (UTC)


 * (restored section above) Yes You see a victim of abusing administrative right. Any tool will be abused, if the a constructive talk is disrupted for any reason. -- Hans Haase (有问题吗) 10:38, 1 March 2019 (UTC)

Navel Gazing
We know that both the total volume of human knowledge, processing power and storage volume are growing exponentially. As much as we might want to believe that democracy includes everybody, this is necessarily false. Some people and viewpoints simply aren't meant to contribute to a well functioning, information based society and its associated economy.

In terms of talk, the evolution of community editing to create mankind's' next greatest library, less is more. Who possibly wants to filter through all of the past bullshit to get to the few essential points upon which we must decide? Instead, we must focus on the essential goals and the strategy and tactics most likely to achieve them.

If the primary goal is to build and maintain the world's most factual, reliable and accessible body of knowledge, then spending precious time and resources involving several million more idiots won't get you far. Rather, why no focus on fact-checking and freezing content after any rational debate has ended long ago? See Urbit.

Whoever keeps pushing this "liquid threads" nonsense is insane.


 * The above is User:BorisDorisDoris's first edit on any Wikimedia wiki. (For future reference, you can sign your comments by putting  after them.)
 * I don't see anybody pushing LiquidThreads. To me it looks like everybody who likes either Structured Discussions or LiquidThreads agrees that Structured Discussions is the better of the two.
 * No substantial argument is offered as to why 'democracy can't include everybody' or 'less is more'. Things like "essential points upon which we must decide" and "essential goals and the strategy and tactics most likely to achieve them" are mentioned as if everyone (anyone) knows what those are. What are these goals and decisions? From context I'm guessing this might be about decisions on how to edit an article, and the obstacle is filtering through past discussions on talk pages.
 * The mention of "Urbit" (which I've never heard of before) reads, to me, as an attempt at pushing one's own personal favorite (distributed, blockchain-based, federatable, buzzword-this, buzzword-that) personal server software as a replacement for wikis. (I had to click around and find its "primer" page to understand this, because the linked documentation makes no mention of what it is.) It's also a non sequitur in the context of what was said immediately before it. How does running your own website help with "fact-checking and freezing content"? Content is hardly ever frozen on Wikipedia (and I imagine other Wikimedia wikis), but that's not for lack of tools to do so. Rather, the community has never thought widespread content freezing was a good thing to do. (And I agree: Even on articles that I'd rate as excellent, and upon which the community has bestowed statuses like Featured Article, I see new and beneficial edits every day.)
 * And "the community", I may add, has more participation from people who participate more. Yes, that's a tautology, but it's also the natural implementation of people with more to contribute getting more say. On the other hand, we do not deliberately exclude people who want to participate, but haven't before, just because we think they're "idiots". That's a very strange position for someone who's never participated before to push. PointyOintment (talk) 18:33, 1 March 2019 (UTC)