Talk pages consultation 2019/Individual feedback

This is a page for all wiki contributors to add their perspectives and ideas to the Talk pages consultation 2019. The goal of the consultation is to identify a general product direction for improvements to the communication tools on wiki by the end of June. (For more information, see the TPC main page.)

When we say "talk pages," we mean all the on-wiki forms of communication. This could mean any of the talk namespaces, a project page, a subpage, a sandbox, or any other page. It includes all the tools or systems you use on the wiki: wikitext talk pages, Structured Discussions (Flow), LiquidThreads, user scripts, gadgets, WikiLove messages, pings, notifications, etc.

Feel free to respond to other people on this page, if you'd like; we'd like to get as much information as we can. If you have questions or thoughts about the consultation process, please tell us. You can write on the consultation main talk page, or ping DannyH and Trizek. Thanks!

If this page is too complicated, then try the talk page.

What do you think of the proposed product direction?

 * Context: The Wikimedia Foundation proposes building a new, clearer design on top of existing wikitext talk pages. It will offer simpler tools for replying, indentation and signatures. You could continue to use wikitext on talk pages, if you prefer that. It should also be possible to participate in a discussion without using wikitext.


 * Question: What do you think of this product direction?

Marking separate discussions

 * Context: People want to watch individual sections on the talk page. They want better notifications, archiving, and search.  To do any of this, we may need to create a more structured definition of what counts as a single discussion. This may mean making changes to the wikitext conventions on a talk page. For example, we may create a new way that discussion headings look in wikitext, or a new link that you need to use to create, rename or split a thread.


 * Question: What are the pros and cons of that approach?

Helping newcomers find the talk pages

 * Context: Newcomers have difficulty finding talk pages.  During user tests, only one person out of ten found the  tab. Most testers looked for a  tab on the opposite side of the page, where all of the other tabs and links are. Many people also expected to see links to discussions about specific sections in the article. We may want to move the link to the talk page to the opposite side of the article page.  We might add discussion functionality connected to individual sections.


 * Question: What are the pros and cons of making the connection between article content and discussions more visible?

Where to show discussion tools

 * Context: Currently, many wikis have community discussion spaces in the project namespace (  or  ), rather than in a talk namespace (  or  ). The project namespace is often used for village pumps/cafés, noticeboards, and some workflows, such as Articles for deletion. The system will need to know where discussions happen, so that it can display the new tools in those discussions, and not display them on other pages. There are several potential ways to do this. One of them is to move all discussions to a talk namespace.


 * Question: What are the pros and cons of doing that?


 * I can see a major issue with moving discussions from their project namespace to their talk namespace: practically all those discussion pages are already using their talk page for meta-discussion about the project page. Compare for example the Wikipedia Teahouse and its talkpage. I don't think it's a major technical hurdle to use a template or category to selectively enable "talk page mode" (for example like the way SineBot works). (note: I'm only speaking from my experience on the English Wikipedia) Rchard2scout (talk) 20:12, 17 May 2019 (UTC)

History tradeoffs

 * Context: Sometimes, you need to see the history of the entire page.  Other times, it would be more helpful to see the history of only a single discussion thread. It would be ideal if we could provide both, but we're not sure how to do that.


 * Question: What are the pros and cons of having a complete page history or a specific thread history?

Metadata location

 * Context: Some wikis place templates at the top of article talk pages.  These may show instructions, warnings, or FAQs.  They may hold page quality information, link to relevant WikiProjects, or identify past activities.  Many new users are confused by finding non-discussion material at the top of an article talk page.  It would be helpful to move some or all of that content somewhere else on the page, or under a different tab.


 * Question: What are the pros and cons of that approach? Which templates are crucial for the proper use of a discussion page, and which could be moved somewhere else?

When you want to talk on-wiki, what tools work for you, and what problems block you? Why?

 * As an experienced admin I'm fine, but even so, the constant need to use (numerous, convoluted) templates with detailed "what to do" directions, on each of multiple pages just to notify multiple users/talk pages/project pages, or in processes such as AFD/RFC/DRV/ANI/..., is a massively time consuming annoyance. Can this be ripped out and replaced with some kind of automated editor-process handler which defines the inputs needed, and stipulates in machine-usable logical steps, where these inputs should be posted on-site, and using what templates? So you can select an arbitrary wiki-process or template, and internal code in the template or page lists any required/optional inputs +validation, and what templates+content should be posted above/below which anchors on which pages as a result. So you can just pick a template, a form pops up, you fill in some text fields and validation + all edits for that process are posted automagically. That would be huge.  (Extra thoughts: We already have if-then-else and other statements as part of the parser. The validation/process handling code for a template would be held with the templates or on relevant project pages, in special &lt;process> ... &lt;/process> tags that render as a link+optional text to start the process, and creatable/updateable as templates and processes change, using ordinary editing, like any other template edits. WORKED EXAMPLE FOR AFD: the inputs could be one or more article/s to AFD, the AFD reason, type of AFD, a list of users/pages[+sections] to notify, and an optional user message or blank for the default notification wording. After entering these on a single page form, the inputs are used to test input validity, create the AFD for the article/s, list them at the AFD summary page, and notify users/pages, adapting its postings for repeat AFDs after testing whether an AFD already exists for the page.) 
 * If I were a less experienced user, I'd hate adding to talk pages. I'd like to see a hybrid system whereby discussion remains on talk pages as usual, but there's the additional ability (if desired) to read and add to it using ordinary chat systems somehow bridged to Mediawiki, and not just plain mediawiki editing. Perhaps talk pages and their sections can have links next to them "open for replying in a chat client" (or "add new section in a chat client")?  (On the possible objection that it implies social chatter, Stack Exchange's website chat system shows that if designed well, a tight focus can be achieved on topic. Anyway, we want user engagement so perhaps facilitating easy reader engagement may facilitate?) 
 * Those would be my two choices. Thank you! FT2 (Talk 11:21, 4 April 2019 (UTC)
 * FT2 (and anyone else), if you had to choose between "improve article talk pages and user talk pages" vs. "fix AFD and ArbCom case pages", which would you suggest doing first? Whatamidoing (WMF) (talk) 18:03, 5 April 2019 (UTC)
 * StructuredDiscussions can be annoying due to reduced control when (re)editing.--Flugaal (talk) 11:36, 4 April 2019 (UTC)
 * Are you using StructuredDiscussions in its wikitext editing mode or with the visual editor? Whatamidoing (WMF) (talk) 18:03, 5 April 2019 (UTC)
 * What blocks me is if the interface gets in the way. Please do not remove the ability to enter text in a plain text editor with zero bells and whistles. Being forced to use an "visual editor" would considerably reduce my enjoyment and usefulness. The format of MediaWiki talk pages is horrendously ineffective. I don't mind you making things easier for newbs, as long as you offer a way to completely opt out of it all. CapnZapp (talk) 11:48, 4 April 2019 (UTC)
 * Support - I'm still using markup editing + MonoBook for that reason - used to it, quicker, less browser hassle, works well, compact, more control. FT2 (Talk 11:56, 4 April 2019 (UTC)


 * I will hand out a barnstar for anyone who implements the ability to edit (my own) edit comments. Paradoctor (talk) 14:38, 4 April 2019 (UTC)
 * See T15937. Whatamidoing (WMF) (talk) 18:26, 5 April 2019 (UTC)
 * The argument for the decline is absurd. Sigh. Paradoctor (talk) 21:15, 5 April 2019 (UTC)
 * I would love the ability to comment on or question an edit/reversal directly from the History view, without having to go over to the editors talk page, start a new topic and then reference the edit (something that won't even work if the edit comes from an IP). As it stands, many editors will now often reverse an edit and use the edit summary as a way to start the conversation. I use this method myself with editors I'm familiar/friendly with, but it's less than ideal. Moebeus (talk) 15:23, 4 April 2019 (UTC)
 * Contrary to many, I'm a big fan of Structured Discussions, I think they really lower the bar for people not familiar with templates, indenting, markup and the like. I suspect the Flow team gets more hate than love, so here's some 💗 from me. Moebeus (talk) 15:23, 4 April 2019 (UTC)
 * This is a very small thing and maybe it's just me, but whenever I see a red badge I instinctively think "warning", "bad news", "immediate action needed". Yet often, I'm simply being pinged or mentioned. Would a blue or other color badge be more appropriate to better distinguish between warnings and mere notifications? Moebeus (talk) 15:34, 4 April 2019 (UTC)
 * See T142981. Whatamidoing (WMF) (talk) 18:26, 5 April 2019 (UTC)
 * At English Wiktionary, I often contribute to talk pages that have a large number of individual active threads, such as the "Tea Room" or "Requests for Deletion". These threads may develop over a period of days or weeks, or even months. What I need is a way to subscribe to individual threads, so that I receive notifications when new posts are added to threads that I am interested in. Without this facility, it is hopeless trying to track the discussions that one is participating in. Mihia (talk) 17:53, 4 April 2019 (UTC)
 * To make talk pages better, revert vandalism or disruptive edits straight away. Hurricane Bunter (talk) 19:37, 4 April 2019 (UTC)
 * For mobile users, it would be nice if I could jump to the talk page without scrolling to the bottom of the article, the reverse of what I do on a pc. Sometimes the articles are long! Student7 (talk) 20:03, 4 April 2019 (UTC)
 * I'd love to see Structured Discussions picked back up, I don't see any reason to use wikitext in talk pages. Yes, it makes more challenging things easy (with templates and such), but it makes basic discussions absurdly complicated, especially for new users. In every other site I've seen, once you have an account the only barrier to making a reply in a conversion is to type into an HTML textarea and press "Submit". Nothing else is necessary, it's automatically formatted, lots of sites automatically have threading, most sites have notifications when a conversation you've commented in has a new comment, most sites have a built-in mechanism for @-ing people, comments are often separated into different sections automatically, and there's no need to manually add a signature because the site handles it for you. Wikitext has none of these features without bending over backwards. I love Structured Discussions, they're so much easier and make me actually want to interact with others on Wikipedia or Wikidata. I almost didn't even comment here specifically because I didn't want to deal with Wikitext. I think that there may be a lot of others like me. Thanks, and sorry for the long comment. I feel pretty passionate about this, and have since I started editing Wikipedia over seven years ago. Nicereddy (talk) 23:23, 4 April 2019 (UTC)
 * I also wanted to mention that, despite having around 5000 edits on Wikidata in the last few months, I never saw the request for comment in the Project chat. I only discovered it after I browsed the "talk page consultation 2019" pages and found that there was a summary of the discussion from Wikidata, that I never saw and was never involved in. Obviously I feel strongly about this and would have loved to offer my suggestions, but I never heard about it. I'm not sure what the solution to this would be (short of notifying everyone with a big banner), but I definitely feel like that biases the responses to power users. I also wanted to point out this comment on the Wikidata RfC, which essentially sums up my opinion on the topic. Thanks and again sorry for the long comment! Hopefully I'll sign my comment properly this time :) Nicereddy (talk) 23:47, 4 April 2019 (UTC)
 * Structured Discussions sounds much better than what we have now. // Things that block me and/or others: (a) Experienced editors who slam other (less experienced) editors with a litany of criticisms, sprinkled liberally with references to THE LAWS OF WIKIPEDIA, you know, the ones that look like this: U:RSTUPID . (Just to make sure ... this entry contains misstatements of fact, e.g., "laws of Wikipedia" and fake wikilinks because I am being SAR:CASTIC . Yes, I know I am NOT:ONTOPIC exactly, b/c I'm talking about human behavior, not tools. But if we don't collectively and actively discourage Biting, Gnawing, and Dismembering Newcomers and less experienced editors, the best tools in the world won't matter much.  - Mark D Worthen PsyD   (talk)  00:22, 5 April 2019 (UTC)
 * This I agree with: we need to double down on "do not bite the newcomers". Remember that back in 2005-2006ish people didn't have as many issues with adding to talk pages. I do believe there should be thoughts of updating talk pages as people used to Facebook/2010ish sites may be a bit bewildered, but it's more important to make the user experience friendly. WhisperToMe (talk) 05:42, 5 April 2019 (UTC)
 * Off-wiki, I'm pretty much an e-mail-only person, so I've never used Facebook or anything similar. What can you tell me about ideas or concepts that you'd like to copy from sites like that?  For example, I hear that they're more mobile-friendly, and that you can block users if you don't want to read what they have to say.  What would be most useful in our context?  (Yeah, I know, the team would want to do formal UX research and user research, but I'm interested in what you all are thinking about.)  Whatamidoing (WMF) (talk) 17:59, 5 April 2019 (UTC)
 * I do think adding comments without needing to add the signature would be quite useful. Having a selection of public domain emoticons would be nice as well. Oddly enough I would not like to see "block users if you don't want to read what they have to say" as I fear it could result in Balkanization of conversations. Wikipedia works as well as it does because users of different points of view are forced to interact with each other. WhisperToMe (talk) 18:10, 5 April 2019 (UTC)
 * "Balkanization of conversations" we are there already. people just do not respond, and archive aggressively. and we have block certain users from your talk or email feature. you can't actually make people read their talk warnings. but you could make it more useful, in the hope they would engage on talk more, which is not happening now. Slowking4 (talk) 01:14, 10 April 2019 (UTC)
 * Being able to hide comments posted by a user you dislike is not the same as people refusing to acknowledge messages you've left on their user talk pages. I can think of some long-running w:en:WP:IBAN cases at the English Wikipedia for which it might be helpful.  I imagine that it'd be personal (only affecting what you see) and easily reversible – something like a little Template:Collapse top-style box that says "Collapsed comment from User:Frenemy; click to read it anyway".  Whatamidoing (WMF) (talk) 18:47, 10 April 2019 (UTC)

A few simple observations that I find: T.Shafee(Evo&#65120;Evo)talk 07:29, 1 May 2019 (UTC)
 * I very often want to just +1, or "like" a comment to show support for that point of view but I've nothing extra to add. Otherwise people tend to stay silent, which can skew the consensus of the conversation (outside of a full-blown vote).
 * Sometimes people will indent with  sometimes with  . This can make it an unnecessary hassle to add bullet points to a reply that is indented
 * Knowing how to outdent using a template took me months
 * VisualEditor across all namespaces would be a minimum necessary change even if no specialised system is implemented
 * Heavily indented threads quickly become unreadable on mobile
 * New users can sometimes place their reply comment in the edit summary rather than the main editing window.
 * Obviously the old-timers and experienced editors are fine with current talk pages. Allowing them to opt out of any new interface is useful for not holding back newer users coming in.

How do new users on your wiki use talk pages, and what problems do they run into?

 * Many new users fail to correctly make new sections for new discussions. Perhaps some scroll to the bottom and click "edit" without knowing about the button at the top. Anarchyte (talk) 11:15, 4 April 2019 (UTC)
 * (+1) Winged Blades of Godric (talk) 15:38, 4 April 2019 (UTC)
 * Forgetting to sign their posts. There is nothing that says "Don't forget to add your signature" when editing a talk page. Anarchyte (talk) 11:15, 4 April 2019 (UTC)
 * +1 for the signing problem. That should not need much explanation/intervention/effort for a user. Maybe it should just be automatic, maybe even without much cryptic wiki code appearing.--Flugaal (talk) 11:26, 4 April 2019 (UTC)
 * I concur that new users ought to have an option enabled (by default) that always append an signature in certain spaces (talk, article-talk et al). Once, you are experienced enough, you find out that setting and might wish to turn it off. Winged Blades of Godric (talk) 15:38, 4 April 2019 (UTC)
 * Anarchyte, at your home wiki, instructions to sign every post are provided at the top of every talk page window. See  w:en:MediaWiki:Talkpagetext, or look at the top of https://en.wikipedia.org/wiki/Special:Random/Talk?action=submit  Whatamidoing (WMF) (talk) 20:10, 4 April 2019 (UTC)
 * tl;dr, nothing says welcome like a wiki'splaining wall of text, and then shifting the burden of mediawiki UI on the user, and then warnings to sign posts. Slowking4 (talk) 11:39, 5 April 2019 (UTC)
 * You left out the step in which we moan that nobody reads the directions. ;-)  I've spent more than a little time adding missing signatures to Village pump pages, and it's my opinion that just telling people to do it, or even how to do it, isn't sufficient.  (But what are we realistically willing to give up to solve that problem?  Slowness?  Sometimes it signs when it shouldn't, and sometimes it doesn't sign when it should?  Re-training our fingers to stop automatically signing?  I don't know about you, but I've sent more than a few e-mail messages that I signed with four tildes, and if full auto-signing were implemented, I'd probably accidentally double-sign some messages for weeks.)  Whatamidoing (WMF) (talk) 17:53, 5 April 2019 (UTC)
 * exactly, if warnings are not working for you, then stop. if people continue to not sign, and the bot signs with a lag it is all good. and it would be better with an auto-sign. i'm sure you could program a "if no signature, then sign" similar to the bot, but it would not be perfect. the enduring problem is the censorious culture that blames newbies for UX difficulties: it is failed programming. and the expectation of perfection and listing of mistakes, without a quality improvement process is dysfunctional. Slowking4 (talk) 13:21, 7 April 2019 (UTC)
 * Note, that one of the comments above had to be indented with . T.Shafee(Evo&#65120;Evo)talk 07:33, 1 May 2019 (UTC)


 * Formatting to differentiate your post from previous ones takes knowledge/experience. Also, with lengthy discussions, it's impractical to just keep adding indentation.--Flugaal (talk) 11:29, 4 April 2019 (UTC)
 * Lots of little discussions get scattered on article pages and never get more eyes other than the few that have watchlisted those pages - it would be nice if the project tagging system allows any new talk page posts to be alerted to all those who subscribe to the projects to which that article is tagged. New users should be automatically asked if they want to join projects, based on the articles that they edit and the projects they belong to. [An alternative to using projects to channel notifications could also be categories - but it becomes more complex due to nesting etc.] Shyamal (talk) 12:00, 4 April 2019 (UTC)
 * AFAIR, Bobo03 was running a research project as to auto-suggesting projects to new editors, based on their editing patterns or something roughly similar to that. Winged Blades of Godric (talk) 15:38, 4 April 2019 (UTC)
 * It's not so much as problems with new users not knowing how to make sections and signing their comments but it's more of not really explicitly showing what the talk page is there. We have to bullet point the functions but is there something more to streamline or illustrate the points? A simple effective flow chat perhaps? The Grid (talk) 12:11, 4 April 2019 (UTC)
 * When a user first creates their account, small messages boxes appear that explain the basics. I do not remember there being any of these tips on Talk pages when I made my account (I could be wrong though. Afterall, I did make my account years before I decided to use it). --Diriector Doc (talk) 13:24, 4 April 2019 (UTC)
 * Edit conflicts, counting colons for some feeble attempt at threaded conversations, crazy colorful signatures or none at all, impossible to write on mobile, the whole thing is a terrible hack and I can't imagine what it would be like for anyone with accessibility issues. There's no user profile images to humanize people just a little (not just "social media" websites have user images, but practically every major website, including twitter, ebay, github, soundcloud, and Wikimedia Foundation's own Phabricator) but any attempt to add a profile image on Wikipedia means licensing your face for use by anyone for any remix or advertising or anything they please (seriously wtf? why should anyone have to open themselves up for harassment like this to have a user image?). The whole comment system is a disaster, and the only reason you're asking the user base is because you already know it. I look forward to seeing the Wikimedia Foundation "consult" the users for the next 20 years on this issue before ultimately admitting they don't have the ability or resources to develop anything better, and will never be able to get the users to switch over any way. Stop wasting everyone's time. Pengo (talk) 22:07, 4 April 2019 (UTC)
 * ^^What Pengo said.^^ Brilliant.  - Mark D Worthen PsyD   (talk)  00:25, 5 April 2019 (UTC)
 * +1 except not "admitting they don't have the ability or resource", but rather admitting they do not have the diplomatic skills of George Mitchell, to bring the fractious community to accept a path to a better way. Slowking4 (talk) 15:51, 8 April 2019 (UTC)
 * I agree with the design points, but I don't see the harm in being cautious with user consultations to ensure legitimate mandate for change. Surely better to keep testing the waters before and during development rather than get massive backlash after development. T.Shafee(Evo&#65120;Evo)talk 07:33, 1 May 2019 (UTC)


 * People often forget to sign, and sometimes users criticize them for doing so. The signature instructions are at top, but people often don't read what isn't bolded or italicized. If it's important, we need to call attention to it. I also second Mr. Worthen's statement that user issues are more important than technical talk page stuff. WhisperToMe (talk) 05:40, 5 April 2019 (UTC)

Thank you for participating!

Radical redesign of UI
Talk pages are still available mostly to experienced editors. Newbies (especially readers) don't even know they exist. That's because talk button/tab is not the standard way to enable discussion on web pages. Standard way is either forums or chat, chat being the most popular. If you can make it chat, you can improve the involvement manyfolds. You can give a floating chat window, in which user can interact in steps. Step 1: Topic selection/creation, Step 2:Read/Write. And replace signature with username (automatic) just like chat. Capankajsmilyo (talk) 00:30, 5 April 2019 (UTC) Support this idea. It needs to be as easy as possible. It boggles my mind that Talk pages on Wikipedia don't even have VisualEditor as a possibility yet. 122.57.169.187 00:41, 5 April 2019 (UTC) (This comment was me, logged-out. Oops.) Hl (talk) 00:41, 5 April 2019 (UTC) I too support this because the UI really sucks, can we have talk page like whatsapp messenger and why we need to sign our comments in 2019 ? I think a small popup on the left or right side should be displayed, and why we call it talk pages ? Can we rename it to chats or messages ? No one other than editors understands what is a talk page. And why editors use Wikipedia terms when talking to newbies ? I have seen many editors using term like WP:BLP, WP:AFD and WP:IRS etc to IP editors, I think these should get converted to their full forms automatically. And to increase editors I would suggest try to follow Facebook's header style login interface. And why are we still using only text ? It would get much better If you add some nice CSS buttons. -- Eatcha (talk) 09:34, 5 April 2019 (UTC)
 * support but expect pushback, cultural inertia is why status quo remains. Slowking4 (talk) 11:37, 5 April 2019 (UTC)
 * Eatcha, I'm not familiar with Whatsapp. Can you tell me what ideas or concepts you'd like to copy from it?  Also, if you (any of you) haven't seen StructuredDiscussions (aka the first step of what was to be a much larger project to smooth some workflows, called Flow) before, then you might take a look at Talk:Talk pages consultation 2019/Individual feedback.  It defaults to visual editing on this wiki, but you can switch to wikitext mode via the pencil icon.  Whatamidoing (WMF) (talk) 18:47, 5 April 2019 (UTC)
 * FT2 suggested "ordinary chat systems somehow bridged to Mediawiki" above. Capankajsmilyo, Hl, Eatcha, Slowking4, what do you all think about that idea?  If it were somehow possible for you to read and reply to discussions from a chat system app (any good examples?), would that be useful?
 * I can tell you that the team is not going to build a chat system. One of their goals from the outset was to get everything on wiki:  open, public, transparent, and permanent.  But whether you first go to the talk page and click an Edit button, or open a third-party messaging client and post to the wiki through its tools – well, I don't remember anyone talking about it, but that might be something they would consider.  Whatamidoing (WMF) (talk) 19:21, 5 April 2019 (UTC)
 * Whatamidoing (WMF), I wanted our talk pages looks changed so that they look more like a social site see this it's a screenshot from whatsapp web (web.whatsapp.com) it's basically a group chat and that's what we do on a talk page, but our pages are far too complex from this. I also want to put your focus on User Images, I'm not saying that we all must add our faces but I have seen this in YouTube, where most of the user images are fake but still they interact with each other maybe it's in our human nature to Interact with an user account with an Image rather than a just talking to a name. (e.g. An image adjacent to my name would be great). Attaching images in the Talk Page without uploading it to commons (It's nearly impossible for a new user to upload an Image to commons and then add it to a talk page. ) And it would be better If you can prevent edit conflicts I don't know how but it does not happens in YouTube chats see this it's Pewdiepie vs T-series live counts by flare TV sometimes it's so fast that it's impossible to read, but still no edit conflicts. If not like a chat system try to follow some features of a chat system like the image that I added above there is an attachment logo it's a thing that most of us are familiar with, when a new user wants to attach something he will most probably look for that logo but s/he after not finding will get discouraged and can even leave without writing anything. There is no need to sign in a chat system or emailing system, user images, and why do we need edit summary for a talk page ? It can be very simple if you follow the above whatsapp web UI (there is no summary section, just a text box and a send button) most of us just write re in the summary or anything that doesn't matters (e.g. you wrote just c and prior to that you wrote This seems to belong here). PROTIP: Try to treat each talkpage as a group (similarly to group in whatsapp) and every user who commented/created or modified in any way as a group member that would definitely improve talkpages. And can you provide customized time by using IP to get timezone? Why are we using UTC ? It does not happen in any chat system or emailing system (e.g gmail or facebook). I will not be able to reply for atleast 6 hours as it's 2:30 AM where I live and I have to wake up early. Thanks for your responce -- Eatcha (talk) 20:07, 5 April 2019 (UTC)


 * Whatamidoing (WMF), I'm adding some screenshots Reddit & Twitter. The talks should get auto adjusted (Why do we need to add ::: or * why not replace the  or   with thumbs up or down similar to Facebook) --Eatcha (talk) 07:06, 6 April 2019 (UTC)
 * this is very good. and i am using telegram, so that minimal threaded conversation system works for me. given the cultural problem, i would suggest, a beta version with a roll out for new users, and opt in. (rather than opt out for the old veterans who will VE it.) Slowking4 (talk) 15:37, 7 April 2019 (UTC)
 * i could see the notification system pivoted to messaging. i.e. send a thanks, respond to a notification with a pop-up which saves text on talk page, but threaded in notification system. don't know how hard that would be. Slowking4 (talk) 16:04, 8 April 2019 (UTC)


 * At least as far as Wikipedia and Wiktionary are concerned, I support a certain (reasonable) effort bar to talk page contributions. It helps to filter out the crap. If people can't figure out how to edit pages or contribute, then most probably their level of contribution will not be welcome either. Most definitely, we do not want a flood of chat-crap on those projects. Any effort to make Wikipedia like some kind of social media stream-of-crap should be resisted most vigorously. 86.173.132.235 01:38, 7 April 2019 (UTC)
 * "If people can't figure out how to edit pages or contribute, then most probably their level of contribution will not be welcome either." i see this ethos a lot among admins and patrolers. why welcome everyone, because you might welcome a vandal? and do not make UX easier, because vandals will edit. it ends up being "you are not welcome, regardless of your contribution." it is the privileging of a class that does not want to collaborate, but dictate: it is the root cause of editor plateau. Slowking4 (talk) 15:31, 7 April 2019 (UTC)
 * IP user, how can you even say that ? It's in our core values, Wikipedia is based on open collaboration. We are not any private company or anything like that. Do you really want to kill the reason because of which you were able to edit this page ? If your are worried about vandals ask yourself why the earth is not yet vandalized by humans ? There are many good people who can help, why do we bar these good peoples because of some bad ones. I will oppose strongly any-kind of effort to bar good people from editing. The reason we are here is to improve the talk pages so that more good people who are not able to use the present complex talk pages can join us -- Eatcha (talk) 20:05, 7 April 2019 (UTC)
 * this is a common reason veteran editors vote status quo. and grace us with their anonymous pushback. it is a dead weight against future progress; but we will need to account for the headwind, to get system improvement. i collaborate with many newbies at meetups, and the UX roadblocks are painfully obvious, but if you do not, then not so much, and "works for me" Slowking4 (talk) 15:59, 8 April 2019 (UTC)
 * I don't think that many established editors actually want status quo. Those responses usually sound more like "Don't make me learn a completely different system, but please fix the following long list of problems, which I've alphabetized for your convenience:   accessibility, archiving, auto-signing..."
 * I also don't think that the team is going to be able to get away with an actual status quo proposal. Audiences will have to take whatever we all come up with to the Board for approval, and I doubt that they'd accept a proposal that says everything's perfect just like it is, and nobody actually wants anything changed.  Whatamidoing (WMF) (talk) 18:40, 10 April 2019 (UTC)

The purpose of talk pages is to discuss improvements to articles, not engage in general discussion about the article's topic. Turning talk pages into forums or texting will only result in more users using them for the latter, and this would be detrimental to the projects. —  python coder    (talk &#124; contribs) 21:09, 27 April 2019 (UTC)

My ideal discussion page system would change the following features: Stuff that should stay the same: Stuff that should not under any circumstances be added (mostly from w:en:Wikipedia:Talk_pages_consultation_2019: —  python coder    (talk &#124; contribs) 21:59, 27 April 2019 (UTC)
 * 1) A computer-readable threading system, with individual posts separated on the wikitext end using a tag or something (e.g. &lt;post&gt;)
 * 2) Posts can also be created (both as new sections and as replies) using a visual editor-type thing
 * 3) Autosign posts in both modes; in wikitext mode, MediaWiki could detect the addition of the post tag
 * 4) CSS that identifies which posts are separate
 * 5) Ability to close via MediaWiki rather than via template
 * 1) Support for wikitext editing
 * 2) Display of signatures after posts (even though there's autosign)
 * 3) Page history
 * 4) Wikitext parsing
 * 5) Compatibility with old posts (this may be difficult but it's important; maybe no visual editor for these or something)
 * 1) Infinite scrolling
 * 2) Excessive whitespace, like in the OOUI
 * 3) Shadowbans