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.

Phase 2 questions

Click to read the the Phase 1 report!

Very briefly, the proposed direction is that wikitext talk pages should be improved, and not replaced. We propose building a new design on top of talk pages that changes the page's default appearance, and offers key tools like replying, indenting and signing posts. To keep consistency with existing tools, the new design will be a default experience that existing users can opt out of. We also propose building features that experienced contributors want, including the ability to watchlist a single discussion, and the ability to move, archive and search for threads. Building these features may require some loss of flexibility, or small-to-medium changes in wikitext conventions. The goal is to only make changes that directly enable functionality that users really want.

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?

• The general view was not "A new clearer design" i but "improving the existing system", That's improving by simplifying||adding|changing features, not adding another layer, even an optional layer. Too many things can go wrong. that is not incremental change. DGG (talk) 17:03, 18 May 2019 (UTC)
• the propensity to not do continuous improvement, but wait until a new consultation project cycle to do discontinuous improvement is a problem. you have already seen the community pushback, in spite of your unprecedented consultation. it may be too little too late; new users have moved on, and will stay away without moderation. Slowking4 (talk) 00:22, 28 May 2019 (UTC)
• The usability testing for newbies is interesting, but we know discontinuous change is confusing and annoying for people who aren't newbies. Therefore the description of a new system as a 'default' is worrying. It also should be remembered that MediaWiki is used for many non-Wikimedia projects, intranets and so on, where the Talk pages themselves may be used in a different way or not at all. The distinction into Page/Edit/Talk/Edit Talk is a basic MediaWiki concept it would be easier to explain or facilitate than overturn. If one of the problems is that new users can't find the normal 'Discussion' tab, then it seems fewer changes are needed to that function, and this new 'layer' could be a distinct 'wizard' accessed from a tab or icon on the right of the page (automating functions like the '+'/'New section' did). Are replying, indentation and signatures really the main priorities from phase 1? Yes, some newbies have to have sigs added for them, but I don't see much of a general problem. For me, the bigger issues would be: a) adding to a section without edit conflicts; b) a complete index (perhaps an evolution of the page contents (TOC)) that includes all archives. I could imagine an incremental change being the addition of newbie-friendly reply or suggest buttons, plus a discussion index per page that could include optional parameters to the code producing the TOC to: index headings subheads and infoboxes on this and related pages; include start and end dates and usernames; omit section numbers; add links to commenting features. I hope any changes are sympathetic to existing editors and prove to be useful and accessible. --Cedders (talk) 07:28, 28 May 2019 (UTC)
• The decision that "wikitext talk pages should be improved, and not replaced" excludes a priori most potential significant improvements, and ensures that the result will be even more complex than the current scheme.
  The argument that "experienced contributors in the larger communities have built a very large number of important workflows based on the ability to manipulate wikitext" is not compelling. The number of such tricks is not important; what is important is the number of editors that would be affected (positively or negatively) by a replacement. If ten "experienced contributors" would be unable to use their 200 fancy tricks when editing the new talk pages, that is a very small price to pay for making the talk pages more usable by the thousands of ordinary editors that contribute actual contents to those pages.
  Moreover, considering the dismal state of typical Wikipedia talk pages, it is hard to believe that those tricks are actually doing any good for Wikipedia. --Jorge Stolfi (talk) 21:22, 29 May 2019 (UTC)
• This is hardly the most important problem here, probably even somewhat out of scope, but I'd be glad to see the signatures being put under the respective comments on talk pages, not in-line on the last row. Especially with long posts, I find it much easier to instantly identify the author, not to mention that otherwise the signatures sometimes get broken apart at the end of the line. Liquid threads, IIRC, is doing this right IMO, except that it puts the signature on top.
  — Luchesar • T/C 14:39, 30 May 2019 (UTC)
• And another thing along the same lines: I always put empty rows between the comments on talk pages, as otherwise, and again especially with long posts, I find it really hard to follow the text. The indentation helps, true, but I feel it isn't enough on its own. This is why blank space is often inserted between the paragraphs in books—it improves legibility. I'd be glad to see this enforced in some technical way; again, liquid threads was a doing a good job in terms of legibility.
  — Luchesar • T/C 14:39, 30 May 2019 (UTC)
• On the “ping”­ functionality: some people—like me—have a name in their signature that doesn't exactly correspond to the username. Understandably, this is a source of possible confusion when pinging. I guess we could simply force the signatures to represent the username, but perhaps the more elegant (and not too hard to implement) solution could be to add a “Ping this user” link to the signatures code, which would insert the proper {{ping}} template at the text cursor?
  — Luchesar • T/C 14:58, 30 May 2019 (UTC)
• I very much like the new direction for editing. It is not clear whether the new direction only applies to Talk/Discussion pages, or to all pages. I would favor making new editing choices available for use on all pages. I also like the fact that I was asked to choose from four different preferences (in spite of the fact that the phase 1 report didn't even include the word "preferences"). I am a big fan of using preferences to allow both new editors and experienced editors to contribute on equal footing. Now, how do I end my editing in this new editor interface without four tildes? I guess I still have to do that. And how do I preview/show my edits? This is not obvious, sorry. David spector (talk) 23:32, 30 May 2019 (UTC)
• Seems to me, much ado here is about new users not knowing how/where to start a new discussion after they click on "talk" from user signature, article, etc. Best I can tell, all a new user requires is for the page to redirect to "new section" creation/edit window by default. As a Schrodinger's editor (both new and experienced), I can tell you that the best way to teach new editors is by example. When the next editors encounter the discussion started by the new user, they can edit it for indentation, they can add signatures, they can address their issues and with permission, merge them to preceding sections which might already be having the exact same discussion. This shows the new user that (1) indentation is important and how to use it, (2) signature is important and how to do it (preceding unsigned comment signed... is a good thing, but this should be possible for any other editor to do and the "preceding unsigned" should link to the four tildes instruction) and (3) that any editor can edit anything, that no user owns their content, comment, etc. (if they make any mistakes regarding this, they can be corrected/guided later on). The most annoying thing as a new user to wikipedia is another editor telling you to sign your comments with four tildes. It should be an automatic process (telling to sign that is, as I said above; signing should be done by another editor without making a fuss). When a supposedly more experienced editor tells you to sign your comments, it immediately establishes superiority and undermines an environment for free discourse. Because whatever the new user thought was important enough to go through all that hassle of starting a discussion is put on the backbench with bureaucratic red tape, essentially. Also, couldn't we additionally have a more informal looking, less scary communication system, like a live chat, instant messaging thing, where from an article you can ask quick questions to major contributors, from user space, talk to people you frequently encounter on the project, from teahouse or something, talk to experienced help, from ANI or something, talk to admin helpers. Just an environment to ask informal quick questions, u know without having to like introduce a bill to the house-floor for the proposed 14th amendment to the constitution of the United States. Usedtobecool (talk) 07:00, 13 June 2019 (UTC)
• A good communication system would have messages / posts / comments as first-class objects with indexed fields for author, time, id, thread, relates-to / in-reply-to, etc. That would then allow searching, sorting, filtering, permalinking, and flexible formatting. It's very different from MediaWiki's seemingly page-and-diff oriented structure (I don't know the internals, I'm just surmising). I also don't know much about Flow, as it's not enabled on en.wikipedia — I have heard that it exists and isn't used much. Given that doing something quite different has already been tried, then the approach of "lets layer some usability over the current system" seems reasonable. (Apologies if that's an unfair summary of the proposed product direction.) There will be limits to what can be achieved.
  • Globally unique anchors (or at least site/project-unique, in other words cross-page or not-page-relative) could go a long way to enabling derived features. Flexibility in refactoring content is valued by wiki editors, but if you change a heading name or move sections between pages then links get broken and history gets messed up. Archiving conversation threads from a noticeboard or workflow page is a prime example of this. But per-post IDs for Talk could do much more: you could have a separate index over the postings that is independent of page structure, whilst still storing talk pages in the accepted way. Sorry for going a bit off-topic, but what I'm saying is the right underlying mechanism implemented now could be built on in future.
  • I'm typing this right now using Visual Editor. It appeared as the default on this wiki and I thought "why not, I'll try it". I'm surprised — it actually works well in this context, where I'm just typing and not dealing with templates or links or adjusting article structure. (A quick test in my sandbox does give me problems with link labels, for a start.) When I clicked the section-edit link here, I was put into full-page-edit mode. In the context of Talk, this could encourage people to edit across multiple threads, which may impact things like post and thread tracking. Would a new Talk UI be built into Visual Editor or separate? If separate, we should consider what tweaks should be made to VE as well as to the underlying wikitext. And then there's mobile, see next.
  • Many editors engaging in this process [Talk pages consultation] will, like me, primarily or solely use wikitext source-editing via the Desktop site. We need to keep in mind that the editing experience is very different in Visual Editor and on Mobile, and that this applies to Talk pages as well. It's probably more relevant to Talk, Help, etc. than to content pages. This affects the scope of these Talk improvements.
  • Some of my clueless statements in the opening paragraph belie deeper questions. For example, are talk conventions (e.g. bullets and indenting) the same on other wikis? Can we encode en.wiki practices into the software? How much do we need sites / projects to be able to configure the new added features to suit their preferences?

— I'm not even sure how to sign this. Our current conventions for Talk look messy when a post has multiple paragraphs or dot-points. Maybe I am offending some convention by using nested bullets? Shrug, Pelagic (talk) 01:32, 16 June 2019 (UTC)

• In the conclusions for Phase 1 and in the proposed direction, I have a feeling that we're missing a *huge* blind spot regarding the functionality of "Article content embedded in the talk page, as a key part of the discussion". This is not very important for discussions at the project space, like this one; but Article Talk pages are often closer to collaboration groupware than they are to discussion forums - i.e. they work as a digital whiteboard where draft content and comments are intertwined. Talk pages are a space where we can compare side by side several candidate versions of the content we want to use at the article. Any new design should take into account this collaborative editing function as a priority use case, and I'm not seeing enough discussion on this point.

This use is trivial in the mediawiki tool, because any content pasted from an article into a talk page will render more or less the same (minus some complex templates, but our templates are usually prepared to support this treatment). IMHO many of the "status quo" people opposing change do it not just from a desire to keep using what they know, but because they intuitively are aware of this need and fear that it would be lost in any radical change. These are some essential properties that are critical for this use of talk pages as collaboration spaces:

- Flexibility to be expanded (with templates and bots), to support new workflows.

- Radical accountability: possibility to see the exact status of a page at any time in the past, and the exact effect of each atomic change. This has heavily influenced our policies, shaping our small community in a form able to sustain the signal from the noise - allowing us to sustain the impact of trolls and groups pushing particular interests.

- Homogeneous tools: having the same tools in articles and discussion space is what allow us to put a copy of any article content in a talk page to see exactly how it will be rendered. Even if article and talk spaces serve radically different purposes, it's essential that discussion can happen around alternative versions of parts of article content. Some editors also mention the importance of newcomers having to learn just one set of tools to work in articles and in this collaborative space.

Maybe in the proposed solution we could explore alternative ways to support this use case, by bringing part of the discussion to articles and drafts instead of copying article content to the talk page? For example we could add the capability to show specific talk threads as comments at the margin of an article or draft, anchored to a specific paragraph (Medium.com does this, and it's quite usable). This Copernican turn could help making discussion about content more discoverable to newcomers, and would help reduce the perception that our software is "not like other conversation tools", which we should avoid anyway when we are using the tool for commenting directly on specific versions of content and not for general discussion. Diego Moya (talk) 08:16, 18 June 2019 (UTC)

• As a very occasional editor over a very long period, here is my take: I am in favor of anything, anything, that makes talk pages function less like a wiki and more like the forum that they actually are. Reading this discussion I see people tying themselves in knots to prove that black is white, for instance with the assertion that talk pages are in fact proto-articles where people can discuss variants of a passage while seeing the passage as it might eventually appear. To me the logic of that is lacking: what is important are the words, and any forum software is easily capable of quotation. This very discussion is an example of why talk pages are broken. Because of paragraph breaks it is not clear where one comment ends and another begins, or who wrote what, and things get worse still if they forget to sign. People are misusing bullet points to try to fix the mess. To a newcomer it must look like a amorphous mass of text, like a particularly disorganized document with a single author rather than the complex discussion it really is. Really, this whole thing has badly needed repair since day one. A wiki, or shared document, is the perfect format for a encyclopedia. For hosting a discussion it is the wrong format and always will be. Rollo (talk) 15:07, 18 June 2019 (UTC)

• Rollo - there is a deep reason why experienced editors defend the wiki as the right tool for discussion at Wikipedia; I'm not saying it's a good or bad reason, merely that it exist and it has strong support behind it. One of the main difficulties of this current initiative is that Wikipedia Talk pages are not forums, never have been (the English Wikipedia even has a policy stating exactly that, although that's more about the purpose than the shape of conversation). You have to realize that some kinds of collaborations used at talk pages (preview article content, re-structuring whole conversations, creating new ad-hoc coordination workflows...) would be very hard or simply not possible in classic forum software.

Wikipedia is a wiki at essence, and it's not obvious to newcomers what this entails in terms of participation; the dynamics of online communities are influenced by the particular software they use, and the kind of collaboration prompted by a wiki knowledge base is quite different from the style enticed by discussion software. Wikis are tools designed to capture knowledge with the least possible friction, not necessarily to have long conversations; for that goal, other wikis typically include comments and discussion in the article pages themselves (how do you feel knowing that?); we have separate pages specific for that purpose, but these pages are also given functions in addition to just threaded conversation. That's why in my comment above I distinguished between project space, which do have more forum-like dynamics, and Talk pages which are often much closer to traditional wiki-style collaboration.

Now I understand why people would want the classic functions of a forum, and I support this project to add support for them (while keeping the wiki as the base layer), and I definitely agree that it should provide an interface for newcomers that didn't depend on knowing the specific conventions of wiki syntax usage; but previous attempts to simply replace talk pages with forum software didn't take into account that they would be reshaping the dynamics of the whole community as well, and we don't know how that would work in the end; that uncertainty caused regular editors to defend what we have and viscerally reject such a profound change. Diego Moya (talk) 08:07, 19 June 2019 (UTC)

Diego Moya, your distinction between Talk: and other discussions is one that editors have mostly not engaged with. One of the things I keep wondering is, if we'd asked experienced English Wikipedians (in particular, but any large wiki) whether the most important thing was to improve either (a) article Talk: pages and User_talk: pages, or (b) w:en:WP:AFD and w:en:WP:ANI, which they'd have chosen. Whatamidoing (WMF) (talk) 04:26, 26 June 2019 (UTC)

Whatamidoing (WMF) - which is a pity IMO, because that distinction (Talk pages vs everything else) makes for quite different use cases with different requirements. Solving specific talk page disagreements about points to include in the article, often has a dynamic (sequential one-on-one discussion with with occasional consultations with third parties, and frequent references to article content) not at all like discussing changes in community policies, or reaching consensus on complex courses of action (page-wide discussions with many participants and lost of subthreads). As a seasoned editor, I'd say it's much more urgent to create improvements on talk pages, since that's the environment that newcomers face more often. In my experience, participating in community / project discussions is something you typically find much later, after you've been involved for a while in improving articles. Also, veteran editors don't feel such a strong need for change. Diego Moya (talk) 10:03, 26 June 2019 (UTC)

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?

• An excellent added feature. But I see no reason why it cannot use the existing "== This Heading==" syntax, without having to introduce a new one that would break existing procedures. DGG (talk) 17:03, 18 May 2019 (UTC)
• Yes, marking sections for software is necessary but it probably will not be "renaming" tags - if so, current tags are enough to separate them. Maybe virtually storing sections as something similar to slots? --wargo (talk) 20:43, 23 May 2019 (UTC)
• I don't see why the current '==' h2 heading shouldn't suffice either. Wouldn't it also be possible for the software to parse existing signatures and indentation? I wouldn't object to an optional 'add your comment' button, to access additional or simplified features, appearing to the right of the '[edit]', or at the bottom of the section, or indeed a 'reply' button to the right of each comment, but wouldn't want to remove access to existing features. User page discussion I find more complicated, as there are varying conventions as to whether the reply appears in the same User talk page or the other editor's. Could the more automated 'reply' or 'add comment' be pre-filled with indentation, a signature and appropriate pings (like Twitter had until its 2017 changes)? --Cedders (talk) 07:40, 28 May 2019 (UTC)
• I would expect a new talk page to be at least as easy to use and read as a subreddit in Reddit. Namely,

1. The page is a flat list of "topics", each with a header, a "head post", and a tree of "reply posts" to that headpost.
2. Each post (head or reply) should have a "reply" button to add a reply to that post.
3. indentation and signing of each new post (head or reply) should be automatic
4. there should be a [−]/[+] button next to each post to collapse or uncollapse the entire tree of replies to that post.
5. The reader should have the option to list the topics (and the replies to each post) in either newest-first or oldest-first order. The default for the topic list should be newest-first.
6. There should be no archiving of old topics. Instead, only 20/100/500 topics are shown at a time, as in a search results or history page.
7. If a tree of replies gets too deeply nested, it is displayed as a button that opens up another window for that subtree, starting at zero indentation.

Reddit does not offer the following features, but a Wiki talk page should allow any (autoconfirmed?) editor:

1. edit any post by any other editor.
2. move any post by any editor to any other place in the structure, including another topic or another talk page, with the attached subtree of replies.
3. mark any subtree as "issue closed", and then its subtree would be collapsed by default (but not deleted) in the display.
4. flag any single post (or at least any single topic) in a talk page as "watched", so that any edits or replies to that post are reported in the watchlist.
5. In the "newest-first" display of the subtrees of a post R, there should be the option to consider only the last-modified date in each child post of R, or the most recent last-modified date in any post in each subtree of R.

Moreover, in the new talk pages:

1. Each reply post should have a one-line summary that is displayed even when that post itself is collapsed. The one-line summary of the headpost being the title of the topic.
2. there should be a separate history log for each post (headpost or reply) recording textual edits to that post; and a history page for the whole talk page, recording only the moves of posts. (The cost would not be prohibitive: most of the post edit histories would be empty, so they would not have to be explicitly stored, and their total size would be the same as the edit history of the current talk pages.)
3. there should be a way to do a textual search restricted to a given talk page, topic, or post and the respective subtree.

--Jorge Stolfi (talk) 21:57, 29 May 2019 (UTC)

• I do want to be able to watch a specific section and not be bombarded by updates every time a very large page like an ANI page gets edited. But I don't want to support any big changes without knowing what unforeseen ways they might affect things I already like. I think "watch section" ought to be possible to implement from the section identity (==text==) alone. Otherwise, it's better to make watchlist display, by default, on the edit summary parenthesis, exactly which section was edited without no more change in the current system. I have no comment on archiving and search. That quagmire, I have elected not to dive into at all, as of now. Usedtobecool (talk) 07:00, 13 June 2019 (UTC)
• Existing ==headings== would suffice for separating threads, but don't limit it to H2 ("Heading" in Visual Editor). Look at this page we're on, the functional threads are ===H3=== ("Sub-heading 1"). On other pages they might be a mix of H2, H3, H4. Something else, like the presence of a persistent ID, or the fact that the heading exists on a talk page could mark it as "watchable".

Threads can become very long: many pages between subheadings. And individual posts can also be lengthy. Collapse-post, collapse-subtree, and/or collapse-all-in-thread are features that I think many readers would want. Collapsed posts should show summary information: who, when, optional description (when uncollapsed do we display that above or below?). Top-level section headings (H2) already collapse on the mobile page. Treating posts as separate units like this means delimiting posts and discussions separately. There has been talk about parsing the signature for something like "(UTC)" to detect end-of-post. Or we could establish a convention where a certain heading level, say H6 "Sub-heading 4", represents the post-level header and everything above that is thread-level. Getting thousands of people to use that convention consistently seems difficult to me. Personally I prefer some kind of new, unambiguous markup for the start &/or end of post. (See also my entry at "Is a indentation the best way to indicate start of a post?". Sorry, I posted to Phase 1 talk before realizing that it's a bit late for it to get read there.) So yes, I favour a new markup, but for posts not threads.

To address your immediate question, pros and cons will depend on implementation details. Requiring a per-post header or footer instead of four-tildes isn't that burdensome, if there's a way to insert the biolerplate or generate the details. Managing IDs for thread splits would be more trouble; would somebody editing source be able to just generate and insert a new thread ID, or would they have to use a special thread-split tool so that the new and old IDs get linked somehow? Thread merges might just be a matter of copying an existing anchor, unless again you want to do some tracking of changes to thread structure.

— Pelagic (talk) 03:25, 16 June 2019 (UTC)

Helping newcomers find the talk pages

Context: Newcomers have difficulty finding talk pages. During user tests, only one person out of ten found the Discussion tab. Most testers looked for a Discussion 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?

• New users not finding where Talk is, seems to be a common problem, tho I have never understood why. I think adding it to them an existing right side tabs would make things worse, not better. Perhaps a clearer name, even though it would be longer, such as "Talk about Article" -- or even boldface or color. Links to (and the ability to watchlist) specific section would be a very good feature, Wikitext already has the ability to edit specific sections. Again, I don't see why it can't build on the existing ==__== markup, automatically adding a "link here" to each of them on talk pages. DGG (talk) 17:11, 18 May 2019 (UTC)
• I thing placing in current tab system is good because there are only some links and in the sidebar they will be less noticeable. But its title changing may be good idea. Connection between sections could encourage to collaborate on article. --wargo (talk) 20:43, 23 May 2019 (UTC)
• of course "timeless skin" does this already. it automatically pushed side menu to the top. however, you need to research why new users do not use talk even after they find it. a big blue button, or new "tutorial" pop-up may not be enough. - Slowking4 (talk) 00:10, 28 May 2019 (UTC)
• what would newcomers actually be looking for in reality though? Did the usability testing use real factual flaws, omissions or spelling errors? Do they want 'Ask a question', 'report problem' or do they actually want to express an opinion on the subject (which should presumably be discouraged on Wikipedia)? I would have thought to interact they might want to attempt editing themselves, or if less confident, 'report' or 'suggest'. That supports adding something near the Edit button. Perhaps a '?' symbol with a tooltip that explains you can click to add a comment or suggestion for improving the article? --Cedders (talk) 07:48, 28 May 2019 (UTC)
• A note on “discussion functionality connected to individual sections [in the respective article]”: this sounds really very nice, but what would happen if the article gets restructured? A section may be completely reworked, changing its topic—or even deleted. I can think of some possible solutions, but I'm not sure if it would really be worth the effort and resulting complexity.
  — Luchesar • T/C 14:25, 30 May 2019 (UTC)
• Yes, two talk links on one page is confusing. But not a bigger problem than requiring two extra clicks to handle. I don't see if that's big enough a problem to overhaul a system that otherwise works well. One possible solution would be to collapse all the user options into the user link itself (as is on many other sites, username is a collapsed menu, that gives user options). I agree it's more comfortable to have the current way once one is familiar but confusing the first time. You could also simply change the "Talk" tab on the article to "Discuss article" and "talk" to "User talk". In the age of cookies, you could alternatively, simply identify first time user and show them where article talk and article edit are the first time around without needing to do anything radical. Yes, the talk page can be fragmented into tabs (much like Article, Talk on article page) with About page (for the project templates), Discuss article (about the overall article and lead) and section talk (for individual sections). Usedtobecool (talk) 07:00, 13 June 2019 (UTC)
• As I commented above, a possible solution to make discussion discoverable is to create a document-centric discussion model, where comments can be shown as notes to the article margin. This is a common idiom in collaborative tools (MS Office, Google docs, also medium.com uses a very lightweight design which doesn't distract from reading article content, showing just a small mark that can be expanded to show the discussion). To avoid the problem described by Luchesar that the comments will be misplaced when restructured, the comments can be anchored to a specific point in the article with an 'anchor' tag that can be moved around when editing.

From this side panel, we could have an "expand discussion" link to the corresponding section at the full talk page, in case the discussion grows too large for the margin. Diego Moya (talk) 08:43, 18 June 2019 (UTC)

Diego Moya, I really like your concept: having the possibility to discuss (“comment on”) specific text would be both beneficial to the experienced editors and easier to get a grasp on for the novices. Using a moveable anchor also makes sense as a solution for when the text gets moved around. Unfortunately, that still wouldn't solve the issue when some text gets deleted—would this also delete all “attached” comments or would they need to go to some special place in order to be kept (after all, quite often the most heated discussions emerge exactly from deletions with no consensus on them, and it would be way too easy to sabotage the discussion by simply deleting the controversial text). I am also worried that while this system does work very well in collaborative tools, as you rightfully point out, it may be because the collaborators in those systems are usually much, much fewer at any given time compared to the typical Wikipedia cases. Very active and complex discussions with many participants may risk “saturating” such document-centered commenting system very quickly (I've seen many discussions much longer than the articles themselves). But if solutions to these problems are found, again, I think such system would be very helpful.
— Luchesar • T/C 10:29, 18 June 2019 (UTC)

My idea is that this interface would be just a view over a dedicated section in the Talk page, so that particular sections can be connected to the point of the article that they are discussing; any comment made from the margin should be recorded at the corresponding point of the talk page thread. I.e. there would be no separate "comments database", just regular edits at the talk page that can be read and written from a special user interface at the article.

For simple threads, all conversation could happen at the margin; for more complex ones, the margin could show either the first or the most recent comments. And if someone deletes the anchor, it doesn't matter, the full conversation will be available at the Talk page section.

If the WMF improved tool can detect single comments at Talk pages, the interface could even work in reverse, showing at the margin comments that were made at the talk page. An advantage of this model is that experienced users could ignore it completely and still collaborate from the talk page with editors that are using only this "article comments" feature at the article.

And if we can dream, we could even have a "reverse anchor" template, which showed at the talk page the paragraph that is being commented on, for a specific version of the Article or Draft page that contains the anchor. Diego Moya (talk) 12:10, 18 June 2019 (UTC)

Diego Moya, thank you for the explanation. This sounds like a great idea. Now that I (hopefully) understand it, it seems to me that it even can be implemented just with a combination of templates and a JS gadget, but of course it would be much better to have standardized support across all the wikis and internal support from the MW software may be needed for some advanced functionality (or at least for better integration). So, to summarize (and see if I really got it right):

• we would have a way to select portions of the text or article elements in general and start a new discussion, which would:

• mark the selected text or elements in some appropriate way (e.g. by a slight highlight);
• create a new section on the talk page with an appropriate “reverse anchor”;

• the marked section of the article may—on mouse hover or in a sidebar—present a snippet of the respective section on the talk page;
• expanding the snippet when clicked and being able to add comments (which de facto would be editing the respective section of the talk page) while staying on the article would certainly be a cool functionality, but I would be fine even if clicking on the snippet would just load the respective section of the talk page—most certainly that would also be much easier to implement;
• on the talk page, such sections with a “reverse anchor” would show in the same way a snippet (or the whole piece if it is small enough) of the respective marked elements from the article;
• clicking on these snippets on the talk page should probably open the article itself, scrolling to the respective marked part.

Again, seems like something that doesn't require serious changes to MW (depends on the details, of course), yet provides a good added value for both the experienced and the novice editors.
— Luchesar • T/C 14:14, 18 June 2019 (UTC)

Luchesar - yes, that's very much it. I hadn't thought of implementing it through wiki templates. It may work, though the trickiest part would be adding the first comment, as you would need to coordinate creating the anchor tag at the article and the corresponding talk page section. The wiki can't do it alone in a single action, so it would need a new specific function to create both at the same time; otherwise it wouldn't be newbie-friendly. Diego Moya (talk) 07:31, 19 June 2019 (UTC)

I think that there's the chance for confusion between user pages and user talk pages when communicating with other users on Wikipedia. When I was new, my first instinct was to click on the username of the editor I wanted to communicate with. That lead me to a user page and I would manually switch to the talk page. However, if you don't know how to do that, you can get 'lost' in-between the steps. Clovermoss (talk) 20:13, 23 June 2019 (UTC)

Where to show discussion tools

Context: Currently, many wikis have community discussion spaces in the project namespace (Project: or Wikipedia:), rather than in a talk namespace (Project talk: or Wikipedia talk:). 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)
• I agree with the above; In enWP, this would be a significant complication. And I see no problem with automatically adding special feature to talk pages as distinctf rom articles--i aren't they already separate spaces? DGG (talk) 17:13, 18 May 2019 (UTC)
  • DGG, the articles and article talk pages are easy to handle. However, "Wikipedia:Verifiability" and "Wikipedia:Administrator's noticeboard" are both in the same namespace. If communication tools are enabled per namespace, rather than per page, then the options are:
    • The tools are enabled on both of those pages (downside: policy pages get discussion tools).
    • The tools are enabled on neither of those pages (downside: noticeboards have no discussion tools).
    • The conversations at WP:AN have to move to WT:AN (and maybe then the meta discussions about the noticeboard's own organization, which currently happen at WT:AN, would get moved to WT:AN/Something) (downside: have to tweak a few bots).
  • Of those three options, which is your preference? Whatamidoing (WMF) (talk) 22:59, 21 May 2019 (UTC)
• Magic word is best solution in this situation. Moving to talk namespace may be not good idea because what we should have on subjectspace then? --wargo (talk) 20:43, 23 May 2019 (UTC)
• Also agree this would be very disruptive, and it seems unnecessary. Is the choice of affected namespaces not something that can be decided by the wiki's sysops and set in options, or even in the config file? --Cedders (talk) 07:52, 28 May 2019 (UTC)
• Discussion about a specific article should be carried out in the article's talk page. Most of the editors who contribute to an article do not care about the Wikiprojects that claim to "own" it (especially when multiple projects claim the same article) and would not see or contribute to any discussion that happens in any other forum.
  That also applies to the "articles for deletion" forum. Most editors who could contribute to the deletion discussion are inhibited about taking part in what — to newbies — looks like a tribunal where a cadre of permanent "deletion inquisitors" sit and pass judgement about any articles that are dragged there by the "deletion police". That impression could be lessened if the discussion was carried out in the talk page of the article itself.
  --Jorge Stolfi (talk) 23:01, 29 May 2019 (UTC)
• One upvote for User:Jorge Stolfi. No further comments. Usedtobecool (talk) 07:00, 13 June 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?

• It would have to be an additional feature, though I don't know how we could have both. DGG (talk) 17:15, 18 May 2019 (UTC)
• They should have both. Whole talk page history is useful, especially when still having normal wikitext page which allow to edit multiple threads and manipulation. Per-thread (or post) history is good for filtering progress of specific discussion, especially connecting with watchlisting. --wargo (talk) 20:43, 23 May 2019 (UTC)
• This is less of a problem for talk pages, which are mostly additive, than it is for article pages in general. On article pages, filtering history by section edited (currently facilitated visually by the -> notation) could be useful, as sometimes we have to use the bifurcating search tools to find a particularly disruptive or erroneous edit. On talk pages, the only times I look at the history are to identify which user added an unsigned edit. If signatures are prefilled on some 'easy comment' feature, that becomes less of an issue. --Cedders (talk) 07:57, 28 May 2019 (UTC)
• Perhaps I'm missing something here, but if each thread on a talk page would have a unique ID, wouldn't it be possible to filter the page history by that ID? As a matter of fact, this is possible even now with some JS code, provided that all editors, who replied in a thread, hadn't deleted the respective edit summary header. Obviously, this wouldn't work if an editor leaves replies in several threads in one edit, but this IMO isn't good practice anyway and should probably be made technically impossible.
  — Luchesar • T/C 14:18, 30 May 2019 (UTC)
  • Comment: I agree that's not good practice unless the editor is purposely refactoring multiple sections. Visual Editor drops you into whole-page edit view and makes it easier, maybe even encourages, editing across sections. I'd like to see that change. Pelagic (talk) 06:42, 18 June 2019 (UTC)
• The article history and talk page history are seperate. This is a drastic idea - but since talk pages are ultimately about improving the article, maybe the history could be merged together? So, if I'm looking at the history of an article, I can see the history of the talk page as well. You could see whether or not talk page discussions influenced edits by browsing the history. In terms of specific discussions or threads, maybe you could organize this history such as selecting whether or not you want to see "all changes" or "changes to [section]". Clovermoss (talk) 20:36, 23 June 2019 (UTC)

• Or, more generally @Clovermoss: , the ability to view a consolidated history across any two (or even many) pages? Pelagic (talk) 23:11, 6 July 2019 (UTC)

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?

Not all wikis has multiple boxes so it may be small problem. Maybe subtab or scroll would help. MCR can be used to help. --wargo (talk) 20:43, 23 May 2019 (UTC)

new users expect top posting. community has resisted this style change. Slowking4 (talk) 00:14, 28 May 2019 (UTC)

This is mostly big wikis like enwiki who like to store metadata in all talk pages. It should be somewhere else, not on the top of all talk pages. Stryn (talk) 06:48, 28 May 2019 (UTC)

• I think the current system is hard to improve on. Things like Biography of Living Person warnings are important to be read by all editors, while other boxes with optional but useful information can have 'show' and 'hide' links. The only thing I can think might encourage mobile users is to minify all but the most important templates on the top half of the initial screen and have the top of the discussion index (table of contents or enhanced TOC) as a fixed div at the bottom of the page. (I don't think this is about top-posting, but top-posting of course interferes with sequential understanding.) --Cedders (talk) 08:04, 28 May 2019 (UTC)
• Wikiproject tags should not be inserted in talk pages (or anywhere). The information they provide is not relevant to the vast majority of the editors, and the space they take (both in the visual page and in the source) is out of proportion to their utility. Instead, each Wikiproject could have a list of "pages of interest", and the wikiprojects that are interested in a given page could be available as a menu entry "Wikiprojects" in the sidebar, using the same mechanism as the "What links here" entry.
  In fact, after watching closely the activity of a couple wikiprojects, I seriously doubt that they are helping Wikipedia at all. But that is another discussion. --Jorge Stolfi (talk) 22:18, 29 May 2019 (UTC)
• Could we possibly have a hidden—“system” if you like—first section on talk pages for those templates, probably only available for editing in raw wikitext? This sounds to me like the easiest and least intrusive possible solution.
  — Luchesar • T/C 14:47, 30 May 2019 (UTC)
• Put a banner about contributing to discussion on the talk page. Move other templates to about page tab. It can be a tab in the talk page or a sister tab to the main page itself (article, talk, about) with page visit statistics made compulsory. Usedtobecool (talk) 07:00, 13 June 2019 (UTC)
• We should distinguish between important warnings (BLP, sanctions) and info/advertising (GA, FA, wikiprojects). Some warnings appear on the content page when you edit source, but not with visual-edit(!); even if that was consistent it's still desirable to have the warning on the talk page also. Wikipedia:Template:Wikiproject banner shell and Wikipedia:Template:Article history are doing a good job, IMO. It would be great if the info and project templates could be made to fit beside the TOC instead of pushing it down the page. Or we put them in a special section below the TOC? Need to consider behaviour in narrow windows and in different skins. Pelagic (talk) 08:15, 18 June 2019 (UTC)
• Note: the templates behave quite differently on the mobile site. Pelagic (talk) 08:15, 18 June 2019 (UTC)

Phase 1 questions

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

• 1. 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 <process> ... </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.)
  2. 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 | email)} 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 | email)} 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 phab: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 phab: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:

• 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 {{od}} 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.

T.Shafee(Evo﹠Evo)^talk 07:29, 1 May 2019 (UTC)

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﹠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 {{talkheader}} 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﹠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 {{s}} or {{o}} 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. — pythoncoder  (talk | contribs) 21:09, 27 April 2019 (UTC)

My ideal discussion page system would change the following features:

1. A computer-readable threading system, with individual posts separated on the wikitext end using a tag or something (e.g. <post>)
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

Stuff that should stay the same:

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)

Stuff that should not under any circumstances be added (mostly from w:en:Wikipedia:Talk_pages_consultation_2019#"Features"_that_people_really_*don't*_want_on_discussion_pages:

1. Infinite scrolling
2. Excessive whitespace, like in the OOUI
3. Shadowbans

— pythoncoder  (talk | contribs) 21:59, 27 April 2019 (UTC)

Strongly Agree that infinite scrolling should never be implemented. Scrolling using scrolled index and body is fine with me, where the index lists each section or heading in the body. Basically, I would always condition new features on preferences, so existing editors don't have to change their style of editing unless they wish to. David spector (talk) 00:03, 31 May 2019 (UTC)

Radical redesign of UI: Preferences: beginners

I'm all for radical redesign based on years of experience with the current interfaces. But, if possible, I would like to see most new features controlled by individual preferences which default to "best for beginners" for newcomers and default to "retain previous features" for experienced editors. This would create a welcoming feeling for people who try out editing for the first time and for experienced editors both. David spector (talk) 23:55, 30 May 2019 (UTC)

Radical redesign of UI: Preferences: organization

Experienced editors should have a hierarchical or question/answer interface to lead them through the individual preferences, including preferences that group other preferences together. This approach allows rapid specification of preferences without worrying about detail at first. For example, a major preference button or checkbox might be "use the experienced editor interface", but then an indented button or checkbox would allow separate specification to enable or disable the preference to insert four tildes automatically. David spector (talk) 23:55, 30 May 2019 (UTC)

Radical redesign of UI: Automatic reviewing; two panes

Showing/reviewing edits when doing source editing should be done automatically on the same page, updated after each character is typed, as is done in some forum software. One should not have to click a Review button after every edit to see what the formatted edit will look like. A preference for reviewing could control showing two panes (or panels) side-by-side during source editing. Each pane would be scaled down by 50%. The left pane would show the source text and the right pane would show the formatted result that will be published. David spector (talk) 23:55, 30 May 2019 (UTC)