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 Wikicat: 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.

I split this portion of my comment to a new section to improve clarity.

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 [1]) 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)

+1 Translated using Google Translate. My perspective on communication possibilities within Wikipedia projects. The Wikipedia discussion site is uncomfortable and misleading for many reasons, especially for beginners. According to my experience with Wikipedia and social networks, the most intuitive discussion is the so-called corporate intranet. Google is currently offering G +. From April 2019, a service G + will be canceled for normal consumers. It will only be available for businesses and organizations. G + is sophisticated, guarantees access security and, above all, user identity. When implanted into the Wikipedia environment, this means getting rid of the problem of identifying editors, especially so-called anonymous IP addresses. For editors, you'll need to sign in with an account linked to the G + intranet. G + would have a quick and effective conversation. I suggest deleting Wikipedia's discussion sites to get the capacity to edit pages (articles) themselves (to increase capacity). For beginners, enable talk through Facebook. At a Wikipedia article in the upper right corner, create a button for editors (G +) as well as enter the Facebook environment (regular communication, especially for beginners). Yours sincerely, Josef Kreuz, from Czech Wikipedia. --PEPan (talk) 12:58, 5 March 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)

@Alsee: 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.

2. Your data is grossly incorrect: According to WMF statistics[2] 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.
3. 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.

4. 

   Retention rate for each editing interface

   Your conclusion is wrong: In 2011 the Foundation undertook a strategy to quote: "deprecate wiki syntax as the primary input method".[3] 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)

Oh, brother, 2. Your grotesque hyper-over reaction to a small comment of mine using the term "elitist", kind of shows all the problems in a nut shell with editing Wikipedia. Humorously, you have broken any number of rules here, with your violent attack on my small comment. I wonder how many budding, potentially competent editors, you, yourself, have personally driven away from Wikipedia with your vitriol? Someone who still no longer edits Wikipedia articles. — Preceding unsigned comment added by 97.118.150.186 (talk • contribs) 22:23, 6 March 2019

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:

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[4] 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.

Alsee (talk) 02:41, 14 October 2018 (UTC)

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)

It is good to have a discussion here, I am a very rarely active editor, (because time does not admit it currently) however, the process of finding a consensus about this process is itself very important, wikimedia foundation (if I add all the mediawikis' users) is one of the greatest democratic experiments of out time, it is tremendously important for humanity and this is very difficult to handle. I am in contact with people that feel annoyed and harrassed by wiki pages, and feel that they cannot change them, but the processes have become so complicated. I recall editing some pages very early in Wikipedia and that it then became forbidden zu immediately edit without having it reviewed. Along this ever increasing control to separate the good from the bad edits also came more and more power to some people in the wikisphere.

It is complicated to understand each other correctly, as we are writing in English, but maybe thinking Dutch, German, Russian, Arabic or whatever our original mother-tongue is. We fail, if we think, that our language means the same to everybody else, so that I feel, there needs to be much more clarification of terms. However, the more we define terms, the more complicated it gets and we lose a bunch of people, just because of the increased complexity. Taking the example of the airplane is a good way to describe what happens, but even before deciding why we should use the right, or the left plane, we have images in our heads, what a good plane looks like, if I am an airforce pilot I'll have a complete different idea, so none of those two options fit. My point is, that we need a complete different communication paradigm, this is not about sending out a message that is received at the other end, but there is a lot of emotion in it that needs to be recognised. Our communication is not separable from our physical being, but it is embodied which provides quite a barrier since we are here communicatig across the whole of the globe. This means, that we cannot please one, but we need to be crowdpleasers, therfor my suggestion is, to keep it all optional, creating a mechanism that does not abandon the old, but extending it carefully, so that it can be used either way. I, too sometimes like the gui editor now, as I can quickly jump in for some minor typos, but when it comes to link editing, I find it clumsy to do the clickety click thing... I would, however love, to get mails if I wanted to, and to be able to reply to a discussion via mail, too. And I believe, that this is a case for the semantic web. right now for example it would have helped me, to remember how to make a signature correctly... it doesn't show in the preview... --Triple5 (talk) 03:01, 3 March 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 — 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 Yair rand: 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)

Auto-archiving, and VE on talk everywhere

Was "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)

Slowking4: 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)

Agree. Community engagement at places like "The Well" didn't happen automatically due to page coding, it happened because dedicated people stepped in to host and moderate discussions. What we have going on right now on talk pages is a little like trying to run the old TV show "Candid Camera" without a host or moderator. You can get a few brief interchanges that are useful from random passers-by, but without a consistent presence from a host, you aren't likely to get an ongoing, coherent discussion. Oliveleaf4 (talk) 03:32, 3 April 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)

I'd be concerned that good auto-archiving isn't technically feasible, since working out whether a thread has concluded requires human intelligence. (And e.g. determining whether an important thread such as an RfD requires admin-level experience according to wiki policies.) Even very old threads are often unfinished, since minor topics can have very few active editors. As such a manual but really easy toggle for "this discussion has concluded" would be more helpful than anything automated, along with some good way to browse the archives. GKFX (talk) 13:58, 5 March 2019 (UTC)

by auto archiving, i mean that archiving is the default. now no archiving is the default, resulting in large pages breaking template code. we have many setting archiving to 1 day, since they do not respond to any message on talk, you are referring to norms at RfD Noticeboards with closure of sections, which is not a talk page norm. users should control / adjust archiving of their own pages. Slowking4 (talk) 23:11, 24 March 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)

+1. For various reasons, it is imperative for some of us to have the technical code of conduct (or its equivalent) in place if we are to communicate with others online. Oliveleaf4 (talk) 02:46, 3 April 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:

• 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.

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)

H-stt: 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)

Sicherlich: 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)

The first two bullet-pointed possible solutions are

• Building features on top of wikitext talk pages, to make them easier and more efficient.
• Using Visual Editor on talk pages, with extra features.

Neither of these options involves rehashing the StructuredDiscussions/Flow scenario. (And as Lofhi says something good has come of that development effort too, even if it wasn't so useful as was once hoped.) Asking all contributors, even new ones, to learn a unique markup language just to communicate on the wiki isn't really acceptable nowadays. I've been editing WP since 2011 and consider myself to be highly competent with IT, yet it took me two attempts to quote the bullet points (correctly indented) above. There is probably no perfect solution to talk pages, but it is absolutely worth spending money to ensure that all WP editors can communicate as conveniently as is practical. GKFX (talk) 17:38, 4 March 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 w: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)

Wnt, 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)

Jmabel: 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)

@DannyH (WMF): 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)

@DannyH (WMF): 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[5] 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. Alsee'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 Bahnmoeller 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)

I'm a newcomer to editing. To write this here it was for me a very fiddly task to find this section again in edit view after reading it in read view. As for the rest, I made mistakes, I still make mistakes because I'm learning as I go. I don't want to be disruptive but I make judgements about whether my contributions are likely to be of net benefit. Quite often others seem happy to see what I'm trying to do & correct whatever needs correcting, I watch what they do. I'm never going to be doing more than minor edits to articles & comments on talk pages, if I had to learn everything before doing anything then my little contributions wouldn't happen. (some of my contributions are simply correcting other people's mistakes). Yes there's a lot that's baffling but I have to assume things are as they are for good reasons. I'm now worried that once I've learnt the system the system will change :o) but hey, that's life...86.148.15.250 02:40, 2 March 2019 (UTC) I said "it was for me a very fiddly task to find this section again in edit view after reading it in read view." but of course that was down to the random way I was navigating, a section edit button is provided which makes getting here simple, so sometimes the only problem is lack of familiarity 86.148.15.250 11:15, 3 March 2019 (UTC)

as an experienced editor, i find talk page discussion tl;dr, and do not use them, perhaps we need to alienate some veterans, that may be in the way. Slowking4 (talk) 10:40, 19 March 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 <done> 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)

Exactly this lies behind my remarks made at w:de:Wikipedia:Projektdiskussion/Globale Konsultation zum Thema Kommunikation 2019#Artikeldiskussionsseiten komplett abschafffen. The big language versions have way too much articles which can be watched indiviually and maintained in a reasonable time, so canalizing their talkpages to related WikiProjects (or portals) could help. [Note, that in DE:WP portal talk pages often serve as WikiProjects. In general, wikiprojects and portals in the English Wikipedia are much more distinguished than in the German WP, and even if both a wikiproject and a portal do exist, in many cases one of them has its talkpage redirected to the other.] --Matthiasb (talk) 04:30, 2 March 2019 (UTC)

Ah, I hadn't noticed these comments before starting my section On Encouraging New Editors below 86.148.15.250 21:35, 4 March 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)

Sunrise: 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)

@Bahnmoeller: , 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)

John Cummings: 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)

Risker: 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 Usergnome: 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)

@DannyH (WMF): 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)

@Isarra: 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.

1. It's reliable. There's no fancy new software to behave unexpectedly.
2. It's familiar. Everyone on Wikipedia knows how to use a talk page.
3. It's easy. There are no signs that newcomers have difficulties, and they need editing skills to update articles anyway.
4. It's consistent. Editing a talk page is just like editing an article, whether you use VE or traditional text or some other editor.
5. 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.
6. 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.
7. 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.
8. It's cheap. Developing the system I propose will take zero hours, cost zero dollars and have zero bugs, with zero risk of overspend.
9. 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)

I know this comment is a little old but I'd like to address each of your points in turn:

1. "It's reliable": This is a fair comment, since it's just code at the end of the day so it's difficult for the system to misinterpret something. However, I don't think this precludes change in the future.
2. "It's familiar". Sure, everyone currently on Wikipedia knows roughly how to use a talk page, but this doesn't make these
3. "It's easy". Categorically untrue. MediaWiki talk pages are pure code. It is ridiculous that people need to do things manually that literally every other website does automatically (signing posts, adding indents, posting to the bottom of the page). Heck, this comment includes at least 30 colons and nine pound symbols.
4. "It's consistent". While on the surface a good thing, the context on talk pages is very different so I'm not sure this is a great argument.
5. "It's integrated". This can presumably be carried over into a new talk page system. I'd also argue it's a downside - there currently is no way to only watch a talk page.
6. "It's flexible". Performing research on talk pages is almost impossible because it's so unstructured.
7. "It's multi-purpose". This is true, and a fair point, though I think our system at present is very hacky and there are other, better solutions for things like WikiProject templates and hidden categories.
8. "It's cheap". It may well cost no money to just sit on our hands, but it will also provide zero improvements.
9. "It's popular". Everything is popular at some stage or another. I remember when this argument was tallied in opposition to VisualEditor, which now is objectively popular among even the most veteran Wikipedia editors.

I personally believe talk pages are a huge barrier to Wikipedia for newcomers, and keeping them as they are perpetuates this view that Wikipedia is only for the "old guard" and nobody else is welcome. It is frankly mindblowing to me that people would defend a system that is so objectively bad and so backwards when compared to almost every other online communication system in 2019. Fox (talk) 18:32, 28 March 2019 (UTC)

"Since then everyone seemed to be fine with the way it was." I think you have a very warped view of "everyone"..... —TheDJ (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)

@Certes, StYxXx, Wargo, and Scott: 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)

I'm a newbie minor editor (not sure how many colons to best address this discussion!) a bit erratic but I respect Wikipedia (for all its imperfection a simply amazing endeavour). I'm an internet surfer (Wikipedia articles are near the top of almost every Duck Duck Go search I make) so take an interest in a wide range of subjects . As long as people are tolerant of my mistakes on talk pages - and sometimes help correct them - then as they are I agree they are an ideal training ground for editing articles. I'm most unlikely to ever get round to creating an article from scratch but I would assert that there's clearly a role for people like me to (e.g.) correct uncontroversially obvious errors in articles I come across.86.148.15.250 22:09, 4 March 2019 (UTC)

yeah, in my experience new editors do not know what a talk page is; and they do not use them, when pointed out to them. they would rather edit articles. and since they only edit at meetups, their collaboration is face to face. and yeah the addition hurdle of editing on tablet is a problem. the burden of turning on VE tab is a major time waster. Slowking4 (talk) 10:36, 19 March 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)

Jc86035: 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)

@Trizek (WMF): 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 gh-pages 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 master 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)

Look at en wikinews - they allow to comment news, you can see "opinions" and it uses LQT. Multi-Content Revisions is the new concept and MediaWiki has already implemented needed structure so it works now. Current feature using it is Structured Data on Commons which is stored separately from wikitext but releated to page and shares history page. You understanding seems good. --wargo (talk) 01:08, 2 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)

Wittylama: 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)

SMH. Pythoncoder (talk) 18:21, 17 March 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. — Preceding unsigned comment added by BorisDorisDoris (talk • contribs) 05:51, 01 Mar 2019

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 and/or talk pages. (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)

Upon rereading, I see that User:BorisDorisDoris may in fact be attempting to push Urbit as a replacement for the Wikimedia Foundation's wikis specifically, not just the centralized wiki model. I had thought that the first time but then changed my mind; now I've changed it back somewhat. Urbit was created explicitly to take a stand against the current state of the web, where websites are run by "Megacorp" and users are "just rows in their database". This is an unfair thing to say about the Wikimedia Foundation, because it is a charity and its wikis are undeniably a social good. They do not try to psychologically manipulate their users or collect their users' personal data. Urbit seems like an attempt to go back to something like the 1990s model of the web, though using currently topical technologies, where everyone has their own website that they personally administrate and serve from a computer they personally own. While I have no objection to that model, it is not the best model for everything. Other models for collaborative encyclopedia websites have been tried, and can be tried in the future, but Wikipedia has been the most successful (so far). Anyway, if this reading of the above post is correct, that it's an attempt to push Urbit as a replacement for wikis, specifically the Wikimedia Foundation's major wikis, not just talk pages, that is way out of scope for a discussion on how talk pages can be improved. Even promoting it as a replacement for talk pages only would be out of scope, unless the proposal is to integrate it into MediaWiki somehow. PointyOintment (talk) 18:55, 1 March 2019 (UTC)

In defense(?) of LiquidThreads

I don't like either but LiquidThreads is much better than Flow/Structured Discussions. A few reasons that come to mind:

1. No infinite scrolling.
2. Full wikitext support, with everything that entails. Creating a topic feels like creating a talkpage section in the wikitext editor.
3. The design is dated, but at least it's 1) more consistent with the rest of Wikipedia's design, and 2) unlike Flow, it will look just as dated 10 years from now as it does today.

This is not intended as an endorsement of having LT replace wikitext. Also thanks to whoever turned off Flow on this page because if it was on there's no chance I would be posting this. — pythoncoder  (talk | contribs) 16:28, 19 March 2019 (UTC)

On Encouraging New Editors

I am a new occasional editor. Where I started was seeing somewhere advice that if I saw a mistake within an article but lacked the skills to put it right I could leave a message on its Talk Page. I was reminded of this when reading on the consultation page "Users for various reasons may not want to use the current talk page discussions to provide feedback. Some capable editors across sites simply do not use them as a regular means of communication..." My first Talk Page comment was ignored, so eventually after six months I modified the actual article itself in a manner which cured a misleading faulty link but left the text a bit clunky, I flagged my edit appropriately & this very quickly drew the attention of a more experienced editor (my guess perhaps the article's creator) with all the knowledge to put things right. My point is that if 'capable editors' are not monitoring Talk Pages then firstly 'why?' & secondly do we need another way for readers of articles to flag up errors? Obviously if well intentioned newbies who have a valid point can be ignored when doing the right thing then that could be discouraging. 86.148.15.250 10:45, 3 March 2019 (UTC)

Essay on wikitext

About one year ago I wrote an essay on wikitext in Polish. Because it seems relevant to the present consultations, I have decided to translate it into English and link here for everyone to have a look at: Essay on wikitext.

Gżdacz (talk) 12:13, 3 March 2019 (UTC)

Why not something as a meet.jit.si/PAGENAME on all talk page ?

Especially during conflict, we can imagine a link on all talk page to joint a jitsi room (or similar application) for discussing. All discussions can be automatically recorded on wikimedia comons under a certain license and stay accessible for other by an url automatically added on the talk page. A way to keeping an history of all conversations. Lionel Scheepmans ^{✉ Contact.} 15:42, 4 March 2019 (UTC)

Agh. No, please, all the discussion should be on the one article talk page and its archives. Editors should not have to look elsewhere to find discussions. Doug Weller (talk) 17:02, 6 March 2019 (UTC)

Not wishing to make your life difficult but Wikipedia Talk Page Guidelines appear to be both interpreted & 'policed' very differently depending on the subject of the article and the 'communities' involved. Across a very wide range of subjects I think we can end up with skewed articles because not enough informed discussion of the subject has been allowed. An encyclopaedia doesn't need to make a controversial subject non-controversial, rather I tend towards a view that it just needs to allow space somewhere for all sides of an argument to be fairly seen for what they are. It often seems to me that if a discussion is wandering out of the desired scope of an article talk-about-editing page then rather than censor it maybe could be better to direct it to a linked page where a little more flexibility can be allowed without disrupting the edit process. Just a thought :o) 86.148.15.250 17:30, 7 March 2019 (UTC)

Answers to the five questions

Thanks for starting the talkpage consultation. I appreciate you try to contact community members, solicit input and do research on the technical aspects of talk pages and how users interact with them, prior to proposing changes. How current users interact with the millions of talk pages can directly be observed. How newcomers might interact is harder to observe. You probably will have to invite them into a laboratory set up.

1. When you want to discuss a topic with your community, what tools work for you, and what problems block you?

   What works for me is in order of declining effectiveness: face to face meetings, video conferences, teleconferences, phone calls, IRC chat, texting, Discourse, Facebook group post/discussion, e-mail, e-mail list, on project user page talk page, on project article talk page, off project wiki talk page - like on meta or on mediawiki. The project team has raised five questions in this consultation. It looks like I'm the first who tries to answer those questions on this page. A conversation or dialogue will work as, if and when the participants have met before and have built op a relation in the past, and there is personal contact in the communication. It is all about trust. And is all about providing a safe social environment for people to participate. It is a lot about behavior and attitude of people. Are people prepared to assume good faith? What blocks me sometimes is (technical) support that helps structure dialogue. For example mechanisms to visibly steer your eyes towards the resolutions of an issue. Article talk pages serve multiple purposes and goals. One of them is some editorial issue with the article. The issue can probably best raised as a question by someone who raises the issues. Other participants can provides answers or resolutions to the issue or questions. Sites like Stackoverflow and Quora have a question/answer model. Participants on those sites can not only answer question, they can also up-vote and down-vote answers by others. The "best" answer up to date appears on top of all the other answers. Those are examples to help resolve issues on other sites. Those sites also allow to flag posts as inappropriate. My wish, desire and goal for talk pages is friendly, polite, decent and respectful dialogue to resolve issues with for example articles. Technical support that promotes preferred behavior is most welcome. Ad Huikeshoven (talk) 15:43, 10 March 2019 (UTC)

   +1. What works for me is face to face meetings, phone calls, and occasional e-mail with known individuals. There are many reasons to avoid having an online presence. If you live long enough to watch people go through divorces, crime, and other messy situations, you will come to realize that maintaining privacy can be very important for maintaining peace, harmony, and safety. Oliveleaf4 (talk) 03:23, 3 April 2019 (UTC)

2. What about talk pages works for newcomers, and what blocks them?

   Newcomers are not new to the Internet any more and have seen quite a few other websites and social media before they stumble on wiki talk-pages. Those other website display newer technology and user interfaces than does MediaWiki talk-pages. The main feature of those newer technologies is that after entering the website / logging in, the user can point the cursor directly into a input-field somewhere and start typing, without having to worry about indentation or signing. Some say, that are just three barriers everybody can overcome and learn. Maybe one in ten will overcome those barriers, nine out of ten won't enter. The possibility to up-vote or down-vote posts by others is just a single click, and is an issue, low barrier of entry interaction, which provides valuable information. Apart from technical barriers there are behavioral barriers. Newcomers might read what is already written on a talk-page. They might see and read hostile reactions to post by other people. They might decide not to enter an hostile arena to protect themselves. Ad Huikeshoven (talk) 15:43, 10 March 2019 (UTC)

3. What do others struggle with in your community about talk pages?

   Vandalism on Wikipedia article pages does occur. It does occur that companies, persons and institutions try to write an article about themselves, which end up not to be up to standard with Neutral Point of View. They might end up in a talk-page discussion with and editor who 'defends' Wikipedia against 'POV'-pushers. As all articles are written by people who know and care about the subject, probably because it is close to home, study or work, it is just behavior, interaction between a more experienced editor with a newcomer.

   Some 'talk' pages, like some village pump pages on some wikis are not an example of friendly, polite dialogue.

   For me personally I can do completely without Articles for Deletion pages, as article talk pages themselves provide plenty of room to discuss any and all issues with the article, including ideas about deletion.

4. What do you wish you could do, but can't due to the technical limitations?

   What I want and desire is:

   1. the ability to enter the cursor in a comment box without having to click on edit
   2. the possibility to up-vote and down-vote posts, mechanisms that help surface the "best" resolution of the issue based on crowd sourced input
   3. the possibility to flag inappropriate posts
   4. the ability to hide from my view posts from users I don't want to see
   5. the ability to have some control over "my own" user talk page, for example control over who can or can not post there or even who can or can not view that page. Those are not only privacy rights, but also mechanism for providing a safe environment for volunteers (and employees) of an organization. Judicial obligations differ per jurisdiction in this regard.
5. What are the important aspects of a "wiki discussion"?

   The current system is open and transparent and retains discussions for eternity. Some people do value that. It might be good to keep a record of the outcome of past discussion including summaries of main points, and to delete once in a while (five years?) old discussions. Some people are experts in digging up "old cows" with a ten year old page diff of a talk page to make the point you were wrong then so you are wrong now. Those are behavioral aspects more than technical aspects. Ad Huikeshoven (talk) 15:43, 10 March 2019 (UTC)

6. Some afterthoughts

   Relevant questions in this regard, not raised so far: (Ad Huikeshoven (talk) 15:43, 10 March 2019 (UTC))

   1. We are all here to share knowledge and write articles in the article namespace of Wikipedia and other projects. Why and when do you need (to enter) a talk page?
   2. What are your purposes, goals or reasons to post on a talk page (of an article, of a user page, of a sitename page, ...)?
   3. What do you achieve by posting on a talk page?
   4. What do you gain by posting on a talk page?
   5. How important is personal contact with other people who contribute to the wiki?

      1. Very important! Based on observation, I'd estimate that are about 2,500-3,000 core editors who do the ongoing maintenance tasks that keep :en wiki going; some of the core editors may work on other languages. If the WMF wants participants to develop trusting, ongoing relationships, and stay motivated to maintain the encyclopedia's quality, the organization needs to ensure that core editors who are interested get the opportunity to meet up with other core editors. Editors with international interests and work need opportunities and support to attend Wikimania, not just local events. It is not a waste of money to invest in people who provide many hours of free labor, so they can connect with others who have shared interests and expertise. Discussing how to collaborate in person can produce much more effective results than random individual efforts, even if all you discuss is "what tasks do you think are most important right now?" Oliveleaf4 (talk) 03:23, 3 April 2019 (UTC)

   6. How do you relate to other people who contribute to the wiki?
   7. To what extent do you feel or sense to be part of a community?
   8. What blocks you in meeting co-editors face to face to work together in good harmony on article(s), or other means of more direct personal communication?

      1. Thanks for asking! Transportation costs are high in our area. It would be helpful if our local organization would provide reimbursement for transit fare or gas. Oliveleaf4 (talk) 03:23, 3 April 2019 (UTC)

   9. What is the influence of the high proportion of people somewhere up in the autism spectrum compared to the general population on the way talk pages are used as they are, rather than other channels of communication?
   10. How best to deal with this kind of diversity?

Mi opinión

Voy a escribir en castellano porque es una lengua que controlo mejor que el inglés.

Mi opinión:

• El sistema de edición en wikipedia (y hasta donde sea posible en el resto de proyectos) debe ser homogéneo
• Normalmente uso editor visual. Si la cosa se complica, uso wikitexto.
• He usado flow en la wikipedia en catalán, pero no me termina de gustar. El principal motivo es que encuentro difícil rectificar mis errores.
• Fuera del wikiespacio me gusta usar Telegram (lo prefiero al Whatsapp) y el correo electrónico. Telegram para cosas inmediatas. Correo electrónico para las cosas más formales y relevantes.

What follows is an attempt to translate my previous text. If in doubt, check the Spanish version.

My opinion:

• Editing system in Wikipedia (and other projects as far as viable) should be homogeneous.
• I usually use Visual Editor. If the thing gets too dificult, then I use Wikitext.
• I have used Flow in Catalan Wikipedia but I did not enterely enjoyed the experience. The reason is that I found dificult to ammend any mistakes I made.
• Outside Wikispace I prefer to use Telegram (much more than Whatsapp) and e-mail. I like to use Telegram for immediate affairs. I prefer e-mail for more relevant and formal affairs.

B25es (talk) 19:01, 10 March 2019 (UTC)

From Wargo

My visions of talk pages.

• New posts tracking. Current: need to watch, on history there are marks when last visit happen, helpful is "visual diff" (especially for new posts) so we can read new posts without find added posts on page itself or ignoring formatting or parsing in head. In Flow there are blue marks on left border. LQT has special page to watch discussions. Also, I imagine refresh button but this will be need for very active discussions (pretends real-time talks).
• On some wikis talking with user takes place on two talk pages. It is uncomfortable for other readers or for those who want to join (so it increases jumps between pages). Mentions in current wikitext call reduce this difficulty (reason for replying on other talk page is notification about new message or necessity to watch page I left message)
• Thread watching
• History - in Flow it is easy way to filter history of specific post but needs to be improved to allow better browsing, reverting and comparing multiple type of changes.
• Visual editing - I support existence of both editors either on article pages and talk pages. It is possible to do, Flow also connect these two ;)
• I can't understand hate to new technical things; most have choice which you use; Wikimedia do not enforces most things and you should also not try to prohibit users using VE or something else. Why do you not like new features? Of course I understand discussion pages needs some significant technical changes which may not allow to use previous. I don' thing other systems disturbs work on articles, they can help! There is also need for competences during technicla discussions - people (proposers, opposers and programmers) must understand technical issues of their proposals. And they need to remember other people also have needs and ideas and you should not command them. Also, we do not try to make similar to Facebook and other social media - and its reverse - social media talkplaces are not first places - forums and comments were before (even before clean talk pages!).
• Archiving - current system to copy messages or move whole pages to subpages peridically is ugly. It needs advanced things to do so and makes difficult to permanent linking to discussions, finding and filtering old discussions and makes mess with edit history.
• Social aspects and external tools: I think off-wiki communication make smore social and we are not use them to building articles or create rules but use for comments, views from readers point and other thing not directly important for editing wiki but also needed to make full engagement to our work. Off-wiki communications is also good for newcommers and to talk about wiki to external audience (non-editors and maybe non-readers). Some other kinds of communication happens on chapters or other helpers, functionaries. Real meetings are also important. Separated forms of communication is also good for those who wants take advantage of social media etc but of course will never be available on-wiki (making pure community, with friends linking, like'ing etc.).
• Object linking (not Object Linking and Embedding although one user on local version of this consultation proposed similar) - maybe we should allow technically to allow point to revision about what is post on talk page or other discussed object?
• Provide easy way to mark as resolved or lock topic. Moderation tools needed: move, remove/edit particular comment.
• Some participants raised that current talk pages accustome with wikitext. I can't full agree, because even for experienced editors it makes cumbersome to so some things and it takes time. But allowing use wikicode in "message" regardless of discussion type can satisfy all - people can use (and newbies can learn) wikicode and it will be possible to add missing things which can't be done in current standard pages.
• I saw term about some talk pages as work space containing not only discussions (suggestions, questions...) but also templates and other stuff (snippets and maybe drafts). I saw above someone proposed using MCR - good idea! For example Flows can't support them. The only place currently is board header but it is description or rules for certain talk page. By the way, board description should be on top (as in LQT), not on sides - even proper use of it needs sometimes adding more and formated content, also can be blank on most pages and also makes too many space under this box.
• Forums, comments are normal things and only wiki have this archaic-looking system. It is difficult for use even for those who know how to use it.
• We need to collect voices of newbies or recollections from time experienced editors started and reach people with body difficulties
• Disabled people need amenities.
• Easier quoting?
• Proposed by others: signatures, search, VE (regardless of system), identations, thread watching... But not: external plugins to host discussions, no need for avatars, hiding/displaying only some messages depended on votings, ignoring. Keep present in dedicated systems: thread summaries, board descriptions, one discussion thread represented by Title object :)...

wargo (talk) 14:36, 13 March 2019 (UTC)

"Embrace and extend" talk pages with a JavaScript wizard

Various people have already made a strong case for the advantages of the current wikitext-based system over any dedicated discussion system - both on the main page and on this talk page, like Alsee's post. To the list of advantages that have already been specified, let me just add one more: information density. Difficult issues require lots of discussion, and that discussion needs to be read by many people. Imagine trying to read the current contents of this talk page in a standard commenting interface, with its boxes and copious amounts of whitespace... and then imagine trying to scroll back and find a point somebody made. It would be an exercise in frustration.

Nonetheless, wikitext is not a perfect system. Beginners need to learn about colons and tildes, and the accessibility of reading - from mobile devices, for the visually impaired, etc. - could/should be much better. Also, it would be great to be able to be notified if someone responds to your post, or to a post within a section that you have commented in.

So, this is my proposal: have a JavaScript-based wizard that aids people in adding talk page comments. When a user goes to edit a talk page, if they hover over a certain paragraph, this wizard (which would presumably be a gadget and/or extension) could place some kind of icon above or to the side of the paragraph, with text that reads "Reply to this comment". If they click on the icon, they would get a popup window where they enter the comment they want to make - if they then click "Submit" in the window, the comment would go into the right place in the talk page wikitext, properly intended and signed. The user would then just have to hit "Save" (or "Publish changes", or whatever it is) to save their comment.

So why do I talk about "embrace and extend"? That was a phrase used to describe Microsoft's strategy in the 90s (although in reality the strategy was "embrace, extend, and extinguish"). In the case of talk pages, the idea is that, once this wizard becomes widely used, it could produce an output that's more complex, and more useful, than just colons + text + tildes. Here is what a short talk page section could look like:

==Spelling of first name==
{{comment|id=628908734|author=Eddie Editor|timestamp=202009231012|text=Is his name really spelled "Iven"?}}
{{comment|id=628908752|reply to=628908734|author=Sandy Speller|timestamp=202009250950|text=Yes, it is - check the sources.}}

This "comment" template, using the "reply to" values, could automatically apply the correct set of indentations, and it could apply different formatting on smaller screens - as well as putting in HTML to allow for good handling for the visually impaired, etc.

Of course, this kind of syntax could already be implemented. (Well, I'm not sure about the automatic indentation thing, but let's say that it can be done.) But it would be too complex for editors to type in manually. If all comments were being added via a wizard, though, it could be doable.

Wouldn't syntax like this be more difficult to read when going to edit a talk page? Yes - unless VisualEditor was being used. So a wizard like this may also make sense as a VisualEditor plugin. Yaron Koren (talk) 03:24, 22 March 2019 (UTC)

Summaries

@Trizek (WMF) and DannyH (WMF): I have some concerns regarding the communities summaries. I've tried doing one for Wikidata, and it took a fair amount of time (I think more than an hour), even though only about 15 people participated.

• Did I summarize the right things? Is the summary too detailed?
• Was it appropriate for me to put my own opinions into the conclusion?
• Are the summaries going to be used quantitatively?
• What happens if/when there is no summary posted for a discussion (particularly those not in English)?

Jc86035 (talk) 11:46, 4 April 2019 (UTC)

Also, regarding the status updates: if community members are in the target audience, it would probably be helpful if staff members' usernames could be indicated after their first names. I can't speak for everyone else, but I usually recognize other editors by their usernames (e.g. I only figured out that "Sherry" = "Whatamidoing" earlier today). Jc86035 (talk) 14:31, 4 April 2019 (UTC)

Hi Jc86035: Thank you for writing the detailed summary. Honestly, we weren't sure what to expect when we asked people to write summaries, and we're happy to see that the two we've received so far are really helpful and complete. I'm glad you added your own conclusion -- one thing that we're interested in is how the people in each community view the discussion. When I read the discussions, it's natural for me to draw my own conclusions based on my interpretation, so reading your conclusions as well helps to round out the picture, and points out things that people on our team might miss.

We're not going to be using these quantitatively, in the sense of counting up votes for one side or another. It's important for us to note the themes that come up often, and the strength of feeling from one community to another, but we're not going to add up numbers and get an answer that way.

We're hoping to get summaries from everyone -- for each group, we've got someone who signed up to report back. We've been asking for help with translations and clarifications as we go along, and if we can't get it, then Google Translate at least helps us get the gist of what people are saying.

Thanks again for taking the time to participate in the discussion, and write your summary. We'll be doing a big writeup of what we've learned from these discussions; your participation is really helpful. -- DannyH (WMF) (talk) 23:46, 4 April 2019 (UTC)

Hope to see flow topics able to be archived

I wish flow topics could be moved from one page to another or moved up and down regardless of the time order (for now the topics with new replies are above). This would be helpful for arranging previous discussions and it would be more convenient for future reference.

For example, there are a lot of questions being asked at Project:Support_desk. If these questions can be archived to the exact extension/MediaWiki version correspondingly, it may be helpful and beneficial for other users for reference, finding the old stuff in the same place.

If developers would like to continue to improve flow, I hope they could take this feature into consideration.

Thank you! --94rain ^Talk 11:15, 27 April 2019 (UTC)

Smartphone app/text notifications

I posted this onto Wikipedia's Idea Lab Village pump the other day, and I was directed here by a foundation employee. As a suggestion that popped into my mind, I'm not sure if such a feature exists, but maybe there should be some sort of app or text notification service of some sort where, if a user decided to sign up for it, could give them a smartphone notification where accounts (obviously not IPs) are given a notification when they get things such as user talk page messages, pings, change in rights (including blocks), reverts, thanks, etc, and also if there are changes on a selected page on their watchlist (I could see that mostly be used for discussions such as article talk pages, other user talk pages, village pumps, AN(I), AFD, RFA, Arbcom, WikiProjects, etc.). Smartphone notifications could be enabled by the user through some app and/or by text (potentially subject to data rates applying outside the control of the WMF, at their own risk) to receive through those means at either, at their discretion, an unlimited or a set number of notifications in two categories: User notifications, and watchlist notifications (you can probably distinguish the two given the examples I provided). How feasible would such an idea be? One pro would be arriving at their potentially time-sensitive and important Wiki matters quicker than they otherwise would have. Thank you for your input. DrewieStewie (talk) 07:14, 29 April 2019 (UTC)

Medium-term plan

How do the talk page improvements fit into the Wikimedia Foundation Medium-term plan 2019? Which metrics will be improved by these changes? DBarratt (WMF) (talk) 20:26, 20 May 2019 (UTC)

DBarratt (WMF): This is a key component in the Thriving Movement priority. Welcoming and supporting newcomers, reaching out to diverse contributors, creating safe and secure spaces -- all of that relies on a communication system that people can learn quickly, and use efficiently. The immediate metrics to look at will be the number of people at different experience levels using talk pages. If the hypothesis is true that less friction in the communication system leads to more connections, more answered questions and less frustration, then we should see increases in contributor retention, especially for newcomers. That's a hypothesis, but that's what we're aiming for. -- DannyH (WMF) (talk) 05:05, 22 May 2019 (UTC)

German banner

The banner promoting this consultation currently displayed in German-language Wikipedia is phrased a bit strangely: "Die Wikimedia Foundation möchte es Ihnen erleichtern, mit anderen Redakteuren zu sprechen. Wir laden Sie ein, unsere vorgeschlagene Richtung zu überprüfen". Firstly, editors in de-WP usually don't call themselves "Redakteure", that's an uncommon word in our context - uncommon enough that it makes it somewhat hard to understand who is meant by it. Though a dictionary might give "Redakteur" as a translation of "editor", I think most German-language Wikipedians would perceive it as too formal a word, implying some kind of official editorship. Then, it also uses the formal "Sie" for addressing, which is also rather uncommon in the German community where we use the informal "Du" mostly, but it might be intentional to show the distance of the Wikimedia Foundation from the community and give the banner an official character? ;-) Gestumblindi (talk) 11:23, 5 June 2019 (UTC)

Hello Gestumblindi, and thank you for your feedback.

I've asked multiple people to help for translations, but I didn't get any. :/ Since I don't feel really welcomed to post on German Wikipedia, I've asked people outside of the Wikimedia movement to help on that translation.

If you have a better wording, please change it directly there. I'll then apply the change.

(And if you have time, can you also please translate that other message for a maintenance banner?)

Thank you, Trizek (WMF) (talk) 08:18, 6 June 2019 (UTC)

@Trizek (WMF): Thank you. I changed the wording to "Die Wikimedia Foundation möchte es erleichtern, Diskussionen zu führen. Wir laden Dich ein, unsere vorgeschlagene Richtung zu überprüfen." I couldn't think of a good 1:1 translation of "editors", as there is no equivalent word used in all contexts in German-language Wikipedia. I could use "Wikipedianer", but I suppose that the banner will also apply to other Wikimedia projects than Wikipedia. "Editoren" is sometimes used, but not that common, and also kind of an anglicism in that context. "Bearbeiter" could work more or less, but seems very technical and is also not gender-neutral ("Bearbeiter und Bearbeiterinnen" would be cumbersome, solutions like "BearbeiterInnen" are controversial). So I avoided the word altogether and wrote what translates as "The Wikimedia Foundation wants to make it easier to conduct discussions". That's also avoiding "sprechen" from the previous translation, as this is mainly used for the actual act of talking, and the talk pages in German Wikipedia aren't called "talk" (or a translation of "talk") but "Diskussion". - I also translated the message for a maintenance banner. It says now it's 67 % translated but I don't see more to translate there? Gestumblindi (talk) 10:53, 6 June 2019 (UTC)

Aschmidt has now added "Benutzern und Lesern" ("users and readers") to my modified translation. I don't disagree with this addition, although I think it's neither necessary nor completely uncontroversial. Apparently, it's using the term "Benutzer" in the technical meaning of a registered user (prefix "Benutzer:" in German Wikipedia, as "User:" in English) as an attempt to find something to stand in for "editors", and adding the "readers" for users who don't contribute directly to the content, but still might want to participate in a discussion. I wouldn't have done this, as it needs some background understanding of "Benutzer" as a technical term (because, of course, on the other hand everyone using Wikipedia is a "user" in the broader sense, even if "only" as a reader), and thought it sufficient to say that the WMF wants to make it easier to discuss (without specifying who is discussing); also, there is the issue of gender - "Benutzer" and "Leser" are grammatically of the male gender; but the so-called generic masculine noun is still widely accepted in the community, as recent discussions show. Gestumblindi (talk) 20:08, 6 June 2019 (UTC)

@Gestumblindi: As you know the current proposal at deWP on the use of gender neutral language is drastically failing with over 70% disapproval. The banner clearly does not need to use gender neutral language. The community at deWP vastly reconfirms the use of the traditional "generical" masculine grammatical gender.

@Trizek (WMF): When I just tried to look at the translation I got a message "Unknown filter please". The old banner is still displayed at deWP. Did you not approve the changes? You could definitely go with Gestumblindi's version - there's nothing wrong with it at all - and the two guys can take their time to find a compromise on additional minor changes. Please. --Martina Nolte (talk) 03:39, 7 June 2019 (UTC)

All changes have been applied. Thank you for your help, Aschmidt, Gestumblindi and Martina Nolte! Trizek (WMF) (talk) 08:48, 7 June 2019 (UTC)

@Trizek (WMF) and Martina Nolte: I think the message "unknown filter please" came from a missing space in If you have a better wording, [https://meta.wikimedia.org/w/index.php?title=Special:Translate&action=proofread&group=Centralnotice-tgroup-Talkpagesconsultation2&language=de&filter=please change it directly there], leading to "please" in Trizek's message being added to the url as a "filter" parameter. I have added the space now :-) Gestumblindi (talk) 10:26, 7 June 2019 (UTC)

What is the status of this project?

I tried to read through the wall of text (there seems to be no summary?) of this page. I assume this is another incarnation of FLOW, a beta-test I participated in many moons ago on enwiki. I have always been a supporter of better communication tools for talk pages, and this is a topic near and dear to my heart.

So, what is the status, is there anyone here who will tell me? Ottawahitech (talk) 15:09, 21 July 2019 (UTC)

@Ottawahitech: According to talk page comments by staff and the status updates, the only remaining work is the creation of the phase 2 report by the team; there will not be a phase 3 and the community consultation is complete. Phase 2 ended about a month ago. Jc86035 (talk) 14:04, 22 July 2019 (UTC)

@Jc86035: Thanks so much for responding. This is not the first wmf "consultation" I have attempted to participate in, and not the first one that seems to be abandoned by the staff that started it, but with glowing statements on the project page such as this one here:

To encourage trust and good faith, the consultation and ultimate product development will be entirely public and transparent. Every step will be documented on wiki.

I am curious to find out the reason for this state of affairs. Is it because the employees who start out these discussions/consultations have moved on to other jobs and their managers don't know what to do next? Does anyone really care? Ottawahitech (talk) 11:55, 26 July 2019 (UTC)

@Ottawahitech: I don't think it would be fair to describe the project as "abandoned", since staff are still working on it (there was a status update posted earlier this week, and I got thanked by a team member for my earlier response to you). I assume it takes a lot of time to categorize and analyze thousands of comments in a dozen languages. The main reason that "the community consultation is complete" (I think I could have worded this better) is because each feedback phase was only four weeks long to begin with, and most of the discussions were inactive by the time each phase was supposed to end.

I wouldn't know why it took this long for you to find out about this, but it has been noted that it's incredibly difficult to actually notify everyone who would want to know about an ongoing project (barring something like a MassMessage sent to every active user). Jc86035 (talk) 12:06, 26 July 2019 (UTC)

@Jc86035: Thanks again for responding. I have never seen you before, so I appreciate your continued followup. I take it you are an unpaid volunteer? So, I wonder why the people who are paid to do this job are not doing what you have managed to do, engage one confused community member in these so-called consultations?

Yes, I agree it is not easy to reach an audience on any Wikimedia project. We all know that as volunteers, but I thought that was the reason for hiring 360 (I think) wmf employees who are paid to do this job since volunteers cannot be relied on in such circumstances. But as this little exchange illustrates, there is something to be said about the fact that volunteers have passion, while for some paid-employees (including managers) this Is just a 9-5 job.

For anyone who does not know me, I am an indef blocked User/"editor" on enwiki, I think because I have a tendency to talk about issues that others want to sweep under the carpet. I hope my posting here, even if you consider it ignorant, will not lead to me being globally locked. I am trying to be constructive by saying what others are too scared to say. Ottawahitech (talk) 13:15, 26 July 2019 (UTC)

@Ottawahitech: I guess I was probably just the first to respond because you asked on a Sunday, and there was nothing on-wiki that the team was supposed to attend to this week (other than the progress pages). Most staff seem to only make edits with their staff accounts during their work hours. Jc86035 (talk) 13:37, 26 July 2019 (UTC)

@Jc86035: Thank you for all your help Ottawahitech (talk) 02:06, 16 August 2019 (UTC)

Update?

Any updates from WMF employees who are paid to run this "consultation"? Ottawahitech (talk) 02:06, 16 August 2019 (UTC)

@Ottawahitech: Coincidentally, the phase 2 report was finally posted earlier today. Jc86035 (talk) 04:25, 16 August 2019 (UTC)

I looked at the wall of text (phase 2 report) and can't find an answer to one of my main questions: will there be permalinks to enable me to link to individual posts? Am i making sense? Ottawahitech (talk) 05:07, 16 August 2019 (UTC)

They don't know yet. They'll be looking at it, but I'd file that one under "no promises". Please put the main Talk pages project page on your watchlist. That's probably the easiest way to stay connected to what actually happens over time. Whatamidoing (WMF) (talk) 00:16, 23 August 2019 (UTC)

thanks for responding. Unfortunately, i find the use of a watchlist to be too cumbersome. Ottawahitech (talk) 15:44, 24 March 2020 (UTC)

Why didn't WMF build off of Convenient Discussions?

@Trizek (WMF) Why was it decided that a new project should be created rather than adopting and building off of Convenient Discussions? Lectrician1 (talk) 05:54, 11 January 2023 (UTC)

@Lectrician1, Convenient Discussions was mentioned many times during the consultation: it is a great source of inspiration. The new project, DiscussionTools, was created to provide set of tools that match global expectations (some elements were not included in CD), that include with visual editing and that provide a complete integration to all Wikimedia experiences. I wasn't part of this project, so I may miss some details.

Some features built by the DiscussionTools' team have been integrated to CD. And people who prefer Convenient Discussions cans still use it. Trizek (WMF) (talk) 13:52, 11 January 2023 (UTC)