Article snapshot taken from Wikipedia with creative commons attribution-sharealike license.
Give it a read and then ask your questions in the chat.
We can research this topic together.
*I generally agree with Risker on all but one point. There is an ability to hide the display of posts in Wikitext, for example {{t|cot}} and {{t|cob}}. If Flow's "hide" acted like that, there wouldn't have been as much objection. I wouldn't object if the Wikitext display was also suppressed until a "show" button in the editing box was pressed. — ] ] 04:54, 25 February 2019 (UTC)
*I generally agree with Risker on all but one point. There is an ability to hide the display of posts in Wikitext, for example {{t|cot}} and {{t|cob}}. If Flow's "hide" acted like that, there wouldn't have been as much objection. I wouldn't object if the Wikitext display was also suppressed until a "show" button in the editing box was pressed. — ] ] 04:54, 25 February 2019 (UTC)
**There are ways to "hide" posts of Wikitext using templates such as you've pointed out, and I wasn't referring specifically to that; I wasn't referring to revision-deletion or suppression, either. I was more referring to the practices of some social media that make certain posts or users undiscoverable via search, or that allow readers or others to "ignore" the posts of certain selected posters. ] (]) 14:11, 25 February 2019 (UTC)
**There are ways to "hide" posts of Wikitext using templates such as you've pointed out, and I wasn't referring specifically to that; I wasn't referring to revision-deletion or suppression, either. I was more referring to the practices of some social media that make certain posts or users undiscoverable via search, or that allow readers or others to "ignore" the posts of certain selected posters. ] (]) 14:11, 25 February 2019 (UTC)
* Someone has asked for a system that will "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)." This has never been possible in any way in any version of Mediawiki. Adding that functionality alone to Mediawiki would be a sizable undertaking. This whole project is doomed from the start because you can't build a discussion system by committee. The users don't know what's needed to make a discussion system work. They're users, not software engineers, UI designers nor community managers. Users should be able to call out when something's broken, but as they're already so steeped in the existing, broken system, somehow they think its only problem is lack of accessibility. It's a hack built on what was easy to do when the software was developed. There's no way any these over-the-top demands of the users will be met in version 1.0 of a replacement. No one will agree on any of the details. The whole thing is it's doomed to fail. What are they going to do next? Put out some grants for some college grads to develop it, scrap it when no one likes it and then a year later start this process again? What is the point of this process? At best Wikimedia are just going to use it as an excuse to do what they were planning to do anyway. But anyone who makes you choose your "formal or informal name to identify your participant group" just to respond to their banner ad survey isn't exactly going to design the next Skype. ——] 02:33, 26 February 2019 (UTC)
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.
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.
The English Misplaced Pages 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)
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)
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 Misplaced Pages 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 Misplaced Pages's goals (not everyone is a prose-generating automaton). However, they probably only represent a very small portion of English Misplaced Pages-related discussion. Jc86035 (talk) 17:13, 23 February 2019 (UTC)
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 Misplaced Pages. I can't believe it took until 2017 for it to be invented. 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. 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. Wnt (talk) 14:37, 24 February 2019 (UTC)
@Wnt: I wrote that mainly based on my experience of manually nominating templates to TfD before I enabled Twinkle. My experience here is probably not shared by a lot of other editors, particularly since a large amount of my edits are to templates and modules. (Come to think of it, the main reason I didn't initially enable Twinkle for those things was probably because the one paragraph about Twinkle is about ten thousand words down the page at WP:TFD, and all of the manual instructions were placed before it so I didn't actually get to that section.) Jc86035 (talk) 16:31, 24 February 2019 (UTC)
Ugggh. That is pretty horrendous. But much of the confusion there is actually due to bad content design rather than a lack of tools. We could have a small section with a neat table of "TFD instructions" sets, with links for deleting and merging various specific kinds of things as presently described in the wall of text; you'd click one link for one category and see only the instructions that apply to you, with little inelegant duplication of content necessary via the magic of transclusion. I mean, I feel like I could write a better version of those instructions myself and propose it today if I didn't have something else I need to do. But WMF could also perhaps devise some clever 'multitalk mode' where prefilled messages come up in multiple edit windows. As each would be a new section there should be no possibility of meaningful edit conflict, so one publish each should do. Imagine if each blank could be cited as a "variable" in another, sort of like with a LibreOffice Calc worksheet! There actually is a lot of room for useful innovation -- the moment people start talking about writing new, optional tools rather than breaking old ones. Wnt (talk) 18:56, 24 February 2019 (UTC)
After some discussion with @Isaacl: on my talk, I found out what the big problem with the indents is: nobody knows how to use them because nobody knows about the help file. Seriously, we have a great explanation at Help:List. Pity is, I've been around a decade and never noticed it. I'm talking indents and bullet points, not a list, right? Look up WP:indent and it gets you an essay, which also points at Help:Talk pages, which, alright, does link to Help:List if you count the thousand links in all the navboxes at the bottom, but otherwise solely offers the guidance that "Some pages (deletion discussions, for example) use asterisks (*) rather than colons for indentation. Generally colons and asterisks should not be mixed; if you see asterisks are being used in a page, use them as well." Which is basically what I knew about the topic. There is your bug -- not in the software, in the documentation! Wnt (talk) 13:20, 25 February 2019 (UTC)
I agree the primary source of confusion is that editors think of the colons and asterisks as indent levels/tab stops. However I think the number of additional people that can be reached by improved documentation is limited. I've seen numerous discussions where someone will explain how they work and why it's desirable not to alter the order of the characters, and it'll just be followed by someone saying something like, "I use : when my comment follows the preceding comment, and * when I'm making a new point, and this is common practice." Since there's no upside in one person disagreeing with them (and not much more in several people disagreeing), it gets let go. As has been suggested by others in other sections, if the mechanics of specifying threaded responses could be handled by the software, rather than relying on all editors to follow a convention which requires copying just the right string of punctuation and putting it in the right place, it would simplify matters. isaacl (talk) 15:50, 25 February 2019 (UTC)
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)
"They rapidly accustom to the proper way of doing things" - I'm putting a big here. Do we have data on new user experiences of talk pages? I'm sceptical that new users 'rapidly accustom' to this largely archaic form of online communication. Sam Walton (talk) 09:04, 25 February 2019 (UTC)
We all have some data about our experiences with talk pages when we joined the project; for my part, I found it logical to place new posts on the bottom and got along well. Also, I don't think the wikitext is really much of a cultural barrier on talk pages, as all you really need to know is to add four tildes at end. I'm not saying that wikitext as a whole is easy, just that posting on a talk page is pretty straightforward, especially with the 'New Section' link that adds the message at the bottom. L293D (☎ • ✎) 13:16, 25 February 2019 (UTC)
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)
They find themselves intimidated, frustrated and overwhelmed when others make heavy references to ], instead of actually stating valid arguments on the topic of discussion. THE NEWImmortalWizard(chat)17:50, 23 February 2019 (UTC)
Excellent point. At time discussion are dominated by people who seem to have memorised every WP:whatever by heart. Nigej (talk) 12:39, 25 February 2019 (UTC)
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)
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)
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 Misplaced Pages, so you can test stuff there, even under supervision of oldies, that are meant for the front side. Grüße vom Sänger ♫11:14, 24 February 2019 (UTC)
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) —Cryptic13:23, 24 February 2019 (UTC)
It's worth pointing out that Misplaced Pages is one of the greatest successes of the modern era. Misplaced Pages 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. Misplaced Pages 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 Misplaced Pages 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)
@Alsee: I largely agree with this, but it's probably worth taking into account that some people can be absolutely abysmal at handling technical things regardless of their other faculties. If they can't get the hang of signatures, it does still form a cultural barrier for them and they're probably more likely to be dissuaded from editing, although I have no idea whether this would be more significant than Misplaced Pages being an inherently unusual hobby to begin with.
It seems to me that the WMF has assumed that technical unfamiliarity is a significant factor in editor retention. From their point of view, it might well appear that experienced users don't really understand this because of some inherent survivorship bias. If they can't directly improve the social environment (for the usual practical reasons), they might as well try to improve the software that facets of the current environment might be a consequence of. Jc86035 (talk) 16:45, 24 February 2019 (UTC)
User retention rates for VisualEditor are roughly half of user retention rates for the Wikitext editorJc86035 I absolutely agree that some people can be completely lost at the faintest hint of anything technical, while being highly competent in other areas. One of the most impressive and highly accomplished people I know once asked me "which is more, one-third cup or two-thirds-cup?" However anyone using a computer to constructively contribute to an online encyclopedia must unavoidably pass some minimal computer-competence no matter what interface we provide. And the lowest possible threshold we can provide is the competence to write a simple plaintext message within a basic plaintext file. Anyone who struggles with that level of "technical" going to utterly drown if you try to shove them into a grossly complicated advanced-tech environment like VisualEditor with countless buttons menus icons dialogs and the implicit gestalt of how such a technical environment operates. The foundation's efforts there have been actively detrimental. Just look at the horrifying new-user-retention-rates data in the graph at right. Data like that should have resulted in VisualEditor being deactivated as an emergency action, if not for the WMF's cult-like obsession with the imaginary flood of new editors that it never brought in. Alsee (talk) 17:27, 24 February 2019 (UTC)
@Alsee: "Competence to write a simple plaintext message" is definitely the low bar for getting someone's message across, but someone who hasn't learned the norms is presumably much less likely to feel that they could competently contribute and would feel like an outsider, separate to their actual capability to constructively contribute and their capability to learn the norms. The issue remains that MediaWiki has a fairly idiosyncratic communication system with a relatively difficult learning curve, and presumably the Foundation has consistently found that lots of people, or at least the people they know IRL (think librarians, activists, members of other non-profits), find it baffling and overly complicated; so one would assume that it is detrimental to editor retention for cultural and technical reasons. Again, I don't know whether this is an actually significant factor.
The graph does look a little worrying. From the graph alone, though, it's impossible to tell whether the difference in retention is because of less technically inclined users deliberately choosing to use VisualEditor and also being more likely to leave (either leaving as they would have done anyway if VE weren't an option, or because of other factors like difficulty in using talk pages), because of users switching away from VE after they become more experienced (these users would be shown on the graph as not being retained by VE), because of VE discouraging new users from continuing to edit at a higher rate than the wikitext editor, and/or because of other reasons. They didn't send out emails asking "why did you stop editing" (at least not in this study), and without sufficient data we can't really assume that VE is being actively detrimental. If anything, some users have clearly found it useful (even if this hasn't actually helped to increase the number of very active editors).
I, personally, would generally try to assume good faith on the Foundation's part (I think they wouldn't intentionally try to sabotage their own software), although their track record does make this more difficult than it should be. Jc86035 (talk) 08:08, 25 February 2019 (UTC)
A list, trying to be brief. I'll probably come back and update this. First the good:
(1) Everyone loves the idea of the talk page. Let's keep them. :) (2) Pretty low barrier to participation. (3) Once you get the hang of it, it's pretty easy. (4) Page history is indispensable. (5) Easy to revise what you've written.
The not good:
(1) Overall formatting not as intuitive as they're used to. (2) Too easy to forget signature. (3) Indenting and bulletting interchangeable and messy. Hard to keep track of where things are sometimes. (4) Accessibility issues. (5) Other people's signatures don't always make it clear who you're talking to. Sometimes add to confusion. (6) Archives often hard to find. Harder to use. (7) Too often don't get a response (only mention because there may be an intervention relating to discoverability of active editors). (8) Banners at the top can be overwhelming as the first thing you see. (9) Edit conflicts. (10) Some pages are overly long. — Rhododendrites \\ 18:21, 24 February 2019 (UTC)
What do others struggle with in your community about talk pages?
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 Misplaced Pages?" 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. —Cryptic09:53, 24 February 2019 (UTC)
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 NEWImmortalWizard(chat)10:49, 24 February 2019 (UTC)
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)
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)
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 ♫11:19, 24 February 2019 (UTC)
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)
The current talk page system is extremely inaccessible to mobile users, particularly Misplaced Pages 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 Misplaced Pages 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. — Newslingertalk14:05, 24 February 2019 (UTC)
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)
Let me clarify: I am absolutely not suggesting that talk page comments should be reordered or scored in any way. The five main things that Misplaced Pages could adopt from Reddit's mobile interface are:
The ability to reply to a specific comment in-place on the talk page without having to scroll to the right place in an entire section on a separate editing page
The ability to edit or delete one's own comment in-place on the talk page without having to scroll to the right place in an entire section on a separate editing page
A clear visual indicator of where a comment begins and ends
A clear visual indicator of a comment's level of nesting
The ability to manually collapse and expand a comment and its replies for easier scrolling
The : indents aren't bad in and of themselves, but there are some aspects that could use reform. For example, if you incautiously respond to a * with a :, you end up with a comment at the same indentation, and I don't really know why. I don't necessarily remember if a third-level star is *:: or ::*, though I think *** gets you three stars in a row, I dunno, does anyone remember how that works or do we all just muddle through and guess? Also, two paragraphs starting with : look like paragraphs, but if you just put a return between them they get merged together. I'm not clear why that happens - odds are if I hit return I had a reason, no? But if I put two, then there's more space AFAIR. Now alternatives to this are limited -- if you want to use Javascript, then several good user scripts have been suggested, which just need a little more publicity. But I want to be free to edit in plain text. So I say keep the indents in the source ... but put the code on stars and non-indented paragraphs to the question. (two cases in point: . I have to admit I literally still don't understand those asterisks, when they make extra gaps, when they display on the page, and neither did the person before me in the previous example, and that's from the past half hour!) Wnt (talk) 15:03, 24 February 2019 (UTC)
OK, I was just informed on my talk that each level of symbol : * or # has to be maintained in each subsequent section or you're closing one thing and opening another. So *#:* should be followed by *#:*@ where @ = one of those three symbols of your choice. The things we learn... apparently my approach of "fiddle with it till it looks about right" wasn't actually socially responsible, as randomizing the order of the symbols breaks screen readers. One thing that's funny about that is that it means that the site *could* display the wikitext with div borders around it that would reveal a lot more structure to the conversation, catch being that some of us would leave some odd looking breaks in there, but still, just breaks at the same level of indent. Anyway, we obviously need now a) more visible help instructions about this, and b) some kind of "screen reader simulator" -- not a real screen reader where you have to wait 15 minutes to hear it and only the blind are used to parsing it, but one that shows the actual transcript of what it would say, with some formatting and perhaps color markup to make it easier for those with the blessing of sight to notice abnormalities. I am not qualified to suggest details about that but I hope someone is and will here. Wnt (talk) 19:04, 24 February 2019 (UTC)
A list, trying to be brief. I'll probably come back and update this.
(1) Indenting is a total mess. Bullets, indents, numbers, combinations, alternations, etc. Even when it works properly, it can make for difficult communication (e.g. two people responding to someone will be on the same level. If just indented, their comments blur together. (2) Signatures too often veer wildly from the username behind them. (3) Signatures are often distracting from the rest of the text (text highlighting is what most affects my personal concentration). (4) Hard to remove/strike/address comments by previously banned/blocked users in violation of ban/block. (5) Edit conflicts. (6) Page size limits not consistently enforced (making issues when viewing with slow connection, slow computer, or on mobile). — Rhododendrites \\ 18:29, 24 February 2019 (UTC)
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)
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)
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)
Well, what's the point of requesting stuff on a wishlist when you know that what you're going to get ... is a lot of developers working on another Flow? Watch lists might be useful for Wikipedians, but would they get you hired at Facebook? Wnt (talk) 14:55, 24 February 2019 (UTC)
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)
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)
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. — xaosflux06:20, 24 February 2019 (UTC)
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 ♫11:25, 24 February 2019 (UTC)
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)
I wish I could transclude and subst special pages, so that I could then quote or edit that text. Also, those pages (like "what links here" and categories) need to have lots of new added features, like no arbitrary alphabetical divisions, but yes filter out only specific namespaces and string searches and so on. I mean, imagine you could do a categories for deletion discussion where you can actually copy out everything in the category directly as Wikilinks substed in your comment, then revise your comment to say that you think these 20 subcategories can be lumped together as one thing and the other 15 are something else and linking them together is improper "synthesis", etc. Wnt (talk) 14:52, 24 February 2019 (UTC)
I wish the bottom of every talk page over a certain length had a clear link to 'skip to top of page'. For the last year I've done much of my editing on a Smartphone (in Desktop view using wikitext), and scrolling back up to the TOC in order to go back down somewhere else is a bit of a pain. I'd be happy with something like {{Skip to top and bottom}} - but a plain text link would probably be more sensible. And if the same function could activate once sections have become inordinately long, that would also aid navigating up and down lengthy pages. Nick Moyes (talk) 16:03, 24 February 2019 (UTC)
Nick Moyes, I daresay that button would be useful on every single wiki-page, and not just the pages where discussion takes place. That is, I'd use it in long articles just as often as I would on talk pages. Risker (talk) 16:42, 24 February 2019 (UTC)
Yes, potentially helpful to everyone on both types of page, I'm sure. (Got to start somewhere!) Thanks for the discussion link, Xaosflux. Nick Moyes (talk) 16:53, 24 February 2019 (UTC)
Great idea. You know, that's the flip side of the frustration here -- developers want to impose things the community soundly rejects, and they don't want to do what the community begs for years on end. Wnt (talk) 13:23, 25 February 2019 (UTC)
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)
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 Misplaced Pages, 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."
"Your product must have full functionality when used with standard wikitext. Not 'lightweight' functionality. Not 'limited' functionality. Not 'fallback' functionality. No 'balk at complicated templates'. No 'subset of the Wikitext language'. Full functionality."
"We need full rendering - of everything, including the ugliest css-hacks or misappropriation of templates. Your job is to provide it. Period. I don't care how difficult it is, your code won't be rolled out until it can deliver."
"cannot be done through any sort of partially-functional wikimarkup simulator... fully-functional - templates, references, everything - Wikimarkup system."
"if the user base say that the software is completely unsuitable for them unless X, then your choices are 1. Deliver X, 2. Do tests to see if they really miss X, 3. Stop development, or 4. Spend a lot of time creating something that will never be used."
"if any templates or Wikimarkup actually used in articles... then Flow is not at all suitable as a sole replacement for article talk pages, and probably not even for user talk pages."
"Wikimarkup editing of articles and of Flow messages should be the same, and rendering must be the same."
"complete wikitext is mandatory"
"full rendering of arbitrary (correct) Wikicode (not limited to that allowed by Parsoid, but any Wikimarkup which generates valid HTML) is required in talk pages... As long as page can be rendered in article-space, it must be able to be discussed in the user-talk-page equivalent."
"The content we post, needs to display the same way as it does in an article"
"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)
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)
@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)
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.)
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)
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 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.
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. — xaosflux06:31, 24 February 2019 (UTC)
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 Misplaced Pages somewhere. Wnt (talk) 06:45, 24 February 2019 (UTC)
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)
^^^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.) —Cryptic12:58, 24 February 2019 (UTC)
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 ♫12:40, 24 February 2019 (UTC)
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.
Misplaced Pages 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.
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)
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)
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)
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)
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)
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)
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)
The status quo is not an acceptable option because it imposes a barrier on editors who use a smartphone to access Misplaced Pages. 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 Misplaced Pages 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 Misplaced Pages, as it makes it harder for Internet users with no access to a desktop or laptop computer to contribute to Misplaced Pages. CNBCreported: "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 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". — Newslingertalk13:11, 24 February 2019 (UTC)
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)
Indeed, the developers should actually write for three audiences: readers, editors, and the transition state between a reader and an editor. The rate at which readers become editors will mostly depend on the feasibility of making those first few edits. Wnt (talk) 19:10, 24 February 2019 (UTC)
Tracked in Phabricator Task T158181 Indeed, MobileFrontend is an example of exercises at reinventing the wheel which make things worse, exacerbating the difficulty we have with the growth of mobile usage. Fix the regressions first and the rest will follow. This is actually an example where the status-quo (pre the forced enlistment of everyone into mobilefrontend) was better. Nemo15:10, 24 February 2019 (UTC)
The linked task on feature parity between the mobile and desktop views is very important. However, after trying Misplaced Pages's desktop view on a smartphone (through the "Desktop" link at the bottom of each page on the mobile site), I disagree that the desktop interface is better than the MobileFrontend on a phone. To display page text at a readable font size in the destop view, the mobile browser needs to be zoomed in to a point where only a fraction of the page's width is visible on the phone's screen. Editors have to constantly pan the browser window to read an article if they want the phone to be positioned at a reasonable distance from their eyes. This problem is exacerbated in the wikitext editor, where the text field is larger than the browser window. It's difficult to find the right position in a large mass of wikitext when you have to pan both horizontally and vertically. — Newslingertalk00:36, 25 February 2019 (UTC)
I almost always have MobileFrontend turned off on my mobile. But, then again, I'm near-sighted, and often operate the phone without my glasses at a few inches distance, giving me a comparable (although somewhat smaller) angular field of view to an old desktop computer. — Arthur Rubin(talk)03:25, 25 February 2019 (UTC)
Its not that hard to have a full-featured responsive skin for the desktop site – Timeless skin does a pretty good job, and in my opinion is way, way better on a mobile device than either MobileFrontend/Minerva or desktop/Vector. - Evad3711:03, 25 February 2019 (UTC)
As a Timeless user I agree with this; MobileFrontend is clearly not designed with editors in mind. Monobook now has a responsive layout on small screens as well, though I've never regularly used Monobook so I don't really know how useful it is. Jc86035 (talk) 11:17, 25 February 2019 (UTC)
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.
This time around they recognize that talk pages are used to "invent templates" and "adaptable techniques", "reorganize conversations on the fly", "always see what's been done on a page, when, and by whom", which were ignored in all previous attempts of redesign. If they're going to keep all the old features in the new discussion configuration, maybe we can find a new arrangement that maintains all the good stuff. Diego (talk) 10:57, 25 February 2019 (UTC)
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)
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). Nemo08:31, 24 February 2019 (UTC)
The ability to create diffs - not just of someone adding a comment but of changes to the entire page. MER-C11:18, 24 February 2019 (UTC)
There's no such thing as discussion pages - we have work pages, and any given work page may include any mix ranging from 0% discussion to 100% discussion. The killer feature of Talk pages is that they are literally just an article page in a different namespace. That means any and all content from article pages may be copied to, and worked on, on any page with 100% fidelity and 100% compatibility. The most important use case is always the new workflow being created tomorrow. Trying to treat pages as "discussion pages" divorced from 100%-article-page-compatibility is an error that the WMF continually makes in this area. Trying to capture individual use cases, trying to replicate those workflows a new system, is another persistent error. The fundamental use case is compatibility with article pages, and our on-the-fly creation of new workflows using article-wikitext on other pages. Alsee (talk) 16:00, 24 February 2019 (UTC)
Alsee, See Possible solutions, this time "Building features on top of wikitext talk pages"is an acceptable option for the WMF. I say, let's take them at their word and work on improving our talk pages with tools to make them accessible. Diego (talk) 11:01, 25 February 2019 (UTC)
Rapid loading. I have a very limited internet connection here, and social media using systems akin to what the Foundation is always proposing simply don't load reliably or fast enough. Espresso Addict (talk) 23:33, 24 February 2019 (UTC)
I do not consider it necessary for each "post" in a messaging system to be Wikitext. However, unless these "discussion" pages are parallel to talk pages (i.e., we also keep talk pages), each post must have the capability of including at least 2 Wikitext sections, which display as if in the Misplaced Pages talk page, and can be copied to/from other posts and the main Misplaced Pages pages. (Although this would also require major rewrite of some of the basic templates used in Misplaced Pages to operate in different namespaces.) Diffs, revert, and restructuring (the latter possibly limited to admins). In some cases, some workflows could be possibly moved from talk pages to discussion pages, provided that we aren't discussing the details of templates. — Arthur Rubin(talk)03:17, 25 February 2019 (UTC)
Threaded/nested discussions. A key difference of Misplaced Pages Talk pages with some other common linear discussion systems is that you can follow the logical sequence of a conversation even when it diverges into several sub-topics, by reading all the replies that have been made to a single comment. This capacity is lost when the direct replies to a comment are widely spaced and intermixed with other topics. If it causes problems to newcomers, we can use tools to improve their usability. (I've just tried the Enterprisey's reply script suggested by Izno, and it really is a simple way to participate in a threaded conversation).
Improving the visual layout of threads (I've done this in my css setup by reducing margins and showing a vertical dashed line for each thread level), and maybe allowing threads to be folded client-side in the browser could improve readability and make them easier to follow. Diego (talk) 11:15, 25 February 2019 (UTC)
(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)
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)
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-C11:17, 24 February 2019 (UTC)
C is the only choice. The problems that Misplaced Pages 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)
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 ♫11:32, 24 February 2019 (UTC)
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. — Newslingertalk12:53, 24 February 2019 (UTC)
C and note that C is what I call status quo. Minor improvements to existing systems is not a drastic change. We should not have any drastic changes here. TonyBallioni (talk) 16:44, 24 February 2019 (UTC)
C - Flow was a catastrophe in the making and reviving it in any size, shape, or form is just a matter of good money chasing bad. Make it go away. Burn the code. There is always room for improvement within the existing framework of talk pages, concentrate effort there. But we don't need to make talk pages into a buggy bad emulation of Reddit... Carrite (talk) 17:05, 24 February 2019 (UTC)
C for Consensus.
note that Kusma's (D) is interesting but must be taken with caution. I recently looked at the Wikimedia blog to find out had been "moved", by which they meant, they had abolished comments except for people who do business with Twitter and Facebook. That means that their impression of whether their blog post had a positive or negative impression is rightfully the sole intellectual property of whatever PR firm or troll farm owns the most accounts on those services. There are duplications of these at the Signpost, but the point is, leaving these evil, deceptive, grasping, monopolistic, commercial bullying operations in control of anything is going to be a mistake. We want to make sure it is feasible to talk things over HERE. But that is mostly a social problem, because we have too many people eager to sanction comments if they're made here while leaving people to do all the same things on another site, as long as the masters of that site want them to. Wnt (talk) 19:17, 24 February 2019 (UTC)
C with elements of B - While the underlying wikitext of talk pages should remain the same, there should be so many user-friendly interfaces for interacting with it, that most users can ignore the wikitext entirely and not even need to know that it's there. Oiyarbepsy (talk) 19:22, 24 February 2019 (UTC)
C. Doing it any other way may or may not help some new editors join up, but will absolutely alienate and drive away much of the existing editing community. If it ain't broke, don't fix it – instead, focus on improvements within the existing structure. --Tryptofish (talk) 20:42, 24 February 2019 (UTC)
C. It would be nice if we could just have a friendly discussion with the Foundation about how to enhance the current functional talk page system to make it still more useful for existing editors without always having to fight off proposals to fundamentally change it in ways that will make it a lot less useful to existing editors. Newbies are, after all, going to have to get used to interacting with plaintext sometime, if they are going to edit mainspace productively. Espresso Addict (talk) 00:11, 25 February 2019 (UTC)
C. The option of having wikitext in any discussion forum is a minimum requirement. Some of the earlier descriptions of Flow had Wikitext as options, but copy/paste never worked, so WP:TNT should be applied to Flow, as it is a failed alternative system. A system with Wikitext as a basis, or possibly stored as Wikitext with additional invisible pointers which can be manipulated by an additional interface, might not be a failure from the start. — Arthur Rubin(talk)04:45, 25 February 2019 (UTC)
A. I remain a big fan of Flow and baffled by what seems to have become ideological opposition to it. It works really well on other wikis and worked well on several talk pages when it was trialled here, and solves most if not all of the problems that exist with the status quo. Of course it isn't perfect and as with any solution, needs and will continue to need ongoing development. WaggersTALK13:10, 25 February 2019 (UTC)
@Waggers: While I personally like Flow (I enabled it on my Wikidata talk page), it remains problematic in several areas critical to a significant number of editors. It's not searchable, it has endless scrolling, you can't view or edit the source code of an entire page, the replies aren't ordered chronologically, and so on. You also have the editors who believe Flow is unsalvageable. And as it currently is, Flow would be a terrible substitute for the status quo in many community processes on many wikis.
Even if community processes continue to only use signature-based discussions, with all talk pages converted to Flow, editors who only know how to use Flow would effectively be shut out from those community processes, because they wouldn't know how to add comments, and/or wouldn't choose to learn how to make signature-based comments just because most other discussions on the project wouldn't require that learning. Jc86035 (talk) 15:30, 25 February 2019 (UTC)
"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)
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.
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)
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.
I would add: anything that looks fashionable now and was not 10 or 20 years ago: because it's just a fad and won't last. (It's worth saying explicitly because WMF routinely tries to impose whatever the cool kids did last year somewhere, be it NYT or M$ or Apple or whatever.) Nemo15:06, 24 February 2019 (UTC)
<sarc>Can we require an on-screen OOUI styled keyboard to do all talk entry? Oh yea, also better emoticon support.</sarc> — xaosflux15:13, 24 February 2019 (UTC)
Note that Wikipedians never agree on anything, our bitter talk page feuds typically end in "no consensus" ... but we agree on this stuff. I certainly agree with Risker above on everything, not just in detail but in concept. I have never seen a page where I could find so little to disagree with overall, and I do try. This should be a clue. Developers, give up fads, give up trying to get hired at Facebook or Google, by the time you're ready to start you'll never be able to get sufficient security clearance with the government anyway. Wnt (talk) 15:20, 24 February 2019 (UTC)
Something that is not wikitext-based of that forces people to use something other than the source editor. The overwhelming majority of active editors would not care one bit if this proposal died today. They should have the option of using what they’ve always used. TonyBallioni (talk) 16:42, 24 February 2019 (UTC)
Agree: don't take away existing capacities. When the visual editor appeared, I played with it for perhaps 20 minutes, and then spent a similar amount of time ensuring I'd never have to see it again. Compelling people to learn a new interface will cause an extinction event among us WikiSloth types. BSVulturis (talk) 17:56, 24 February 2019 (UTC)
As per the two comments just above mine, don't fundamentally change the talk page system. And don't feel a need to imitate social media, just because new users allegedly find it more familiar. --Tryptofish (talk) 20:46, 24 February 2019 (UTC)
I generally agree with Risker on all but one point. There is an ability to hide the display of posts in Wikitext, for example {{cot}} and {{cob}}. If Flow's "hide" acted like that, there wouldn't have been as much objection. I wouldn't object if the Wikitext display was also suppressed until a "show" button in the editing box was pressed. — Arthur Rubin(talk)04:54, 25 February 2019 (UTC)
There are ways to "hide" posts of Wikitext using templates such as you've pointed out, and I wasn't referring specifically to that; I wasn't referring to revision-deletion or suppression, either. I was more referring to the practices of some social media that make certain posts or users undiscoverable via search, or that allow readers or others to "ignore" the posts of certain selected posters. Risker (talk) 14:11, 25 February 2019 (UTC)
Someone has asked for a system that will "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)." This has never been possible in any way in any version of Mediawiki. Adding that functionality alone to Mediawiki would be a sizable undertaking. This whole project is doomed from the start because you can't build a discussion system by committee. The users don't know what's needed to make a discussion system work. They're users, not software engineers, UI designers nor community managers. Users should be able to call out when something's broken, but as they're already so steeped in the existing, broken system, somehow they think its only problem is lack of accessibility. It's a hack built on what was easy to do when the software was developed. There's no way any these over-the-top demands of the users will be met in version 1.0 of a replacement. No one will agree on any of the details. The whole thing is it's doomed to fail. What are they going to do next? Put out some grants for some college grads to develop it, scrap it when no one likes it and then a year later start this process again? What is the point of this process? At best Wikimedia are just going to use it as an excuse to do what they were planning to do anyway. But anyone who makes you choose your "formal or informal name to identify your participant group" just to respond to their banner ad survey isn't exactly going to design the next Skype. ——Pengo02:33, 26 February 2019 (UTC)
Why are off-wiki chat tools not an option?
It seems to me that it would be an enormous and obvious mistake to try to design a system that supports use cases best handled through other means. I would hate to see a product that is trying to replicate Slack on-wiki, and as a result doesn't do discussions or chat well. I agree that whether that is IRC or Discord or Slack or a new "MediaWikiChat" product isn't relevant now, but the possibility of officially including such a tool in our workflows should be considered. It certainly is technically possible to record that information on-wiki in some fashion or to have it integrated with MediaWiki SSO. power~enwiki (π, ν) 18:05, 24 February 2019 (UTC)
Off-wiki chat tools should never be private companies demanding terms and conditions so people can have a say in Misplaced Pages. See my comment in the section above. IRC and email have the advantage of not being bound to a specific company -- things that are can have no role except if individual users choose them to use with each other, and only because we have no right to stop them. Developing new tools -- one of which could be as simple as a dedicated IRC server to reliably serve and record the Misplaced Pages conversations -- should be a good idea. But any such new tools must be set up with the best "legal condom"s that lawyers can conceive of, to ensure they cannot leak liability back to WMF organizations if some idiot starts spouting off about his plans for tomorrow's massacre on a discussion forum. Understand that however desirable chat tools are, and however important they are to the maintenance of a free society, we are in a situation where sites that formerly made an effort to seem freewheeling like YouTube will now literally axe tens of millions of conversations because supposedly there's a perv out there somewhere and it's scarcely news. When fanatics claim that one wrong word is more bad than a lifetime of saying anything else could possibly be good, we are surrounded by helpful people who want to screw our mouths shut for our own good. We absolutely have to fight them but we also have to be wary about avenues of attack. If we come out of this being the one site that didn't shut down its forums -- unlike the Wikimedia blog for example -- we already can be heroes ... provided we don't compromise ourselves along the way. Wnt (talk) 19:29, 24 February 2019 (UTC)
@Wnt: As a party to the Discord channel, I think the WMF itself is fairly safe from liability if the WMF isn't the moderator of the channels, since they have absolutely nothing to do with it. (Whether a commercial service is the most appropriate is another question, but surely Facebook and Gmail already dominated off-wiki conversation years ago.) Jc86035 (talk) 16:25, 25 February 2019 (UTC)
Forgotten talk pages
One of the biggest problems with our talk pages, that I almost never hear anyone talk about, is the huge number of talk page posts that are never noticed, for years on end. A new user posting on an obscure topic has no idea that no one is watching a talk page and that no one might see it. One of the biggest things we need a some system where posts on obscure topics would be cross-posted to a broader discussion page - for example, a post on Talk:Paulicianism could be cross-posted to a Christianity-related articles notice board so that knowledgeable editors actually see the post and can respond as appropriate. On our current system, such talk page posts are typically ignored for a very long time. Some ideas for accomplishing this can be found at User:Oiyarbepsy/Wikitalk: The Next Generation. Oiyarbepsy (talk) 19:18, 24 February 2019 (UTC)
This is a great point. One thing I'd love to see, that would help fix it, would be a diff across transclusions. In other words, you select two dates of a page, but instead of hitting the usual diff button, you hit some other button where you can check off which transcluded templates you want to see changes in also. That would mean, for example, that you could transclude 50 obscure talk pages together and then hit the diff and see all the comments made on any of them. Obviously there would be some processing and length limits imposed to keep things feasible, but Lua does that already. Indeed, it would almost be possible to do this whole thing in Lua now, but the interpreted language isn't as efficient as something at a deeper level in the site, I don't think, and I don't think Lua can access old versions of pages. Wnt (talk) 19:35, 24 February 2019 (UTC)
Yes, I also thought of that problem (long-time unanswered posts). Talk pages with active editors work great, but many are underwatched, and posts no longer on the watchlist never get noticed when hidden at the bottom of a long talk page that starts with a page full of metadata and maintenance notices. Cross-posting to some other noticeboard only helps if that board is reasonably active. Unfortunately many WikiProjects are also more dead than alive, with talk pages that seem to only consist of unanswered requests (a random example is Misplaced Pages talk:WikiProject Pokémon). It is often not easy to find out how to ensure you get an answer to a query at all. But that is probably due to general community health more than technical problems. —Kusma (t·c) 19:50, 24 February 2019 (UTC)
There are so many talk pages which have never had any topics added, that one can be forgiven for not bothering to check any of them. Were the Talk Page Tab to change in some way (colour/boldening/width increase) if there had been a new topic added or non-bot edit made within, say, the last four months, we might actually get readers and editors noticing them. That would mean some would be permanently highlighted, others only occasionally so, and many never changing their apoearance. And if we could stop keen types from seeing old topics on infrequently-used talk pages and thinking they're helping out by shunting them off into an archive, we would make it even easier still to see whether the talk page is genuinely inactive or not. I find it helpful to quickly see that there has been minimal activity over a ten year period, than have to click into a pointless archive sub-page, only to discover the self-same thing. Nick Moyes (talk) 23:15, 24 February 2019 (UTC)
Message crossposted from MediaWiki: 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 Misplaced Pages, and certain parts are specific to the time period in question, but I would venture it is likely to be useful reading regardless. PS: Improvements and discussion are welcome. Sunrise(talk)00:02, 25 February 2019 (UTC)
Straw poll: changing indentation
Hypothetically, would you accept the introduction of \ (or a different ASCII character, like > or %) as the sole character to be used for indentation in new discussions? (I have not discussed this with anyone yet, but it's probably technically possible, although it has the potential to cause some amount of temporary disruption if the change is handled poorly. It's also possible that something like this has been discussed before, but it might regardless be worth gauging whether such a change is currently practically feasible.)
This would at least partially resolve the practical, semantic and accessibility issues of using various existing list items (and could potentially ameliorate things like the use of tables in indented comments); the alternative would probably be to create a new wikitext parser to interpret list items differently on discussion pages, which I think would be much more technically challenging and more difficult to administrate and understand, and would be unnecessary if a new indentation method could be introduced. A page's configuration could then be set to interpret and display single-indent comments in a different way based on the function of the page (e.g. numerical votes for RFA, statements of opinion for AFD); alternatively, an extension tag could be used to set this for portions of pages and would achieve the same visual and semantic output. Furthermore, with an actually semantically correct model for discussion pages, developers would presumably be more inclined to add additional features like automatic setup of talk page archival, visual improvements like indications of nesting levels, and visual editing on talk pages. However, this would require all users to be notified of the changes and could require all existing talk pages to be modified or archived. It would also require pages using the new indentation character at the start of a line to be modified. Jc86035 (talk) 09:22, 25 February 2019 (UTC)
Sounds great. Better and specific markup for indenting would solve the accessibility issue and end the silly ::* versus *:: confusion (which is done for optical effect, not for semantic reasons). Finding a universal character for this might be difficult across all WMF wikis, but it sure is worth exploring. —Kusma (t·c) 09:31, 25 February 2019 (UTC)
Comment Not opposed in principle, but thought would need to be given to readability in the edit window.
:::*Maybe it's just familiarity but this normal indented comment feels much easier to read in the edit window than
@Espresso Addict: (I've formatted your comment.) I agree with this. Perhaps ` or ^ could also be considered, though there may be languages where some of the aforementioned symbols would be problematic due to being used relatively often at the start of sentences (% might have this issue in some languages). Jc86035 (talk) 10:20, 25 February 2019 (UTC)
I think low symbols such as .... or ,,, might prove more readable than high ones ```` or ^^^^^, but all are better than %%%% or \\\\\. The difficulty is going to be finding one that everyone agrees is readable but doesn't cause coding problems. Espresso Addict (talk) 10:42, 25 February 2019 (UTC)
I always have to adjust to the strange indentation patterns here @enWP, at deWP we nearly only use : in discussions. * is only used if something should be sorted in a single post, and # is usually used for votes (as we use votes quite often instead of this for us strange consensus process here). I don't know why we should change to any other random character, I fail to see any advantage. Grüße vom Sänger ♫12:03, 25 February 2019 (UTC)
@Sänger: Using a different character would be beneficial for mainly the technical reasons described above, as well as making it easier for experienced users to reply to comments in source code. The current use of list items for indentation, particularly definition lists, generates syntactically and semantically invalid HTML.
mw:Help:VisualEditor/FAQ specifically indicates that VisualEditor does not support talk pages because of issues with list items (talk page discussions "are not structured discussions from a technical perspective"), and Whatamidoing (WMF)'s 2014 comment on the talk page indicates that it would not have been desirable to signing and indenting in VisualEditor, and thus it would have been undesirable to support VE on talk pages (at the time Flow was still in active development). I suspect that the developers would not want to formalize a semantically and syntactically incorrect convention (even if it was pragmatic at the time the convention was formalized), because this would effectively set the invalid syntax in stone, and it would become even more difficult to change it to valid syntax later. At the end of the day, if improvements are desired then developer support is needed as well as community support, and I think it is very unlikely that something that is technically incorrect will be officially supported. Jc86035 (talk) 12:38, 25 February 2019 (UTC)
Your willingness to introduce new characters to wikitext is interesting. There are many ideas that would be much easier if people are willing to play with the basic syntax. However, you have some huge problems with that -- the most important being that you have unfathomable amounts of content written under the assumption that those symbols did nothing. You have to be willing to go through the database and pull out every instance that would have to be changed and change it without damaging the way it appears, and people would have to be willing to put up with that. Wnt (talk) 13:42, 25 February 2019 (UTC)
@Wnt: If it's ^, then if you already have the full database, since the character doesn't normally do anything one would just change every instance at the start of a line to ^ (with special handling for usage inside templates and parser functions, if any). Am I missing something? Most of the proposed characters would be extremely uncommon at the start of a line anyway. Bots have done far more wide-ranging edits on the English Misplaced Pages. Jc86035 (talk) 13:55, 25 February 2019 (UTC)
Perhaps the first thing to do would be to write a better search, because I don't think I have any way to grep out ^ at the beginning of a line here without having my own copy of Misplaced Pages on my own computer. I have no idea how many instances are involved and how many people would be "surprised" to find that writing ^ at the beginning of their lines causes trouble. You are probably right... Wnt (talk) 14:03, 25 February 2019 (UTC)
The other problem I see with changing to an "indent character" is that the way indenting caught on in the first place is that it (hypothetically) implements a list. Now very few of us ever saw Help:List I think, but I mean, there is a theory to it, sort of. Just indenting to indent ... why are you indenting anyway? Hmmm. The main catch is that the original specification doesn't seem to be explicit enough on how to open and close items. For example, here I have two bullet points, and there's no way to claim them both by format alone, so I'll just sign both of them. On the other hand, if they were :s, then they would just be two paragraphs, and if someone wrote a third paragraph below, there would be no way for him to say "wait this isn't just part of wnt's comment" at the format level. And suppose I wanted to write a bullet point, but needed five paragraphs to flesh it out? Of course, we use the signatures for these purposes semantically, judging that a third paragraph with a new signature after it is a different comment etc. There might be a way to convert that fairly reliably into a new wikitext format if we have a wikitext format that accomplishes those goals. I have some vague ideas in mind like using = at the end of an indent to specify a new section or putting your \ at the end of one to indicate a desired break in the conversation, but am nowhere near proposing something sensible at the moment. Wnt (talk) 13:42, 25 February 2019 (UTC)
@Wnt: While thinking about the "new wikitext parser" idea I did consider proposing additional markers to indicate the end of a comment (i.e. a <sig/> extension tag after each four-tilde signature). This could be useful depending on the implementation of any visual changes, as it could effectively be used to split the rendering of comments depending on how well the parser could interpret this. Jc86035 (talk) 14:01, 25 February 2019 (UTC)
Help:List § List basics describes one way to have a paragraph break within a bulleted item; it can also be done by an equivalent template, for those who like to write {{something}} instead of <something>. isaacl (talk) 15:25, 25 February 2019 (UTC)
@Isaacl: Certainly, although I didn't know that <p> was appropriate for quite a long time, and it's not exactly the most intuitive way to add a line break. It's rarely ever used anywhere else in wikitext. Jc86035 (talk) 15:34, 25 February 2019 (UTC)
It's a bit of HTML markup that is adopted by wikitext (the history of the meaning of <p> in HTML is convoluted, but I'll ignore that for now). Following the intent for wikitext to be a somewhat intuitive text-based format, the start of new paragraphs is usually indicated by a new line, but for a list item, this also indicates the end of the item. isaacl (talk) 16:05, 25 February 2019 (UTC)
Oh, how about if we had something we could write that expands to an anchor? Like, you type *= at the beginning of your comment, and the = gets turned into a template with a unique code, I dunno {{a|88912356}}</nowiki> or some such (that's not a real template usage). When that template is displayed it should show up as a line or something with an HTML link attached, so that we can "copy this link" in our browser to respond to it. Then if we put something like {{r|88912356}} in our reply, it should provide a link directly to that comment. If we put something like {{r|<pasted HTML link here>}} it should get automatically substituted to do the same thing. And then there could be some other sequence that indicates "end of reply", and at that point you have anything useful that could be salvaged out of Flow turned into wikitext. I mean, you could even put postings in the opposite or a random order on a page and still follow the threads. But you could also use these things to direct some kind of format markings. Still not sure if I have this idea right, but it's a start... Note, I'm not proposing to steal these particular template letters, but I should note that if you have WMF resources behind something you can reclaim a letter if you can find a template that is only used a few thousand times. Wnt (talk) 13:59, 25 February 2019 (UTC)
@Wnt: This sounds like a plausible idea (though I would do it with a parser function or an extension tag). Couldn't this basically be notifications plus anchors based on revision IDs (with suffixes added for multiple signatures in one revision)? I think if the software automatically found the beginning of each comment (based on contiguous modified lines preceding signature?) it could work; I would be wary of forcing users to add more code than necessary. Jc86035 (talk) 14:41, 25 February 2019 (UTC)
You're right about not forcing code -- my idea is ugly -- but the contiguous modified lines idea could run afoul of many other page elements, like instructions for a poll etc. Maybe a hybrid - an optional manual way to start the line, perhaps as simple as a blank signature that the software knows not to try to make look like a comment. All of this pretty much depends on your idea of making signatures an element with formal code like <sig />, which will have its own resistance, but as long as you make it come out automatically when people put the four tildes it shouldn't really be too jarring. Wnt (talk) 15:10, 25 February 2019 (UTC)
I don't see any difference in complexity between the current system and this proposed system. It looks like it would be prone to exactly the same inconsistent practices as the current practice. And when it comes to practice, that's really a community issue, not a software or WMF issue. Risker (talk) 14:08, 25 February 2019 (UTC)
@Risker: Not necessarily. If there are enough visual indicators that the new system is different, it would get rid of the issue where users reply using bullet points to threads, for one thing.
The problem with making any changes that are any more drastic is that there would probably be lots of community opposition, so the current level of complexity would probably have to remain to prevent flexibility from being lost (but probably with a nice sheen over it so that a little VE box can be used to reply to comments inline). Jc86035 (talk) 14:28, 25 February 2019 (UTC)
Responding to ping, but I don't think I understand what's being proposed, despite a couple read-throughs of the original post. It sounds like it's just changing colon to something else? To me a solution would require being able to visually separate people's comments more easily. That's a lot of why people use bullets, outdents, extra indents, etc. to begin with. I don't think, if this is part of the proposal, that we can really do away with the multiple ways of formatting (regular text and bullets, mainly) -- there are functions for both. — Rhododendrites \\ 14:40, 25 February 2019 (UTC)
@Rhododendrites: Changing colon to something else would be the only change for regular users who write comments as source code.
As far as I'm aware, across the MediaWiki wikis where I'm active, asterisks are mainly used only at the first level of certain discussions, where users are voicing their opinions on the statement previous to the bullets; and all threaded replies are supposed to use colons. Similarly, hashes are only used at the first level in votes, with all replies indented using colons. If there were a parser function/extension tag for parts of pages (e.g. <discussion type="vote">, which would set all of the discussion content until the next <discussion> tag to a "vote" display method) and/or an option to change this on a per-page basis, you would be able to change the display of the top-level comments to fit the discussion type, and different symbols to indicate formatting could be eliminated.
And after discussions are changed so that the input results in semantically correct HTML, the developers can go about adding features like giving a background to every other nesting level, or whatever, without having to worry about not formalizing invalid syntax. Jc86035 (talk) 14:54, 25 February 2019 (UTC)
I'm ambivalent about how much mileage we would get from using different ASCII keyboard keys to accomplish this goal. But an alternative occurs to me. If three more clickable buttons were added to the top of the editing window (maybe only when the page being edited is a discussion page?), there could be one with a → that would be labeled "indent", one with a • that would be labeled "bullet point", and one with a # that would be labeled "numbered line", or something similar to that. That would be more intuitive to new users, and would still allow experienced users to use the existing keyboard shortcuts. --Tryptofish (talk) 19:22, 25 February 2019 (UTC)
Sub-proposal: change threading convention
If changing the indentation process is on the table, I want to propose a small change that can make a large impact to readability and doesn't require any software support:
Change Help:Talk pages#Indentation so that the convention is "The reply to the first comment is indented at the same level", and "if you add a second reply to a post, indent one level all replies to that post (and put the second reply below the first one, also indented one level)".
This would help keep discussions flat by default. We largely do this already at straw polls, where each new comment is at the first level (preceded by *) and only replies to a previous comment are indented.
For example, in a conversation which looks like this:
First comment
Direct reply to first comment
Another unrelated comment
Adding a second reply to user A's comment would change it to this:
@Diego Moya: Ultimately, since this would not involve any software changes (unless it is formalized as part of a software change), I don't think the proposal could affect the results of the consultation, and each project's community would have to decide whether to change this long-standing convention which appears to be consistently observed across the Wikimedia projects. I also think this would be too easily associated with Flow, since what you're proposing is exactly how Flow nests replies. Jc86035 (talk) 12:08, 25 February 2019 (UTC)
Flow threading isn't the same as this. A large backlash against Flow threading was that it changes the order of replies, placing the oldest reply below all the newer ones. (In the example above, Flow would place User B's reply unindented and below User D's, right above User C's). The proposal above maintains the same ordering as the current practice (though it sometimes requires a small edit to one comment by a different user), and avoids the current situation of a discussion between two editors made with deeper and deeper threads.
Since this conversation is about discussing possible global solutions to talk, not merely software solutions, I believe that changes to long-standing common practices are within the scope. Diego (talk) 12:46, 25 February 2019 (UTC)
To clarify, this is how the above conversation would be threaded by Flow:
@Diego Moya: Sorry, that was incorrect. Would users determine whether to indent the previous post through context alone? I think this could potentially make discussions more confusing, particularly if there's more than one indent level. Jc86035 (talk) 13:47, 25 February 2019 (UTC)
@Jc86035: If we don't get tooling support, unfortunately yes, manual intervention would be needed. But we could have "reply" commands that managed this automatically; the indentation mechanic has a precise specification that can be followed exactly.
You're talking about trying to make a social change against thousands of years of habit. It's not likely to go over well. There is even some rationale (Help:List) to the current system - the problem is, there are some things you can't do with that syntax as it is (see my comment above). Wnt (talk) 13:45, 25 February 2019 (UTC)
Well, the goal of my suggestion is having a threading system that only gets extra indentation when it's needed (i.e. when there are two or more direct replies to the same comment), not after each reply like our current convention. Doing it through social change is just one possible way to achieve it, one that could work even if we don't develop new tools; but adding tool support would of course be better.
In any case, I thought the whole point of this exercise was to evaluate all of our current ways of communication and justify which ones still make sense, and which ones could be improved? Diego (talk) 14:54, 25 February 2019 (UTC)
Is there a realistic, practical way of making this change using only software development? There's a fairly obvious way to make a different character work (making comments look unambiguously different so it's obvious where the syntax is being used), but indenting could be more challenging. Let's frame it as "how do you technically dissuade/prevent people from indenting their comments the old way".
You can't restrict users from editing the page source, because users wouldn't want that. You can't really perform automatic fixes, because there would be no way to tell if some edits are indented correctly. I don't know what else you could do.
Bear in mind that the current consultation plan is to have an as yet unknown team of WMF software developers carry out the changes. If their job becomes "send MassMessages to make people use different indentation methods", then this effectively becomes a waste of their time and energy. Jc86035 (talk) 15:10, 25 February 2019 (UTC)
There's a real simple way to get rid of "too much indentation" without changing any habits, and that is to mess with the actual pixel value of the indentation. Indeed, much of the anti-Flow opposition is because white space was more than in the present convention. You might be pleasantly surprised how people respond to less. Bear in mind that Misplaced Pages draws in people who do a lot of reading - the sort of people who look at a whole page at once to check something like "is there something about ethics on this page?" without actually reading the words one by one. Nonetheless ... make the indent adjustable by user preference just to be on the safe side, and it will be better for all. Wnt (talk) 15:15, 25 February 2019 (UTC)
Speaking of changing pixel values ... I should note that Misplaced Pages doesn't have to be totally passive where the edit source is concerned either. It is possible to make the source window come up with a different font or even custom-write a font specifically for the purpose of editing Wikis. For example, such a font might display a non-breaking space visibly so that if the user's keyboard is also tampered with by some means, it becomes possible to type them and read them directly. WP could come out with custom keyboard things that let you type other significant characters more easily also. You'd have to have a preference for each though - some people would want to see in their source and some would be OK with replacing that with the custom character. Expect preference proliferation, but this is a good thing (just think about all the changes you make in the advanced settings for a Firefox browser!). Wnt (talk) 15:30, 25 February 2019 (UTC)
@Jc86035: You're right, I hadn't thought of how adopting the new style by "changing the wetware" could depend on other language Wikipedias. I was assuming that, if we achieved community consensus at an RfC, we could rewrite the guideline that recommends adding one indentation level, and this would become the new standard.
To add support within the mediawiki platform, allowing editors to keep using wikitext manually but also adding interface support, there should be a way to extract with high reliability the individual comments and their dependence relations in the thread (it doesn't need to be perfect, as special cases could be corrected by hand). I think I like the idea of using a special character as a delimiter for new posts (like we use * to start new !votes at straw polls); probably a parser could deduce in most cases the lightweight structure of threads by using heuristics over signatures, indentation levels and comments using this special character. If the parser could identify individual comments, we could even show the same conversation with different styles to different users through theming.
@Wnt: I know that reducing the size of margins would improve the visibility of threads; in fact I've configured my custom theme to achieve exactly that! The side image is how I see this current thread, thanks to my .css settings:
Still, I think having a simple linear discussion be shown as a series of posts with increasing indentation is unnecessary complex; and in long conversations, it forces editors to reflow the whole thing using the {{outdent}} template. Diego (talk) 16:09, 25 February 2019 (UTC)
Sub-proposal: automatically indent and sign discussion entries
To help facilitate and format asynchronous discussions universities and colleges use platforms such as blackboard for online discussion boards. Users can 1) start a thread and 2) reply to a thread and the writer doesn't have to sign it or indent because the entry is signed, dated and indented for them. Would this functionality be possible? --the eloquent peasant (talk) 15:06, 25 February 2019 (UTC)
@Level C: Enterprisey's reply-link script already does this to some degree (I'm writing this comment without pressing "edit source" and without typing four tildes), so it's definitely technically possible. But for the reasons I outlined in my replies two subsections above (search for "semantic" and "developer"), I don't think the WMF would implement this as a standard feature without a change in the HTML to be generated; and a change in the HTML generated would only be possible with small breaking changes to how users write comments in source code. Alternatively they could just implement Enterprisey's script without any other changes, but this would mean that it would become harder to make the HTML less technically incorrect, and the developers wouldn't like that. Jc86035 (talk) 15:17, 25 February 2019 (UTC)
A preference for "autosign at end" would be great, which simply tacks on the four tildes if it doesn't find tildes in the post. I don't want to say always do it because there's always some goofy instance like you want to insert a figure at the start of a discussion so it doesn't poke out into the next one but you don't want your sig coming up after the figure because then it's in front of the first guy's question! Also, the autosign should be averted if you put your own tildes anywhere in the post. I am prone to using a P.S. every now and then, after all.
On the other hand, if a genuine <sig /> tag is introduced to allow more definitive delineation of comments, that degree of informality might be sacrificed somewhat. In that case you might have to stick an empty <sig /> after the image you put in front, or even a duplicate of your own. There's a cost-benefit to work out with that depending on the specifics of the proposal which could override my first paragraph. Wnt (talk) 15:22, 25 February 2019 (UTC)
@Wnt: You wouldn't necessarily have to put the <sig/> after the image, because no one would need to reply to the image itself. The invisible <sig/> would exist for the sole purpose of allowing the software to distinguish different comments; a username+timestamp regex (which would be more difficult anyway, particularly considering localization of namespace names) wouldn't work because users are accustomed to being able to copy and paste signatures. Jc86035 (talk) 16:15, 25 February 2019 (UTC)
Also, perhaps the autosign would be better as a "did you forget to sign a comment?" message upon pressing save (on by default but only for new users, as usual). This would be possible without any syntax changes. Jc86035 (talk) 16:19, 25 February 2019 (UTC)
Unless there is creation of an entirely new type of page, any page can be a discussion page. Every existing page has a "talk" page, but this proposal is not limited to only those kinds of pages. We are talking about software for discussions, and discussions include things like AFD and other deletion discussions, ANI, Arbcom Noticeboard and other noticeboards, Wikiproject pages, lists, subpages of other pages, etc. We come up with new places for discussion all the time (anyone can create an RFC on a subpage, for example), because this is a wiki and (within certain conventions) any page can hold any kind of data or be used for any function; that's one of the foundational principles of a wiki. And guess what? these are going to happen in namespaces where signatures are used only some of the time. Even if a page is primarily used for discussion, there is almost always a section that should *not* be signed - such as metadata on article talk pages. Risker (talk) 19:27, 25 February 2019 (UTC)
