The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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 Wikipedia at large is currently signed up as one "participant group" at mw:Talk pages consultation 2019/Participant group sign-up. WikiProjects, off-wiki groups and the like are also encouraged by the WMF to conduct their own discussions.
At the end of the discussion, one or more users are to summarize (i.e. formally close) the discussion and post the summary to mw:Talk:Talk pages consultation 2019. Since the WMF prefers that at least one primary contact be available, if you are interested in closing the discussion and will be able to do so, please add your signature to the next subsection. It may be appropriate for only administrators (or only experienced users) to close the discussion. Jc86035 (talk) 14:28, 23 February 2019 (UTC)[reply]
The Wikimedia Foundation has set a deadline of April 6, 2019 for results from this RFC, and recommends a deadline of March 31 on new responses to ensure time for closure.[1] The RFC was opened on February 23, and closing could reasonably be done as early as March 23.
The Foundation has not specified how to deliver the results, but in the absence of further instructions I suggest posting a copy of any closure at MW:Talk:Talk_pages_consultation_2019, along with a link to this RFC. Ping for currently listed interested closers: MattLongCT, DannyS712, cygnis insignis, Xain36.
I'm too far too involved to close, but I have extensive experience engaging the Foundation and with RFCs relating to the Foundation. I am specifically keeping informed of the Foundation's activities&processes surrounding this Talk Page Consultation. Please ping me if there is any information or assistance I can provide. Alsee (talk) 13:13, 11 March 2019 (UTC)[reply]
The deadline just passed. A summary has been posted for the Foundation, but I expect they will be directly examining this page in detail. Alsee (talk) 12:54, 7 April 2019 (UTC)[reply]
Multi-branching conversations are a double-edged sword. Yes, it can be convenient to be able to branch off a new thread in close proximity to the triggering post, and to keep the new branch in one place. However, the conversation sprawls very rapidly afterwards, making it extremely difficult to keep up with all of the latest additions to all branches. There is a good reason why the linear structure of bulletin boards continues to persist online: there is a straightforward way for readers to bring themselves up-to-date on the overall conversation. They just need to start reading from the last post they previously read. This increases the chance that each post will be read (or at least considered by readers before they decide to skip a post), which can make the overall conversation more efficient. I suspect this is often a worthwhile tradeoff versus the ability of making it easier to only follow and respond to a specific branch. isaacl (talk) 17:07, 23 February 2019 (UTC)[reply]
To broadly address the question for context, since most WMF staff members are not regulars: The noticeboards and established community processes (village pumps, the Teahouse, WP:AN, WP:RSN, WP:AFD, the main page processes, and so on) are presumably indispensable, since they perform a vital role in centralizing discussion about related matters. The requests for comment process is quite useful for initiating other major discussions, particularly when combined with the feedback request service. However, these might only work for the English Wikipedia because of its size compared to other projects. Talk pages are also useful, although only if someone else is around to respond. Off-wiki channels, such as IRC and the Discord server (and Special:EmailUser, of course), are also useful for general discussion, and for matters considered unrelated to Wikipedia's goals (not everyone is a prose-generating automaton). However, they probably only represent a very small portion of English Wikipedia-related discussion. Jc86035 (talk) 17:13, 23 February 2019 (UTC)[reply]
I'd also like to bring up Enterprisey's reply-link user script. Even for experienced users, it can make it much easier to reply to a comment (especially in large, messy discussions – if the users in the preceding discussion have indented their posts correctly, that is). It's also customized for the major discussion boards on the English Wikipedia. I can't believe it took until 2017 for it to be invented. Jc86035 (talk) 17:17, 23 February 2019 (UTC)[reply]
Other user scripts, particularly Twinkle, are also very useful for starting discussions like deletion nominations (which would otherwise require a fair amount of manual bureaucratic checkbox-ticking). However, Twinkle is not enabled by default, so newcomers may end up wasting significant amounts of time doing all of these things manually, if they ever get past the walls of text surrounding most of the community processes. Jc86035 (talk) 17:44, 23 February 2019 (UTC)[reply]
Twinkle is prone to be abused, either causing trouble for undeserving beneficiaries of its mechanical invective or for the inexperienced or incautious editor who is called to account for it. I won't say you can't use it, but that kind of custom-made tool to make it easier for editors to chew on each other is not really what I would call a great benefit to the user experience. Vandalism on-wiki (as viewed by a random reader, I mean) is already at incredibly low levels, but loss of editors over "processes" is alarmingly high. Just look at the top contributors of all time and see how many are banned now! So I don't really want it to be incredibly easy to take that thing out for a spin, no. Wnt (talk) 14:37, 24 February 2019 (UTC)[reply]
@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)[reply]
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)[reply]
There are a number of Byzantine processes that could be greatly improved through automation, though. Good Article Reassessment and Featured Article Review come to mind, both of which involve page creations, transclusions and placing of templates in multiple places which could easily be done through Twinkle or something similar. FAR even requires the nominator to use a "Click Here" link partway through the process which leads them away from the instruction page. –dlthewave☎04:06, 1 March 2019 (UTC)[reply]
Something like "Let us build (or locally customize) automated systems to handle things like GAR and FAR" should be in-scope for this discussion. If that's something that you all think would improve communication, then please ask for it. Whatamidoing (WMF) (talk) 17:05, 1 March 2019 (UTC)[reply]
French Wikipedia talk page styling Strongly agree. The styling on the French Wikipedia looks very nice. The clear delineation between different comments is very helpful, especially when someone on a talk page responds to a comment that has a numbered list in it or something like that, where the indentation levels can get confusing. -- Ununseti (talk) 07:37, 3 March 2019 (UTC)[reply]
How about code folding for discussions? Being able to manually close sets of replies to a given comment would also make it easier to read long discussions. —((u|Goldenshimmer)) (they/their)｜😹｜✝️｜John 15:12｜☮️｜🍂｜T/C23:31, 8 March 2019 (UTC)[reply]
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)[reply]
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)[reply]
The existing talk page system works well for me. It's just like editing an article, which I've probably just done or am about to do, so I only have one interface to learn. I can add talk namespaces to searches, view them in contribution histories and see talk changes in my watchlist. I don't feel blocked by problems. Certes (talk) 18:33, 26 February 2019 (UTC)[reply]
When the talk page grows to more than a single screen, with several branches, then it is becomes pretty hard to understand who is replying to who. I believe StructuredDiscussions, or something similar is the right solution, but it might be possible to get the same functionality with other tools. The problem is to refer another post without having to dig up a diff in the history. Jeblad (talk) 11:30, 28 February 2019 (UTC)[reply]
I find the existing system very workable on a 27inch monitor, but it might not be for people who use smaller screens, and they are certainly the majority. When they are used incorrectly in a long discussion and mess up the sequence, someone usually fixes them. A good deal of confusion could be done by simplifying the list options, and not use numbered lists in discussions--I do use numbers in discussions, but I just use colons, and write out the numbers. The code is primarily helpful for numbered lists that are going to change, and that doesn't apply. But what does need fixing is a that we need a way to avoid splitting discussion between multiple places--and this is not a question for the foundation really, because it does not involve the code. It needs better controls here. DGG ( talk ) 20:32, 28 February 2019 (UTC)[reply]
Something like "Prevent discussion forking by making it possible for the same conversation to happen simultaneously on two or more pages" should be in-scope for this discussion. (Noticeboard plus an article talk page? WT:SPAM plus Meta's spam page?) If that's something that you all think would improve communication, then please ask for it. Whatamidoing (WMF) (talk) 17:05, 1 March 2019 (UTC)[reply]
actually,I would not want to do that; I think it would be too confusing regardless of the implementation; I was thing of our have a practice of closing all but one thread and linking to a single active discussion. This does not need any WM code, or tools, just the determination at enWP that we want to do that . I do not see any way of automating it because the judgment that it's the same topic would have to be human. And then it would just be placing a template. DGG ( talk ) 23:58, 1 March 2019 (UTC)[reply]
The ability to use Wikitext works well for me. Using the same interface and markup as article space makes it simple to copy-and-paste content for discussion, or propose changes in the same way that they will appear in the article. –dlthewave☎04:13, 1 March 2019 (UTC)[reply]
One more thing which I mentioned above: I really like tools that automate talk page processes while retaining the same underlying Wikitext, such as using Twinkle to open an AfD and post notifications on multiple pages in one step. The Visual Editor would be a great step in this direction as well. I feel that increased availability of these tools would empower new and experienced editors alike to participate in the way that best fits their needs. Personally, I often switch back and forth between manual and automated processes depending on the task at hand, especially when I need to fine-tune something by editing the Wikitext.
It would be great to have the option to render talk pages in a way that resembles online forums, with a "reply" button that automatically applies the correct indent. Again this would give editors the choice to view the page as they always have or use the new interface as a supplement. –dlthewave☎17:45, 1 March 2019 (UTC)[reply]
isaacl wrote: "... 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." Yes! - Mark D Worthen PsyD(talk)06:15, 1 March 2019 (UTC)[reply]
Nope. And this is yet again another example of why a more advanced discussion platform is needed. Left to my own devices I would have responded to isaac1 immediately under his post of 15:50 (UTC-0) on 25 Feb 2019. But a few years ago a more experienced editor chided me for replying in that manner. I was told to respond at the bottom of the page. - Mark D Worthen PsyD(talk)22:33, 1 March 2019 (UTC)[reply]
I am a relative newby. I have tried to communicate through talk pages but I found that this does not work very well, at least not for newbies. Talk pages definitively have their place though. I found the tea house very helpful. There is one simple button labelled "Click here to ask a question", which is wonderful. At the end I have learned a lot, but I also feel that I have wasted the time of some very kind, patient and experienced Wikipedians and that I should have been able to find out myself by reading the Manual of Style (at least in most cases). I wanted to try the Village Pump but I do not like the name and could never decide which category was right for my question or comment. I dislike the name because it suggests gossip. I do not want to take up somebody's time with gossip. I want to learn and solve problems. - Another aspect is that I find the Wikipedia format and editing style unsuitable for fora like Teahouse and Village Pump. They should work like other fora. Johannes Schade (talk) 15:30, 19 March 2019 (UTC)[reply]
What about talk pages works for newcomers, and what blocks them?
Very new users are occasionally confused where to add text, i.e. at the bottom like when writing a paper rather than at the top like on Social Media. They rapidly accustom to the proper way of doing things, which should not change, but a set of "tips" advising them of things like this, displayed in some small out of the way space as they get accustomed to editing, might not do much harm. Wnt (talk) 16:52, 23 February 2019 (UTC)[reply]
"They rapidly accustom to the proper way of doing things" - I'm putting a big [Citation Needed] 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)[reply]
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)[reply]
all you really need to know is to add four tildes at end We so routinely have people who don't know or don't remember to do so that we built a bot for it. That's not trivial and shouldn't need to be done. --Izno (talk) 14:58, 10 March 2019 (UTC)[reply]
And a similar comment for especially with the 'New Section' link that adds the message at the bottom. New or inexperienced users (and even a number of experienced users) have no idea that this button exists as they routinely post in the last existing section, or the top section, or the first one they see an [edit] button for. --Izno (talk) 14:59, 10 March 2019 (UTC)[reply]
New and even existing users can be perplexed by the fact that some users -- even admins -- sign their posts with names other than their own actual account name, piping it through a wiki redirect. That wouldn't be bad to change. Wnt (talk) 16:52, 23 February 2019 (UTC)[reply]
They find themselves intimidated, frustrated and overwhelmed when others make heavy references to [[WP:...this and that..]], instead of actually stating valid arguments on the topic of discussion. THE NEWImmortalWizard(chat)17:50, 23 February 2019 (UTC)[reply]
Even at the ever so user-friendly Teahouse we still jump on new users who repeatedly fail to/forget to/don't know how to sign their posts. So why is not signing a post still so easy to do? Even a simple 'yes/no' prompt to add a signature on hitting 'Publish changes' without already having added the four tildes could solve many problems of unsigned posts. I also agree with Wnt that users creating signatures not reflecting their true username can be quite confusing and does not aid communication. There's one example immediately above. Nick Moyes (talk) 21:16, 23 February 2019 (UTC)[reply]
Many newcomers seem to be able to add text somewhere, often in the wrong place or without a heading. They also don't follow any of our (inconsistent) indenting standards for replies. But just like forgetting to sign (which can even be done by bots), these formatting issues can be easily fixed by the more experienced Wikipedians participating in the discussion. When I discuss with newbies on my talk page, the problem seems much less that talk pages are difficult, but that they find it hard to tell me what page they are discussing (but I can usually figure it out from their contributions or deleted contributions) and can't understand our byzantine system of policies, guidelines and practices. I expect most newbies despair not of the difficulty of navigating wikitext, but of having their edits reverted and their articles deleted, and instead of an explanation we point them to WP:ALPHABETSOUP. The great advantage of our current approach to talk pages is that there is no need to learn two different systems for editing pages. The downside is that we use different conventions (especially about signing and indenting). —Kusma (t·c) 11:03, 24 February 2019 (UTC)[reply]
The mix of what Nick Moyes and Kusma describe is probably the most dissuasive experience for noobs (and being called something like noob "in the face" by not-so-friendly other users). For the friendliness it's probably irrelevant what form the page has, it's a behavioural issue not a programming one, and the very little syntax skills needed to just get along on talk pages (indentation by : and signing) are no more a barrier then any other new stuff. I think it probably helps newcomers, if the talk pages behave in the same manner as everything else in the Wikipedia, so you can test stuff there, even under supervision of oldies, that are meant for the front side. Grüße vom Sänger ♫ (talk)11:14, 24 February 2019 (UTC)[reply]
Stripping out parts of the content on mobile just because they look like clutter is an ongoing disaster; please don't make it worse. (Primarily a mainspace problem - omg nav templates and articlespace maintenance templates and especially edit notices are there for a reason - but applies to talk pages too, e.g. Special:Permalink/884793900#Blanking and active block messages) —Cryptic13:23, 24 February 2019 (UTC)[reply]
It's worth pointing out that Wikipedia is one of the greatest successes of the modern era. Wikipedia underwent literally exponential growth up until 2007. Exponential growth is inherently unsustainable, and the post 2007 decline back to stable numbers was obviously unrelated to Talk pages and unrelated to "wikitext editing being too hard", because those things did not change in 2007. Wikipedia was so successful in large part due to how dead-simple things are. A wiki is nothing but a bunch of identical pages, and a page is nothing but a basic text file with a name. Someone who knows exactly nothing can click Edit and start writing an article entirely in plaintext. Someone who finds Talk pages discovers nothing new - it's just another article page - it's just another dead-simple text file. So long as they can write a plaintext message somewhere on the page, we can successfully communicate with them. If someone has the motivation, if they have the mental and social competence to collaboratively write an encyclopedia as a hobby, there is no hurdle to start picking up the most basic elements of wikitext at their own pace. Any powerful system must have complexity in it somewhere - and a wiki hides all of that complexity within the wikitext parser. A new user can write a plaintext message on a Talk page, without knowing squat about signatures or indentation, and succeed in their journey. The real hurdle for new users is the overwhelming nature of Wikipedia itself, and dealing with other people. Most people have no interest in writing a public-service-encyclopedia as a hobby, and for those who do take an interest it can be difficult or impossible to embrace the fact that the community may re-write or outright delete their work at any time. And for those who can embrace that, the biggest challenge is simply managing to constructively deal with the constant onslaught of other people. The basic fact is that people inevitably disagree about anything and everything, and new users can be easily be overwhelmed trying to make progress through the social arena. There's a fire-hose of information to learn about how to write wikipedia, and it takes confidence and fortitude to deal with other editors when they are wrong. Alsee (talk) 13:27, 24 February 2019 (UTC)[reply]
@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 Wikipedia 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)[reply]
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)[reply]
@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)[reply]
Alsee, "Just look at the horrifying new-user-retention-rates data in the graph at right" That's not what that graph shows at all. Please carefully read its description: 'This graph does not show overall retention rates for new accounts. "Retention" means that the user continued to use that specific editing environment during that 26-week period'. It shows how likely people are to stick to a single specific editor (software, not user) during a period of time. —TheDJ (talk • contribs) 10:37, 26 February 2019 (UTC)[reply]
Wikipedia is a gigantic success, but you have to ask about the price as well. Wikipedia, both technically and socially, is highly inefficient and wearing. User retention is important. Community engagement is important. User satisfaction is important. Wikipedia hasn't enough of either. François Robere (talk) 16:10, 22 March 2019 (UTC)[reply]
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. — Rhododendritestalk \\ 18:21, 24 February 2019 (UTC)[reply]
I do not see the VE as the factor in lower retention. I think it's the other way round. People who come here sporadically and are scared by the idea of wikitext will likely use the VE, and they also will be less likely to stay. People coming here with some experience are likely to be comfortable with code, ad they're the ones who stay. (I think the VE does have a place, and I often use it for revising an existing article, especially when I want to move sections around, or make lots of little formatting changes. ) I think the VE might work for discussions also, as it's list format is very straightforward. . DGG ( talk ) 20:38, 28 February 2019 (UTC)[reply]
Question: What about talk pages works for newcomers, and what blocks them?Answer: A significant number of current editors criticize, ignore, or belittle newcomers when they post something on a Talk page. Ten times as many newcomers read such interchanges on Talk pages and resolve to never post something on a Talk page, and, really, why should I even bother to learn how to write and edit articles if this is how they treat newcomers? - Mark D Worthen PsyD(talk)07:35, 1 March 2019 (UTC)[reply]
(edit conflict) The problem is usability. Sure editors like you and me are able to edit talk pages easily, but for someone who has only been on Wikipedia for one day and does not understand wiki syntax? We can take them through the tutorials, but we need a practical solution that can reach out for all users. I have seen some criticism with Flow because of how it is counterintuitive for some of the people used to the Source editor and cannot understand the Visual editor. By allowing editors to submit comments while allowing wiki formatting, structure, and backward compatibility, the UI would become easier for all of us. AwesomeAasim07:39, 1 March 2019 (UTC)[reply]
I do not really see any studies about the usability of Wikipedia (probably because established community editors are used to the source editor), but it would be an area where Wikipedia could get more insight. Wikipedia is very usable for reading, but for editing, it can get difficult. (One time when editing a toolbar button got stuck and I had to reload the page) AwesomeAasim14:56, 1 March 2019 (UTC)[reply]
The Wikipedia Usability Initiative ended in January 2011. The Wikimedia article, Wikimedia Research/Usability testing, "... describes the basics of how, when, and why to do usability testing". It is not about usability testing of Wikipedia itself. - Mark D Worthen PsyD(talk)22:45, 1 March 2019 (UTC)[reply]
A wikipage is nothing but a text file with a title. A new user can start writing an article in plaintext, and they can comment in plaintext. You could hardly set a lower threshold for a new user to start writing an online encyclopedia. It's clearly a major reason for the enormous growth and success of Wikipedia. New users can learn simple wikitext at their own pace; things like [[links]] and :indentation are almost trivially easy to pick up. Alsee (talk) 17:03, 1 March 2019 (UTC)[reply]
The content is text, it is not plaintext. It has assumptions on how ithe text is formatted and what character sequences mean, thus it is not plaintext. Jeblad (talk) 12:29, 2 March 2019 (UTC)[reply]
I am a certified volunteer trainer for Wikimedia UK and also in the past 11 months, I have been working as Wikimedian in Residence at the Scottish Library and Information Council, training people across the library sector on how to contribute to Wikipedia and its sister projects. In both those roles I regularly get the opportunity to interact and get feedback from new users on their experience of editing Wikipedia. First of all, I want to say that I'm a big fan of talk pages, they are on of the project's greatest strengths and newcomers are always impressed with the opportunities for transparency, communication and collaboration that Wikipedia affords. Talk pages are also a great tool for teaching people about information literacy and how the Wikipedia community build and reach consensus on a variety of complex and often controversial issues. Despite those positives though, I must say that talk pages are often one of the most inaccessible features of Wikipedia for new editors and that problem has gotten worse since introducing the visual editor feature for editing Wikipedia pages. The reason for that is because the visual editor, which was specifically designed to make editing Wikipedia pages easier and more accessible to edit for newcomers has not been rolled out to talk pages. As a result, newcomers are getting a great experience of editing Wikipedia pages using the visual editor, but then struggle with the wikitext editing code on the talk pages. It's also a difficult issue for us as trainers to address as ultimately we often have limited time during training sessions and have to be selective about the content that we cover. As a result, we often have to focus our training time on the rules for editing Wikipedia (5 pillars, standards of notability, copyright, conflict of interest editing, reliable sources, etc...) and on the features of the Visual Editor (headings, wikilinks, references, adding photos, categories and infoboxes), which leaves us no time to cover wikitext and writing on talkpages. The most straight forward solution I would see to solving this issue for newcomers would be to enable using the visual editor on talk pages in the same way as it is enabled on the article pages. Editors would then have the option as to whether they want to edit the talk page in source code or using the visual editor. Another frustrating aspect I wish could be resolved on talk pages is the fact that people have to opt in to signing their pages by adding the 4 tildes. Any other chat room program or similar that I have ever used online automatically signs my contributions or attributes them to my user account, so I would say as a very minimum, we should look at automating the signature process on talk pages as well. I'm happy to discuss these comments further if anyone has any questions further along in the consultation. Delphine Dallison (talk) 11:29, 7 March 2019 (UTC)[reply]
As a quick reminder, the creation of a group of editors that could edit but not talk was one of the arguments against Visual Editor.—Kww(talk) 17:13, 8 March 2019 (UTC)[reply]
@Delphine Dallison: Why don't you (and other instructors) use wikitext from the very start, and simply drop Visual Editor? Then you get new editors who can edit articles and talk pages, instead of editors who can only edit articles (and even that not completely). The use of VE is not helping Wikipedia in the long run, the use rates of it on enwiki are still terribly low even after all these years, and while new editors are often steered towards it, we don't see an increase of its use in the long run, suggesting that new editors soon switch to using the wikitext editor anyway, or that they drop out and stop editing. Fram (talk) 13:27, 11 March 2019 (UTC)[reply]
@Fram:, @Kww: The issues between VE and using talk pages only exist because we haven't taken VE far enough and I will simply reiterate my comment above that VE should be extended to talk pages. As far as I'm concerned, VE has been a game changer in terms of reaching out to wider audiences and recruiting new editors and even as an editor who can use wiki markup, I much prefer working in VE, which is far more user friendly. Wiki markup has its place and I will occasionally switch to it for more complex formatting, but I would never recommend scrapping VE as it would be a major step-back. I think some of the issue here is that when people have been editing for a long time, they forget how to put themselves in the shoes of new editors and how it feels when you're familiarising yourself with a new platform. Before VE, we would spend all of our time training just teaching wiki markup and we wouldn't even get to the point of creating new content, which made the task sometimes feel insurmountable to people who aren't that way inclined. Thanks to VE, most people I train will actually manage to create a Start or C class article in the space of training session and that sense of achievement often will encourage them to keep editing afterwards. What we should be looking for is solutions for fixing the problem with talk pages, not arguments for scrapping a useful tool just because people who have been editing for a long time don't see the point of it. Delphine Dallison (talk) 13:52, 11 March 2019 (UTC)[reply]
Thanks, but that kind of misses the main popint: after more than 5 years of VE, the actual evidence is that it is not (just) "people who have been editing for a long time don't see the point of it.", but most new editors after a while don't see the point of it either. The use rate of VE has been stable at 4 to 5% for 5 years now (non-bots, article space only), and no amount of training new editors or promoting of VE otherwise seems to change this at all. The last 1000 Visual Editor tools in article space go back from 10.03 to 14.06, or 4h3min (243 minutes). This does not include the more than 60 edits in the same period which started in VE but switched to wikitext to finish the edit... The last 1000 edits in total (no bots, article space) altogether were between 13.57 and 14.10, or 13 minutes. So my 5% is about right for now as well. While VE editing is a bit higher for less experienced editors, it is the minority editing environment for them as well, and you seem to mainly get people switching from VE to wikitext over time, and rarely the opposite. Fram (talk) 14:21, 11 March 2019 (UTC)[reply]
The switch tag is a little buggy and additionally doesn't indicate "A or B exclusively" but indicates "mixed use in one edit session on a page". --Izno (talk) 14:50, 11 March 2019 (UTC)[reply]
Uh-oh! Data! That's a futile thing to use in an argument with people that decided what the problem was before they started.—Kww(talk) 16:21, 11 March 2019 (UTC)[reply]
Meh, no need to call ImmortalWizard out on this. The questions presented are vague enough that their answer is relevant. (Rephrasing, Q: "What's wrong with discussions on Wikipedia?" A: "Nobody ever agrees about anything.") It's not immediately obvious except to cynics like us that this is really just another attempt to force Flow or something substantially Flowlike onto us. —Cryptic09:53, 24 February 2019 (UTC)[reply]
As Crpytic pointed out, I just roughly answered the vague question. It is up to the "experts" (who are asking for suggestions here) to decide how it could be done in practice. I don't believe it's a non-goal. THE NEWImmortalWizard(chat)10:49, 24 February 2019 (UTC)[reply]
Edit conflicts and finding the right spot to reply and the correct indent level in long discussions on the Pump or similar (but newbies are unlikely to participate in those anyway...) —Kusma (t·c) 11:04, 24 February 2019 (UTC)[reply]
Proper signing in the first few days, edit conflicts and indentation issues all the time. And of course the most dissuasive problem with talk pages: the sometimes quite deterrent lack of AGF and the abusive behaviour of MoaM. Grüße vom Sänger ♫ (talk)11:19, 24 February 2019 (UTC)[reply]
As noted elsewhere, threading is important and difficult. The use of :*# seems simple at first, but nested discussions get complicated quick, especially as users typically just reply to the most intended comment rather than the one they're actually referencing. Mixed use has accessibility problems I believe, but it's not always clear what to use. I have for years used some custom CSS (borrowed from MuZemike) that highlights different indentation levels which is very helpful, and makes it clear how often we editors mismatch things. I think this is one of the things flow was supposed to but failed to help. ~ Amory(u • t • c)11:22, 24 February 2019 (UTC)[reply]
The current talk page system is extremely inaccessible to mobile users, particularly Wikipedia editors who use the mobile site and apps on a smartphone. Having to go into into an editing mode and then manually position your comment into the discussion with wikitext is an unbearable experience in active talk page discussions, such as the ones found in noticeboards and for controversial articles. VisualEditor on mobile improves this, but the user experience still pales in comparison to threaded discussion interfaces for other websites (most notably Reddit), and the VisualEditor is also not supported in the Wikipedia apps. An officially supported and automatically enabled version of User:Enterprisey/reply-link for both mobile and desktop users would help address this, as it would make it much easier to directly reply to another editor's comment. — Newslingertalk14:05, 24 February 2019 (UTC)[reply]
I would not recommend Reddit as an alternative to anything. The first knee-jerk reaction to a post, whether clever or (more often) silly, is put at the top of the discussion because it gets all the upvotes and replies. All the best comments on any given thread are often at the very bottom, where you would have to expand everything a dozen times to get to them, because they are something that somebody didn't want to have said. A truly good post can get fifty or even a hundred downvotes, even though nobody can read it without deliberate hassle from the software, because they have some secret cheering section running against them even after they disappear. Reddit is like the Refdesk, but only one or two people can answer and the rest are wasting their time. Oh, and this is a fossil reaction from years back before the censoring got bad, and by now I'm sure it's much worse. Wnt (talk) 14:32, 24 February 2019 (UTC)[reply]
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 Wikipedia 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: [2][3]. 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)[reply]
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)[reply]
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). — Rhododendritestalk \\ 18:29, 24 February 2019 (UTC)[reply]
I often come across questions on a talk page for a little-monitored taxon that have had no response for years, even a decade. Maybe a way to ping a WikiProject (or just the ones listed on the talk page) would be good. Or maybe a checkbox when a user posts a new section to note that an answer is requested, and then it populates a category like 'WikiProject Algae talk pages with unanswered questions?' --Nessie (talk) 07:02, 27 February 2019 (UTC)[reply]
Consensus building is often very hard, especially with mixed sufficient and necessary clauses. Users often make claims that break clauses that should be uphold. It seems to me that there are at least two different cases; one where all cases use necessary clauses, and the other one with at least one sufficient clause. The first one can probably be solved by simple voting, but if there is a necessary clause then that will override any voting. The problem is what to do when someone find a necessary clause during a voting over a set of sufficient clauses. Jeblad (talk) 11:26, 1 March 2019 (UTC)[reply]
What do you wish you could do on talk pages, but can't due to the technical limitations?
Sometimes I wish I could just watch a section or singe discussion on an article's talk page. I may want to follow a specific conversation, but not have all changes to an article and its talk page appearing in my watchlist. ---Another Believer(Talk)17:12, 23 February 2019 (UTC)[reply]
As well as being able to watchlist selected sections, I'd like to be able to choose whether only to be notified whenever a completely new topic is added to certain pages I watch, and not every time any new post is added. And for the help forum page I assist on, I'd welcome an on-wiki notification as soon as a new question is posted there. Nick Moyes (talk) 22:43, 23 February 2019 (UTC)[reply]
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)[reply]
Sections watchlisting has been requested by the community for years. However it's important to note that this is a GENERIC PAGE FEATURE, with no connection to Talk pages per se. The feature would (probably) be most often used on talk pages, however the ability to watchlist article-sections or sections other non-talk pages is equally an element of the feature specification. Alsee (talk) 05:43, 24 February 2019 (UTC)[reply]
Agree with suggestions above. Would also like to be able to use Visual Editor on talk pages. Having new editors be able to use the same editing tools in both spaces would make teaching them easier. Doc James (talk · contribs · email) 06:07, 24 February 2019 (UTC)[reply]
On talk pages with Flow that I run across on WMF projects outside of enwiki (see mw:Talk:Notifications for an example), I wish I could easily find all the discussions on a page, but you can't even search the page as it doesn't show all the content when going to a page - requiring infinite scrolling before you can search the page. So I suppose I wish that all content would load and not require infinite scrolling on flow pages. — xaosfluxTalk06:20, 24 February 2019 (UTC)[reply]
I'd like to watch just single sections and all new ones, and get those in distinct lines in my watch-list. I don't have much problems any more with edit conflicts and indentation, I'm a bit too long here and know how to deal with them. As I think every wikipage has to have the same look-and-feel, I think the VE should be deployed on all wikipages, so that there is no artificial rift between article and talk page. I probably won't use it, as I'm accustomed to editing in wikitext, but any wikieditor should be able to be used on any wikipage, or it's just not worth using it at all I know that there are some special purpose editors for some nerds, but those are not what this here is about. Grüße vom Sänger ♫ (talk)11:25, 24 February 2019 (UTC)[reply]
Not quite a technical thing, but it annoys me that on enwiki I need to actually the talk page to see if there has been any discussion about the article, ever. Almost all articles have a "talk page" that is filled with metadata (quality ratings, wikiproject templates, old afd links) instead of discussion. In a complete redesign of talk pages (something I generally oppose), I would suggest to find a new home for the metadata. —Kusma (t·c) 14:33, 24 February 2019 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I've been wondering about something similar; if all contributions belong to a single section, then add the section in the summary, and if necessary override the existing summary. If the section is added in the current contribution, then that section should be used during the processing like all other sections. If the editing spans several sections, but has a common section heading, then that heading should be used. Jeblad (talk) 21:55, 28 February 2019 (UTC)[reply]
This is part of my personal list:
Move topics between pages, retaining all history.
Archiving, without having to copy paste and use seperate pages. Archiving should be a first class citizen.
Read a talk page on mobile, with a normal text size, but without having insane indentation depth.
Watch a topic.
(perma)link to a topic (sort of possible with revision link + section, but breaks due to archiving)
Automatic signing
quick reply button (mostly possible with Enterprisey's userscript)
have a history of to which comment someone is replying to
Searching a specific Flow board for discussions about a specific topic. This should probably be more "fuzzy" than ordinary searching. Jeblad (talk) 21:48, 28 February 2019 (UTC)[reply]
Three improvement proposal for better communication, for fun & consent building and less edit wars:
1. Clear start of a new comment that can be used as identifier / part of an identifier and for chronological sorting to identify easy last added comments. I would suggest as identifier sortable date/time and username: YYMMDDhhmmUsername, e.g. #1903030052Charis (this includes an anchor). The comment can be ending with long name and date signature but even without signature, the next identifier indicates easily start of next comment. I would suggest to identify a anchor by a leading # in the text (but not in the anchor itself).
2. 1:n relation of n reply to one chat comment. Current thread chain is ony a 1:1 related to previous and following. The flow Structured_Discussions/Sandbox and as well the Extension:LiquidThreads see Example relates at least also 1:1, is no solution for me. For 1:n relations to comments this have to being build by links separate from comment text and position. This allows to reference to multiple arguments, to summarize, and to build themes out of a older chats and dedicated comments. To build links to each comment, each comment needs an identifier within a chat thread. I would suggest to use date/time/username + the first 100 characters which creates a link / URL to this identifier which provides direct readable information about the subject. No user is in the same minute writing and saving again same 100 characters which excludes duplicates on the same site. For a new comment automatically the identifier is set and created at first saving like signature. Additional the link to the previous and alternative to all other comment identifier on the same page should be provided to create a link in the edit. The Tool "What links here" should support to overview the link structure on a page by selection of all links pointing to other pages as well as all internal links onto a reference of the same page. It should also allow multiple selections of the namespace e.g. to seach all links that are not links from/to User or User talk. Like the following link to a header onto this page, the change of an identifier would break all links to it, so the editing user has to care in case of an update of a comment like this one. It's upward compatible, talk pages can be continued like now but manually anchors and links to it allow a structured discussion due to links to important chat comments like in Jira_(software). For beginners it would be nice to create identifier and anchor at begin of a comment automatically by the editor and to offer the existing anchors for selection and supported link creation. This would fit to the option Possible Solutions "Visual Editor on talk pages with extra features".
3. A anonymous audio conference and chat. In case of missunderstanding and conflict it is easier to find an agreement spoken than by written words. Wikipedia:IRC provides online chat. A similar or combined solution for audio conference would be appreciated. Charis (talk) 00:52, 3 March 2019 (UTC) updated Charis (talk) 12:13, 3 March 2019 (UTC)Charis (talk) 17:11, 9 March 2019 (UTC) 08:40, 11 March 2019 (UTC)13:31, 16 March 2019 (UTC)[reply]
For very lengthy talk pages like this one, it takes a lot of scrolling before I get to where I'm supposed to type my comment. If I want to reply to a specific comment within that massive collection of comments, it takes a long time to find the one I'm looking for within the wall of wikitext. A reply-to feature would be nice.
Additionally, for very long talk pages, it's hard to tell which comments have been added since I last visited. I usually end up relying on the diffs to read newly added text, but pure wikitext doesn't look very nice. Actually, this could probably be easily resolved by being able to see unified diffs. GitHub has this (example). -- Ununseti (talk) 08:16, 3 March 2019 (UTC)[reply]
For the unified diff, it would also be nice to have a shortcut link "diff of page since your last visit". And a navigation tool to jump between the various changes, like in MS Word's next/previous in its accept/reject changes feature. (Are there any userscripts for this?) -- Ununseti (talk) 08:23, 3 March 2019 (UTC)[reply]
Here is a list the things I'd like to be able to do on talk pages:
Use lists in any post without them being mistaken for separate comments;
Have the start of a new thread in a discussion clearly delineated from previous posts;
Have the start of each editor's contribution to an existing thread clearly delineated from previous posts, and from the start of a new thread;
Have each each editor's contribution to an existing thread clearly associated with any previous posts to which they are replying;
Have the end of each editor's contribution to an existing thread clearly delineated from previous posts;
Have all of my posts equally accessible by a sighted user and any using assistive technology such as a screen reader;
Look back at archived threads and still be able to read them in the way that they were originally presented;
Have all of the above implemented in the simplest, most transparent way.
Now, that's a specification for the job. I don't really care about how the software produces the end results, as long as it matches my requirements. I accept that we may have to abandon the current wikitext markers going forward, or maybe we don't. I also accept that it looks like we need at least three separate delimiters of some kind (start thread; start comment; end comment), none of which should be duplicating the markup for ordered or unordered lists, although maybe the software can deal with that without needing the editor to do so. Am I asking for things that others don't want? Am I being unrealistic in what I'm asking for? Hopefully the answers to both questions is 'no'. --RexxS (talk) 15:59, 3 March 2019 (UTC)[reply]
It would be nice to be able to identify who are in fact contributing to the subject page, that is how much, from the beginning to present. Not just character added or removed, but actual workload. The discussions on the talk pages often spiral into bickering where someone insists on being an expert (wikiwikiexpert, or fast-fast-expert) while doing very little real work in the article except edit warring. If the real contributors could be identified, and plain edit warring muted, then the discussions on the talk pages would probably be more civil. There are several ways to visualize this, but my favorite is a smoothed accumulated edit distance or some approximation, and a race track diagram for amount of contribution for each contributor over time. Such diagrams tend to mute both vandals and edit wars, leaving only the real contributors. Jeblad (talk) 13:20, 4 March 2019 (UTC)[reply]
It would be nice to be able to list issues with the subject page, in a way that made it darn simple to identify the passages that has issues, and also simple to say the problems are solved. For example if a passage is unclear it should be easy to just copy-past the passage into the issue, and the have the issue pointing back to the passage on the subject page, even if the passage was slightly edited. It is not necessary to make a full-blown annotation, just make it possible to write an issue without sprinkle the subject page with templates. Not to forget, but the issue should also be darn simple to mark as solved. I wonder if it should be something like checkboxes, just check it off when it is done and sign it somehow. The check-action should be logged somehow, like getting an entry in the history. Jeblad (talk) 22:13, 7 March 2019 (UTC)[reply]
I believe that mailing list on which Wikimedia issues get discussed should be on Wiki. Flow should be updated in a way that it can do everything that's needed for doing the job of the existing mailing lists.
A polling function using voting buttons would be nice. That is something that many forums do better than we can do with the existing Wikitext editor. VQuakr (talk) 15:38, 11 March 2019 (UTC)[reply]
A voting module was planned for Flow, but it wasn't built. (Imagine a world in which ArbCom clerks don't have to "Confirm that the vote summary in the heading section is current", because the software would automatically counting the votes for them.) Voting is quite common in some communities, and used for at least one purpose in (I think) all of them except MediaWiki.org. Do you have any specific ideas about how you'd like it to work? Whatamidoing (WMF) (talk) 16:12, 19 March 2019 (UTC)[reply]
What are the important aspects of a "wiki discussion"?
This is an odd question. (All of the suggested questions are repeated verbatim.) Civility. Assumption of good faith. Consensus. I'm not sure how this is supposed to inform the consultation. I don't think Flow or LiquidThreads would have measurably affected these things. The content of the discussions isn't necessarily significantly affected by the interface and software, although at this stage I would probably oppose functions like straw polls (if those are being considered) unless implemented properly so as to limit their use to designated voting areas like RfA subpages. Jc86035 (talk) 17:29, 23 February 2019 (UTC)[reply]
I will simply post some of the onslaught of community comments that the WMF previously ignored in the Flow_Talk archives shortly after Flow was first announced here:
"let's get this absolutely straight. Unless Flow will be able to render every single aspect identically to every valid editor of the article name space, it must not and will not be rolled out! Talk pages are not independent social websites, but they have only one purpose: to discuss articles. For this we need to be able to copy every kind of content, format and structure between the article name space and the talk pages. Your job is to support us in writing Wikipedia, your job is not to build a flashy social website. The identical rendering of every possible content must be your paramount design goal. Everything else takes second place."
"Your product must have full functionality when used with standard wikitext. Not 'lightweight' functionality. Not 'limited' functionality. Not 'fallback' functionality. No 'balk[ing] 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)[reply]
The "PHP parser" will go away eventually. That's not really negotiable on our part. What can/should be done is identifying any of the last of the deltas either to be fixed or not (the "or not": all parsers will have their quirks, some of which may not be worked around. PHP parser is quirky in a number of ways, and "being used to those quirks" isn't a good enough reason to keep it). --Izno (talk) 06:24, 24 February 2019 (UTC)[reply]
@Izno: Please explain what will be "going away" in more detail. If you are talking about the old 'padleft' being cautiously replaced by something elegant and versatile, that's one thing. If you are talking about breaking transclusion or forcing every template to be rewritten from scratch, or worse, that's quite something else. Wnt (talk) 06:40, 24 February 2019 (UTC)[reply]
There is not now a significant difference between the two parsers, so neither of the above items will need change. Parsoid and the current PHP parser use two different models of figuring out what the source wikitext means, which is why there are some differences in what we see when we have a final look at a page between someone using VisualEditor/2017 WTE and someone using 2010/2006 editor and their associated previews/renderings. Right now, of course, when you see a page, it uses the latter and not the former.
(One of the problems with Flow is that it basically used neither Parsoid nor PHP parser on release.)
Izno I'm aware of the WMF's 2016 plan to kill off the current wikitext engine, and I'm also aware of the WMF's 2013 plan to deprecate wikitext as the primary input method altogether. And both of those imaginary plans are utterly irrelevant here. The article-rendering-engine is the one and only valid and acceptable engine. It's fine if the WMF wants to work in a way that calls the PHP engine because it's the article engine, without caring that the article rendering engine happens to be the PHP Parser. However if the WMF tries to shove a new discussion system down our throats that doesn't use the article rendering engine, it's going to blow up in their face. Again. I suggest you re-read the comments I gathered above from the Flow history, and carefully consider how much tolerance the community will have for any discussion system with less than perfect fidelity to article rendering. The worst case outcome here would be if the WMF builds yet another discussion system that it can't deploy. Alsee (talk) 07:54, 24 February 2019 (UTC)[reply]
Izno, As far as my current knowledge carries, the plan right now is to convert Parsoid from Node to PHP and then make the Parsoid parser the new and one and only 'php parser' (there are various technical reasons for this) (Much as we switched from Tidy to RemexHTML).
There are very few differences between the old and the new parser left and many of the differences that are there, are either edge cases, or in areas where we need to make changes to the old renderer as well (video content comes to mind). A lot has been learned over the past years about wikicode and how it works (and hundreds of testcases have been added) making it possible to do these kinds of transitions, where before this was practically not doable. —TheDJ (talk • contribs) 13:31, 26 February 2019 (UTC)[reply]
On point 1, StructuredDiscussions (Flow) use the same rendering engine, but it is wrapped in a slightly different outer container.
On 2, 3, and 4; same as 1.
On 5; this is a faulty argument, and the conclusion is way off, unless you believe that somehow you need the exact same outer container. That should never be necessary, but you can always create a new subpage.
On 6; this does not make sense.
On 7; same as 1.
On 8; you are free to use wikitext, but you also have a VisualEditor-like interface.
On 9; the code generated by Parsoid is pretty close to wikitext, and you should be more than the usual garden veriety of user to find any differences. Note that wikitext does not produce valid HTML in all cases, so using what you can do as a measure of what is correct is flawed.
On 10, and 11; same as 1.
I believe it is time for everyone to check out StructuredDiscussions (Flow) and how it works. Note that I am not one of the developers of this extension, I'm an user. Jeblad (talk) 10:34, 28 February 2019 (UTC)[reply]
Jeblad I suggest you strike your post, it's wrong starting from #1. Flow does NOT use the same rendering ending as articles (PHP parser), it renders everything with Parsoid. Furthermore Flow's supposed wikitext support is grossly broken, as Flow simulates wikitext support by roundtripping everything through Parsoid. Speaking as a programmer, the technical term for this is "unholy hack". It results in a grossly overcomplicated system riddled with pervasive bugs - up to and including randomly mangling wikitext, datacorruption, and even managing to break the revert button. Trying to revert an edit can literally break the previous content - because Flow is so braindamaged that it never actually saved the original content - so it doesn't have the correct wikitext to revert back to. Regarding the discussion below about diffs, Flow's history page is utterly useless. It has nothing except for single-comment-view and diffs within that comment. There's absolutely no ability to see what the discussion looked like when someone posted their comment, and absolutely no diffs across the discussion. Alsee (talk) 07:20, 1 March 2019 (UTC)[reply]
My understanding was (and still is) that Flow only use Parsoid while rendering for VisualEditor, but if not I can't really see any real problem except for imaginary ones. If there are so many pervasive bugs, then file bug reports. Don't just claim there is bugs, write bug reports. The idea that someone need more than a single comment diff is new to me, and I have done a lot of editing on dicussion pages. It is far more important to clearly show who is responding to who. If you believe your idea is important, then write a complete use case. Perhaps you should implement it yourself? Jeblad (talk) 11:10, 1 March 2019 (UTC)[reply]
That has always been a minimum requirement for any Wikipedia page, including discussion pages: The ability to find all changes from a specified past time to the present, and the ability of (at least) admins to revert the page to the version at that past time and (for adims) delete intermediate versions. The difference between the versions at two past times, and to undo the changes when possible, is helpful, but perhaps not necessary on discussion pages. — Arthur Rubin(talk)12:54, 1 March 2019 (UTC)[reply]
Flow has no capability to save wikitext. If you try to type in wikitext, Flow discards it the moment you preview or save. Flow tries to translate it to something else(HTML5RDFa). When you return to edit mode, it needs something to put in the wikitext-box, so it tries to translate the HTML5RDFa back into something resembling your original wikitext. That gross hack creates a crazy assortment of complexity and bugs. It can randomly mutate what you typed, it can completely destroy the content, it can generate constantly-expanding "tumors" of corrupt wikitext, and it means the revert button has no access to the original content to revert back to - meaning the revert button can corrupt the original content. Alsee (talk) 17:31, 1 March 2019 (UTC)[reply]
As Parsoid will be doing the rendering on Wikipedia eventually (in spite of damage to articles), it might as well do the rendering for Flow. That's a WMF decision, no matter how much it discredits Wikipedia. However, it is important that there be Wikitext (so we can see the individual elements), that it can be copied between Wikipedia pages and discussion pages with no loss, and that it render on the discussion page essentially as on the Wikipedia page (including a reasonable approximation of the window size, and probably exactly the same background color). Subpages are not an acceptable substitute.
I haven't used Flow for anything complicated since copy/paste for Wikitext never worked on Wikipedia, and < math> didn't work correctly when I tried it. I can't say whether the container difference, itself, would make it unusable for complicated discussions. The lack of complete diffs and revert does make it unusable for Wikipedia discussions, even if a true revert might have to be restricted to admins. "Hide" is not "revert". This brings up an additional minimum requirement.... Deletion (including the the three-part deletion options for user name, content, and edit summary) and suppression must be made available. Having a "hidden" comment by "Jimbo eats dead babies" is not an option.
Sorry, but this is not quite correct. For the moment Parsoid does not do any rendering except for VisualEditor. If Parsoid in the future (any version) replace our current parser it will have to pass the current tests. If you or anyone else has edge cases or corner cases you deem important for proper operation please report them. Don't just claim some such cases might exist. Just double checked whether there are any problems with math, but I can't find any. You can check out w:no:Sak:Uv2sbxaehl6g4a0m. Even if you type <math it will open the math editor as expected. If you change to wikitext editing you can copy-paste complete formulas. Diffs exists, undo exists, revert does not. I don't know of anyone that has said "hide" is "revert", but feel free to provide a link. It should be possible for an admin to delete a post, it is nothing more than a contribution, but I'm not an admin on neither enwiki or nowiki and can't verify without creating a test environment. Perhaps Whatamidoing can clarify. Jeblad (talk) 20:37, 28 February 2019 (UTC)[reply]
I think we've misunderstood each other.
On Parsoid: (from above)
Izno, As far as my current knowledge carries, the plan right now is to convert Parsoid from Node to PHP and then make the Parsoid parser the new and one and only 'php parser' (there are various technical reasons for this) (Much as we switched from Tidy to RemexHTML). There are very few differences between the old and the new parser left and many of the differences that are there, are either edge cases, or in areas where we need to make changes to the old renderer as well (video content comes to mind). A lot has been learned over the past years about wikicode and how it works (and hundreds of testcases have been added) making it possible to do these kinds of transitions, where before this was practically not doable. —TheDJ (talk • contribs) 13:31, 26 February 2019 (UTC)
On "hide" v. "revert"
mw:Special:Contributions/Clump has probably done deal with more vandalism and spam in Flow pages than anyone else in world (literally). I'm not sure whether User:Clump would agree with the claim that it's harder to deal with vandalism on a Flow board than on a free-form wikitext page. You click a button called "Hide" rather than one called "Undo", but it's otherwise pretty much the same idea. This user talk page shows a large number of reversions and deletions, if you want to see how it appears in page history. Whatamidoing (WMF) (talk) 19:29, 27 February 2019 (UTC)
@Whatamidoing (WMF):Both hide and undo don't do anything about the fact that a given topic went to the top of the talk page because it had interaction.
In addition if a vandal creates multiple bad edits, rolebacking on normal talk pages batches those edits together and it only takes one click to undo multiple edits. On flow such batching doesn't happen and that massively increase the amount of work to deal with the vandalism. ChristianKl ❪✉❫ 16:32, 8 March 2019 (UTC)[reply]
And by "diff" and "undo", I mean the ability to compare and revert the state of the entire discussion between two different times. I frequently use "undo" to undo multiple consecutive edits on article pages; I rarely USE undo on Talk pages these days, as the vandals I interact with don't use or vandalize talk pages, so I only use "undo" to revert my own edits when I attempt to fix things, and fail miserably.
As I reported to Whatamidoing on MediaWiki, as far as I can tell, copy/paste works there within Flow, at least for simple attempts. And anyone is welcome to reformat my use of < blockquote> quoting other threads from this section to display properly. I don't think it can be done completely, but it can certainly be done better. — Arthur Rubin(talk)22:09, 28 February 2019 (UTC)[reply]
I think this is a good question to lay out some of our uses of pages for talking, just in case the WMF doesn't know what those are:
Discussion, clearly (within the bounds of WP:NOTFORUM)
Straw polls 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. — xaosfluxTalk06:31, 24 February 2019 (UTC)[reply]
It is important to me that 1: you don't censor discussions. Assuming you do anyway, it is important to me 2: that you don't conceal the history. Assuming you do anyway, it is important to me 3: that you don't conceal the fact that the material was censored at all. Assuming you do anyway, it is important to me 4: that you don't copy the worst dishonest practices of social media, such as 'shadow bans' and mechanical downvotes. But I have in mind that nearly every computer science major in the world has the same dream, namely to work for a social media company doing dishonest things for dishonest money, and the rest are as dead as Aaron Swarz. Past that point, there's really nothing for people to do but hope there is a decent mirror of the old Wikipedia somewhere. Wnt (talk) 06:45, 24 February 2019 (UTC)[reply]
For article talk pages, help desks, or WikiProject talk pages, having the exact same rendering as on the articles themselves is crucial so article text and formatting errors can be discussed properly without unnecessary technical barriers. —Kusma (t·c) 11:08, 24 February 2019 (UTC)[reply]
^^^This. Bug-for-bug compatibility with final article rendering is an absolute requirement, just like it is with "Show Preview". (Insert your own VE snark here.) —Cryptic12:58, 24 February 2019 (UTC)[reply]
I think this section by Alsee over at MW sums up the utterly wrong approach by most of the developers with obviously no encyclopedial experience, that created LQ and FLOW. WP:NOTFORUM, full stop. The talk pages have to be made in a way, that enhances the quality of the articles, it's the only reason for them to exist. Grüße vom Sänger ♫ (talk)12:40, 24 February 2019 (UTC)[reply]
mw:Special:Contributions/Clump has probably done deal with more vandalism and spam in Flow pages than anyone else in world (literally). I'm not sure whether User:Clump would agree with the claim that it's harder to deal with vandalism on a Flow board than on a free-form wikitext page. You click a button called "Hide" rather than one called "Undo", but it's otherwise pretty much the same idea. This user talk page shows a large number of reversions and deletions, if you want to see how it appears in page history. Whatamidoing (WMF) (talk) 19:29, 27 February 2019 (UTC)[reply]
That's missing the point. At enwiki, trolls would love the opportunity to leave permanent reminders of their presence. A trail of "This post was hidden by Hiàn (history)" is the opposite of DENY. Flow does not allow refactoring of someone else's comment to fix a simple blunder like an incorrect link. Refactoring should be rare, but the ability to fix problems is the whole idea of a wiki. Johnuniq (talk) 23:50, 27 February 2019 (UTC)[reply]
Thanks for the correction. It must have been more than the lack of an edit button that led to my misunderstanding. Perhaps I only looked at a very early version. Johnuniq (talk) 03:42, 28 February 2019 (UTC)[reply]
The Edit button is in the ••• menu for each comment, labeled "Edit". There's been so much misinformation spread about Flow (like "it can't do math equations", which wasn't even true in the alpha phase), that it's hardly surprising that people don't know what it actually can and can't do. NB that I'm not wild about some of the current limitations. For example, I would have liked to see phab:T113902 done years ago. There's nothing inherent that prevents this; they just haven't put the time and effort into building it. The things that annoy me tend to correlate with decisions to depart from the initial design, often for immediate practical reasons. But I've been using it for a couple of years now, and I don't hate the current version. There are even a couple of features that aren't available on a wikitext page and that I really appreciate (like watchlisting a single discussion thread, and getting automagic cross-wiki Echo notifications if someone replies). All that said, if something like that truly were wanted by all the communities, I'm not sure that we would get exactly Flow anyway. In addition to the inevitable bitrot problems, I gather than some of the devs are unhappy with some of the architectural choices in the past, so even if everyone said that they loved it, it might be due for a major re-write. I'd cross "having the current version of Flow everywhere" off my list of things to worry about. Whatamidoing (WMF) (talk) 04:07, 28 February 2019 (UTC)[reply]
Aargh! You changed my post! ;) There are several misunderstandings about Flow and how it works. It is rather strange, as it is pretty obvious when you start poking around in a thread. Jeblad (talk) 10:08, 28 February 2019 (UTC)[reply]
So the WMF is still making the utterly false claim that "hide" does the same as "undo" for vandal fighters? With "hide" one can hide one edit, by one person, in one topic, at the time. Undo is often used to revert a whole series of edits, sometimes by multiple editors and across multiple "topics" (sections), in one go. O course, Flow doesn't even have a good "diff" across multiple edits, so this may be hard... Fram (talk) 10:56, 28 February 2019 (UTC)[reply]
What this question means: This appears to be the most confusing of the original five questions, so let me try to explain. If you come up with a better way to phrase that question, then please feel free to update it. What that team seems to be looking for is a sort of essential-qualities checklist. So, for example, we (i.e., we the editors, not them-the-devs) want to know who said what, when they said it, whether anyone's been messing with it since then, whether they said this before or after they screwed up our favorite article, etc. Any system that doesn't do that is missing some essential quality. Feel free to state the obvious ("Wiki discussions have to happen on wiki"), and to identify things that aren't important (e.g., does it really matter whether the article assessments are on the same page as the discussions?). Whatamidoing (WMF) (talk) 04:31, 28 February 2019 (UTC)[reply]
Sometimes you want to point to a statement in a previous post, and discuss that, but without naming the user who post the statement to avoid spiralling down into a discussion about person. It could be done by abusing the fragment of the URL (the tingy after the hash mark) and using Javascript to search for the string. It is even possible to do a fallback to a LSH form if it fail. This can even be generalized somewhat and the whole block level element containing the found string could be highlighted, not just the found string. If the whole post is highlighted, and a date-time-group (dtg) is found, then the revision could be found and highlighted, not just a single element. Such a system could even be generalized to point into other pages, both subject pages and talk pages. Jeblad (talk) 21:43, 28 February 2019 (UTC)[reply]
I have many things that I recognize as integral parts of a wiki discussion. For example, it should be easy for a newcomer to participate in a discussion about an article. So talk pages should, well, have an easy to use interface. Second, it should be easy to moderate discussion so that they fall in policy. Our current talk page system allows for easy moderation as RC patrollers can remove potentially harmful comments and admins can remove them from the history. Finally, talk pages should be easy to navigate for anyone. People use mobile and desktop. Something similar to but not exactly like a forum, where each discussion on a talk page has its own subthread and only the past few comments for a topic are visible (of course with an option to override so that admins can evaluate long discussions in search of a consensus. AwesomeAasim07:24, 1 March 2019 (UTC)[reply]
Don't scare the newbs. I find a civil discussion is enough to keep a person engaged but I hate it when a new editor tags me in something and I have to point out why it's incorrect Oaktree b (talk) 16:39, 7 March 2019 (UTC)[reply]
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.
I am not suggesting to deploy any set of rules or format that should be followed. However, I think all editors should be made familiar with discussion procedures (especially in the contentious ones such as AFDs, ANI etc.), to ensure smooth and effective conversations withOUT abusing. Newcomers should be guided through properly and taught the importance of talk page discussions and the techniques they should be using. I know there are several policies and guidelines already present to minimize heated disputes, but I think a much clearer, focused and general amendment would be a good starting rule of thumb, which would be required to practice in order to show civility.
Wikipedia is for everyone and I understand that not everyone gets to learn properly and sometimes get the right opportunities. Inexperienced users and IPs showed be given chances and should not be expected with prior knowledge. As a disclaimer, I myself is not that experience, hence I leave this discussion open as of now. If someone has some bright ideas to drop by, go for it. We need to think long-term here.
Surely you all remember the disaster of Flow? I believe it was one of the times where an en.wiki admin threatened to block a WMF staffer. If the community actually prefers things to stay generally the same, that should be heard and should be a possible outcome. Generally the biggest issue people had with talk pages was replying, and that issue is now handled via a script if people want it. Just make reply-link a gadget that can be enabled via preferences. Problem solved and saves you likely millions of dollars in stafftime. TonyBallioni (talk) 05:42, 24 February 2019 (UTC)[reply]
The status quo is a non-starter (IMO) per WP:Accessibility. That said, it's not not an option. The discussion above doesn't speak to solutions--a fact I noted elsewhere--just problems that people have with the status quo. --Izno (talk) 06:09, 24 February 2019 (UTC)[reply]
Because there are things wrong... as noted above... (accessibility of talk pages is garbage, newbies don't figure them out, and the list goes on). As I said, don't fixate on solutions (or past solutions), comment on the issues that you have with talk pages. (Or do as DocJ did and comment on the good things about talk pages.) --Izno (talk) 06:27, 24 February 2019 (UTC)[reply]
Even if the talk pages were different, do we have evidence that that will help newbies figure it out? I often feel that some do not even realize that talk pages exist and simple keep repeatedly adding the same text over and over. Text that they have obviously written in Microsoft word and are simple copy and pasting and are only here when making that one copy and paste. Unfortunately you see this in a number of school efforts. This would be addressed by further coaching for their instructors rather than changing WP. Or by having scripts that help guide students when they hit "publish such as proposed here.Doc James (talk · contribs · email) 06:34, 24 February 2019 (UTC)[reply]
Well, of course there are things wrong, but there are things that would be wrong with any system. The question is whether or not the benefits of fixing them and moving a new system is worth the disruption of the change. This is the problem every organization goes through when discussing technology changes, and why you still have some major retailers operating on computer systems that use 1980s technology. Right now, the current system works for its intended purposes and generally works well. There are maybe minor fixes here and there that can be made, but in general the system is not in need of a drastic overhaul that would justify the disruption such an overhaul would cause. TonyBallioni (talk) 06:38, 24 February 2019 (UTC)[reply]
but there are things that would be wrong with any system: Right. But part of the point of this discussion is whether there are small things in the context of the current system that would get us better, like Enterprisey's reply script. Maybe that should be a global gadget? (And etc.) Flow is not necessarily the answer that the WMF is looking for this time. (I suspect something Flow-like will be an answer, given, again, the need for accessibility.) --Izno (talk) 06:56, 24 February 2019 (UTC)[reply]
Well they listed it as a “non-goal”, which is basically them trying to frame the discussion not to talk about what the likely outcome is anyway because they know how bad Flow ended up and that there would be resistence to it. By the status quo I mean nothing much gets changed and the basic structure stays the same. I’m fully aware that even if nothing real changes the WMF needs to point to something to say that they did something, so I’m sure they can find something minor to twiddle with on that count, but I actually like the existing wikitext format and think it makes a lot of sense for our project. TonyBallioni (talk) 06:24, 24 February 2019 (UTC)[reply]
The status quo is not an acceptable option because it imposes a barrier on editors who use a smartphone to access Wikipedia. Try using the mobile site or apps on a smartphone, and you will understand that it is difficult to participate with the current talk page system as a mobile user. While the vast majority of Wikipedia edits are currently done on a desktop or laptop computer, most web traffic is generated by smartphones (see Usage share of web browsers § Crossover to smartphones having majority share). The inaccessibility of the current talk page system contributes to systemic bias in Wikipedia, as it makes it harder for Internet users with no access to a desktop or laptop computer to contribute to Wikipedia. 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 [billion] mobile users" and "Almost three quarters (72.6 percent) of internet users will access the web solely via their smartphones by 2025, equivalent to nearly 3.7 billion people". — Newslingertalk13:11, 24 February 2019 (UTC)[reply]
Mobile view and the mobile app seem to be designed only for readers, with little concern for editors. If we want to turn readers into editors, this is where developers should try fix things, both for talk pages and non-talk pages. —Kusma (t·c) 14:28, 24 February 2019 (UTC)[reply]
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)[reply]
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)[reply]
The linked task on feature parity between the mobile and desktop views is very important. However, after trying Wikipedia'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)[reply]
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)[reply]
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. - Evad37[talk]11:03, 25 February 2019 (UTC)[reply]
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)[reply]
I've just tried Timeless for the first time, and I agree that a responsive skin like Timeless in desktop view offers a better user experience than the MobileFrontend on mobile devices. Timeless is not perfect, since it doesn't restrict the width of infoboxes (which stretches out the scrollable width of the article body on a mobile device), but I appreciate how both desktop and mobile devices get the same overall experience. To have a significant impact on editor recruitment and retention, the default skin needs to be responsive, full-featured, and fully supported. Special:Preferences is not available to IP editors, and a lot of registered users aren't aware of the option to use Timeless. — Newslingertalk10:40, 26 February 2019 (UTC)[reply]
I've been making a lot of edits from smartphones since just over two years ago and I can honestly say that the setup that works best for me is simply just using the desktop version (without any added responsive design), so at the very least there may be a difference depending on what you are used to: someone who started with desktop and simply switched to majority mobile usage out of necessity would likely be more comfortable with using the desktop view. It works very well for me on talk-page discussions (I am typing this on mobile, after all). Honestly, the big problem I have with smartphone editing is actually adding references, because if I replicate what I would do on a desktop, I need a tab open with the citation templates, and I need to switch back and forth between tabs to put in details from the references, and it's a total hassle because on my rather old smartphone the tabs reload if you are away from them for too long. What I would really like for this is a template that would let you put in just a bare DOI or an ISBN with page numbers as your reference, which could then somehow automatically be converted into a real citation template. But this is not an issue restricted to talk pages. Double sharp (talk) 03:37, 28 February 2019 (UTC)[reply]
Personally, I also prefer to use the desktop view when editing pages on a smartphone (even without knowing that the Timeless skin is an option). For me, this is because the desktop view is fully-featured, while many of the user scripts and gadgets don't work in the mobile view. I agree that both you and I are more comfortable with using the desktop view on a mobile device because we're already familiar with using the desktop view in a desktop web browser.
However, the desktop view is not user-friendly for smartphones. I'm not good at defining user-friendliness, so I'll defer to Apple's and Google's simplified human interface guidelines for mobile sites, which the desktop view violates in numerous ways. It has been over a decade since the original iPhone was released, and most smartphone users are familiar with websites and apps that are designed for smartphones. Providing a reduced-functionality mobile site/app (the current state of affairs) or returning to using the desktop view as the default mobile interface might not prevent you and I from contributing to Wikipedia, but it would discourage new smartphone users from contributing, and provide an inferior user experience to the majority of Internet users.
Regarding your citation template concerns, RefToolbar handles ISBNs and DOIs fairly well in my experience, and I usually don't need to switch to another tab except to double-check the generated citation template. For citations of websites, Citoid does an acceptable job of generating citation templates, and you can use it with the wikitext editor through the sidebar with the User:Salix alba/Citoid.js user script. — Newslingertalk20:46, 28 February 2019 (UTC)[reply]
Features that people would like to see retained in discussion pages
In my opinion it is important to look at what works well with our current talk pages. A few things:
The order of the posts generally stays more or less the same with newer threads lower than old ones. I dislike endless scrolling and when new comments adjust the ordering of the section. I find Facebook incredibly hard to use.
There is a history page such that one can easily look at all changes to a talk page since one looked at it last.
Content can be copied and pasted from the main article to the talk page and the formating remains the same. Thus one can remove large blocks of poorly done text to the talk for further work / discussion. People can than collaboratively edit the text added by a single user.
We have two main ways to edit (old way and visual editor), before introducing a third we need to be very careful as it will make thing more complicated and thus raise the barrier for entry for new users.
Moving text around and fixing it up is one of the features of our discussions that was already flagged as important 8 years ago in the discussions about our discussion systems: Keep talk refactoring possible. (It's still we have to repeat ourselves every couple years.) Nemo08:29, 24 February 2019 (UTC)[reply]
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)[reply]
The most important feature of the current discussion system is that it is extremely flexible, and the loss of that flexibility would have adverse effects on just about every type of discussion I can think of. Risker (talk) 08:23, 24 February 2019 (UTC)[reply]
m:Right to fork. It's not an option to start using any system unless the discussions keep being in the XML dumps, exportable and importable with ease elsewhere (and proven to be so). Nemo08:31, 24 February 2019 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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 Wikipedia talk page, and can be copied to/from other posts and the main Wikipedia pages. (Although this would also require major rewrite of some of the basic templates used in Wikipedia 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)[reply]
Threaded/nested discussions. A key difference of Wikipedia 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)[reply]
It's easy enough to delete old discussions/sections by simply deleting chunks of text, I've done it on my talk pages a few times for a clean up. I don't have to worry about html tags everywhere; select a block of text and delete. Cut and copy/paste also works well. Simpler is better IMHO Oaktree b (talk) 16:53, 7 March 2019 (UTC)[reply]
Ability to roleback edits on the page via the roleback interface that results in a page looking the same way afterwards as it did before. (Deleting and undeleting on flow pushes a discussion to the top of the history). ChristianKl ❪✉❫ 16:21, 8 March 2019 (UTC)[reply]
(A) Revive work on Flow, (B) try to design a new Talk replacement from scratch, or (C) consider improvements to existing pages?
C. Flow's design is irredeemably broken, and I have yet to see any suggestion for a new system that would credibly be a positive cost-benefit tradeoff vs the simplicity flexibility power and compatibility of existing pages. We should consider any proposals for improving existing pages on their individual merits. Alsee (talk) 07:16, 24 February 2019 (UTC)[reply]
C Agree gradual improvement to the existing talk page structure is much more likely to result in "success" than the other two options. Lots of improvements to talk still needed. And we can make the current system more accessible. Doc James (talk · contribs · email) 08:45, 24 February 2019 (UTC)[reply]
C - just git rm Flow now, just like you should have done five years ago in response to the community feedback. Flow has demonstrated the WMF's incompetence and ignorance regarding talk pages - they simply cannot be trusted with any wholesale redesign. MER-C11:17, 24 February 2019 (UTC)[reply]
C is the only choice. The problems that Wikipedia has are mostly social and cultural problems, which are traditionally extremely difficult to solve by technical changes. I very much hope the WMF won't waste more money, time, and (most importantly) volunteer goodwill by insisting on developing another non-starter. Also, what is the fundamental problem with (D) continue to augment talk pages by other means of communication (we traditionally have used mailing lists and IRC, and could just as well use additional forums if people need other means of engagement)? —Kusma (t·c) 11:19, 24 February 2019 (UTC)[reply]
C, it's the only valid option. No syntax will ever solve the behavioural problems. And it's of utterly importance, that all wikipages behave in an more-or-less identical manner, and can be edited the same way, so that the learning curve of editing is the same for talk pages as well as for the real stuff. Grüße vom Sänger ♫ (talk)11:32, 24 February 2019 (UTC)[reply]
C. It is never a good idea to use WP:TNT on something that isn't hopelessly irreparable. The current talk system should be made more accessible (especially for editors who use the mobile site or apps), but it's clearly working for many of its current users. — Newslingertalk12:53, 24 February 2019 (UTC)[reply]
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)[reply]
The Talk pages consultation 2019 page defined the status quo as "Leaving talk pages exactly as they are." That's not the same thing as improving existing pages, which gives context to the discussion in the "Why the status quo not an option" section. It's hard to quantify the meanings of "minor" and "drastic", but it's clear that most of the editors here prefer to use our current talk page system as a starting point for improvements. — Newslingertalk18:42, 26 February 2019 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
To add on to what I said earlier, I think a good middle ground could be enabling VisualEditor on talk pages, with discussion-focused enhancements. VisualEditor is by no means perfect, but it is pretty good by now and it is the best solution we have at this time (that would not require additional draining of donation $$$$) to how to make talk pages more accessible, especially to new contributors. Since the Foundation has on many occasions been unable to use common sense and take the most obvious hints, I should add that wikitext must always be an option on talk and other pages, and Flow or equivalent systems must not be enabled. — pythoncoder (talk | contribs) 16:05, 19 March 2019 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
The lack of search is certainly an issue but is (next) on the development roadmap. Endless scrolling isn't a problem as such, it's just a personal preference thing. I understand that a lot of people don't like it, but it's a very familiar concept for users of the popular social networks and search engines. Whenever I've used flow the replies have indeed been ordered chronologically - much more so than on conventional talk pages - but if there's a bug or a need to change the way things are ordered, then I'm sure that can be fixed/developed. In short: none of these are reasons to discount it as a viable option.
I agree that Flow (I suppose I should called it Structured Discussions now) isn't the right fit for every process that exists on talk pages and there would need to be more development, or alternative solutions, for those. Using flow for discussions doesn't mean that other tools / templates can't be used in places where an ordinary structured discussion doesn't fit the bill. As is said below, it's not a binary choice and there will always be special cases that need a different approach. WaggersTALK10:42, 28 February 2019 (UTC)[reply]
@Waggers: Aside from the shutting-out of editors from vital processes, I think SD could have its place, but given the concerns that many other editors have (e.g. wanting to view diffs of a whole page), it would likely be more pragmatic to improve the current discussion system until it has a more graphical interface that's as easy to use as SD's.
SD certainly works in some cases (e.g. on the MediaWiki wiki, where most of the community processes and many of the talk pages are only frequented by developers), but as far as I can tell, the overwhelming consensus on this page is that it would be a bad idea to introduce something radically different from the current discussion system, regardless of how idiosyncratic MediaWiki's discussion system was to begin with. Jc86035 (talk) 11:32, 28 February 2019 (UTC)[reply]
I believe this is flawed as it assumes there is something unique to posting on a talk page. It is not. Unless we turn off wikicode editing on all pages users will be exposed to wikicode. Jeblad (talk) 11:39, 1 March 2019 (UTC)[reply]
None of the above This makes the assumption that these are monolithic systems and/or binary choices. But they are not and should not be treated like that. MediaWiki is a highly layered and modularized piece of software. Deciding whether it is more efficient to adapt Flow or to start from scratch is a decision that should be made based on the criteria you want to reach. Defining your criteria is more important than fretting over a name of an extension that you have a negative feeling about. It's a distraction. What most people are saying here is: "I want less of what made Flow bad, and more of what makes wikitext good". But really, everyone already knew that part. Please fill that in with more details (some of you have btw. props). —TheDJ (talk • contribs) 12:15, 26 February 2019 (UTC)[reply]
C. Making enterprisey's reply-link available to new users by default would solve the minor concerns that seem to be at issue here (people who have issues with technology participating in talk page discussions). Natureium (talk) 14:53, 26 February 2019 (UTC)[reply]
* None of the above, second TheDJ on this one. (As a side note; it seems like some of the users commenting on Flow never actually used it.) Jeblad (talk) 11:31, 1 March 2019 (UTC)[reply]
C, and definitely not A. And yes, I have used Flow extensively when it was available on enwiki, and looking at it now at MW or at the French wiki (which has some 2000 Flow pages, but 90% of those are autogenerated by a buggy Flow manager and never actually used), I see the exact same problems it had back then. Flow is somewhat easier (or at least gives that impression) at the start, but very soon the major deficiencies become apparent. This includes things like undoing, viewing multiple edits at once, searching, subsections, making it clear which edit you actually reply to (if not the bottommost in the topic), splitting or merging topics, hatting part of a topic (basically, any structuring of a discussion which doesn't exactly meet the pre-defined basic system of the very poorly named "structured discussions"), using admin tools on Flow pages (no idea if the problem persists, but hardly anything worked with Flow, e.g deletion or moving), the automatic substitution of templates (which meant that an update to a talk page header template didn't perpetuate to all talk pages that used that template, only to templates introduced from then on or page headers edited from then on; and which also broke the notifications for many editors by simply adding 10 or 15 characters to a Flow page in a way that any vandal could have done, no extra tools needed), ... Basically, whatever is decided, it should be anything but Flow. Fram (talk) 12:34, 1 March 2019 (UTC)[reply]
C, please for the love of bleep, keep the current interface as-is. It's quick and dirty, but works well. I have no problem improving it, but don't make users re-learn how to use the wheel. Oaktree b (talk) 16:58, 7 March 2019 (UTC)[reply]
C - We need 2 things - VE & Mobiles VE needs be expanded to talk pages to make it a viable equal editor. We also need a mobile interface that can be used to edit the talk pages effectively. These two would let us keep the good parts of the talk page system and fix about 70% of the negatives. Nosebagbear (talk) 22:44, 9 March 2019 (UTC)[reply]
The point of the consult is the problems. Tell the developers what the problems are with whatever form of discussion methodology. This section doesn't do that. See also TheDJ's comment. --Izno (talk) 16:22, 10 March 2019 (UTC)[reply]
Flow was designed after a consultation with some people about what was wrong with talk pages. They developed a new tool which solved some of these issues. What they had totally forgotten, was asking or considering what was right about talk pages, which features were essentials which had to be kept. So Flow did some of the things they set out to do perfectly (autosigning, and probably one or two others I forget), and did most things current talk pages do well a lot worse (or not at all). Reminding the people behind this survey not to make the same mistake again (whether it is by reviving Flow or by starting again from scratch but with the same mindset) may not be what they asked, but it is something they need to be told. The DJ said "What most people are saying here is: "I want less of what made Flow bad, and more of what makes wikitext good". But really, everyone already knew that part.", but this sadly probably isn't true, considering how some people from the WMF handled this from the start ("status quo is not an option") or in this discussion (oh, but "hide" in Flow is the same as "undo" in wikitext, you know...). Never assume that the WMF already knows something. Fram (talk) 09:25, 11 March 2019 (UTC)[reply]
what was right about talk pages, which features were essentials which had to be kept This section doesn't do that either, though I think that also is a Good Thing to do. (You'll see my comment earlier about the use cases that need to be enabled/protected by any future talk software, so I'm not taking the position that the WMF already knows something.) What are the qualities of Good and what are the qualities of Bad? Certainly those should be answerable without this section. "I like wikitext" falls into the ILIKEIT trap; "I like wikitext because: information density, familiarity for old hands, and etc." falls into the "Good qualities" bucket instead, and while I see above some of the latter, the intent of the section is clearly just to decide the former, which is categorically Bad system (non-)development. --Izno (talk) 12:58, 11 March 2019 (UTC)[reply]
You'll see in my post that I identified a lot of things which were bad with Flow (not thngs which would be nice to have in an ideal world, but things we already have in wikitext). These obviously fall into the "good qualities of wikitext"/"things any new or improved system should have". And while this section isn't necessarily about that, it does send out a rather clear message that simply reviving Flow and tinkering a bit with it is not the solution people are waiting for. What most people here want is a tool which keeps most of the functionality of wikitext talk pages (dense, flexible, manageable, traceable, searchable, ...) with some improvements (solutions for autosigning, autoindenting, and some combination which allows archiving while maintaining links). We need a lot of what we have and a few extra bits, not the other way around. Fram (talk) 13:12, 11 March 2019 (UTC)[reply]
C: I think the main problem with the existing talk pages are with being able to follow the thread of comments, and identify who's making the comment and to whom they are responding, if anyone. To that end, I have the following suggestions.
Auto text at the beginning of each comment identifying the user, and, where appropriate, to whom they are replying: could this be done by modifying the signature feature? Could a respond to option be added to the edit page that allows you to select the name of users who have already posted a comment? Or even their specific comment? Could a background color be assigned to each users comments?
Limit new posts to the end of the section: Could a bot automatically move a new comment to the end?
People that do what your last suggestion requests are the root of the problem. Correct talk page etiquette is to place your reply immediately after the one you are specifically replying to, indented one notch relative to that comment. An unindented comment at the end of the section is not a reply to any previous writer. —Kww(talk) 04:29, 17 March 2019 (UTC)[reply]
"Features" that people really *don't* want on discussion pages
Inflexibility. "Discussion" pages are used for an enormous variety of discussion types, many of which are ad hoc and fairly undefined. Any redesign must be equally flexible.
Any discussion page that restricts the use of specialized text software (e.g., math notation) as well as wikitext is a complete non-starter, as it defeats the purpose of the page.
Seems to me we had this conversation a few years ago, and instead of paying attention to what editors said they wanted or needed, we got Flow. Don't do that again, please. Risker (talk) 08:03, 24 February 2019 (UTC)[reply]
Adding:
No upvote/downvote functions. They're antithetical to the "equity" that is one of the objectives.
Any system where it is not possible to provide a direct and permanent link to a specific revision of the discussion page (i.e., every single element of the page is exactly as it was at the time of that revision). Ability to accurately and easily reconstruct the progress of complex discussions is required on a regular basis.
Having different kinds of software for different kinds of discussions increases complexity and is antithetical to the equity this project seems to feel is a major objective; it creates ghettos of discussions, with only the most "advanced" users being able to participate effectively across multiple types of discussion platforms. I cannot emphasize this enough.
Software should never be used as a tool of social control. That means no shadow banning, no ability to "hide" the posts of another user, and so on. Frankly, I don't trust the WMF to understand enough about the culture of any of the projects well enough to develop social behaviour modification software - and I say that as someone who generally gets along pretty well with most WMF staff. Risker (talk) 08:27, 24 February 2019 (UTC)[reply]
Three more:
Pointless or worse than useless UI changes - including but not limited to:
Excessive whitespace - anything that reduces the information density of current talk pages is unacceptable.
Anything that looks remotely like a discussion forum or the recent idiotic Reddit redesign.
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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, so I don't exactly have any faith in Wikimedia to do anything. I've been on Wikipedia 15 years and I can't work out where the fuck I'm meant to put this comment and frankly I don't care. You're all wasting your time. ——Pengo02:33, 26 February 2019 (UTC)[reply]
Pengo, that would be me. And I can get those diffs (links) any time I want on a wiki page. Go to the history of the page, select any point in the revision history, and click on the date/time. Voila - direct and permanent link to a specific revision. Now, admittedly, if someone changes an unsubsted template in the period between the revision and the lookup, that will be changed, and I find that okay today and would find it okay after any changes. I just know that with LiquidThreads and Flow, this was definitely not possible. You can discover more information about diffs and links here. Risker (talk) 03:11, 26 February 2019 (UTC)[reply]
Pengo is probably talking about the fact that if you click a permalink to an old revision, you will get the correct wikitext, but it might not be rendered correctly because, for example, some templates have been deleted. Or, consider the recent upgrade to the wikitext parser which broke several talk pages with invalid signatures and so forth. However, your point is exactly correct, namely that we very rarely care about how a page looks—we need a permalink to a discussion showing what text was posted. Johnuniq (talk) 03:44, 26 February 2019 (UTC)[reply]
Things that no one wants to add? A new interface. I had to chuckle when I saw this notification on my talk page (which still works quite well, even though I'm not around much anymore). It seems futile to try to fix an editing problem by introducing a third editing option, especially given the data that shows that the Visual Editor did exactly what we expected it would do: reduce user retention and involvement. Wikitext is a remarkably flexible solution, and if someone would work on how to make a decent phone/tablet based interface that edited it, most of the problems would be solved.
For what it's worth, when they try to turn this on, I'll be happy to have my admin bit turned back on so I can turn a new talk page editor off for you again.—Kww(talk) 05:21, 27 February 2019 (UTC)[reply]
This has turned into "I don't like this, that, and those things, and I'm so important you must listen to me!". It is better to discuss actual solutions to actual problems than state antipathies for whatever you dislike. Jeblad (talk) 12:51, 4 March 2019 (UTC)[reply]
Let me quote For what it's worth, when they try to turn this on, I'll be happy to have my admin bit turned back on so I can turn a new talk page editor off for you again.[4]Jeblad (talk) 15:44, 4 March 2019 (UTC)[reply]
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)[reply]
Off-wiki chat tools should never be private companies demanding terms and conditions so people can have a say in Wikipedia. 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 Wikipedia 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. [5] 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)[reply]
@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)[reply]
You may be interested in looking at https://discourse.wmflabs.org However, I believe that's out of scope for the current consultation (because it's off wiki and requires e-mail. The team believes that being able to use your SUL account is important for transparency, and that not requiring e-mail is important for privacy). Whatamidoing (WMF) (talk) 19:42, 27 February 2019 (UTC)[reply]
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)[reply]
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)[reply]
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 Wikipedia 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)[reply]
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)[reply]
I think this is an important and oft overlooked point. The great thing about talk pages is that each page has them. The worst part about talk pages is that an non-visited talk page is less efficient than a more visited and more general forum. Personally my hope has always been that eventually it would be possible to move topics between Talk pages (without loss of history) and possibly even filter all topics, based on criteria like we have in Recent changes. That would help move things from 'fora' like pages to 'subject' pages and vice versa, which I think would help, especially newbies, a lot. Seems like a longer term issue though there are more important things to solve before this gets tackled. —TheDJ (talk • contribs) 12:24, 26 February 2019 (UTC)[reply]
Every talk page has a Page Creator and a Latest Editor (available in “Page information”) A system generated “Ping” to one or both of them for a new topic that is not directed to to another user should elicit a response in many cases. Downsize43 (talk) 02:12, 27 February 2019 (UTC)[reply]
A section tagging system might work well for this, for example every RfC is tagged as #RFC; discussions awaiting a response #Open, move discussions #Move. Discussions related to a certain Wikiproject or topic could be tagged as well. This would draw attention to sections awaiting responses, and also make it easy to sort through the archives to find relevant past discussions. (I'm not proposing that we use #hashtags, it's just an example.) –dlthewave☎18:00, 1 March 2019 (UTC)[reply]
This can mostly be done by filtering on namespace. Tagging can be an idea, but then users should be able to subscribe to specific tags. The tags could really be anything, as long as they are obvious. I would like them to reflect topics, and not processes, as the later would create a lot of noise. Still allowing tags to be used for administrative purposes could be interesting. Jeblad (talk) 01:18, 3 March 2019 (UTC)[reply]
This issue also applies to places like Category talk and File talk pages, in which there are so many that nobody looks at the majority of them. Maybe there could be a bot where WikiProjects select articles relevant to their topic that they want to monitor, and the bot posts an alert to a centralised discussion board for that WikiProject, whenever a new section is added to the talk page of one of the project's monitored articles. That could work for articles - finding every File relevant to your project would be a lot more difficult though. – numbermaniac13:14, 11 March 2019 (UTC)[reply]
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 Wikipedia, 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
> could be nice, because it actually looks like you're pushing the text inwards. But I don't know if that would cause issues with HTML tags or anything like that. – numbermaniac02:47, 12 March 2019 (UTC)[reply]
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 ♫ (talk)12:03, 25 February 2019 (UTC)[reply]
@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)[reply]
@Jc86035: I couldn't care less but about such stuff as parsers or so, that's something we have those many high-paid devs in SF for, to deal with this menial tasks. I care about what I do now in the editor on screen, and that's just starting the paragraphs with 3 colons, that's all. Very simple, very easy to understand and to remember, if you did it once and thus get it. Introduction of such heavy nerdy stuff like HTML or any other more complicated stuff as colon, asterisk and hashtag will definitely not bring in more people on the talk pages (or anywhere else in the Wikiverse). I simply don't believe that an editor, that can manage dealing with templates and with tables should really be impotent in regard of indentation, that's just a straw men to promote the current pet-project FLOW. Indentation and autosign should be quite easy to implement, but nobody must work on it, because it jeopardises FLOW. Grüße vom Sänger ♫ (talk)17:03, 27 February 2019 (UTC)[reply]
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)[reply]
@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 Wikipedia. Jc86035 (talk) 13:55, 25 February 2019 (UTC)[reply]
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 Wikipedia 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)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
@Wnt: One of the main technical reasons for creating Flow was that there wasn't enough(?) formal code to make talk page discussions structured. Presumably, if there were standardized markers for the start (start of page, end of section header plus line break, new indent, discussion extension tag) and end (sig extension tag + any text until end of line) of messages, then it would be possible to distinguish different comments and add additional features like diff links and automatic notifications. So I think it might not be necessary to add anything to the front for an anchor or permalink(?) – if the parser knows where the start and end are, the anchor ID could be inferred from the end tag and placed at the front.
The biggest issue I can think of (that hasn't been mentioned) is replying to comments that have an outdent after them, although I don't think I've ever had to do that. Jc86035 (talk) 11:21, 26 February 2019 (UTC)[reply]
Ah, outdents -- THAT you could fix with any extra format character. You could make % match "% or the first eight left-margin characters from the post above". So you follow :::::::::* with %:* for a second bullet, and continue talking without breaking any semantics. The % would also bring the text back toward the margin, but because it's a different character you can think about ways to mark or shade it so that people remain aware they are in an outdent. What is more, the outdent character in this situation should always be applicable when it can be applied, which means that you could reprocess old wikisource reliably to change it over to this system, and you could automatically translate new contributions to the system with no loss of capability. Less reliable would be processing old source with an "od" template or manual comment, but there should be some options to make some fairly reliable less-than-AI decisions about that and have human editors yea or nay the output. Wnt (talk) 13:39, 26 February 2019 (UTC)[reply]
@Wnt: That sounds like a good idea. With 1-indent and 8-indent characters, editors modifying page source wouldn't be inconvenienced by any inability to use ((outdent)); and if all comments were automatically shown in individual divs by the parser (as would probably occur upon implementation of a nesting method without list items), it could be technically possible to implement arbitrary collapsing of parts of threads (similar to the implementation in Reddit's pre-redesign interface), automatic shifting of nested discussions to the left, etc.. Jc86035 (talk) 14:13, 26 February 2019 (UTC)[reply]
I don't necessarily understand all of that - by "individual divs" I assume you mean potentially boxing, or preferably just putting some line next to comments, which can probably be a good thing if done right. "Arbitrary collapsing" sounds dangerous to my ears, especially with Reddit as the comparison, because they routinely used collapsing as a way to hide comments and make it prohibitively difficult to see what people with disfavored points of view had to say. Wikipedia has "collapse" and "archive" and "hat" templates occasionally used to cover up comments some people don't like, and that is a chronic low-level disease ... I don't want to see it exacerbated by some feature that makes it easier to impose on someone. On the other hand, simply being able to collapse threads while reading as you prefer could be a good thing, even if as a generally non-Javascript reader I wouldn't normally use it nor miss it. Wnt (talk) 15:22, 26 February 2019 (UTC)[reply]
@Wnt: Yes, I was referring to collapsing while reading, not collapsing text for everyone (although that could also hypothetically be implemented, I guess). Jc86035 (talk) 15:35, 26 February 2019 (UTC)[reply]
I don't like introducing an outdent character to be used within the existing characters used to denote list items, because it would introduce an odd hybrid type of element solely for its appearance: list item that is outdented. I would prefer introducing a new character (like '>' suggested above) to mean "reply to previous comment" and then let the parser decide how to format the replies, much like how email clients will often provide special formatting for text blocks starting with '>'. It can decide when to outdent, and possibly even make this contingent on the browser's width. isaacl (talk) 15:46, 26 February 2019 (UTC)[reply]
@Isaacl: I wasn't proposing it would be just for outdenting - the idea was to provide a shorthand for the list item characters based on the previous line. I mean, there are a hundred ways to outdent the text on display, but my goal was to make the text more readable in editing mode.
Now to be sure, having characters to mark replies can work also, but this implies some kind of closing tag that has to be managed. I mean, anyone could write a template now so we do
My introductory comment -Wnt
((reply|That's a lousy idea -Isaacl
((reply|No, it's quite grand, you'll see -Wnt))
((reply|I agree, dumbest thing ever -Interloper
((reply|See you at ANI -Annoying Admin
((reply|Oh come off it -Wnt))
((reply|I'm so sorry, honest -- Interloper))
))
))
))
But how do you avoid counting all the )) at the end and hand fiddling with them to avoid breaking the syntax? P.S. I tried to get that to format in a line by nowiki, pre, blockquote, sticking a space in front ... I totally don't remember how to get a block of monospaced unfooled around with text, which it used to seem like happened all the time by accident. But it doesn't matter that much to express the confusion, though it looks less crazy in the source. Wnt (talk) 01:37, 27 February 2019 (UTC)[reply]
Just as a newline character denotes the end of a list item, it could also denote the end of a reply. The tricky part with your idea of a "shorthand for previous list nesting" character would be how to stop the nesting and specify how many levels to pop back up. If everyone replied to the initial :, for example, with %:, it goes on for six levels, and then someone wants to reply to the third reply, they have to manually figure out the right nesting level. Today, they can copy the prefix string for the comment to which they want to reply. In any case, personally I don't find the increasing length of the prefix in wikitext is a problem; it's the visual appearance on the page itself that becomes hard to read. isaacl (talk) 04:36, 27 February 2019 (UTC)[reply]
@Isaacl and Wnt: Alternately, if it's technically possible to keep the current indent syntax if signatures are changed (see below), maybe an abbreviated syntax could work, and then users would gradually transition towards using it as more people start to comment without editing whole sections.
== Section ==
>0: I'm Alice. ~~~~
>1* I'm Bob. ~~~~
would then be interpreted exactly the same as
== Section == I'm Alice. ~~~~ * I'm Bob. ~~~~
~~~~ indicates a generated signature with extension tag.
This would be more attractive than introducing a single character for indentation, since indenting in long conversations would become easier (with the use of a number to indicate the nesting level).
When used before a signature, the use of the current list item syntax would be interpreted as discussion nesting – unless preceded by the new-style markers, in which case it would be interpreted as list item syntax. This would make it more complicated for existing users, who would nevertheless not be forced to use the new syntax; but (with an inline comment/reply interface) would also make commenting less fragile and easier to use for users in general.
>0: could also be ;0: or :0: or something else; obviously this isn't really a concrete proposal.
It would also then allow greater separation between individual comments within the page source. Currently, the correct method is to bunch comments together (single line breaks), but since normally paragraph breaks are double line breaks, it would make more sense to use those on talk pages as well. This would also make it easier to use tables within comments without any sort of modification (i.e. just insert a single line break between >10: and the start of the table). Furthermore, it would also become possible to ignore any nesting errors within the current style of nesting, as long as the correct number of characters are used; and it would also mean users wouldn't have to repeatedly copy their indents just to make multi-paragraph replies. (The use of extension tags would also mean that only discussion pages/archives edited after the transition would have to be parsed specially, since pages without said extension tags would still be interpreted exactly as they're currently parsed.)
@Wnt: I don't think it would be necessary to count curly brackets. The software already handles nested lists without requiring end markers other than line breaks, so presumably a <sig/> could be interpreted in a similar way (but including the rest of the text until the end of the line, since otherwise it wouldn't have anywhere to go). Jc86035 (talk) 16:56, 27 February 2019 (UTC)[reply]
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)[reply]
@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)[reply]
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. — Rhododendritestalk \\ 14:40, 25 February 2019 (UTC)[reply]
@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)[reply]
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)[reply]
@Tryptofish: This would be a workable solution, although if the characters aren't actually changed, this wouldn't be able to provide any of the technical benefits associated with replacing the list item formatting; and if the new characters can't be typed on most keyboards it could be considered unduly disruptive. Jc86035 (talk) 11:02, 26 February 2019 (UTC)[reply]
On a technical note, depending on whether the parser would be able to tell different comments apart based solely on an extension tag generated by signatures, it might not actually be necessary to create new indentation markup. Basing the hypothetical upgraded discussion system on using signatures to change how paragraphs and list formatting are interpreted (i.e. if <sig/> occurs, then preceding colon indicates nested comment and not a definition list) might be technically feasible, and would not affect all but a few existing pages (possibly this page itself). However, it would be problematic, in terms of temporarily breaking most discussions occurring mid-transition, and familiarizing users with not copying and pasting said extension tag; and issues could still occur with mixing of list formatting and usage of actual definition lists within discussions (depending on implementation). Jc86035 (talk) 14:58, 26 February 2019 (UTC)[reply]
I oppose the proposal for the following reasons:
People use the existing markup in comments for a reason, such as numbered lists. And yes I deliberately used # in my response here.
Is this proposing to break :*# markup in all articles and archives? Or is this a proposal to issue blocks against editors who use basic wiki markup in discussions?
I see no reason to introduce a new character for this proposal. If this proposal goes forwards, I suggest that the obvious character should be the colon. At which point the proposal vanishes in a puff of silliness. Alsee (talk) 15:23, 27 February 2019 (UTC)[reply]
@Alsee: The proposal (in whichever form proposed above) wouldn't break the markup in articles and archives, except for special cases where the new markup conflicts with existing text (presumably fairly unlikely and resolvable through database searches + bot run); it would only mean that they wouldn't be displayed as "new-style" discussions. I think the proposal I commented just now (16:56) might be better, since it would also allow users to continue commenting using the current syntax. My original proposal wouldn't have prevented you from using the numbered list. My actual proposal text is probably too opaque, so I've tried to demonstrate it below. (All of the modified proposal styles would be valid at the same time.)
==== Current syntax ==== * I oppose the proposal for the following reasons: *# People use the existing markup in comments for a reason, such as numbered lists. And yes I deliberately used # in my response here. [[User:Alsee|Alsee]] ([[User talk:Alsee|talk]]) 15:23, 27 February 2019 (UTC)
==== Original proposal ==== <discussion type="vote"> \ I oppose the proposal for the following reasons: \# People use the existing markup in comments for a reason, such as numbered lists. And yes I deliberately used # in my response here. [[User:Alsee|Alsee]] ([[User talk:Alsee|talk]]) 15:23, 27 February 2019 (UTC)
==== Modified proposal, style 1 (the <sig/> tag would be generated by the four tildes) ==== * I oppose the proposal for the following reasons: *# People use the existing markup in comments for a reason, such as numbered lists. And yes I deliberately used # in my response here. [[User:Alsee|Alsee]] ([[User talk:Alsee|talk]]) 15:23, 27 February 2019 (UTC)<sig rev="885361658"/>
==== Modified proposal, style 2 ==== >1* I oppose the proposal for the following reasons: # People use the existing markup in comments for a reason, such as numbered lists. And yes I deliberately used # in my response here. [[User:Alsee|Alsee]] ([[User talk:Alsee|talk]]) 15:23, 27 February 2019 (UTC)<sig rev="885361658"/>
==== Modified proposal, style 3 ==== >1* I oppose the proposal for the following reasons: # People use the existing markup in comments for a reason, such as numbered lists. And yes I deliberately used # in my response here. [[User:Alsee|Alsee]] ([[User talk:Alsee|talk]]) 15:23, 27 February 2019 (UTC)<sig rev="885361658"/>
@Whatamidoing (WMF): Would commenting on the related Phabricator tickets be useful at this point? T6521 has been open for more than thirteen years, so clearly no one is just going to submit a patch that fixes it. (I've also commented on that ticket already, although not substantially. phab:T6521#3811832 and the surrounding conversation might be useful in the consultation, depending on the proposed software changes.)
The main purpose to begin with, anyway, was just to gauge whether users would put up with something like the originally proposed change. The results are probably skewed because I deliberately notified four users who expressed issues with indents, but it largely indicates that some users would probably only put up with something like it if there are clear benefits to current users (aside from the benefits to HTML purists and the developers).
On the other hand, the threads that Wnt started have basically become a thought experiment for other possibly technically feasible ways that the discussion system could be improved. While I don't know if this discussion would actually be useful, the general consensus on this page (further above) is that users would very much prefer improvements to the current system rather than anything else, so at least in that regard, any improvements would probably (but not certainly) have to involve modifying/extending/replacing the parser in some similar way. Jc86035 (talk) 04:12, 28 February 2019 (UTC)[reply]
Posting substantive technical and tech-adjacent information on mw:Phab tasks is always a Good Thing. (Don't post "votes" or "I want this" comments on Phab.) However, for the purposes of this discrete process, linking to it in a comment/summary/whatever on wiki is probably more effective than just posting in the Phab task. The team is reading what editors want to tell them, but they're not necessarily going to see comments on Phab (e.g., if they're not subscribed to that particular Phab task). Whatamidoing (WMF) (talk) 04:44, 28 February 2019 (UTC)[reply]
It is not especially hard to fix phab:T6521. Unless there are only data list definitions (dd, aka colon) all the way back [to] data list text (dt, aka semicolon) or a data list (dl, aka root semicolon), then it is not a data definition list, but the colons might still be interpreted as indentation (aka a div with padding). There are not many places where this simple rule fail. Not sure, but I wonder if it was hard to fix this back in 2006. Now there are several ways to fix this. Jeblad (talk) 12:54, 1 March 2019 (UTC)[reply]
@Jeblad: While it doesn't seem exceptionally difficult to fix that issue alone, in spite of the amount of time the issue has been unresolved, using pure list formatting is still somewhat unsatisfactory for a discussion system (for reasons noted elsewhere on the page), so I think I would prefer a more comprehensive overhaul. Jc86035 (talk) 10:56, 4 March 2019 (UTC)[reply]
I haven't read all the responses to this proposal, but adding a new character to be used as the sole character to be used for indentation in new discussions feels it would suffer from this problem (xkcd). -- Ununseti (talk) 06:37, 3 March 2019 (UTC)[reply]
@Ununseti: Funnily enough, I linked that exact page in the next section. The original proposal could result in existing users refusing to use the new system, but I think my later proposals wouldn't be as likely to suffer from that because the older system would be made compatible with the newer system. The addition of a visual/inline interface would also mean that new users would be more likely to use the newer system instead of the older system. Jc86035 (talk) 10:56, 4 March 2019 (UTC)[reply]
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 [User A]
Direct reply to first comment [User B]
Another unrelated comment [User C]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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 Wikipedia 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)[reply]
Speaking of changing pixel values ... I should note that Wikipedia 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)[reply]
@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)[reply]
This screenshot looks great, and is one plausible implementation of "A clear visual indicator of a comment's level of nesting" and "A clear visual indicator of where a comment begins and ends" that I described in the "What do others struggle with in your community about talk pages?" section. Visual indicators like these need to be shown by default to make talk pages more readable for new and anonymous editors (who don't know how to use or don't have access to user styles), and to encourage editors to adjust their indenting behaviors. — Newslingertalk13:06, 26 February 2019 (UTC)[reply]
@Diego Moya: I just suggested an answer to outdents in the straw poll above: have a new "outdent character" % match itself or the first eight indent/list characters from the preceding line. The % would maintain the list structure while also bringing the text back out toward the margin. Please say if you think this will work. Wnt (talk) 13:44, 26 February 2019 (UTC)[reply]
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)[reply]
@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)[reply]
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)[reply]
@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)[reply]
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)[reply]
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)[reply]
@Risker: I agree with this, although a "did you forget to sign a comment?" message (which could be enabled with a parser function, or perhaps auto-detection of other messages) would potentially have the same utility if the majority of edits on a page comprise addition of comments. Jc86035 (talk) 12:09, 26 February 2019 (UTC)[reply]
Risker is correct: something like AFD should be considered in-scope for this discussion. As for creating an entirely new type of page, it's worth remembering that Wikipedia invented the Talk: namespace. Back in the day, there was only one namespace. Article (or policy – there was no Wikipedia: namespace, either) content went at the top, and discussions (which got refactored when they ended) went at the bottom of the page. (Have a look at the old NPOV policy page for an example.) After that, people starting using subpages, so the discussion on that page would have been moved to Neutral point of view/Talk – still in the mainspace. At the time that we-the-editors first invented talk pages, I understand that there were no specialized page types. However, those certainly do exist now (e.g., JSON pages), and I believe that admins at most wikis have the ability to change the "content model" for most page types (although I think that CSS and JS are hard-coded content models). All of which is a long-winded way to say that if editors want to re-invent talk pages, then that could be considered. Speaking from the POV of the team that will have to implement it, it'd be really handy if people could frame ideas in terms of needs, like "I need to be able to quickly and easily see who said what, even if it's a new person who doesn't know how to get a signature or is using a keyboard that doesn't have a tilde" (Have you tried doing that on a mobile keyboard? I don't know how people manage it), rather than proposing specific implementations, like "Let's use this script". Whatamidoing (WMF) (talk) 19:14, 27 February 2019 (UTC)[reply]
I would support this as an optional feature within the existing interface, possibly enabled by default for new accounts. How difficult would it be to build a tool that counts the number of colons in the previous comment and adds one more colon? It could even outdent automatically when some predetermined limit is reached. –dlthewave☎18:06, 1 March 2019 (UTC)[reply]
(See video to the right.) One easy way to tell whether something is a talk-page-style reply: Check whether the previous line ends in a signature. If a user creates a new line after an existing comment (pressing enter), a script can add the correct indentation and signature at the end. This can help new users understand the syntax, while not adding any restraints. Users can delete the indentation or signature where appropriate. (The script itself is right now mainly for demonstration purposes. I put it together several days ago without spending much time on it, and I doubt it's anywhere near bug-free or suitable for widespread deployment.) (We'd also presumably need to decide on whether spaces are appropriate after the indentation, and whether : or * is preferred generally.) --Yair rand (talk) 19:52, 3 March 2019 (UTC)[reply]
I would like to flag up that ((Election box metadata)) is added to all political party articles talk pages and that reform to talk pages must not remove this functionality. doktorbwordsdeeds04:30, 26 February 2019 (UTC)[reply]
OMFG that's a kludge for the ages. You have to have a section on the talk page with this box so people can look up the two individual named templates for every single political party that contain two small items of text! What you ought to do is hold this information in an HTML comment at the beginning of the article, and have a Lua script open the wikitext and find the comment and parse the information from it. I don't know if you ever access election box templates so many times in one article this would cause a performance hit though. Another way (the way the WMF wants) would be to have Wikidata properties, though it seems very possible you might already have tried and found that project ... obstructive. Whoever they're here for, it's not us. Or, you could just have your election box documentation say very clearly that the template finds its data at location Template:X/meta/color, which is probably the best way. And for love's sake can't you find a way to put those two bits of text and any others you might later want into ONE page and just parse out whichever one you want when you access it? Wnt (talk) 15:37, 26 February 2019 (UTC)[reply]
@Wnt and Doktorbuk: As a frequent Wikidata editor, I think it would probably be possible to use Wikidata for political party colours (e.g. Liberal Democrats (Q9624) has the statement sRGB color hex triplet (P465) = FDBB30), although it would probably be more difficult to use in templates at this stage: a Wikidata-less system already exists; without a large abbreviation translation table I think you would probably need to type full article names to get colours; and there probably isn't a standard way to also specify background colours for internal purposes. But anyway, the ((Election box metadata)) template seems like it would be better as a ((Tmbox)) than a random talk page section.
@Wnt: Your Lua proposal wouldn't work, because Lua (to my knowledge) strips hidden comments from wikitext, and the module would have to load an entire talk page just to get the colour code. It would be much more efficient to have a big Lua data table storing all of the colours. Jc86035 (talk) 15:55, 26 February 2019 (UTC)[reply]
I have to say in this conversation there are references to technical things I don't understand (Wiki markup is fine, HTML is beyond me). As a proud and committed member of the tiny corner of Wikipedia dealing with election results, I want to speak up for us, and hope that we can be heard. doktorbwordsdeeds16:35, 26 February 2019 (UTC)[reply]
A big Lua table may indeed be more efficient ... depending on the size of the table, of course, which depends on the total number of articles involved. My gut instinct is to set up the system so that it can grow to an indefinite number of articles, because I'm the inclusionist nut who always thought Wikipedia could have billions of articles. ;) My recollection is that getContent() title field returns raw wikitext, but I haven't played with Scribunto in a few years. Wnt (talk) 01:22, 27 February 2019 (UTC)[reply]
The Wikipedia mobile app seems to deliberately conceal talk pages - a simple "talk page" link at the top of an article in the mobile app, exactly like on the desktop site, would do wonders. Making talk pages accessible on the mobile app, displayed and editable like normal articles, would do a lot to bring them to the attention of new users, if that's the goal. Certainly more so than a lot of more convoluted and disruptive schemes would. ∴ ZX95[discuss]06:28, 26 February 2019 (UTC)[reply]
I wish someone would just level with us. I don't use the mobile phone app, but I assume the concern from above is that mobile phone users are more naive and more vulnerable -- I mean, some guy from Pakistan makes a flippant comment on an article, his IP is publicly displayed, they pull up what phone that was, read the name and track the location by GPS, and before he finishes his tea he's facing an official or unofficial execution. But if WMF would just say what their thinking really is it would spare gigabytes of why is the mobile version crippled? moaning. Wnt (talk) 13:51, 26 February 2019 (UTC)[reply]
Wikimedia is interested in many things. I think you meant the Wikimedia Foundation, which is one entity among many, or perhaps more specifically one of its teams or product managers. Nemo18:19, 26 February 2019 (UTC)[reply]
Then WMF should reallocate their developer-hours from "Flow 2" to making notifications etc. work on mobile. I've read that Talk: is unacceptable because it's not accessible (no further details given). Accessibility is important. By all means, add whatever buttons and menu options would make Flow 2 easy to access. Then link them to the existing talk pages instead. Job done. Certes (talk) 18:57, 26 February 2019 (UTC)[reply]
In my opinion, bringing the mobile site and apps to feature parity with the desktop site (including notifications) should be a higher-priority project than improving the talk pages. However, I don't really know how the WMF is organized. The WMF might have different teams with specialized skillsets for mobile and web development, and these projects might not be competing for resources. I've stated that the current talk system is not acceptable on mobile devices because the lack of the ability to create and edit comments in-place without unnecessary scrolling and positioning makes it arduous for mobile users to participate in discussions. — Newslingertalk20:06, 26 February 2019 (UTC)[reply]
This looks like a significant improvement over the current MobileFrontend, and I look forward to seeing it implemented. Per-comment handling would improve the talk pages even further for mobile devices, but this looks good for a first iteration. — Newslingertalk20:25, 27 February 2019 (UTC)[reply]
I use the mobile website, not the app, and I've never had trouble accessing talk pages. My main concern is that indents do not work well on a small screen: Comments that are indented seven or eight times become increasingly tall and narrow, and in some cases they squeeze down to one character wide. –dlthewave☎13:08, 1 March 2019 (UTC)[reply]
Collapsed proposal by a sock account. Feel free to reopen this section if anyone sees further discussion as valuable.
Make the mainly trafficked IRC channels logged publicly, and the archives clearly navigable from Wikipedia.
This would make them reserved for Wikipedia business, and to make all Wikipedia business of the wiki model, which is to publicly document everything.-Usergnome (talk) 10:40, 26 February 2019 (UTC)[reply]
Honestly, I thought people went to off-wiki channels mostly to plot cabalistic actions that wouldn't be logged... still, having at least one logged channel for WP business would fill a niche, so it's a good idea as far as it can go. Wnt (talk) 13:46, 26 February 2019 (UTC)[reply]
@Natureium: To my understanding, the consultation is supposed to be about communication, but is named after talk pages because the main goal is to improve talk pages. I think this is somewhat relevant. Jc86035 (talk) 15:58, 26 February 2019 (UTC)[reply]
What purpose would this serve for the overall community?
More importantly, what do you propose is done to protect users privacy in order to comply with Wikimedia’s current privacy policies and requirements? Unless every user is sufficiently cloaked (and it is my understanding that even that does not hide your IP address or other potential identifiable features) logs would have a significant amount of PII that most editors are not qualified to access.)
Are you aware of Freenode's policies?
And finally, as we do not currently require editors to be identified to chat or idle in #wikipedia-en, how would you suggest we deal with impersonation?
Since I thought it was probably a good idea, to some extent, I'll try answering those. 1) The purpose might be primarily to have a fast reaction for wiki level events ("black vagina.jpg" is blocking my view of the Main Page ... I still remember that one. ;) Or high level admin-on-bureaucrat-on-dev wheel wars!) 2) logs would show who did what when so the procedures could be debugged ... though I still think everything important would probably duck out of there 3) I don't see why an IRC log would have to contain anything but screen nicknames and comments 4)no ;) 5) disclaimer that screen names are meaningless and don't necessarily represent anyone. Wnt (talk) 01:48, 27 February 2019 (UTC)[reply]
PS, as a debug instance ... with current wikitext, what is the right way for me not to have a bullet point in front of my post, but be responding to Usergnome's bullet point? I tried adding bullet points in front of his #s and replacing the first colon in his final ::, but that makes his post misaligned with itself, while having a separate * would be two bullet points. Wnt (talk) 01:52, 27 February 2019 (UTC)[reply]
You should use a regular colon instead. "Copy previous indentation and add one symbol" has its exceptions, but not here. There are no really good ways to reply with a bullet point and have a list in your reply without giving your signature its own bullet point, so this is an okay result. Enterprisey (talk!) 03:42, 27 February 2019 (UTC)[reply]
Oh sorry, I didn't mean just what I should do - I meant for Praxidicae also. That post starts with *, then #, and ends in :: because otherwise it would be a bunch of bullet-points. After that my reply *: made a stray bullet because the * is already lost, but what can the first poster do to put everything under the *? Wnt (talk) 10:15, 27 February 2019 (UTC)[reply]
See Help:List § Continuing a list item after a sub-item. The third example and the one below it that use pure wikitext markup aren't ideal semantically, since it doesn't continue the bulleted item after the numbered list, but is less verbose (and probably more friendly to some) than using templates or HTML. Typically, I'll just introduce a new bulleted item and put my signature there, as Enterprisey suggested. isaacl (talk) 17:01, 27 February 2019 (UTC)[reply]
With regard to your answer to number 3, wnt I'm afraid you're misguided about how IRC currently works. As far as 5, it's still highly problematic as people will still take it at face value and it gives even more reasons for trolls to impersonate others as they often do on IRC. I'm not sure why there's such a concern, for example, as to what goes on in #wikipedia-en (which I'll note is a public room for anyone thinking it's a cabal) for example, particularly as the proposer isn't even a participant in the chat itself to my knowledge and if they were they'd know that virtually nothing of value is said in that room that isn't also on-wiki but creating a public log would jeopardize privacy of many people since it's not oversightable, which brings me to another point. What do you, Usergnome propose as an action plan to deal with oversightable information that is posted in logs? Do we require an OSer to go through each days logs, which could be thousands upon thousands of lines? Have you spoken to them about this? Praxidicae (talk) 16:28, 27 February 2019 (UTC)Now that the proposer is indeffed as an obvious sock, I guess a targeted response is out of the question....[reply]
As the proposer of this idea and the one listed above, I want to leave this one as is and reserve comment for the one above, as I think its valuable. All I want to say is this one is an important policy idea which is simple—to have open discussions is inline with the wiki spirit, where open discussions aren't broadsided by cabalistic ones. It's been delivered and is now the hands of the community. -Usergnome (talk) 03:02, 27 February 2019 (UTC)[reply]
I started reading one of the usual depressing articles about all the big corporate monopolies shutting off somebody's access to internet and print media on the same day, when I stumbled across something unusual -- resistance! Yesterday Gab Dissenter became newsworthy, and after two days of bans on Tommy Robinson (activist) his fans are now downloading a plugin to comment on any web page. That includes, of course, Wikipedia, and someone already modified the article with a screenshot of some comments about that article.
To be sure, I haven't tried this plug-in; I also have some deep qualms about it. It is reported to have the technical facility of upvoting and downvoting, and in my opinion these, not morals and ethics, are the cause of cyberbullying. It doesn't help though that the media are tarring Gab as a bunch of neo-Nazis, which will affect who shows up. And of course, we are speaking of a private company having an in to user computers, which (as always) can't end well. All told, I don't think Wikipedians are going to like what happens at all. Despite all these things, the primary tone in this case drowns out the overtones -- having someone stand up and advocate uncensored communication is better than not. The availability of this alternative should be a warning not only to designers of bad talk interfaces but to the existing administrative mandarins lording over their revdels -- bad will not be good enough. Wnt (talk) 15:18, 28 February 2019 (UTC)[reply]
Gab is largely irrelevant; even Mastodon has a wider userbase and more activity by now. A federated free software solution is certainly a better response to "corporate monopolies" than the n-th for-profit proprietary whatever. Nemo16:34, 28 February 2019 (UTC)[reply]
There is no "censorship" on Mastodon itself: there are different policies and admins on different instances, with no influence one on the other. If you start disliking the policies near you, you can trivially move to another home and you won't need to miss anything you left back (if you want to follow Japanese lolicon and the people around you don't, you can just move to some art-positive or sex-positive instance; you will still be able to follow everyone and be followed by everyone). Federation is the only solution to the impossible tension between opposite needs that social networks face nowadays on how inclusive to be. Nemo07:26, 1 March 2019 (UTC)[reply]
I think you're right. When I read that "a number of large, predominantly North American/European Mastodon servers stopped federating posts from the Japanese site" I thought this was at a lower level of the protocol than individual community moderation, which was probably incorrect. Wnt (talk) 12:52, 1 March 2019 (UTC)[reply]
Some time ago I played with a quite simple idea, perhaps it can solve some problems.
Note that a core motivation for this proposal is give an idea how multiple layouts can be provided on a current wikipage, and without ditching wikicode altogether.
Assume a thread has a some initial content. It will somehow define the thread, but without being complete in any way. Now someone wants to reply to this initial content, (s)he writes a reply and wraps it in a rather imaginary tag "talk" (could be something else). When this shows up on the page it has a link "reply to this post". This is similar to the reply-link at Flow. It is also nothing more than what can be implemented with a template today.
Because the users post is clearly delimited with tags ("talk") it is possible to protect it from changes, even if it is on an ordinary wikipage. That makes it possible for admins to edit and remove unwanted content. It also makes it possible to notify the user of such edits.
The initial post is left without tags, as it defines the thread, and thus should be open for further editing. Now we tend to disallow such editing, but in general it should be allowed unless it is a talk post. Instead of signing that post, which makes it contentious to edit it, the user could add an empty talk post. That could be identified as such and given some special treatment. In particular it could have an edit-box like it is on a Flow page. In fact the edit-box would be attached after the last talk post in the thread.
When such talk posts are rendered on the page we should not just dump them in some predefined order, but let the reader organize them as (s)he seems fit for the particular use case. Sometimes it would be best to order them chronologically, some time on who is relying to whom, etc. It could be written out in the cards header who the reply is directed to, making it obvious if the cards are in chronological order. Perhaps it could even be possible to reorder the cards manually into separate stacks to clarify what they try to say. Such ordering could even be shared for further discussions.
Sometimes it could be interesting to wrap the first content in a separate tag, for example "thread", to be able to refer to the thread itself. This makes it slightly weird to talk about the section title for the thread as it will be outside the thread as such. Still for this discussion a tag name "thread" should be fine.
As often happens a thread can wander off-topic for the original post. How would a new thread be opened? You would then write a new subsection and wrap the content in "subthread". A subthread connect to talk posts in opposite direction, you identify the posts following this subthread. That will connect the whole tree following those posts to the subthread. Same way, if a subthread is removed then the posts reattach as before. This moving of posts are possible if the cards themselves show which cards they are replies to. It will not be important where a subthread is posted, as long as it is after the main thread.
Because threads could be referenced from other pages it could work somewhat similar to the proposed extension of Flow, where you would have personal boards that lists topics of interest to yourself.
I believe it could work, but I also believe it would pose the same resistance as Flow. It is different and people (especially wikiusers) are afraid of changes. This would although look pretty familiar if you set it up to list posts in chronological order. In particular all admin tools would work as before, and searching would work out of the box. Jeblad (talk) 14:33, 1 March 2019 (UTC)[reply]
Will it be a wikipage like any other wikipage? Or will it break with the current system, that a wikipage is a wikipage is a wikipage, and thus stuff you learned here works in the same manner there, like Flow did in a massive way? If a wikipage is no longer a wikipage, but something completely detached from the rest of the wikiverse, like Flow is currently and LQ was, then thanks, but no thanks. We don't need any dumbed down forum impersonation, because we don't need any forum at all, we need working pages for the working on articles to make them better. Grüße vom Sänger ♫ (talk)14:46, 1 March 2019 (UTC)[reply]
From the text above; Note that a core motivation for this proposal is give an idea how multiple layouts can be provided on a current wikipage, and without ditching wikicode altogether.Jeblad (talk) 15:42, 1 March 2019 (UTC)[reply]
As long as the underlying Wikicode is retained, this seems like a great way to make both new and existing pages searchable and sortable. –dlthewave☎18:11, 1 March 2019 (UTC)[reply]
Assuming I understand the proposal correctly (and I think I do), I believe it involves adding significant additional markup complexity to commenting, I believe it pretty much generates a presumption that the page will be edited through some software interface to implement and enforce the expected restrictions and structure. And while the proposal appears to continue to allow access to the page via the wikitext interface, it appears there is a presumption that that access will be crippled, prohibiting any edits that don't conform to the intended plan. If you want to cripple the wikitext editing interface, then yeah there's all kinds of things you can do. However I believe the majority of editors expect to preserve the unrestricted nature of the plaintext editing interface, and the ability to arbitrarily modify, restructure, and refactor the page without restriction. Alsee (talk) 19:36, 1 March 2019 (UTC)[reply]
I think you are right, but I'm not completely sure. IN THEORY the code to mark up posts in the way described does not have to be huge and obtrusive. The first two words are in all caps because we're talking about the developers who default-renamed all the conflicting accounts to XXX~enwiki or some such despite my strong comments against it; these are not people who could grok the concept of user convenience even if you paid graphic designers a hundred grand to make a YouTube video about it. But I mean, IN THEORY you don't have to have a 20-character unique token to identify a talk page comment, because the identity of the talk page itself specifies a much narrower group. You could specify 62 different characters just with AZaz09, so something like A7xG might specify "talk comment #468261 on this page", which could keep even User talk:Jimbo Wales' gob stopped for quite a long time, after which you'd have to add a fifth 'digit'. I mean, there's not much difference in readability of source between
Actually though, to delineate comments it might be smarter to use a tag like <c> at the beginning and </c with all the data> at the end. You could also simply to have the signature data in the <c> at the beginning, but I'm not sure how that would be to work with - my guess is more confusing.
The talk of having comments protected and then having admins edit them is definitely on the wrong track. The admins tend to resent being asked to do work and take it out in bans, which is to say, loss of project membership and production. At the same time, the modification of comments is often annoying. A better balance could be struck if you could duplicate the "tag: references removed" that we see in articles, which is surely the best single act of content enforcement ever done by Wikimedia developers. Nobody is stopped from doing tagged actions, but when they happen it is a red flag to all editors alike. Wnt (talk) 05:51, 2 March 2019 (UTC)[reply]
I don't think it is the right place to spiral into technical details, but it could be something like <talk reply-to="Wnt 05:51, 2 March 2019 (UTC)">some text</talk>, to make it editor friendly. You rarely need the user name, usually the dtg is enough. The "reply-to" can be simplified to the revision as in <talk reply-to="885769692">some text</talk> to make it more compact. [You can even add some keywords, and then use sometning like <talk reply-to="prev">some text</talk>.] With some added UI you just hit reply links and never sees the tags with its attribute unless you want to write wikicode. It could also be possible to use VE to edit the content of the cards. [Note, this assumes editors sign their own posts.] Jeblad (talk) 11:41, 2 March 2019 (UTC)[reply]
For the record, this is the same thing we do with math tags, source tags, etc, and it is pretty straight forward. And yes, we can even convert well-formatted talk pages into this scheme. (If something like a well-formatted talk page exists…) Jeblad (talk) 11:52, 2 March 2019 (UTC)[reply]
Your reply-to attribute is not too terrible, but if we make it a local reference like I'm suggesting rather than a global revision reference, then pieces of the talk page can be cut and pasted to a new local copy with valid local links. Also, it is a little shorter, especially for the first 62 comments (A to 9). Bear in mind that by "added UI" you mean Javascript, which I don't want to use routinely. Keeping the wiki source human readable should be very high on the list of priorities here. Software comes and software goes; the wiki source is Wikipedia. Which brings me to the last point: this is absolutely the right place to "spiral into technical details". That's the purpose of the conversation. A lot of us can't even envision the more general statements being made without specifics to relate it to -- what I call epitopes (i.e. isolatable, recognizable pieces) by analogy to immunology. This isn't a project that can be done by suits in an office blathering at each other - if the altered software is proposed, then believe me, every single epitope in it is going to be examined and judged by the community as either "self" or "foreign". Wnt (talk) 15:24, 2 March 2019 (UTC)[reply]
#1903030053Charis is an suggestion for clear start indicator of a comment (including an anchor) and can be used as human readable identifier together with up to 100 first following characters of the comment. See my complete proposal date&time+1min near end of What do you wish you could do on talk pages, but can't due to the technical limitations? link by anchor: 1903030052Charis. Probably it can solve the need of an identifier for Proposal:_Discussions_as_threaded_cards with further benefits. Main need is the option in wiki texts to be able to define hyperlink targets, not only by section headers. For better understanding I would ask for a sandbox to test it. Charis (talk) 00:53, 3 March 2019 (UTC) update Charis (talk) 12:28, 3 March 2019 (UTC)Charis (talk) 17:09, 9 March 2019 (UTC)[reply]
@Wnt and Jeblad: I think it could be preferable to only add to the code of existing signatures and not remove anything from them. For one thing, removing things would break ~~~ and ~~~~~, and it could be difficult to re-implement customization.
Something more lightweight that's more difficult to parse but easier to handle would probably work better than lots of new XML tags/attributes. (Furthermore, if a revision ID is included in such a tag, then any interface software could potentially use the date and user ID of the revision, as well as any related user information, instead of getting that data directly from the page.) Jc86035 (talk) 15:37, 2 March 2019 (UTC)[reply]
I don't understand what you mean. You said you don't want to change the tilde code, but then you suggest getting the date and time from the revision rather than the wikitext (I suppose you can get username, talk page etc.), so does that mean simply not using tildes? I think I was suggesting you might avoid the tilde code entirely and use some kind of XML tag so I don't think I was disagreeing with you on that point? And by "lightweight" do you mean for the user and "more difficult to parse" you mean a short code without < >? Like instead of maybe <c rev="885769692" reply-to="885769691">Text of comment</c> have =Text of comment(some number of paragraphs without = at the start) 885769692(nick WntNick, reply 88576991)=? Probably not... Wnt (talk) 15:53, 2 March 2019 (UTC)[reply]
@Wnt: The reason I used the example for "reply-to" was that this is easy to invert into a revision id, and I supposed it was easy for readers to understand. It is possible to use other means to get to the revision, but I don't think it is wise to start discussing merits of various hashing schemes and how they can be utilized in this case. Jeblad (talk) 17:27, 2 March 2019 (UTC)[reply]
@Jc86035: The signature like content of "reply-to" would be the dato-time-group (dtg) of the post you reply to, not your own signature. It is used as a proxy for the revision number. In fact, you could simplify the dtg by leaving out parts as long as it is still unique, at least unrolling from your own post. Jeblad (talk) 17:34, 2 March 2019 (UTC)[reply]
@Wnt: The date and username would still be contained in the signature, but the system could potentially use the revision ID to fetch data for display purposes instead of doing a regex search on the entirety of each comment. Jc86035 (talk) 17:43, 2 March 2019 (UTC)[reply]
There are several possible solutions, but the short answer is; you only need to provide some identification of the previous post. I wonder if "rely-to" is a wrong name for the attribute, it is confusing as it means nearly the opposite in emails. Perhaps call it "in-reply-to" or something similar. Jeblad (talk) 17:55, 2 March 2019 (UTC)[reply]
"re" would be better - I think everyone knows that one, and it's shorter. I remain confused but hope a concrete proposal will clear things up. Wnt (talk) 21:24, 2 March 2019 (UTC)[reply]
I haven't been following the details of this discussion, but for attribute names to describe threading, we should look at what has already been done for USENET and email header fields: Message-ID, In-Reply-To and References. isaacl (talk) 21:47, 2 March 2019 (UTC)[reply]
Why try to duplicate something wikitext isn't, at the cost of filling the wikitext with a lot more characters of boilerplate intrusion? Humans being able to read and edit it directly must rank above some pointless partial consistency. If Wikipedia talk pages ever get linked back and forth to Usenet, having the program translate "re" fields to "In-Reply-To" will be the least of the technical obstacles. Wnt (talk) 06:57, 3 March 2019 (UTC)[reply]
My suggestion was to consider leveraging known terms, rather than invent new ones; I had no thoughts about sending any of this data via email or Usenet. In-Reply-To matches the suggestion from Jeblad, and the meanings of the other headers seem perfectly readable to me. My wild guess is that tagged markup for threaded responses is only going to become popular if inserted by VisualEditor (or something like it), so I'm not that concerned about a few extra characters. In any case, personally I feel the concept matters more than the actual names. isaacl (talk) 22:06, 3 March 2019 (UTC)[reply]
I agree on that, but would like to add that I don't think it is important to discuss attribute names, it is more important to figure out if something breaks with this scheme. Jeblad (talk) 12:42, 4 March 2019 (UTC)[reply]
Yes, I said that the actual names aren't as important as the concept itself. I don't think it's necessary to work out a full design in this venue, given that the overall target goals are yet to be set, but certainly finding any major problems is useful. isaacl (talk) 14:58, 4 March 2019 (UTC)[reply]
Note that it is possible to post replies in this system without using Javascript, an edit page would then append on a thread chronologically. It is even possible to add posts manually in the raw wikicode for the complete page. It is rather difficult to split an existing discussion to another page without additional tools, as posts belonging to a branch may not be siblings on the page. Joining two pages are rather easy. Jeblad (talk) 13:31, 4 March 2019 (UTC)[reply]
Attaching comments like references, also inside an existing text, would be interesting. By reusing most of the mental model from references it would be simple for users to figure out how the system works. You would insert a named tag like <comname="foo"group="bar"/> inside a opening text for the thread, and then write your comment inside a comments block following the opening statement like
Subheadings following the initial one could even reuse the same comments block. The actual layout of the comments could be according to user preferences. Each comment would be very different from a reference, much more like posts in a flow-thread, but attached where the comments block are inserted.
A comment can probably be made without a name, it could be added automatically if someone replies to the comment. Comments inside a section can probably be given group automatically. If a comment is inserted in a section, then it would be an error not to insert a comments block with the same group attribute. Jeblad (talk) 20:09, 6 March 2019 (UTC)[reply]
Sorry I for all that loves wikicode, but this will probably work best in a VisualEditor-like environment. It could be possible to make it work in an old-style wikieditor, but it would be slightly more awkward.
Sorry II for just posting a bunch of ideas.
From time to time I have worked on articles that has been a collaboration between several editors. To facilitate that we used some messaging tools in addition to the article itself. Using a separate communication channel speed up the process quite a bit, but it was awkward to save the article before we could show changes to the other editor. What we was missing was some kind of half-way live documents, where we could say "What about this version?" and then iteratively enhance the article in cooperation. If we could have a fully live document, that would probably be even better, but a half-live document is probably enough. That is possible now with the temporary work copy.
With a (half) live document it will also be necessary to create a communication channel. Right now I believe text messaging is enough, but in the future voice communication will probably be more common for such purposes. We could use separate messaging platforms, but there are another option.
Assume you have a wiki environment, and several editors within this environment want to co-edit an article. Would it be a natural extension to say that those editors would join the channel on the article? You go to the article, you open it in VisualEditor, and it opens with a messenger-like sidebar. Something like a Gdoc that is open for all to edit.
Assume you see a beginner trying to edit a page and messing it up in recent changes, you could even open the page for editing yourself and talk to the newbee. That could be pretty awesome, but also pretty darn scary. We would need some tools to police the message channels, but if we say that the channels are logged it would probably not be a very good place for private talks. If they are logged, then the logs should be truncated.
If we have something like the cards in #Proposal: Discussions as threaded cards, then we should be able to reference the cards in the communication channel. We should also be able to copy a comment from the communication channel and to a card on the talk page.
Should a communication channel like this be more like W3 web page annotations? [7] I am not sure. I tend to believe that a web annotation is more like a card from #Proposal: Discussions as threaded cards attached to a specific part of the subject page. Think of it as attaching talking points to the subject page that becomes part of a running thread on the talk page. That thread is more like an editorial board for the subject page. The communication channel is more like the actual editors' communication to implement decisions from the board. Jeblad (talk) 00:51, 3 March 2019 (UTC)[reply]
I like that idea! However, I think it should be available for registered users only because of how IPs can insert copyright violations and vandalism. And there should be a way for privileged users (not just admins) to kick people from pages for violating policies and guidelines. Otherwise, I am all in for a page where more than one user can collaborate. It helps resolve edit conflicts as well. AwesomeAasim16:57, 4 March 2019 (UTC)[reply]
Excluding IPs from site features is always a failure to make an encyclopedia "anyone can edit", and should never be imposed as part of the design from the beginning, but reserved as a "temporary" measure, to the degree that any security measure in any venue has ever been temporary. More to the point, if you ban IPs you'll be banning newly registered soon enough, and so on. While ancient and highly-privileged users can still be a huge nuisance the moment politics gets involved. Bottom line: a live collaboration should have, not an admin, but a user in charge who started it (even an IP at times), who can decide who to let into and boot out of his project. However, the wikitext everyone contributes must be CC-licensed at creation (otherwise someone can lose their internet connection during the session, then sue...) which means that people booted off a live page should retain a copy in their browser that they can cut and paste for their own forked version.
Although I want to see this proposal implemented, I should note that the whole idea of multiple unvetted people getting into communication with each other without the government looking over their shoulder is so radical compared to the modern censor-and-surveil-everything ethos that I expect someone on high to simply announce that This Will Not Be Done, Period at any moment. Nonetheless, it is not officially illegal to do this. Wnt (talk) 13:13, 5 March 2019 (UTC)[reply]
I have reservations about restricting participation in discussions. At the moment I can contribute to any talk page unless it's protected (rare) or I'm blocked, topic banned, etc. (probably my fault). Even if live discussions would run alongside (rather than instead of) talk pages, topics might still migrate there and exclude editors who deserve to be involved. Certes (talk) 13:33, 5 March 2019 (UTC)[reply]
The problem with IPs is that they are hard to track if they do something illegal, not just copyvio but things like drug sale on a page about cannabis. That is using the page as a dead drop. Without means to inspect and stop it that would be terrible. If the channel is logged, and someone is allowed to inspect the log, then using the channel for dead drops would be pretty hard. It is still possible though, but it would imply some kind of encoding or encryption.
Because most users would assume the channel to be semi-private it is not obvious anyone could or should be able to inspect what's going on in the channel. We could change the users expectation to the channel. If all can join the channel, and the channel is logged, then users most behave accordingly. It would then be a group channel, and not a private channel.
By only allowing users that contributes to the subject to post in the channel we could throttle the channel very efficiently, but it could lead to junk-posting on the subject page to be listed as contributor. Demanding work to be done before being allowed in on the channel could also block knowledgable users that hasn't contributed yet. Including users from the talk page could be a solution. It could even be possible for someone with sufficient rights to open the channel and invite other users in, or "voice" them, even IP editors, and thus avoid some issues. Let's say you must be autoconfirmed and have contributed to the subject to open the channel, but then you can invite an IP. The IP can't stay on the channel when the inviter has left the channel. Jeblad (talk) 19:31, 6 March 2019 (UTC)[reply]
Well, that's the censor-and-surveil-everything ethos I was talking about. It's hard to believe that there was a time when I was a kid when people could just pick up a phone - even drop a quarter in a pay phone and just talk to each other, with no government bureaucrat listening in unless there was a big FBI investigation or something going on, because "this isn't Russia". Now this is Russia and there are a lot of things you can't do, like improve software. Seriously -- just give it up and go home. Wnt (talk) 13:20, 12 March 2019 (UTC)[reply]
@Wnt: This has some reall-world implications, and without solving them a communication provider might find itself in a lot of problems. WMF provides services to slightly more than the US, also to Russia. Forget that, and you open up a can of worms. It has a pretty easy solution; make systems that can't be abused. Jeblad (talk) 18:14, 10 April 2019 (UTC)[reply]
@Jeblad: I didn't forget that -- I just don't think it is in my power, let alone my job, to make sure that Russian spies can't communicate with home base. I mean, I'm not James Bond, and they pretty much are. Every time a vandal posts a dozen random words, well, they could be looked up out of a code book and be carrying instructions about what city to nuke, but how would I know? Or it could be a good editor who posts 50 edits each citing news link #N out of 65,536 to carry two bytes of secret data apiece. A professional spy with something to say can do stuff like that, while we can just daydream. So I say let's not pretend to be God and let's not demand to do our totalitarian part to spy on other people's conversations. But apparently that's just me. There's a Dark Age coming, and there's a reason for that. Wnt (talk) 11:25, 11 April 2019 (UTC)[reply]
I can write a multi-paragraph post, with <syntaxhighlight>...</syntaxhighlight> and other block content, without having to worry about how that interacts with line-based indenting.
Ability to watch an individual section.
Highlighting of unread posts in the "read" view, when accessed via the Echo notification.
Clear separation of posts when reading the discussion.
People can't screw up the indentation as easily.
No need to find the right place to add a reply in a page full of wikitext.
Bad things about Flow:
Each post is its own weird little page, completely disconnected from the rest of the thread and talk page. History and diffs are nearly useless since they only apply to each individual post.
History and diffs are missing features: T189213, T189214.
Requirement to watch each individual section if I want to see posts after the initial creation.
Highlighting of unread posts is flaky (e.g. it disappears if you reply to one, before you've seen the others) and only applies when accessed via the Echo notification.
Low information density.
Poor searchability, thanks to "infinite scrolling" breaking Ctrl+F.
Weird ordering of replies. At least they finally caved into displaying threading.
Inability to refactor the structure of the discussion (e.g. fixing indenting, collapsing subthreads).
Weird interaction with watchlists, particularly highlighting. Use of Echo notifications for every new post to a watched thread.
I don't know if it's even possible to watch for edits to a post, nor how they might be easily reviewed.
The only preview is switching to VE, then back again.
A lot of these are already in the Structured Discussions project on phabricator; I saw weird ordering of replies on there just yesterday. --Izno (talk) 16:36, 10 March 2019 (UTC)[reply]
Please drop the absolutes. I don't think there were (m)any that were won't fix, but you're welcome to peruse them yourself, and identify others missing. --Izno (talk) 12:54, 11 March 2019 (UTC)[reply]
That's the way to bet. I'm not saying all the "won't fix" are show-stoppers, but a number of "won't fix" in the last discussion that I saw, were show-stoppers and will probably remain so, unless actually fixed. — Arthur Rubin(talk)08:56, 12 March 2019 (UTC)[reply]
Anomie, I'm not sure that "Requirement to watch each individual section if I want to see posts after the initial creation" is exactly true. I get a lot of Echo notifications about posts that happen after the initial creation. The process seems to be a notification about the thread, and then no further notifications until I've read it, and then individual notifications for every single post after I read the thread. This isn't exactly great (I've always wanted the full Flow feed, which wasn't built but which would scale to my volume much better than Echo can), but I am getting notified about all posts after I start reading the thread. Whatamidoing (WMF) (talk) 16:21, 19 March 2019 (UTC)[reply]
Flow was clunky and yucky-looking. The current interface, lets call it "old-school" seems easier to use. Not that "old-school" can't be replaced, just not with flow. The current interface is pretty quick to load and stays pretty much the same; I hate when sites get a graphical redesign that really changes how things are done when you interact with them. Stop changing, so I don't have to re-learn to use my website again. Oaktree b (talk) 16:49, 7 March 2019 (UTC)[reply]
Doc James, Harej interesting idea. Might have some private info disclosure problems, as people using stuff like that generally expect it to be private. Also need to make sure we deal with the license grant in that case. I suggest sending people a clear link in return, as to where they can find their post, that will help them find it back and maybe will make them edit faster. —TheDJ (talk • contribs) 13:07, 22 March 2019 (UTC)[reply]
Asking Wikipedians what changes you should implement is akin to studying the bombers that returned from the raid (to paraphrase the famous operational research anecdote) - you end up with discussions on indentation, CSS and "gadgets" - nothing actually useful. Unfortunately you can't ask everyone else, so the best you can do is ask Wikipedians, then do the opposite.
Using Wikitext as a "golden hammer" is wrong. For the majority of uses Wikitext should be deprecated or so well hidden that it's unnoticeable to casual users, just like HTML is in the vast majority of websites. The "visual editor" was a step in that direction.
MediaWiki is unsuited for several use cases, as it doesn't have a concept of text fragments. In other words, I can't ask the system questions about paragraphs or sections, only about articles or diffs. This means users can't post "messages", just "sequences of diffs that happen to string into a paragraph when parsed to HTML".
One example of when that's a problem: Policies generally require diffs. What process do you use to get the diff for a particular message, and what would you do in any other system? (Answers: use a third party service to run a binary diff search that may or may not result in the full text of the message, vs. right click on the title and copy a URL)
"Talk pages" should be full fledged forums, or in the very least akin to Github Issues. Editors should be able to reference arbitrary segments of text (similar to an EPUB CFI), editors and revisions with zero hassle.
MW should implement personal messaging.
Policy should change to reflect normal human interactions, rather than banning them (or rather brushing them under the carpet) in the name of some faux social order. Example: "canvassing". Seriously?
The whole system is painfully backwards in terms of automation. Manually archiving discussions? Manual text layout (eg. indentation)? Manually "substituting" templates? Manually linking forms written in Wikitext?[8] What is this, Usenet? And no, a community writing a zillion independent bots running through external APIs is hardly a solution.
I note that François Robere is also a Wikipedian, and therefore by the suggestion of this proposal we should do the opposite of what they say. ;) Anomie⚔02:20, 23 March 2019 (UTC)[reply]
@Johnuniq: I think some of the points do have merit, particularly 3 and 7 (which seem to be in the vein of "WMF should improve/maintain software that already exists instead of developing shiny new things").
Briefly: (1) most highly active contributors prefer wikitext and that probably won't change soon; (2) this has been cited by some Flow opponents as a negative due to the reduction in flexibility; (4) WP:NOTFORUM and this would be a fairly big change with unknown (dis)benefits productivity-wise (although I wouldn't necessarily oppose something like this); (5) I don't think the WMF would do this and Special:EmailUser mostly serves this function already; (6) policy is not relevant to the consultation because the WMF is only planning software changes and cannot unilaterally change local policy. Jc86035 (talk) 06:51, 23 March 2019 (UTC)[reply]
Nitpicking, but WP:NOTFORUM isn't actually pertinent to this discussion as it doesn't mean what the title says. It's a policy about what topics one can should (not) discuss on article talk pages, not about which format they are in. Jo-Jo Eumerus (talk, contributions) 09:23, 23 March 2019 (UTC)[reply]
Johnuniq, I agree that this does not represent the general view of highly active, long-time editors at the English Wikipedia (e.g., people like me). But some of this does look like the views of some other types of users, especially users outside of the English/German Wikipedia orbit.
The thing that's been most interesting to me this week is that our notion of users in developing countries/places that are relatively new to the internet seems to be wrong. I think if we asked the "old hands" at the Village Pump about how to make Wikipedia work for people in, say, English-speaking African countries, we'd be hearing things like limited bandwidth, fewer images, don't link to videos because it's too expensive, avoid fancy formatting, etc. But the New Readers team is doing some research with these users, and they're apparently hearing the opposite: More images, more video, more everything. A lot of the core community at the English Wikipedia, including me, remember when "the web" was a new thing and nobody really knew if it would stick around. A lot of the editors at what they're currently called "emerging communities" have never known an internet that didn't support smartphones. The views of the what's normal on the internet is significantly different. Some of these requests have already been mentioned in other community discussions. Whatamidoing (WMF) (talk) 17:39, 29 March 2019 (UTC)[reply]
I find the comment by François Robere to be rather good. (In another forums I would call most of the replies plain bullshit, and point them out with diffs, but this is wiki-world and the diff-links would be removed.) Jeblad (talk) 18:07, 10 April 2019 (UTC)[reply]
I'd just like to throw in my two cents asking for the visual editor on the talk pages. I'm an infrequent editor, and prefer wikitext when building an article or section. But once it becomes dense with references, pictures, and formatting I need to switch to the VE to keep my speed up. I find it too hard to spot what I'm trying to change in the sea of other information (something I suspect more experienced editors learn to subconsciously filter out). The same is true on talk pages which can be dense with formatting that signals conversations.
The other issue for me is that I have trouble navigating to pages, talk pages, etc... on the android mobile app. It's fine for surfing an article but I can hardly use it for anything else. I think it would be easier (given the limited screen space) to have VE on those mobile based talk pages. Ian Furst (talk) 22:21, 25 March 2019 (UTC)[reply]
The mobile apps don't technically use mw:Extension:VisualEditor, but there are some changes with the main Mobile Web site for the mobile visual editor. The team is trying out a kind of "section editing", which seems like a reasonable precondition. Nobody's going to want to open WP:ANI in the visual editor (and if you did, and you managed to find the section that you wanted to comment in, then saving might be a nightmare, especially if a typo elsewhere on the page resulted in unbalanced HTML). I'm cautiously optimistic that they've found a middle ground for editing long articles on smartphones, but I'm still a bit doubtful about the desirability of using it on talk pages. Whatamidoing (WMF) (talk) 17:09, 29 March 2019 (UTC)[reply]
What goes in to an empty one line note on a file description you can't see in WikitextI just saw a pretty picture of an exoplanet on the Main Page. But I couldn't just click through to the article about it, so I was going to change the Commons description to provide a link. To be sure, I quickly saw that wasn't permitted due to cascading protection. But then I noted an "Edit" button on something called "Structured data", an empty box stuck between the image and the descriptive information. This seems to match some high priority objectives for Flow and similar redesigns:
Requires Javascript to do anything
No apparent Wikitext
Makes special bureaucratic request to agree to terms and conditions
Doesn't tell you you can't post because it's protected until after you've wasted your time trying to edit
Is actually blank on a file used on the Main Page right now
Searching around on Commons I see there is one of those fancy diagrams you think of overpaid seat fillers coming up with, which if I actually read it makes me wonder if I could possibly count as a 'curator' or 'casual uploader', which would make me sort of a stakeholder via "Casual uploaders" -> "Commons uploaders" -> "Commonists" -> "Wikipedia Community" -> "Structured data on Commons". Somebody else by the name of Sloan is apparently a direct stakeholder, no intermediaries ... I don't know who that is but honestly I doubt they are getting what they want either.
Anyway, a file description is essentially a talk page, and it seems to me that this is an extension of all the same syndrome. Technology is defined as something that gives power to those that control it over those who do not. Wnt (talk) 12:54, 17 April 2019 (UTC)[reply]
I have a very strong hatred of this so-called feature, to the extent that I set my adblock to block this "feature" from Commons. It reminds me very much of the abomination that is Flow/Structured Discussions (the use of "Structured" in both could be a helpful hint as to WMF's intentions). That said, it's a topic for another discussion. —pythoncoder (talk | contribs) 16:20, 17 April 2019 (UTC)[reply]
It's really more Wikidata's twin than Flow's. The plan is basically to have each file have Wikidata-style properties for the description, author, license, and so on instead of having that information only embedded in Wikitext templates where it's harder for automated re-users to access it, although at the moment it looks like they've only implemented the "captions" so far. You can read more at c:Commons:Structured data, and leave feedback on the talk page there. Anomie⚔00:30, 18 April 2019 (UTC)[reply]
By the way, since everyone's still here, this thing was supposed to be over about two weeks ago and has already been summarized (although the comparative lack of detail in the summary is slightly disappointing). Jc86035 (talk) 10:33, 18 April 2019 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
