Wikipedia:Talk pages consultation 2019/Phase 1: Difference between revisions

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 14:37, 24 February 2019

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. This page has been added to the following lists:

When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

On 21 February 2019, the WMF informed various Wikimedia projects of the 2019 talk pages consultation.

The Talk pages consultation is a global consultation planned from February to June 2019, to bring Wikimedians and wiki-minded people together to define better tools for wiki communication. The consultation will seek input from as many different parts of the Wikimedia community as possible – on multiple projects, in multiple languages, and with multiple perspectives – to come up with a product direction for a set of communication features that a product team will be able to work on in the coming fiscal year.
— mw:Talk pages consultation 2019

An explicit objective of the consultation is to change communication on Wikimedia projects in some way, because the present wikitext communication system effectively forms a cultural barrier for new contributors, in spite of its flexibility and transparency. In enumerating various possible outcomes and solutions, the consultation page notes: "For this process to work, we need to be open to all kinds of directions."

In this stage of the consultation, the WMF suggests asking community members five questions. There are therefore five subsections for each of those questions (under § Suggested questions). It may also be appropriate for other issues to be considered on this page, in separate subsections (under § Other topics). Jc86035 (talk) 14:28, 23 February 2019 (UTC)[reply]

Bureaucratic stuff

To allow for different types of Wikimedians to share their thoughts, we want everyone to be able to talk about wiki discussion systems in their primary language in an environment where they feel comfortable.
— mw:Talk pages consultation 2019/Participant group sign-up

The English Wikipedia at large is currently signed up as one "participant group" at mw:Talk pages consultation 2019/Participant group sign-up. WikiProjects, off-wiki groups and the like are also encouraged by the WMF to conduct their own discussions.

At the end of the discussion, one or more users are to summarize (i.e. formally close) the discussion and post the summary to mw:Talk:Talk pages consultation 2019. Since the WMF prefers that at least one primary contact be available, if you are interested in closing the discussion and will be able to do so, please add your signature to the next subsection. It may be appropriate for only administrators (or only experienced users) to close the discussion. Jc86035 (talk) 14:28, 23 February 2019 (UTC)[reply]

Users interested in closing the discussion

―Matthew J. Long -Talk-^☖ 16:42, 23 February 2019 (UTC)[reply]

Suggested questions

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

Multi-branching conversations are a double-edged sword. Yes, it can be convenient to be able to branch off a new thread in close proximity to the triggering post, and to keep the new branch in one place. However, the conversation sprawls very rapidly afterwards, making it extremely difficult to keep up with all of the latest additions to all branches. There is a good reason why the linear structure of bulletin boards continues to persist online: there is a straightforward way for readers to bring themselves up-to-date on the overall conversation. They just need to start reading from the last post they previously read. This increases the chance that each post will be read (or at least considered by readers before they decide to skip a post), which can make the overall conversation more efficient. I suspect this is often a worthwhile tradeoff versus the ability of making it easier to only follow and respond to a specific branch. isaacl (talk) 17:07, 23 February 2019 (UTC)[reply]
To broadly address the question for context, since most WMF staff members are not regulars: The noticeboards and established community processes (village pumps, the Teahouse, WP:AN, WP:RSN, WP:AFD, the main page processes, and so on) are presumably indispensable, since they perform a vital role in centralizing discussion about related matters. The requests for comment process is quite useful for initiating other major discussions, particularly when combined with the feedback request service. However, these might only work for the English Wikipedia because of its size compared to other projects. Talk pages are also useful, although only if someone else is around to respond. Off-wiki channels, such as IRC and the Discord server (and Special:EmailUser, of course), are also useful for general discussion, and for matters considered unrelated to Wikipedia's goals (not everyone is a prose-generating automaton). However, they probably only represent a very small portion of English Wikipedia-related discussion. Jc86035 (talk) 17:13, 23 February 2019 (UTC)[reply]
I'd also like to bring up Enterprisey's reply-link user script. Even for experienced users, it can make it much easier to reply to a comment (especially in large, messy discussions – if the users in the preceding discussion have indented their posts correctly, that is). It's also customized for the major discussion boards on the English Wikipedia. I can't believe it took until 2017 for it to be invented. Jc86035 (talk) 17:17, 23 February 2019 (UTC)[reply]
Other user scripts, particularly Twinkle, are also very useful for starting discussions like deletion nominations (which would otherwise require a fair amount of manual bureaucratic checkbox-ticking). However, Twinkle is not enabled by default, so newcomers may end up wasting significant amounts of time doing all of these things manually, if they ever get past the walls of text surrounding most of the community processes. Jc86035 (talk) 17:44, 23 February 2019 (UTC)[reply]

Twinkle is prone to be abused, either causing trouble for undeserving beneficiaries of its mechanical invective or for the inexperienced or incautious editor who is called to account for it. I won't say you can't use it, but that kind of custom-made tool to make it easier for editors to chew on each other is not really what I would call a great benefit to the user experience. Vandalism on-wiki (as viewed by a random reader, I mean) is already at incredibly low levels, but loss of editors over "processes" is alarmingly high. Just look at the top contributors of all time and see how many are banned now! So I don't really want it to be incredibly easy to take that thing out for a spin, no. Wnt (talk) 14:37, 24 February 2019 (UTC)[reply]

A little bit of custom CSS to help track the indentation level would help quite a bit. Shipping a custom CSS like fr:Discussion Wikipédia:Accueil principal with MediaWiki is a quick and easy win. MER-C 12:18, 24 February 2019 (UTC)[reply]

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

Very new users are occasionally confused where to add text, i.e. at the bottom like when writing a paper rather than at the top like on Social Media. They rapidly accustom to the proper way of doing things, which should not change, but a set of "tips" advising them of things like this, displayed in some small out of the way space as they get accustomed to editing, might not do much harm. Wnt (talk) 16:52, 23 February 2019 (UTC)[reply]

New and even existing users can be perplexed by the fact that some users -- even admins -- sign their posts with names other than their own actual account name, piping it through a wiki redirect. That wouldn't be bad to change. Wnt (talk) 16:52, 23 February 2019 (UTC)[reply]

They find themselves intimidated, frustrated and overwhelmed when others make heavy references to [[WP:...this and that..]], instead of actually stating valid arguments on the topic of discussion. THE NEW ImmortalWizard(chat) 17:50, 23 February 2019 (UTC)[reply]

Even at the ever so user-friendly Teahouse we still jump on new users who repeatedly fail to/forget to/don't know how to sign their posts. So why is not signing a post still so easy to do? Even a simple 'yes/no' prompt to add a signature on hitting 'Publish changes' without already having added the four tildes could solve many problems of unsigned posts. I also agree with Wnt that users creating signatures not reflecting their true username can be quite confusing and does not aid communication. There's one example immediately above. Nick Moyes (talk) 21:16, 23 February 2019 (UTC)[reply]

Many newcomers seem to be able to add text somewhere, often in the wrong place or without a heading. They also don't follow any of our (inconsistent) indenting standards for replies. But just like forgetting to sign (which can even be done by bots), these formatting issues can be easily fixed by the more experienced Wikipedians participating in the discussion. When I discuss with newbies on my talk page, the problem seems much less that talk pages are difficult, but that they find it hard to tell me what page they are discussing (but I can usually figure it out from their contributions or deleted contributions) and can't understand our byzantine system of policies, guidelines and practices. I expect most newbies despair not of the difficulty of navigating wikitext, but of having their edits reverted and their articles deleted, and instead of an explanation we point them to WP:ALPHABETSOUP. The great advantage of our current approach to talk pages is that there is no need to learn two different systems for editing pages. The downside is that we use different conventions (especially about signing and indenting). —Kusma (t·c) 11:03, 24 February 2019 (UTC)[reply]

The mix of what Nick Moyes and Kusma describe is probably the most dissuasive experience for noobs (and being called something like noob "in the face" by not-so-friendly other users). For the friendliness it's probably irrelevant what form the page has, it's a behavioural issue not a programming one, and the very little syntax skills needed to just get along on talk pages (indentation by : and signing) are no more a barrier then any other new stuff. I think it probably helps newcomers, if the talk pages behave in the same manner as everything else in the Wikipedia, so you can test stuff there, even under supervision of oldies, that are meant for the front side. Grüße vom Sänger ♫ ^(talk) 11:14, 24 February 2019 (UTC)[reply]
Stripping out parts of the content on mobile just because they look like clutter is an ongoing disaster; please don't make it worse. (Primarily a mainspace problem - omg nav templates and articlespace maintenance templates and especially edit notices are there for a reason - but applies to talk pages too, e.g. Special:Permalink/884793900#Blanking and active block messages) —Cryptic 13:23, 24 February 2019 (UTC)[reply]
It's worth pointing out that Wikipedia is one of the greatest successes of the modern era. Wikipedia underwent literally exponential growth up until 2007. Exponential growth is inherently unsustainable, and the post 2007 decline back to stable numbers was obviously unrelated to Talk pages and unrelated to "wikitext editing being too hard", because those things did not change in 2007. Wikipedia was so successful in large part due to how dead-simple things are. A wiki is nothing but a bunch of identical pages, and a page is nothing but a basic text file with a name. Someone who knows exactly nothing can click Edit and start writing an article entirely in plaintext. Someone who finds Talk pages discovers nothing new - it's just another article page - it's just another dead-simple text file. So long as they can write a plaintext message somewhere on the page, we can successfully communicate with them. If someone has the motivation, if they have the mental and social competence to collaboratively write an encyclopedia as a hobby, there is no hurdle to start picking up the most basic elements of wikitext at their own pace. Any powerful system must have complexity in it somewhere - and a wiki hides all of that complexity within the wikitext parser. A new user can write a plaintext message on a Talk page, without knowing squat about signatures or indentation, and succeed in their journey. The real hurdle for new users is the overwhelming nature of Wikipedia itself, and dealing with other people. Most people have no interest in writing a public-service-encyclopedia as a hobby, and for those who do take an interest it can be difficult or impossible to embrace the fact that the community may re-write or outright delete their work at any time. And for those who can embrace that, the biggest challenge is simply managing to constructively deal with the constant onslaught of other people. The basic fact is that people inevitably disagree about anything and everything, and new users can be easily be overwhelmed trying to make progress through the social arena. There's a fire-hose of information to learn about how to write wikipedia, and it takes confidence and fortitude to deal with other editors when they are wrong. Alsee (talk) 13:27, 24 February 2019 (UTC)[reply]

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

Edit conflicts on busy talk pages. Andrew D. (talk) 20:12, 23 February 2019 (UTC)[reply]
Fails to reach proper consensus in polarizing issues and third party comments or closure doesn't help a lot. THE NEW ImmortalWizard(chat) 20:29, 23 February 2019 (UTC)[reply]
- For some issues the community is fairly split 50/50 and as such no bit of software will bring about a proper consensus... Doc James (talk · contribs · email) 08:48, 24 February 2019 (UTC)[reply]
ImmortalWizard, notwithstanding the invalidity of your point, I have no clue about how this's any relevant to the issue, at hand. ∯WBG^converse 09:04, 24 February 2019 (UTC)[reply]
Meh, no need to call ImmortalWizard out on this. The questions presented are vague enough that their answer is relevant. (Rephrasing, Q: "What's wrong with discussions on Wikipedia?" A: "Nobody ever agrees about anything.") It's not immediately obvious except to cynics like us that this is really just another attempt to force Flow or something substantially Flowlike onto us. —Cryptic 09:53, 24 February 2019 (UTC)[reply]
As Crpytic pointed out, I just roughly answered the vague question. It is up to the "experts" (who are asking for suggestions here) to decide how it could be done in practice. I don't believe it's a non-goal. THE NEW ImmortalWizard(chat) 10:49, 24 February 2019 (UTC)[reply]
Pages with lots of subsections where it's very effort intensive to respond to each subsection in turn (eg. the XfD set). --Tom (LT) (talk) 21:57, 23 February 2019 (UTC)[reply]
Edit conflicts and finding the right spot to reply and the correct indent level in long discussions on the Pump or similar (but newbies are unlikely to participate in those anyway...) —Kusma (t·c) 11:04, 24 February 2019 (UTC)[reply]
Proper signing in the first few days, edit conflicts and indentation issues all the time. And of course the most dissuasive problem with talk pages: the sometimes quite deterrent lack of AGF and the abusive behaviour of MoaM. Grüße vom Sänger ♫ ^(talk) 11:19, 24 February 2019 (UTC)[reply]
As noted elsewhere, threading is important and difficult. The use of :*# seems simple at first, but nested discussions get complicated quick, especially as users typically just reply to the most intended comment rather than the one they're actually referencing. Mixed use has accessibility problems I believe, but it's not always clear what to use. I have for years used some custom CSS (borrowed from MuZemike) that highlights different indentation levels which is very helpful, and makes it clear how often we editors mismatch things. I think this is one of the things flow was supposed to but failed to help. ~ Amory (u • t • c) 11:22, 24 February 2019 (UTC)[reply]
The current talk page system is extremely inaccessible to mobile users, particularly Wikipedia editors who use the mobile site and apps on a smartphone. Having to go into into an editing mode and then manually position your comment into the discussion with wikitext is an unbearable experience in active talk page discussions, such as the ones found in noticeboards and for controversial articles. VisualEditor on mobile improves this, but the user experience still pales in comparison to threaded discussion interfaces for other websites (most notably Reddit), and the VisualEditor is also not supported in the Wikipedia apps. An officially supported and automatically enabled version of User:Enterprisey/reply-link for both mobile and desktop users would help address this, as it would make it much easier to directly reply to another editor's comment. — Newslinger talk 14:05, 24 February 2019 (UTC)[reply]
I would not recommend Reddit as an alternative to anything. The first knee-jerk reaction to a post, whether clever or (more often) silly, is put at the top of the discussion because it gets all the upvotes and replies. All the best comments on any given thread are often at the very bottom, where you would have to expand everything a dozen times to get to them, because they are something that somebody didn't want to have said. A truly good post can get fifty or even a hundred downvotes, even though nobody can read it without deliberate hassle from the software, because they have some secret cheering section running against them even after they disappear. Reddit is like the Refdesk, but only one or two people can answer and the rest are wasting their time. Oh, and this is a fossil reaction from years back before the censoring got bad, and by now I'm sure it's much worse. Wnt (talk) 14:32, 24 February 2019 (UTC)[reply]

What do you wish you could do on talk pages, but can't due to the technical limitations?

Sometimes I wish I could just watch a section or singe discussion on an article's talk page. I may want to follow a specific conversation, but not have all changes to an article and its talk page appearing in my watchlist. ---Another Believer _(Talk) 17:12, 23 February 2019 (UTC)[reply]
I, too, would find it very useful to be able to watchlist selected sections instead of the entire talk page. --Tryptofish (talk) 22:34, 23 February 2019 (UTC)[reply]
As well as being able to watchlist selected sections, I'd like to be able to choose whether only to be notified whenever a completely new topic is added to certain pages I watch, and not every time any new post is added. And for the help forum page I assist on, I'd welcome an on-wiki notification as soon as a new question is posted there. Nick Moyes (talk) 22:43, 23 February 2019 (UTC)[reply]
As well as the above, I'd like to watch only the talk page of an article (or even just the article). – BrandonXLF (t@lk) 00:02, 24 February 2019 (UTC)[reply]
It is possible to do this with a bit of CSS hackery, but that's hardly a solution that's good for many pages, new users, or users uncomfortable with CSS. --AntiCompositeNumber (talk) 01:19, 24 February 2019 (UTC)[reply]

This would be most welcome, I was surprised it wasn't wasn't more requested in the wishlist survey. ~ Amory (u • t • c) 11:38, 24 February 2019 (UTC)[reply]
Sections watchlisting has been requested by the community for years. However it's important to note that this is a GENERIC PAGE FEATURE, with no connection to Talk pages per se. The feature would (probably) be most often used on talk pages, however the ability to watchlist article-sections or sections other non-talk pages is equally an element of the feature specification. Alsee (talk) 05:43, 24 February 2019 (UTC)[reply]
Agree with suggestions above. Would also like to be able to use Visual Editor on talk pages. Having new editors be able to use the same editing tools in both spaces would make teaching them easier. Doc James (talk · contribs · email) 06:07, 24 February 2019 (UTC)[reply]
On talk pages with Flow that I run across on WMF projects outside of enwiki (see mw:Talk:Notifications for an example), I wish I could easily find all the discussions on a page, but you can't even search the page as it doesn't show all the content when going to a page - requiring infinite scrolling before you can search the page. So I suppose I wish that all content would load and not require infinite scrolling on flow pages. — xaosflux ^Talk 06:20, 24 February 2019 (UTC)[reply]
I'd like to watch just single sections and all new ones, and get those in distinct lines in my watch-list. I don't have much problems any more with edit conflicts and indentation, I'm a bit too long here and know how to deal with them. As I think every wikipage has to have the same look-and-feel, I think the VE should be deployed on all wikipages, so that there is no artificial rift between article and talk page. I probably won't use it, as I'm accustomed to editing in wikitext, but any wikieditor should be able to be used on any wikipage, or it's just not worth using it at all I know that there are some special purpose editors for some nerds, but those are not what this here is about. Grüße vom Sänger ♫ ^(talk) 11:25, 24 February 2019 (UTC)[reply]
Not quite a technical thing, but it annoys me that on enwiki I need to actually the talk page to see if there has been any discussion about the article, ever. Almost all articles have a "talk page" that is filled with metadata (quality ratings, wikiproject templates, old afd links) instead of discussion. In a complete redesign of talk pages (something I generally oppose), I would suggest to find a new home for the metadata. —Kusma (t·c) 14:33, 24 February 2019 (UTC)[reply]

What are the important aspects of a "wiki discussion"?

This is an odd question. (All of the suggested questions are repeated verbatim.) Civility. Assumption of good faith. Consensus. I'm not sure how this is supposed to inform the consultation. I don't think Flow or LiquidThreads would have measurably affected these things. The content of the discussions isn't necessarily significantly affected by the interface and software, although at this stage I would probably oppose functions like straw polls (if those are being considered) unless implemented properly so as to limit their use to designated voting areas like RfA subpages. Jc86035 (talk) 17:29, 23 February 2019 (UTC)[reply]
An easy way to archive entries. --Tom (LT) (talk) 21:58, 23 February 2019 (UTC)[reply]
Yah better archiving would be nice. We could do this fairly simple by bot right now though. Doc James (talk · contribs · email) 06:08, 24 February 2019 (UTC)[reply]
I will simply post some of the onslaught of community comments that the WMF previously ignored in the Flow_Talk archives shortly after Flow was first announced here:
- "let's get this absolutely straight. Unless Flow will be able to render every single aspect identically to every valid editor of the article name space, it must not and will not be rolled out! Talk pages are not independent social websites, but they have only one purpose: to discuss articles. For this we need to be able to copy every kind of content, format and structure between the article name space and the talk pages. Your job is to support us in writing Wikipedia, your job is not to build a flashy social website. The identical rendering of every possible content must be your paramount design goal. Everything else takes second place."
- "We are are trying to get you to understand that full support of wikitext is not optional"
  IMPORTANT NOTE to WMF staff who do not understand what the community means by "wikitext": we mean the PHP Parser. VisualEditor/Parsoid is not an acceptable substitute for genuine wikitext. Alsee (talk) 06:11, 24 February 2019 (UTC)[reply]
  The "PHP parser" will go away eventually. That's not really negotiable on our part. What can/should be done is identifying any of the last of the deltas either to be fixed or not (the "or not": all parsers will have their quirks, some of which may not be worked around. PHP parser is quirky in a number of ways, and "being used to those quirks" isn't a good enough reason to keep it). --Izno (talk) 06:24, 24 February 2019 (UTC)[reply]
  @Izno: Please explain what will be "going away" in more detail. If you are talking about the old 'padleft' being cautiously replaced by something elegant and versatile, that's one thing. If you are talking about breaking transclusion or forcing every template to be rewritten from scratch, or worse, that's quite something else. Wnt (talk) 06:40, 24 February 2019 (UTC)[reply]
  There is not now a significant difference between the two parsers, so neither of the above items will need change. Parsoid and the current PHP parser use two different models of figuring out what the source wikitext means, which is why there are some differences in what we see when we have a final look at a page between someone using VisualEditor/2017 WTE and someone using 2010/2006 editor and their associated previews/renderings. Right now, of course, when you see a page, it uses the latter and not the former.
  
  (One of the problems with Flow is that it basically used neither Parsoid nor PHP parser on release.)
  
  Anyway, mediawikiwiki:Parsing#Long-term directions as of November 2016 has more to speak on this topic. --Izno (talk) 06:53, 24 February 2019 (UTC)[reply]
  Izno I'm aware of the WMF's 2016 plan to kill off the current wikitext engine, and I'm also aware of the WMF's 2013 plan to deprecate wikitext as the primary input method altogether. And both of those imaginary plans are utterly irrelevant here. The article-rendering-engine is the one and only valid and acceptable engine. It's fine if the WMF wants to work in a way that calls the PHP engine because it's the article engine, without caring that the article rendering engine happens to be the PHP Parser. However if the WMF tries to shove a new discussion system down our throats that doesn't use the article rendering engine, it's going to blow up in their face. Again. I suggest you re-read the comments I gathered above from the Flow history, and carefully consider how much tolerance the community will have for any discussion system with less than perfect fidelity to article rendering. The worst case outcome here would be if the WMF builds yet another discussion system that it can't deploy. Alsee (talk) 07:54, 24 February 2019 (UTC)[reply]
I think this is a good question to lay out some of our uses of pages for talking, just in case the WMF doesn't know what those are:
- Discussion, clearly (within the bounds of WP:NOTFORUM)
- Straw polls, to generate WP:Consensus
  - Consensus for deletion of content via AFD, etc.
  - Straw polls more-or-less need less-rather-than-more whitespace. Or an entirely different tool. (See also WP:NOT#DEMOCRACY, so, it's not a vote.)
- Drafting article text (so, we need wikitext on talk pages, or we need a tool to make it easier to draft content--maybe Draftspace is good enough for en.WP)
- Page metadata, including WikiProject banners, topic-sanction alerts, article milestones.
- WP:Dispute resolution, including AN/ANI/Arbcom/DRN/EWN, and the list goes on.
There might be others that I'm missing. --Izno (talk) 06:18, 24 February 2019 (UTC)[reply]
Talk pages handle all edit requests, from everything to article text (referenced above) to new markup for a mediawiki message, so yes being able to code the request in the same format somehow is critical. — xaosflux ^Talk 06:31, 24 February 2019 (UTC)[reply]
Ah, yes, edit requests. Those more-or-less fall in the 'drafting article text' bucket. --Izno (talk) 06:37, 24 February 2019 (UTC)[reply]

It is important to me that 1: you don't censor discussions. Assuming you do anyway, it is important to me 2: that you don't conceal the history. Assuming you do anyway, it is important to me 3: that you don't conceal the fact that the material was censored at all. Assuming you do anyway, it is important to me 4: that you don't copy the worst dishonest practices of social media, such as 'shadow bans' and mechanical downvotes. But I have in mind that nearly every computer science major in the world has the same dream, namely to work for a social media company doing dishonest things for dishonest money, and the rest are as dead as Aaron Swarz. Past that point, there's really nothing for people to do but hope there is a decent mirror of the old Wikipedia somewhere. Wnt (talk) 06:45, 24 February 2019 (UTC)[reply]
For article talk pages, help desks, or WikiProject talk pages, having the exact same rendering as on the articles themselves is crucial so article text and formatting errors can be discussed properly without unnecessary technical barriers. —Kusma (t·c) 11:08, 24 February 2019 (UTC)[reply]
- ^^^This. Bug-for-bug compatibility with final article rendering is an absolute requirement, just like it is with "Show Preview". (Insert your own VE snark here.) —Cryptic 12:58, 24 February 2019 (UTC)[reply]
I think this section by Alsee over at MW sums up the utterly wrong approach by most of the developers with obviously no encyclopedial experience, that created LQ and FLOW. WP:NOTFORUM, full stop. The talk pages have to be made in a way, that enhances the quality of the articles, it's the only reason for them to exist. Grüße vom Sänger ♫ ^(talk) 12:40, 24 February 2019 (UTC)[reply]

Other discussions

Before adding a new subsection, please check that the purpose of the section is not to address one of the non-goals. To create a new subsection, add a level 3 header, with your comments and signature below it, at the bottom of the page. Due to the open-ended nature of the consultation, subsections may be structured in any format, including (but not limited to) open discussion, support/oppose !vote, and multiple-choice !vote.

Talk pages etiquette

I am not suggesting to deploy any set of rules or format that should be followed. However, I think all editors should be made familiar with discussion procedures (especially in the contentious ones such as AFDs, ANI etc.), to ensure smooth and effective conversations withOUT abusing. Newcomers should be guided through properly and taught the importance of talk page discussions and the techniques they should be using. I know there are several policies and guidelines already present to minimize heated disputes, but I think a much clearer, focused and general amendment would be a good starting rule of thumb, which would be required to practice in order to show civility.

Wikipedia is for everyone and I understand that not everyone gets to learn properly and sometimes get the right opportunities. Inexperienced users and IPs showed be given chances and should not be expected with prior knowledge. As a disclaimer, I myself is not that experience, hence I leave this discussion open as of now. If someone has some bright ideas to drop by, go for it. We need to think long-term here.

Thanks, THE NEW ImmortalWizard(chat) 17:34, 23 February 2019 (UTC)[reply]

Why is the status quo not an option

Surely you all remember the disaster of Flow? I believe it was one of the times where an en.wiki admin threatened to block a WMF staffer. If the community actually prefers things to stay generally the same, that should be heard and should be a possible outcome. Generally the biggest issue people had with talk pages was replying, and that issue is now handled via a script if people want it. Just make reply-link a gadget that can be enabled via preferences. Problem solved and saves you likely millions of dollars in stafftime. TonyBallioni (talk) 05:42, 24 February 2019 (UTC)[reply]

The status quo is a non-starter (IMO) per WP:Accessibility. That said, it's not not an option. The discussion above doesn't speak to solutions--a fact I noted elsewhere--just problems that people have with the status quo. --Izno (talk) 06:09, 24 February 2019 (UTC)[reply]

Izno, nope; they clearly mention that status quo ain't an acceptable option for them. ∯WBG^converse 06:21, 24 February 2019 (UTC)[reply]

Because there are things wrong... as noted above... (accessibility of talk pages is garbage, newbies don't figure them out, and the list goes on). As I said, don't fixate on solutions (or past solutions), comment on the issues that you have with talk pages. (Or do as DocJ did and comment on the good things about talk pages.) --Izno (talk) 06:27, 24 February 2019 (UTC)[reply]

Even if the talk pages were different, do we have evidence that that will help newbies figure it out? I often feel that some do not even realize that talk pages exist and simple keep repeatedly adding the same text over and over. Text that they have obviously written in Microsoft word and are simple copy and pasting and are only here when making that one copy and paste. Unfortunately you see this in a number of school efforts. This would be addressed by further coaching for their instructors rather than changing WP. Or by having scripts that help guide students when they hit "publish such as proposed here.Doc James (talk · contribs · email) 06:34, 24 February 2019 (UTC)[reply]

Well, of course there are things wrong, but there are things that would be wrong with any system. The question is whether or not the benefits of fixing them and moving a new system is worth the disruption of the change. This is the problem every organization goes through when discussing technology changes, and why you still have some major retailers operating on computer systems that use 1980s technology. Right now, the current system works for its intended purposes and generally works well. There are maybe minor fixes here and there that can be made, but in general the system is not in need of a drastic overhaul that would justify the disruption such an overhaul would cause. TonyBallioni (talk) 06:38, 24 February 2019 (UTC)[reply]

but there are things that would be wrong with any system: Right. But part of the point of this discussion is whether there are small things in the context of the current system that would get us better, like Enterprisey's reply script. Maybe that should be a global gadget? (And etc.) Flow is not necessarily the answer that the WMF is looking for this time. (I suspect something Flow-like will be an answer, given, again, the need for accessibility.) --Izno (talk) 06:56, 24 February 2019 (UTC)[reply]

Well they listed it as a “non-goal”, which is basically them trying to frame the discussion not to talk about what the likely outcome is anyway because they know how bad Flow ended up and that there would be resistence to it. By the status quo I mean nothing much gets changed and the basic structure stays the same. I’m fully aware that even if nothing real changes the WMF needs to point to something to say that they did something, so I’m sure they can find something minor to twiddle with on that count, but I actually like the existing wikitext format and think it makes a lot of sense for our project. TonyBallioni (talk) 06:24, 24 February 2019 (UTC)[reply]

The status quo is not an acceptable option because it imposes a barrier on editors who use a smartphone to access Wikipedia. Try using the mobile site or apps on a smartphone, and you will understand that it is difficult to participate with the current talk page system as a mobile user. While the vast majority of Wikipedia edits are currently done on a desktop or laptop computer, most web traffic is generated by smartphones (see Usage share of web browsers § Crossover to smartphones having majority share). The inaccessibility of the current talk page system contributes to systemic bias in Wikipedia, as it makes it harder for Internet users with no access to a desktop or laptop computer to contribute to Wikipedia. CNBC reported: "WARC estimates that around 2 billion people currently access the internet via only their smartphone, which equates to 51 percent of the global base of 3.9 [billion] mobile users" and "Almost three quarters (72.6 percent) of internet users will access the web solely via their smartphones by 2025, equivalent to nearly 3.7 billion people". — Newslinger talk 13:11, 24 February 2019 (UTC)[reply]
- Agree we need to make talk pages easier to edit via mobile. Should not be that difficult. Doc James (talk · contribs · email) 14:02, 24 February 2019 (UTC)[reply]
- Mobile view and the mobile app seem to be designed only for readers, with little concern for editors. If we want to turn readers into editors, this is where developers should try fix things, both for talk pages and non-talk pages. —Kusma (t·c) 14:28, 24 February 2019 (UTC)[reply]

Features that people would like to see retained in discussion pages

In my opinion it is important to look at what works well with our current talk pages. A few things:

The order of the posts generally stays more or less the same with newer threads lower than old ones. I dislike endless scrolling and when new comments adjust the ordering of the section. I find Facebook incredibly hard to use.
There is a history page such that one can easily look at all changes to a talk page since one looked at it last.
Content can be copied and pasted from the main article to the talk page and the formating remains the same. Thus one can remove large blocks of poorly done text to the talk for further work / discussion. People can than collaboratively edit the text added by a single user.
We have two main ways to edit (old way and visual editor), before introducing a third we need to be very careful as it will make thing more complicated and thus raise the barrier for entry for new users.

Doc James (talk · contribs · email) 06:16, 24 February 2019 (UTC)[reply]

Hear, hear! Wnt (talk) 06:47, 24 February 2019 (UTC)[reply]
- Tracked in Phabricator
  Task T31711
  Moving text around and fixing it up is one of the features of our discussions that was already flagged as important 8 years ago in the discussions about our discussion systems: Keep talk refactoring possible. (It's still we have to repeat ourselves every couple years.) Nemo 08:29, 24 February 2019 (UTC)[reply]

The most important feature of the current discussion system is that it is extremely flexible, and the loss of that flexibility would have adverse effects on just about every type of discussion I can think of. Risker (talk) 08:23, 24 February 2019 (UTC)[reply]
m:Right to fork. It's not an option to start using any system unless the discussions keep being in the XML dumps, exportable and importable with ease elsewhere (and proven to be so). Nemo 08:31, 24 February 2019 (UTC)[reply]

Reading here it says "Building features on top of wikitext talk pages, to make them easier and more efficient. Using Visual Editor on talk pages, with extra features."

Both those are excellent ideas. And ones I strongly support. We all know we can do better than our current fairly decent system. Doc James (talk · contribs · email) 09:17, 24 February 2019 (UTC)[reply]

The ability to create diffs - not just of someone adding a comment but of changes to the entire page. MER-C 11:18, 24 February 2019 (UTC)[reply]

(A) Revive work on Flow, (B) try to design a new Talk replacement from scratch, or (C) consider improvements to existing pages?

C. Flow's design is irredeemably broken, and I have yet to see any suggestion for a new system that would credibly be a positive cost-benefit tradeoff vs the simplicity flexibility power and compatibility of existing pages. We should consider any proposals for improving existing pages on their individual merits. Alsee (talk) 07:16, 24 February 2019 (UTC)[reply]
C Agree gradual improvement to the existing talk page structure is much more likely to result in "success" than the other two options. Lots of improvements to talk still needed. And we can make the current system more accessible. Doc James (talk · contribs · email) 08:45, 24 February 2019 (UTC)[reply]
C - just git rm Flow now, just like you should have done five years ago in response to the community feedback. Flow has demonstrated the WMF's incompetence and ignorance regarding talk pages - they simply cannot be trusted with any wholesale redesign. MER-C 11:17, 24 February 2019 (UTC)[reply]
C is the only choice. The problems that Wikipedia has are mostly social and cultural problems, which are traditionally extremely difficult to solve by technical changes. I very much hope the WMF won't waste more money, time, and (most importantly) volunteer goodwill by insisting on developing another non-starter. Also, what is the fundamental problem with (D) continue to augment talk pages by other means of communication (we traditionally have used mailing lists and IRC, and could just as well use additional forums if people need other means of engagement)? —Kusma (t·c) 11:19, 24 February 2019 (UTC)[reply]
C, it's the only valid option. No syntax will ever solve the behavioural problems. And it's of utterly importance, that all wikipages behave in an more-or-less identical manner, and can be edited the same way, so that the learning curve of editing is the same for talk pages as well as for the real stuff. Grüße vom Sänger ♫ ^(talk) 11:32, 24 February 2019 (UTC)[reply]
C. It is never a good idea to use WP:TNT on something that isn't hopelessly irreparable. The current talk system should be made more accessible (especially for editors who use the mobile site or apps), but it's clearly working for many of its current users. — Newslinger talk 12:53, 24 February 2019 (UTC)[reply]

"Features" that people really don't want on discussion pages

Infinite scrolling.
Inflexibility. "Discussion" pages are used for an enormous variety of discussion types, many of which are ad hoc and fairly undefined. Any redesign must be equally flexible.
Any discussion page that restricts the use of specialized text software (e.g., math notation) as well as wikitext is a complete non-starter, as it defeats the purpose of the page.

Seems to me we had this conversation a few years ago, and instead of paying attention to what editors said they wanted or needed, we got Flow. Don't do that again, please. Risker (talk) 08:03, 24 February 2019 (UTC)[reply]

Adding:

No upvote/downvote functions. They're antithetical to the "equity" that is one of the objectives.
Any system where it is not possible to provide a direct and permanent link to a specific revision of the discussion page (i.e., every single element of the page is exactly as it was at the time of that revision). Ability to accurately and easily reconstruct the progress of complex discussions is required on a regular basis.
Mandatory javascript.

I'm sure I will think of more. Risker (talk)

And I did:

Having different kinds of software for different kinds of discussions increases complexity and is antithetical to the equity this project seems to feel is a major objective; it creates ghettos of discussions, with only the most "advanced" users being able to participate effectively across multiple types of discussion platforms. I cannot emphasize this enough.
Software should never be used as a tool of social control. That means no shadow banning, no ability to "hide" the posts of another user, and so on. Frankly, I don't trust the WMF to understand enough about the culture of any of the projects well enough to develop social behaviour modification software - and I say that as someone who generally gets along pretty well with most WMF staff. Risker (talk) 08:27, 24 February 2019 (UTC)[reply]

Three more:

Pointless or worse than useless UI changes - including but not limited to:
- Excessive whitespace - anything that reduces the information density of current talk pages is unacceptable.
- Anything that looks remotely like a discussion forum or the recent idiotic Reddit redesign.
Avatars.
CSS and JavaScript bloat. MER-C 11:03, 24 February 2019 (UTC)[reply]

Those that made Flow terrible (for example, infinite scrolling and lack of proper history). —Kusma (t·c) 11:21, 24 February 2019 (UTC)[reply]

@@ Line 29: / Line 29: @@
 * I'd also like to bring up {{u|Enterprisey}}'s [[User:Enterprisey/reply-link|reply-link]] user script. Even for experienced users, it can make it much easier to reply to a comment (especially in large, messy discussions – if the users in the preceding discussion have indented their posts correctly, that is). It's also customized for the major discussion boards on the English Wikipedia. I can't believe it took until 2017 for it to be invented. [[User:Jc86035|Jc86035]] ([[User talk:Jc86035|talk]]) 17:17, 23 February 2019 (UTC)
 * Other user scripts, particularly Twinkle, are also very useful for starting discussions like deletion nominations (which would otherwise require a fair amount of manual bureaucratic checkbox-ticking). However, Twinkle is not enabled by default, so newcomers may end up wasting significant amounts of time doing all of these things manually, if they ever get past the walls of text surrounding most of the community processes. [[User:Jc86035|Jc86035]] ([[User talk:Jc86035|talk]]) 17:44, 23 February 2019 (UTC)
-:Twinkle is prone to be abused, either causing trouble for undeserving beneficiaries of its mechanical invective or for the inexperienced or incautious editor who is called to account for it.  I won't say you ''can't'' use it, but that kind of custom-made tool to make it easier for editors to chew on each other is not really what I would call a great benefit to the user experience.  Vandalism on-wiki (as viewed by a random ''reader'', I mean) is already at incredibly low levels, but loss of editors over "processes" is alarmingly high.  Just look at the top contributors of all time and see how many are banned now!  So I don't really want it to be incredibly ''easy'' to take that thing out for a spin, no. [[User:Wnt|Wnt]] ([[User talk:Wnt|talk]]) 14:37, 24 February 2019 (UTC)
+:: Twinkle is prone to be abused, either causing trouble for undeserving beneficiaries of its mechanical invective or for the inexperienced or incautious editor who is called to account for it.  I won't say you ''can't'' use it, but that kind of custom-made tool to make it easier for editors to chew on each other is not really what I would call a great benefit to the user experience.  Vandalism on-wiki (as viewed by a random ''reader'', I mean) is already at incredibly low levels, but loss of editors over "processes" is alarmingly high.  Just look at the top contributors of all time and see how many are banned now!  So I don't really want it to be incredibly ''easy'' to take that thing out for a spin, no. [[User:Wnt|Wnt]] ([[User talk:Wnt|talk]]) 14:37, 24 February 2019 (UTC)
 * A little bit of custom CSS to help track the indentation level would help quite a bit. Shipping a custom CSS like [[:fr:Discussion Wikipédia:Accueil principal]] with MediaWiki is a quick and easy win. [[User:MER-C|MER-C]] 12:18, 24 February 2019 (UTC)