Wikipedia:Talk pages consultation 2019/Phase 2

Phase 2 of the 2019 talk pages consultation began on 17 May 2019 and is tentatively scheduled to end on 15 June 2019.

Feedback from the first phase, which occurred between 21 February 2019 and 6 April 2019, has been evaluated and turned into a report. Based on the first phase's discussions, six main questions are being asked. (The questions, their section headers and the contextual information are quoted verbatim in the subsections below, under § Main questions.) Anyone may also begin a new discussion of their choice under § Other discussions.

In the first phase, the English Wikipedia was registered as a single "participant group"; this is to be the same in Phase 2. About 100 editors participated in the local discussion, and more than 300 other editors participated elsewhere. In this phase, there is also to be an option to give feedback through a Qualtrics survey (which has not been opened yet); as in the first phase, feedback can also be given on mediawiki.org and in discussions on other fora.

As in the first phase, at the end of the discussion, a summary is to be posted to mediawiki.org. Jc86035 (talk) 14:03, 18 May 2019 (UTC) (modified 08:41, 19 May 2019 (UTC))

Main questions

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?

• I like the proposed changes. I will always be in favor of changes to improve communication!DBRGoodman (talk) 14:49, 27 May 2019 (UTC)
• I'm happy with basically all of the proposed direction, although some of the technical details seem to need some ironing out. Jc86035 (talk) 14:38, 18 May 2019 (UTC)
• This is good, so long as once something has been indented by the auto-setup, it can be altered manually in the future without difficulties. Nosebagbear (talk) 15:22, 18 May 2019 (UTC)
• For some "talk" pages, it would be impossible to participate constructively without understanding wikitext, so it being possible to participate without using wikitext may not always be desirable. But these seems a process which might lead to real improvements. — Arthur Rubin (talk) 20:21, 18 May 2019 (UTC)
• OMG will we also have AJAX?? I've been waiting for it since 2006!!! François Robere (talk) 21:10, 18 May 2019 (UTC)
• I like how "this new design will be a default experience that existing users can opt out of". Different editors have different levels of comfort regarding changes to software they regularly use. Having the option to opt out of the new interface would allow editors who prefer the improved interface to take advantage of the new features, while editors who do not think the changes are worthwhile can continue to use the interface that they are familiar with. — Newslinger talk 06:38, 19 May 2019 (UTC)
  • The above comment by User:Newslinger coincides with my own view of the matter entirely. Eebahgum (talk) 15:29, 27 May 2019 (UTC)
  • The value of offering simpler tools is that it will be more inclusive for new participants. This makes it important that the default editing mode is the simple one and only skilled users will require the knowledge that they can opt out of the simplified mode. Eltimbalino (talk) 22:30, 27 May 2019 (UTC)
• I don't have a philosophical problem with making it easier to edit talk pages. With respect to this new clearer design on top of existing wikitext talk pages, please ensure that every element of the checklist I drafted is included; aside from the obvious "must be in a public log", being able to delete/revision-delete/suppress is mandatory (think of the nasty things someone could write on a BLP talk page), and these edits need to show up in the CU log as well. I'll note that checklist was drafted after about the sixth time of dealing with extensions that created publicly-viewable content that didn't show up in logs and/or couldn't be deleted/suppressed. Talk pages are obviously intended to be publicly viewable, so any overlay needs to start off with those requirements in mind. Risker (talk) 04:27, 21 May 2019 (UTC)
• The Phase 1 report has good information about how users perceived the talk page and so far I'm happy with the proposed direction, maybe some adjustment in technical details (per Jc86035) would be appreciated.--Vulphere 12:07, 23 May 2019 (UTC)
• I like the proposed changes. I also appreciate the clear, coherent prose. :O)   - Mark D Worthen PsyD (talk) (I am a man. The traditional male pronouns are fine.) 18:31, 23 May 2019 (UTC)
• In general I'm like the product direction but "simpler tools for ... indentation" does ignore, that indentation is the problem and from my and other's view not the solution to indicate the start of a post and it's relation to other posts. Please ask: Is_a_indentation_the_best_way_to_indicate_start_of_a_post?. The common standard in social media shows WHO postend WHEN and this can be used as an identifier and if needed as an anchor for replies - and can substitute indents partly or complete.Charis (talk) 10:07, 25 May 2019 (UTC)
• Support: Any move that will enhance user experiences, especially if supplied with an opt-out for those that may not like it for editing talk pages Not sure, unless able to see an example, if I would like a plan that will "substitute indents partly or complete". Again, I would have to see it in action and if it would limit the ability to insert a comment directly below someone else's comments or replies, or if it was structured so as all comments are a "next in line" flow. Otr500 (talk) 15:25, 26 May 2019 (UTC)
• Support as the best of both worlds. I get grumpy when things change and will probably continue editing wikitext; this allows me to do so without denying anyone the new interface they may desire. Certes (talk) 14:40, 27 May 2019 (UTC)
• Seems fine, although I'll probably opt out, just because I'm used to the current display method. Oaktree b (talk) 14:42, 27 May 2019 (UTC)
• Support the proposed changes. --Rosiestep (talk) 14:53, 27 May 2019 (UTC)
• I think that's great. I'd like to support it although the existing one still suitable for me. Samuelsp15 (talk) 15:16, 27 May 2019 (UTC)
• I don't believe a new appearance is necessary, and will probably opt out if it ever is deployed, but would welcome some tools for easier formatting, in particular for indentation. These tools, however, must be independent of the appearance. Would it be possible to introduce a tree-like structure? --Schlosser67 (talk) 15:46, 27 May 2019 (UTC)
• Support obviously. Masum Reza^📞 16:00, 27 May 2019 (UTC)
• Support: this is the real idea that people think is obvious. Benjaminkirsc (talk) 16:40, 27 May 2019 (UTC)
• Support: this is a good step forward, indenting, replying, sectioning and threading of a talk page are all way more difficult than they need be. —Flicky1984 (talk) 16:46, 27 May 2019 (UTC)
• Support glad that the foundation finally accepts the need for autosigning on talkpages. Interesting to hear that newbies find it difficult to get to talkpages, but if we don't have to tell all newbies about the need for four tildas, maybe we can update some welcome messages to tell people how to get to article talkpages. ϢereSpielChequers 17:43, 27 May 2019 (UTC)
• Support I had trouble getting the hang of talk pages when I started out. - ZLEA _T\^C 18:01, 27 May 2019 (UTC)
• Support: this seems to be one of the best solutions available. Registered users may be provided with a profile's option in order to set as their personal default value one of the following: the existing wikitest talk pages or the new feature. This is for all the WP articles in all the Wikipedias supporting it. In each WP talk page, users (both logged and anonymous) also are enabled to switch from a mode to another, both in the desktop and in the mobile version of WP.Micheledisaveriosp (talk) 18:12, 27 May 2019 (UTC)
• I suppose I'm not picky about how talk pages are formatted since I've only read the key parts of the 'proposed direction'. That being said, I'm all for the general idea and purpose of making talk pages easier to edit and navigate, as long as it's an alternative rather than a replacement, seeing as while the current format has its faults, doing away with it would case more problems than it'd solve (the same reason why visual editing didn't replace wikitext editing). Therefore, I support the proposed direction its in spirit, while not being so much concerned with its particulars. Does that make sense?—Mythdon (talk • contribs) 19:39, 27 May 2019 (UTC)
• Support I like the approach of the Visual Editor, which gives editors the option of a simpler interface with automated tools while retaining the underlying Wikitext. –dlthewave ☎ 19:47, 27 May 2019 (UTC)
• Very much support, I think the talk pages' format of editing posts and whatever is awful. It's unintuitive and tedious to edit wikitext if I only want to add a short comment. - VeryGoodDog 21:18, 27 May 2019 (UTC)
• Support: This looks like a good path forward to me. I like the talk pages, but their current layout is unintuitive for new users. They are familiar to established users, and established users may have habits and even software tools that will break when things get updated, but even the established users will be more productive and comfortable after they get reestablished with the new talk page functionality. It will take time to adjust human habits and patch software tools, but that is the price of progress. And this is Wikipedia, so the cost-benefit discussion of each painful change will be discussed in painful detail. I trust this community to move forward while making reasonable compromises. Fluoborate (talk) 21:22, 27 May 2019 (UTC)
• Support: Being able to talk without knowing how to indend seems like an excellent idea. One thing: I'd like to be able to type complex wikitext (including tables, bullets and so on) and have it automatically formatted/indented to the correct level. Also on autosigning, I'd like it to be really obvious whether I need to type ~~~~ on any given occasion as a post that gets signed twice (manually then automatically) always looks silly. User:GKFX^talk 21:27, 27 May 2019 (UTC)
• Support: No objections to the direction, as it'll be a boon to both the experienced and the new. I may have some qualms with some bits, but the overall direction is correct. —Javert2113 (Siarad.|¤) 21:55, 27 May 2019 (UTC)
• A, B, C? Let's assume the new tool will operate as intended. Is the intent to (A) restrict tool users to a narrower scope of comment than currently available; (B) maintain parity; or (C) offer tool users greater flexibility of expression than can be found in wikimarkup? If A then the concept is <a sop thrown to the digilliterte mass||a failed attempt to dethrone techwiz-deacons> and the exercise does not pay for debate let alone implementation. If (B) the tool is as easy and powerful as markup anyone can edit then this debate is bikeshedding over the correct shade of eggshell. If (C) tool users lose nothing against markup holdouts then what use the option to refuse? & rarr; IRL, tool constraints will be geared to curbing the most blatant abuse and foolishness; and avoided by bullies and fools. — Xiong熊talk* 23:03, 27 May 2019 (UTC)
• More of the same is not desirable unless you are buying time by deferring the communication problem. Additions by users can still be in the usual wiki method or by quick-edit window (new feature, client-side) at the bottom. As expected, practical changes should try to transfer the changes to Talk by moving processing burden to be client-side. Talk has both visual searching of changed items and visual confusion from many "equal status" displays of obsolete items. Automatic compression of old sections can be done client-side. Since dates of responses are known, so automatic compression of that section occurs if no one added any comments to that section in the past XXX days (set-able by the user). Thus, old items compress down to one line while newer items remain displayed for both context and reading of the most recent talkable items of concern. AnimeJanai (talk) 23:19, 27 May 2019 (UTC)
• Support the proposed changes. this is a good step if approved in Wikipedia, for indenting, replying, sectioning and threading of a talk page. It would be a great help for all Wikipedians. AR.Dmg (talk) 23:50, 27 May 2019 (UTC)
• 'Support': This helps not only new users who might be intimidated by learning syntax just to talk, but might save experienced users some clicks if there is a good way to handle indentation and signatures automatically. The fact that it allows editing if wikitext if wanted is also a big plus. Ideally, the features are good enough that people voluntarily use the new interface for most common actions of the talk page. Forbes72 (talk) 01:09, 28 May 2019 (UTC)
• Support: While i'm sure i won't use it, and will opt-out, I think it's good for new users. Hauunanodesu (talk) 03:05, 28 May 2019 (UTC)
• Oppose. Wiki pages as a discussion forum are a failure, and quite frankly embarrassing, considering that proper tools for facilitating a discussion forum (i.e. forum software) have existed for decades. You now propose to pour a huge amount of work into making wiki pages function both as wiki pages and discussion forums. I guess you might succeed at it, but why reinvent the wheel? Why mash together two things that have different purposes? Talk pages should not be a wiki, they should be a proper discussion forum. If people need to put wiki text in them, you can have insertable wiki sections where wiki text can be rendered, much like you can insert a picture or code section. That's a far better and easier solution than creating a forum-wiki hybrid. Silver hr (talk) 03:27, 28 May 2019 (UTC)
• A good idea could be a "Live" chat functionality, for decision making, or perhaps adding a pole, where editors can vote on what is the best action for the article. It may not be, just thought I might put it out there. Sorry if someone said this already.0w0 catt0s (talk) 04:27, 28 May 2019 (UTC)
• Support. I very much appreciate being given the option to opt-out, as I most likely will do. -- œ^™ 06:05, 28 May 2019 (UTC)
• Support, so long as, and only so long as, those who "opt out" will see talk pages exactly as they work right now. Bolt whatever you want on top of that, but absolutely no changes to it, so no "magic words", no "you may need to learn some new convention...", or whatever else. Talk pages as they are right now work fine. If you want to throw some interface on that, to make it easier, go ahead and do that. But no changes to the underlying structure. Seraphimblade ^{Talk to me} 06:48, 28 May 2019 (UTC)
• Caution (I'm duplicating my comments from the MediaWiki.org consultation in case they suggest anything to users here.) 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^tk 08:48, 28 May 2019 (UTC)
• This sounds like a nice idea in theory, but the devil is in the details. When the data underlying a system is either unstructured or semi-structured, the system can fall apart or behave strangely, and I suspect a talk page system that is unstable is likely to be (correctly) abandoned by communities, thereby achieving nothing. It's certainly possible to build nicer experiences on top of wikitext—the visual editor is a good example of this—but it's a very large, multi-year undertaking. Is this going to be a multi-year project, or is it going to be a series of quickly hacked together scripts which are then left abandoned so that teams can move onto the next project? Quickly hacked together scripts definitely have their place in the process—as a proof of concept, as early prototypes, or as minimum viable products—but they're not a long-term solution. In short, it's a nice statement of principles, but I can't really say I support it until more details become clear. --Deskana (talk) 09:37, 28 May 2019 (UTC)
• sounds good! TTTime05 (talk) 09:50, 28 May 2019 (UTC)
• Support. There are many issues with talk pages right now, such as it being hard to scroll through talk pages on the desktop site when there are long discussions. I think this can go somewhere good, because there is nowhere to go except up from here. Invalid^OS (talk) 11:34, 28 May 2019 (UTC)
• Support. Obviously I have to support. Gun23man (talk) 11:59, 28 May 2019 (UTC)
• Support I may have gotten to the point of hating change - but anything that helps people communicate is a good thing. (to an extent - I'm not going to go off on a tangent about cell phones, texting, tweeting and whatever else they call it these days.) — Ched :  ?  — 12:11, 28 May 2019 (UTC)
• Support: I am always willing to try improvements. Hoping it works! Rorix the White (talk) 14:09, 28 May 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?

• I think this generally wouldn't be a bad approach, and it would pretty much be necessary for introducing section watchlisting in any way. One way I could see this working would be to include a random 128-bit identifier in each new section header. This ID could be used as a secondary anchor to the one generated from the displayed text (allowing edit summaries to link to it), and could also be used in a tagging system so that all edits to the section could be found at a special page (which could be linked from the header itself). This would resolve several different issues, including section linking on multilingual wikis and finding all edits to a particular section. Jc86035 (talk) 14:38, 18 May 2019 (UTC)
• If any part of this will make "sections" separate "pages" (like flow did) then please no. Also, sections can currently be very fluidly managed - they can be renamed, merged, have their parent/child level changed. I'm all for improving the use of section titles in edit summaries - and then for major watchlist improvements like "watch for this summary on this page". — xaosflux ^Talk 15:20, 18 May 2019 (UTC)

  +1 on the last point. There is a simple way to implement a feature for watching specific sections: edits that contain /* section_name */> are the edits to the section. Simple. I know its possible to make changes in the section by editing the page, but such behaviour is uncommon, and can be discouraged if we implement such a feature. Anyway, if someone does need to edit the whole page, they could write out the /* ... */ syntax manually to aid watchers. SD0001 (talk) 17:06, 18 May 2019 (UTC)

  Unfortunately, that doesn't necessarily work, at least at the present time. If an editor starts editing a section, but gets an edit conflict, the /* section_name */> remains in the comment, but the edit could change any section. — Arthur Rubin (talk) 20:39, 18 May 2019 (UTC)

  @SD0001: - my reading of that would be that edits to the page would ding each section's watchlist (whether in it or not), which seems a reasonable negative to bear for when page-wide editing has to be made. It means there'd still be some false positives but would avoid generating lots of complexity if someone wanted to edit multiple sections. Nosebagbear (talk) 22:45, 18 May 2019 (UTC)

  @Nosebagbear: Yes. To add into this flow of ideas, we could have the "edit lead" button (&action=edit&section=0) displayed on all discussion pages, so that people can edit the the metadata (talkheader, old xfd, wikiproject tags, etc) without dinging each section's watchlist. SD0001 (talk) 03:22, 19 May 2019 (UTC)

  @Nosebagbear: I think it could also be possible for edits to the whole page to be automatically tagged based on which parts of the page are modified, but this would be somewhat dependent on none of the section IDs being changed (in theory, it should always be able to detect if an entire section is deleted). Jc86035 (talk) 17:23, 19 May 2019 (UTC)

  Agreed. However, discussion threads that get too long should be automatically collapsed, and only the last so many comments in a thread should be visible to make scrolling easier. The last thing I want is something like Wikipedia:Redirects for Discussion, where the page is too long and takes forever to scroll through. Awesome Aasim 15:03, 22 May 2019 (UTC)

• Re-naming threads is frequent, and splitting et al at least occasional. I am somewhat against any change. If and only if it is, it would need to be made extremely user-friendly to do if altered from the current set-up. Nosebagbear (talk) 15:22, 18 May 2019 (UTC)

  @Nosebagbear, Xaosflux, and SD0001: From reading the phase 1 report, I think the reason this question's being asked is specifically because it's (technically) difficult or impossible in the current system to distinguish separate comments and distinguish unique sections over multiple revisions of a page. As such, extra metadata or markers might be automatically added to comments, and/or each section would be turned into its own entity separate from the discussion page itself (as noted previously, I'd favour the former approach). I don't think there are any other options that don't involve a lot of assumptions and guesses on the part of the software (e.g. having an extra parser specifically for identifying sections), which is probably the wall that the Flow team ran into. The phase 1 report specifically states that "the intention is to only make changes that are necessary, in order to enable functionality that's worth making the change", illustrating the point by using the notification/mention system as an example. Jc86035 (talk) 18:08, 18 May 2019 (UTC)

  Nosebagbear, You should try this https://nostalgia.wikipedia.org/wiki/HomePage :) —TheDJ (talk • contribs) 18:29, 27 May 2019 (UTC)

• On user talk pages, I frequently end up combining sections with identical names (Twinkle-generated Month-Year headings for warnings), or some other automatically generated section headings. Creating, splitting, merging, and reordering sections might require special actions. Our bots and tools which create sections might also need rewriting. This needs more work to see if what is necessary to maintain section histories can be done without making edits too difficult. — Arthur Rubin (talk) 20:39, 18 May 2019 (UTC)
• Question: Does a section correspond to a level 2 header? And, if so, do the subheaders have to be tagged with the level 2 header for tracing? — Arthur Rubin (talk) 20:56, 18 May 2019 (UTC)

  @Arthur Rubin: Presumably a "section" is defined as a level 2 header. The software could theoretically auto-tag an edit as it's published instead of just checking if the text in the edit window contains a thread ID, but this all depends on how everything is implemented (there might not even be thread IDs; I think I just made up the idea of tagging edits without asking if it was feasible). Jc86035 (talk) 12:00, 19 May 2019 (UTC)

• Yes. François Robere (talk) 21:29, 18 May 2019 (UTC)
• I think it would be easy for this to make editing in codeview a lot more difficult or impossible, which I would strongly oppose. Espresso Addict (talk) 23:38, 18 May 2019 (UTC)
• People say they want this but they probably do not understand the issues. If someone complains about me at WP:ANI I might naively want to watch only the section where I was mentioned. However, that section might be removed and reposted at WP:AN as the more appropriate noticeboard. Or, the section might be collapsed or deleted and the content moved to an earlier section about the same underlying issue. If implemented, watching a section should be on a best-effort basis with no promises—the only way to make it certain would be to reincarnate Flow which is definitely not wanted for reasons I could go into if anyone has a spare couple of hours. Johnuniq (talk) 05:30, 19 May 2019 (UTC)

  @Johnuniq: Presumably you'd still be able to see the edit in which the section's removed, assuming that the software figures out which threads are affected by edits of the whole page (I have no idea if that'll happen but I hope it does). There's always going to be a way for someone to mess it up, but functional section watchlisting would at least be an improvement. Jc86035 (talk) 12:04, 19 May 2019 (UTC)

• So yes. I think I mentioned this in Phase 1. There is a section in the upper-tier of my talk (I don't like to archive open and unresolved issues). And detailed discussions dating back to 2014 on a subpage of my talk. Task T22307 was opened by Brion VIBBER back in 2009. It sat dormant until I pinged it in November 2015. It got plenty of support in that month's Community Wishlist Survey but not enough to make the "top 10". A volunteer developer claims to have produced code that, teasingly, almost works... "patch sets" have been submitted for review, but there've been roadblocks that have kept them from passing through review to the next step for implementation. Leadership at the WMF has found it difficult to see how one could do this "right" and said that adding section links to edit summaries without user prompting would be very poor form, and goes against our user expectation models. It's going to be hard to watchlist sections on a talk page if you insist on letting your users, including the trolls, be in charge of making the section links. The rules for making an edit-summary section link should be pretty simple: (1) If the editor edits the lead section, then no section link in the edit summary. If the user edits below two or more level-2 headers, then no section link. If the user edits within one level-2 section, then that becomes the section link, unless they also edited only within one level-3 section, then that becomes the section link, unless they only edited within one level-4 section, then that becomes the section link... Once you have consistent, reliable and accurate software-controlled edit-summary section linking, then you can watchlist for changes within those sections, including for the removal of those sections. If you're watching a level-2 section, then changes to a level-3 subsection will also ping the level-2 section above it, unless the user explicitly limits their watching to the level-3 level. You don't have to do all the bells and whistles at once. You can roll out improvements in phases (agile development). The first, most basic use case is for when a new section is added at the bottom of a talk page. For example, THIS edit, which did not have any edit summary, should have been given the summary /* Requested move 12 May 2019 */ – that should be an entirely uncontroversial enhancement. And if an editor changes the title of a section, that should ping those watching that section, and their watchlists should automatically update to continue watching that section under its new name (unless the user removes it from their watchlist). – wbm1058 (talk) 19:26, 20 May 2019 (UTC)
• I'd really like to be able to do this, and I think I've been saying it for years. On the other hand, I don't consider it a required feature, and it would not be a deal-breaker if this still remains too complex for effective implementation. Risker (talk) 04:30, 21 May 2019 (UTC)
• I'm neutral on this one. Perhaps a "test run" on specific Talk pages might help us better understand how it would work in practice.   - Mark D Worthen PsyD (talk) (I am a man. The traditional male pronouns are fine.) 18:33, 23 May 2019 (UTC)
• Agree with User:Nosebagbear: While many might be extremely computer literate there are some of us that are not, so "it would need to be made extremely user-friendly". Otr500 (talk) 16:44, 26 May 2019 (UTC)
• A great idea in theory. I often want to watch, say one RfD without having my watchlist clogged with comments on the day's other proposals. The devil may be in the detail but if we can make improvements without imposing Flow 2 then I'm all for it. Certes (talk) 14:43, 27 May 2019 (UTC)
• Sounds like an easier-to-use talk page, which can't hurt.I like the idea of a "test run" first to see how it works, but sounds ok so far. Only downside I can see is that it will have too many "subheadings" and get too complicated to follow. Seems like a good idea. Oaktree b (talk) 14:45, 27 May 2019 (UTC)
• Support: sounds like a positive step forward, but I would like to see a batter contents list of a talk page as part of this new approach. —Flicky1984 (talk) 16:48, 27 May 2019 (UTC)
• Support: The ability to watchlist an individual section, and view its history separately as well, would be a huge improvement for busy pages like ANI. Issues like moves, renames and splits don't seem insurmountable; let's see what WMF comes up with and test it on a few pages first.

I'd like to see some sort of built-in archive search/browse function that works on every page instead of relying on a Wikitext-based box/banner. –dlthewave ☎ 20:04, 27 May 2019 (UTC)

• I support being able to watch an individual section. Some talk pages have a huge number of sections. Recommendation: Do not use the section header as the identifier. Use a persistent identifier, such as Talk Page Section 1, Section 2... Section N. If anyone changes the title of that section, all of the people watching "Section N" for that value of N will still be watching it. I am well aware that many things in Wikipedia work based on title, but this should be ordinal number or persistent identifiers, because talk page sections are often about what the proper name or term might be. Fluoborate (talk) 21:27, 27 May 2019 (UTC)
• Support Fluoborate's recommendation: I like this idea, in theory; always good to not hear about something extraneous on a Talk page. I'd like to second Fluoborate's idea, insofar as it is technically feasible, and so long as the enumeration of the identifiers does not prove to be too cumbersome. (For instance, if it's A to Z, I don't want empty sections for, say, W, X, Y, and Z.) —Javert2113 (Siarad.|¤) 22:02, 27 May 2019 (UTC)

Addendum: Insofar as those empty sections are just white space on the web-page. —Javert2113 (Siarad.|¤) 22:03, 27 May 2019 (UTC)

• "Stay in your lane." Yell it loudly, plant Botts' dots, pour Jersey wall. Some obey, some sneak over, some jump the boundary; many honk behind the inevitable stall. — Xiong熊talk* 23:16, 27 May 2019 (UTC)
• I don't see why the current '==' h2 heading shouldn't suffice. 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^tk 08:50, 28 May 2019 (UTC)
• I echo my comment in the above section: nice idea, but the devil's in the details. There are examples of wikitext annotations being able to provide semi-structured behaviours, such as mw:Extension:Labeled Section Transclusion. Section transclusion would certainly be useful on-wiki, but it never took off. Why is that? I don't know the answer, and it seems like it'd be useful to know before undertaking something quite similar. So, as above, I'd like to learn more. --Deskana (talk) 09:48, 28 May 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 Talk tab. Most testers looked for a Talk 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?

• As a Timeless user, I think that the Vector user interface generally leaves a lot to be desired. As noted in the phase 1 summary, users might mistake the link to their talk page for the link to an article's talk page; Timeless always hides this link in a drop-down, which might help. Emphasizing the important links (whether through placement, size, symbols or other formatting) would also help a lot. Jc86035 (talk) 14:38, 18 May 2019 (UTC)

  @Jc86035: in looking at the skins, I actually think timeless (example) may have the best direction with the "View - Edit this page - History" in the top right of the article area, using something like that with a "Discuss changes to this article" or something may be good. — xaosflux ^Talk 15:24, 18 May 2019 (UTC)

  @Xaosflux: I do think that that helps, although I wouldn't assume that it would result in statistically significant improvements. In general, porting over certain features from Timeless and the Monoboook mobile view would probably improve the design a lot. Jc86035 (talk) 18:25, 18 May 2019 (UTC)

• An absolute must - this change would only cause temporary minor irritation (retraining fingers etc) - for some major gains. Nosebagbear (talk) 15:22, 18 May 2019 (UTC)
• The strategy for desktop vs mobile should be completely different here - is there more information about the interface the testers used? — xaosflux ^Talk 15:24, 18 May 2019 (UTC)
  • Xaosflux, they used desktop, Vector, on test.wiki, e.g., https://test.wikipedia.org/wiki/Talk:Mountaineering_TEST_00 See mw:Talk pages consultation 2019/New user tests. Whatamidoing (WMF) (talk) 20:21, 20 May 2019 (UTC)
• The obvious con would be if leaving comments on the talk page were too easy, we risk repeating the Article Feedback debacle (whose root cause was essentially "lots of clueless people on the internet"). Any improvements in accessibility need to be balanced against a potential increase in moderation workload. MER-C 19:47, 18 May 2019 (UTC)

  While keeping talk pages less accessible for everyone helps ward off low-quality comments from inexperienced editors (i.e. security through obscurity), I don't think the benefits of the status quo justify the drawbacks. Less accessible talk pages also discourage high-quality and good-faith discourse from editors who are unfamiliar with Wikipedia's interface, and lower the chance that our readers end up joining the Wikipedia community as editors. I would prefer to encourage these readers to participate in talk page discussions and to join the community. These new editors would become more experienced over time, and eventually take on roles to help moderate the increased talk page traffic. — Newslinger talk 06:26, 19 May 2019 (UTC)

  Newslinger, i'm off the same opinion. Sticking to something that scares away most people will just end you up with not enough people to keep your community alive. More people, will also eventually mean more people to deal with cleaning up the trash. —TheDJ (talk • contribs) 18:37, 27 May 2019 (UTC)

  @MER-C: I think one of the main problems with the article feedback system was how it was implemented. The edit request system (still operational, of course) works somewhat similarly, but it has tracking categories and a bot. Then again, it's somewhat difficult to find and still requires posting to talk pages (and the link to make a request is only active on protected pages), so that might be partly why it's not overwhelmed with test edits. Jc86035 (talk) 09:10, 19 May 2019 (UTC)

  • Part of the problem with Article Feedback was that the reader was given suggestions of what to put in the feedback, most of which were inappropriate for any given page, with the result that the same set of pointless comments were made on hundreds of feedback pages, overwhelming the actually useful feedback with things like requests for images in articles where images were not needed. Whatever we do, we must never put stupid ideas into the minds of our readers, because enough of them will take the suggestion to heart and respond in a way that will create vast amounts of garbage to clean up. The pushback could cause the change to fail. · · · Peter Southwood ^(talk): 05:59, 28 May 2019 (UTC)
• The TP is a tool. The entire tools section needs to be redesigned. François Robere (talk) 21:34, 18 May 2019 (UTC)
• I'm still using MonoBook, so can't comment on where the talk tab should reside (it's pretty clear in MonoBook, right next to the default tab). Putting talk links in individual sections pre-supposes that there is any sort of structured section-by-section discussion, which in the vast majority of talk pages, is not the case. I think more thought needs to be given to why we might want to encourage newcomers to post to article talk pages. The vast majority of such comments I've seen fall into general chat, chat related to the article subject, and unfocused complaints that the article is biased or fails to cover xxx; very little is at all actionable or useful, and some needs immediate removal under the BLP policy. Espresso Addict (talk) 23:32, 18 May 2019 (UTC)

  Espresso Addict, "it's pretty clear in MonoBook, right next to the default tab" that's pretty much where it is for Vector users too... —TheDJ (talk • contribs) 18:40, 27 May 2019 (UTC)

• Sorry to be a wet blanket but the last thing the community needs is comments from people who cannot find the talk page. If there are skins where that is difficult, fix the skins. If really wanted, an experiment could offer in-your-face discuss this buttons with proper logging of the results and thorough analysis of the outcomes of such comments. My prediction is that while participation might go up, any benefits would be outweighed by junk. Junk damages talk pages as it accumulates and drives off good editors. Johnuniq (talk) 05:37, 19 May 2019 (UTC)

I think one problem is we actively don't want people to discuss this, and we shouldn't be inviting them to do so. How one codifies Is there a problem with this information? Can you improve this information? Do you have access to reliable sources that contradict/expand/update this? Can you translate a better article on your native-language wiki? Can you supply a photograph of this? in a visible but not-too-intrusive link is beyond me. I don't care if only 1 reader in 10 can find the talk page. I care whether the 1 reader in whatever who knows something non-trivial based on reliable sources is capable either of just wading in and adding the material with the source or of finding the talk page and explaining exactly what needs doing. Perhaps the existence and purpose of talk pages needs to be explained more clearly to those obviously good-faith editors whose early edits are reverted for eg lacking reliable sources or not being in good enough English. Or perhaps not -- we don't actually want readers to post on talk pages, but to edit articles. The other type of note from newbie editors I occasionally see on low-traffic talk pages is "this needs fixing but I don't feel confident to do so, please help!" usually dated more than a year ago, and unanswered. Espresso Addict (talk) 07:26, 19 May 2019 (UTC)

@Espresso Addict: I think the assumption behind this, and a lot of the WMF's initiatives, is that improving something for all readers would also improve it for those who have something useful to contribute. I don't know the extent to which this is an accurate assumption, but there are almost certainly some people out there who would both benefit from this (i.e. by being able to find the talk page) and have some sort of positive impact on Wikipedia. Something more proactive would be better, of course, but the consultation is mostly about changing the software. Jc86035 (talk) 11:31, 19 May 2019 (UTC)

As with everything there's a problem of balance. En-wiki has many millions of readers, but only a few thousand active editors. If even 1% more readers choose to comment because of this initiative there's the potential to generate far more discussion than editors can handle. Everyone hopes that this will lead to readers converting to editors, but is there any evidence this happens in practice? Is there any way of guiding readers who desire to comment so that their experience is positive and leads them towards editing articles? Espresso Addict (talk) 22:10, 19 May 2019 (UTC)

Correct me if I'm wrong, but I think your concern is that making talk pages more accessible would lead to Wikipedia's very own Eternal September, where a mass influx of newcomers who are unfamiliar with Wikipedia customs overwhelm the current editors. That's a real possibility, but there are ways to prevent and mitigate it:

• Any talk page visibility improvements should be tested on a small number of articles at first, and then gradually enabled for more articles as we learn how to handle the increased traffic.
• Talk pages with too many overheating or nonconstructive discussions should be protected.
• New editors should be made aware of Wikipedia's policies and guidelines. The current message displayed above the editing window is not helpful enough:

Content that violates any copyrights will be deleted. Encyclopedic content must be verifiable. Work submitted to Wikipedia can be edited, used, and redistributed—by anyone—subject to certain terms and conditions.

It mentions a couple of critical subjects, but doesn't cover enough ground to adequately inform new editors of our expectations. A summary of (or link to) the Wikipedia:Simplified ruleset and a reminder that talk pages are not discussion forums would be more effective. Also, the message is in italics, which makes it less noticeable. The message should made more prominent for unregistered and non-autoconfirmed users, and wrapped in a bright banner. To minimize intrusion, the banner could be collapsed by default for editors that are at least autoconfirmed.

Although this section appears to focus on the desktop interface, I'd like to emphasize that editors using the mobile website and mobile apps should be shown the same message. (They should be shown editnotices, too: T201595, T201596, T201597.)

We can guide new editors to become constructive editors by encouraging them to edit articles themselves (after reading the rules). We already do this for edit requests when the requester has the ability to do it themselves (i.e. "According to the page's protection level you should be able to edit the page yourself.") and we can apply the same principle to any editor who has a constructive suggestion. — Newslinger talk 07:43, 20 May 2019 (UTC)

@Newslinger: That text is at MediaWiki:Editpage-head-copy-warn. The name of the interface page indicates that it's only supposed to be a copyright disclaimer, but there's already a bunch of other text tacked onto it, so I think this would be a fairly uncontroversial change (although removing the verifiability link might be somewhat controversial). Modifying MediaWiki:Anoneditwarning or MediaWiki:Editnotice-0/MediaWiki:Editnotice-1 could be better. Jc86035 (talk) 16:55, 20 May 2019 (UTC)

​Thanks for the links! Yes, I think these templates should be more visually prominent and contain a more comprehensive message. The current link to the verifiability policy should be supplemented with additional guidance, perhaps a short bulleted list (with brief descriptions) of the policies/guidelines that are most relevant to new editors. Mobile users should also see the template, which requires changes to MediaWiki. — Newslinger talk 21:53, 20 May 2019 (UTC)

​For future reference, I found those pages by appending &uselang=qqx to the page URL.

I think adding too much text would be detrimental. You know how no one ever reads the terms and conditions? (I'm not sure if there's a term to describe that.) I don't think I've read even those three sentences of italicized text in a very long time. Jc86035 (talk) 23:40, 20 May 2019 (UTC)

​You're right, too much text is not helpful. I'm concerned that the current message doesn't adequately communicate our rules to new editors, and I'm sure there is some middle ground that would be an improvement over what we have now. For example, USA Today's website has a bright blue link to their Conversation Guidelines above the comment box of their articles, which is similar to the Wikipedia:Simplified ruleset page. — Newslinger talk 23:47, 20 May 2019 (UTC) And thanks for the &uselang=qqx tip, which is very useful. — Newslinger talk 02:41, 21 May 2019 (UTC)

@Newslinger: Perhaps the text should suggest in some way that reading the page improves the likelihood that new users' contributions would be useful and/or wouldn't be reverted? I'm not sure how this would be phrased, though, and it would have to be fairly concise. Jc86035 (talk) 00:00, 21 May 2019 (UTC)

@Newslinger and Jc86035: Probably better to use Template:Editnotices/Namespace/Main and Template:Editnotices/Namespace/Talk rather than MediaWiki:Editnotice-0/MediaWiki:Editnotice-1. Anomie⚔ 00:29, 21 May 2019 (UTC)

Belated response to Newslinger's original comment: I'm not sure that edit notices are adequate. There's a fundamental problem that readers-who-are-not-editors are likely to assume (based on other internet venues) that the talk page is intended as a discussion forum, and moreover (having never tried to edit) will find it difficult to understand their actual purpose. If people are encouraged to participate, they are likely to feel discouraged if their desired form of participation is unwelcome – and doubly discouraged if they manage to raise an appropriate query but fail to receive any response. Any trial of accessibility increases could perhaps be integrated with an automated invitation to the Teahouse to any new editor who comments (or an invitation to IPs to create an account), or to a relevant Wikiproject that's still active and welcoming to newcomers (if any can be found). Espresso Addict (talk) 23:58, 25 May 2019 (UTC)

Automated invitations to the Teahouse and relevant, active WikiProjects are a great idea. A bot could monitor talk pages for new editors who are making their first talk page edit on Wikipedia, and then invite them to one of the article's tagged WikiProjects (provided at least one of them is active), and/or the Teahouse. For this to be successful, WikiProjects would need to provide appropriate guidance to new editors. Personally, I'm happy to communicate with new editors to motivate them into contributing constructively, and I believe the effort is worth the extra participation.​ — Newslinger talk 05:42, 26 May 2019 (UTC)

• I have spent years wondering why people expect to get responses to anything they write on a talk page. I've been here for 14 years, I'm pretty selective on where I post to talk pages, I know how to figure out if anyone is watching a page, and even still I'd say I only get responses to about 60% of talk page posts. I don't think there's really all that much correlation between being *able* to post to talk pages, and actually having a discussion on one. I'd venture to say that, with the exception of busy or highly-watched pages, most article-space talk page posts do not result in a response, and I do not see that changing regardless of how easy it is to make talk page posts. I can understand that new users might find the absence of response to be disturbing; even for articles with dozens/hundreds of watchers, it's not unusual for there to be a large gap between initial post and response. If we were to focus on other types of discussion pages (e.g., noticeboards, XfD discussions), that would be a very different story; most of these pages will have responses, many of them quite promptly, although again there may be extended gaps in the discussion. "Ease of use" is one issue, but it really isn't addressing the core issue, which is that a lot of the time, nobody's responding.

  On the other hand, being of the oversighters whose workload increased exponentially with the article feedback tool, I do worry a little bit that putting *too much* emphasis on the talk pages may encourage a lot more "clueless on the internet" additions. I'm good with improving accessibility to the talk page, generally speaking. Risker (talk) 04:18, 21 May 2019 (UTC)

• I'm generally in favor of helping newcomers understand how Wikipedia works, including finding the Talk page and learning how to post a question or start a discussion. At the same time, several cautions/concerns posted above by other Wikipedians make sense. I like Espresso Addict's questions at 22:10, 19 May 2019 (UTC): "Everyone hopes that this will lead to readers converting to editors, but is there any evidence this happens in practice? Is there any way of guiding readers who desire to comment so that their experience is positive and leads them towards editing articles?".   - Mark D Worthen PsyD (talk) (I am a man. The traditional male pronouns are fine.) 18:40, 23 May 2019 (UTC)
• I think helping new article contributors feel "included" by making the talk page more visible is a good thing. So long as we can keep a delineation between the article and the talk page, so that they don't blend into one another, should be welcome to new users. Oaktree b (talk) 14:48, 27 May 2019 (UTC)
• More feedback is good but we do need to explain the purpose of Talk: to new commentators, and to clarify that it's not a social medium for venting our POV about the subject of the article. Certes (talk) 14:51, 27 May 2019 (UTC)
• My concerns are that "Talk" is not descriptive of what can actually be found in that page, regardless of whether or not the user finds the option. —Flicky1984 (talk) 16:54, 27 May 2019 (UTC)
• Midas? What if we find the touch? We already have more talkers than readers; and far more "comments" than thoughtful, pertinent discussions of the sort adults used to have. Shall we invite all article readers to Instawiki selfies of their mental digestion? — Xiong熊talk* 23:29, 27 May 2019 (UTC)
• Moving the link to the other side of the page sounds fine, but I suspect moving the link around or making it more prominent won't have a huge effect regardless. I think the key is the lack of notification to ongoing discussions. You can put talk pages on your watch list, but by default it's otherwise hard to know a discussion is progressing on a relevant page. I think making a strong tie between talk page and alerts/notifications might bring discussion to editors' front of mind, and get more productive discussion going between editors. (this sort of exists already, but having your username mentioned directly in discussion is uncommon) Forbes72 (talk) 01:24, 28 May 2019 (UTC)
• (Repeated comment independent of Markworthen, Certes and Xiong, but possibly in agreement with them.) 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^tk 08:54, 28 May 2019 (UTC)

• Regarding “We may want to move the link to the talk page to the opposite side of the article page”, it is important to remember the original reason that the Vector skin (which replaced the Monobook skin as the default) kept the “Talk” tab on the left side when it moved the “Read”, “Edit”, and “View history” tabs to the right side. The reason for the separation was that this split hints that the modes on the right are verbs that can act on any of the nouns on the left. That is, a talk page can be read or edited, and so can the article itself. So your current page is always defined by a combination of text source on the left and mode on the right.

  I am against moving the “Talk” link to the right side because it would destroy that useful hint that talk pages are full-fledged pages, just like the articles themselves. I agree with other users in questioning whether “finding the Talk page when told to find it” is really a good measure to optimize. I also agree with Flicky1984 that “Talk” is a unclear name, and I think that choosing a better name would make it more likely for users to find the page when they have something to post that actually belongs there.

  —Rory O'Kane (talk) 11:03, 28 May 2019 (UTC)

• The only problem with it is that sometimes you have to edit to talk on a talk page (sorry if I did this wrong) YippeeSlushy (talk) 11:15, 28 May 2019 (UTC)

Where to show discussion tools

Context: Currently, many wikis have community discussion spaces in the project namespace (Wikipedia:), rather than in a talk namespace (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?

• Briefly, don't do that; it's unnecessary and will break a lot of stuff (e.g. the existing Wikipedia talk:Teahouse). I would favour the use of a pair of magic words to allow for exceptions to the content/discussion binary, like __DISCUSSION__ and __NOTDISCUSSION__. Jc86035 (talk) 14:38, 18 May 2019 (UTC)

  I also brought up extension tags for marking discussions in the phase 1 local discussion. Depending on implementation, something like <discussion type="vote"/>, or maybe just something like __VOTEDISCUSSION__, could be used to mark the current section until the next header as a vote, so that all of the following comments could be formatted differently depending on site CSS without users having to remember to use bullet points for first-level indents and colons for replies to those votes. Jc86035 (talk) 09:03, 19 May 2019 (UTC)

• Marking non-talk pages as discussions pretty much already exists as Category:Non-talk pages that are automatically signed and Category:Non-talk pages with subpages that are automatically signed. The only use case I can see for marking talk pages as non-discussions is Module talk:XXX/testcases pages, which are themselves a terrible hack that should be fixed rather than perpetuated. * Pppery * _survives 15:00, 18 May 2019 (UTC)

  @Pppery: I think this probably couldn't be done with categories, because the formatting and/or interface for discussion pages would probably be changed as a result of the consultation (e.g. an interface for inline replying to comments might only be loaded on discussion pages). The main reason I could see for using a "not discussion" marker would be to prevent older talk pages from breaking. Jc86035 (talk) 15:09, 18 May 2019 (UTC)

• This would be disruptive, both for the reason given, but also because having a WP-space allows for easier picking out of what is an internal discussion and what isn't. This is both when doing a search and looking at a mix of results. I would be against a change. Nosebagbear (talk) 15:22, 18 May 2019 (UTC)
• Leave this alone, it should be able to be improved via links TO the discussions (shortcuts, template links, etc). — xaosflux ^Talk 15:25, 18 May 2019 (UTC)
• I find that it's best for me, as a casual user, to keep my profile namespace separate from my page namespace and timeline namespace. Wa.. wait, this isn't Facebook? François Robere (talk) 21:39, 18 May 2019 (UTC)
• Don't move all discussions to talk space! That would be extremely disruptive, especially where it's useful to have an official discussion plus a less-formal meta discussion (eg RfAs, arbcom proceedings). Espresso Addict (talk) 23:17, 18 May 2019 (UTC)
• Requiring discussions to be in the talk namespaces would cause problems on noticeboards (e.g. the reliable sources noticeboard), where discussions occur on the noticeboard page and meta-discussions occur on the noticeboard talk page. The use of magic words would be a much better solution. — Newslinger talk 06:45, 19 May 2019 (UTC)
• The immediate problem I see with setting or removing the talk-page-interface with magic words is that it opens us up to nuisance changes by vandals. I can't see any use case for a page to change back and forth, and there's a relatively small number of top-level pages that need this interface but aren't already in a talk namespace. Letting it be set by changing the content model seems an almost ideal solution. The big problem I see is if we want to make all RFAs or AFDs or such use that model too: we'd need some way to configure all pages matching "^Wikipedia:Articles_for_deletion/" and so on to default to the talk-page-interface. —Cryptic 18:59, 20 May 2019 (UTC)

  @Cryptic: We could have a default based on the namespace, and allow a magic word with an edit filter to restrict addition or removal by non-confirmed or even non-extended-confirmed users. Alternatively, something like the titleblacklist, where admins can use regex to specify a group of pages, or list specific ones individually. --DannyS712 (talk) 19:12, 20 May 2019 (UTC)

• The implementation of this could have a serious impact on the DYK workflow where the nominations exist on Template talk. I think magic words would be a good workaround, but in general I think this should be restricted to article talk. Much of editorial space is built around having a rather vague distinction between talk and non-talk namespaces, and having to opt out so many pages would not be ideal for the reasons given above. The main purpose of many of these changes seems to be ease of use for newcomers which is most useful on article talk; by the time new users are seriously contributing in editorial space they should be familiar with WP:TPG and WP:TPHELP diminishing the gains in editorial space. Wugapodes [t^hɑk] [ˈkan.ˌʧɹɪbz] 19:37, 20 May 2019 (UTC)
• Magic words should be used to disable on talk pages (on a very rare case) and to enable on non-talk pages (which would be used much more than its counterpart). This is due to deletion logs pointing to articles for deletion discussions which are to the Wikipedia namespace, and Sockpuppet investigation casepages which are in the Wikipedia namespace and are linked to in block logs of blocked sockpuppets. These pages, although complicated in their nature, are still talk page like discussions and could be improved.

On a side note, I would say that AfD is in need of a way for newbie editors to be able to contribute in a discussion, as there is often the time where an IP or newbie editor will have a hard understanding how to !vote in an AfD (and thus will make mistakes in formatting of their !vote). Dreamy Jazz 🎷 ^{talk to me | my contributions} 22:01, 26 May 2019 (UTC)

• Not sure about moving all talk pages to the same space, but making links to the relevant pages more evident from the article space would help. Like a different colour for the link to a talk page, or something to really make it stand out and hard to miss (where ever that points too) is a good idea. Oaktree b (talk) 14:50, 27 May 2019 (UTC)
• This sounds like a pipedream. Yeah i want that too, but there is 18 years of archives to think off and a gazillion tools to adapt. Doesn't sound realistic to me. —TheDJ (talk • contribs) 18:47, 27 May 2019 (UTC)
• Good intentions paving. At one time I believed the foremost virtue of MediaWiki was the provision by default of a Talk for every Page. My faith weakened in the evident need for Talk Talk, Stored Talk, InsideOut Template Talk, and ArbCom Fez-wearing Process Wonk User Talk Templates. Just a bit farther down this page I see Talk of splitting Talk Templates (sufficient evil) from Talk onto Metatalk pages (Dante's 666th circle) which must, by natural progress, require Talk of their own (door forbidden Satan) and Final Talk on which editors may argue the merits of all previous Talk (write-only). — Xiong熊talk* 23:52, 27 May 2019 (UTC)
• IMO moving content between namespaces to make it easier for the software 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^tk 08:57, 28 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?

• At this point I've already sort of convinced myself that giving each section a unique identifier would be the best solution, because it would be less disruptive, wouldn't break page diffs and wouldn't result in two revision IDs for every edit or something like that. I think keeping a complete page history would be best, since otherwise you would be splitting a page into separate chunks, which would break people's workflows; and keeping a thread history still wouldn't surface comments which have been copied from another discussion. Some projects already divide their forums into month pages and just mark them as archived when all the discussions finish, which could be done without software changes but would represent a pretty big change to a lot of article and user talk pages. Jc86035 (talk) 14:38, 18 May 2019 (UTC)

  @Jc86035: in this idea, how would you deal with sections that are merged/moved/had parent\child level changed,etc? (Just keep tacking on more and more UID's?) — xaosflux ^Talk 15:27, 18 May 2019 (UTC)

  @Xaosflux: I don't think this could be thoroughly resolved unless it were to become possible to merge pages and the diff system were to be rewritten. Otherwise I think the best you could do would be to add diff links to every comment upon posting – there has to be at least one edit that merges the sections, so if you're at that diff you could find the other edits from the links, and the links from the discussion would take you directly to the old thread. (Including the ID link when merging sections or moving comments could also be made best practice in guidelines.)

  If an edit affects multiple threads, either the software could tag the edit with maybe-[all IDs on page] or the software could guess which sections have been modified (in theory this would be easily done; it's not rocket science to split a string with a regex). If an edit affects the "lead" of the page then it could be tagged with the page ID or something like that. Jc86035 (talk) 16:49, 18 May 2019 (UTC)

• I'm concerned on how this would work when you comment on multiple threads in a single edit (like I'm doing right now, in fact). Stick with full page, unless you can find a way to do both. Nosebagbear (talk) 15:22, 18 May 2019 (UTC)
• On any page, we (vandalism checkers) need access to the complete page history. Thread histories would be nice, but pretty much worthless unless accurate, which means (due to edit conflicts) unless generated by the software. — Arthur Rubin (talk) 20:26, 18 May 2019 (UTC)
• Why would I like to see the history of the talk page? Do I need to see the entire history of a page on Stack Overflow or Discourse? It's a tool. You shouldn't need to manage a tool. And by the way, you don't even need Wikitext for 95% of the things you do on a TP, but you do need a raft of things you don't currently have: proper citation management, easy diffing, better link syntax, AJAX. Did I mention AJAX? It's this idea invented in 2004 that can really make page whiiiz and smoosh and look like they're flying! I discovered it in a book just the other day. François Robere (talk) 21:52, 18 May 2019 (UTC)

  There are no histories or diffs on Stack Overflow. I've also seen more vandalism there than here. — Arthur Rubin (talk) 11:51, 24 May 2019 (UTC)

  There is actually.[1] I'm not sure what vandalism has to do with it. François Robere (talk) 21:08, 24 May 2019 (UTC)

• Individual threads is a nice to have. It's essential to be able to see the history of the whole page for eg vandalism reversion. Espresso Addict (talk) 23:14, 18 May 2019 (UTC)
• If it's possible to show histories for individual sections without affecting the display of the entire page's history, then I don't see a downside to doing so. Section histories would be very useful for validating the integrity of a discussion, which is something that should ideally be done in formal closures. — Newslinger talk 06:48, 19 May 2019 (UTC)
• I don't see a downside to discussion- or section-specific histories, but it would be a "would be nice"; full-page history really essential. As oversighters, we use it just about every time we use the suppression tool. Risker (talk) 04:36, 21 May 2019 (UTC)
• The only use I would see for this is for moderators knowing who is posting what and when, so that they can subst timestamps for people who forgot to sign, remove comments that are obviously spammy or trolling, and block editors who persistently leave tendentious comments. I would rather have individual threads in the page history than bunch of edits to one discussion, though. Awesome Aasim 07:00, 21 May 2019 (UTC)

One question to be asked: If the history is stored by section, is it also possible to delere revisions of one thread, without disrupting other threads which may have been edited in tbe meantime? If so, Wikipedia:Usernames for administrative attention could use the section history feature. עוד מישהו Od Mishehu 13:02, 22 May 2019 (UTC)

• It would be nice to have both options. Sometimes I can remember a certain point that was made about a particular topic in a long discussion, but can't find it without moving down through the entire history. Oaktree b (talk) 14:52, 27 May 2019 (UTC)
• As others have noted, it would best to have both single-section and full-page options. This would be complicated to implement in article space (if that's on the table) where content is often moved/split/merged between sections, so I would be happy if it was only used on talk/discussion pages. –dlthewave ☎ 20:15, 27 May 2019 (UTC)[
• (repeating my comments from mediawiki.org consultation) 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^tk 08:58, 28 May 2019 (UTC)
• I think we should keep the normal page history link (as others said), but add a 'history' link along with the 'edit' after sections. It would look like "'Section' [edit - history]". How the local history would work would be by having the software search for edits that start with /* Section */ and list them in the local history view. Yes, I am aware that the /* */ can be manually removed, but we could make it irremovable, or add a separate tag for the software to know which section was edited. L293D (☎ • ✎) 13:24, 28 May 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?

• In general, moving the majority of it somewhere else would probably not have much significant negative impact. Most new users wouldn't (and probably shouldn't have to) read six paragraphs' worth of bureaucratic text before starting a new discussion. If they violate policies or guidelines they can always be reminded through warnings on their own talk pages. Jc86035 (talk) 15:13, 18 May 2019 (UTC)
• A majority of this information is helpful to find on top and/or benefits users to read before participating in the talk page. This definitely includes FAQs, the archive/search bar etc. I believe that the project quality/importance bits should stay there but could benefit from a smoother/shrunk appearance. However, things like "there was a prior AfD" or "there was a DYK" needs to be easy to find but might unnecessarily add to the complexity. Nosebagbear (talk) 15:22, 18 May 2019 (UTC)

  Nosebagbear, "benefits users to read before participating in the talk page" in my opinion that shows a fundamental misunderstanding about how people behave in real world situations. I'm an admin, i NEVER read anything up there, unless i need to look something up in terms of status or flags of the page. —TheDJ (talk • contribs) 18:50, 27 May 2019 (UTC)

• So here's my idea on this - which would result in a new "page" - create a new page for metadata - keep it in the talk space and stick it to the top of the talk pages. Think of the way we do /doc pages on templates. Compare to 'FAQ threads' in forums. This section could have all the tags, FAQ's, etc - but would never be used for active discussions. It could be shaded and possibly collapsed by opt-in/opt-out. — xaosflux ^Talk 15:30, 18 May 2019 (UTC)
• This is a double-edged sword. Some of the templates (old GA reviews, WP project affiliations, etc...) are not needed for the average editor, but others (wp:paid) are critical, and should be on their own. Rather than moving to another page, I'd favour ranking each template into critical or non-critical, then minimizing the non-critical into a small icons like we have for GA/FA status, locked, etc... Editors that need to see it, can hover-over and click for details. Ian Furst (talk) 16:18, 18 May 2019 (UTC)

• My argument is that if a template is critical like that, it needs to be placed in the article. If it isn't critical, it needs to be easy to access for heavy editors and out of the way for the average joe. Prometheus720 (talk) 22:15, 27 May 2019 (UTC)

• Possibly just a big collapsed top section. — xaosflux ^Talk 17:13, 18 May 2019 (UTC)

• Multi-Content Revisions may be useful here. If MCR is easy to use, metadata may be grouped in multiple containers. MER-C 19:53, 18 May 2019 (UTC)
• Or to a whole different database table. Why the hell do it in Wikitext to begin with? You know how confusing that looks to new users? François Robere (talk) 21:53, 18 May 2019 (UTC)
• In my experience the great majority of talk pages are unused and exist because Wikiprojects have put templates on them which are essential for administrative purposes, such as quality tracking. It would be extremely annoying if that data were rendered impossible to read without an extra click merely to facilitate discussions that aren't happening, particularly for those of us with disabilities such as carpal tunnel that make repetitive clicking painful or impossible. Permanently collapsed states are extremely unhelpful to such editors, though opt-in/out collapsed state might be an option at least for logged-in editors. I wouldn't personally object to moving the WP templates to an entirely different metapage, but feel that they are potentially useful for guiding newcomers to Wikiprojects, which are sometimes more likely to be watched than low-traffic talk pages. Espresso Addict (talk) 22:54, 18 May 2019 (UTC)
• I would suggest having most of these templates be small boxes that appear to the right of the discussion, in an unobtrusive fashion. A small amount of templates could retain their current format at the tops, limited to those that are explicitly placed in response to abuse of the talk page, or things like arbitration. Oiyarbepsy (talk) 15:32, 20 May 2019 (UTC)

I support this idea. Important ones at the top, the administrative ones over on the side. Oaktree b (talk) 14:54, 27 May 2019 (UTC)

• One advantage I see with moving the notice at the top of the page is that it prevents scrolling. Information about an article can maybe move to a pop-up "Info" tab so the order of the tabs looks like this:

View • About this article • Edit • History

But information about a talk page could stay on that talk page under a "Read before posting" section. Awesome Aasim 01:44, 21 May 2019 (UTC)

• It is extremely useful to have information on WikiProjects, quality, and past reviews on top. This is how many users find out about wikiprojects. How else do you expect users to find out about, for instance, WP:NYCPT, which I work on?--Kew Gardens 613 (talk) 14:40, 27 May 2019 (UTC)
• Instead of actually moving the templates, perhaps this could be implemented as a "show/hide" option in the interface. Users who work with wikiprojects etc. could set all pages to "show templates" by default. A special "override" tag could be added to important administrative notices, making them visible to all users. –dlthewave ☎ 20:24, 27 May 2019 (UTC)
• Mostly pros I am a fairly new editor, and yes I did find WP:Plants through a talk page banner. I think that the information available on talkpages is good stuff and should stay there, but the templates are terribly excessive. Look at Talk:Cleopatra. Almost none of that talk page is people actually talking. It's a giant set of templates and a giant category box. We should have a little WPX-like wizard that guides people through making a new discussion. That is where we should give information to new users, as well as during account creation. The rest of that stuff probably belongs either on the side of the article or in a new Data page. We already have Page Information links on the left sidebar. I think all that information should instead be displayed in a metadata page which holds all the extraneous junk that is not necessary. Or, you know what? Forget just having a data page, let's go bigger. WP:Bold The left sidebar is honestly kind of junk in the first place. It is sort of wasted space. For one, most of the links there are not useful to new editors or readers. And two, it's not at all adaptive to what you are looking at. It just sits there, taking up space on every page. It's not expandable/retractable in any way. And it never incorporates useful information about the page you are looking at. As far I know, the only changes we ever see to the left sidebar are for what languages are available. This is a waste of prime real estate and honestly, I'd be interested in seeing it adapt to the metadata on our pages.

Imagine that you are just reading a page and not trying to edit. You open it from your favorite search engine and lo and behold, there is a beautiful article. On the side, instead of having a bunch of links that you don't really care about and have 0 context regarding the page you are on, you see several things: a big button to the talk page, a big button to Wikipedia:Wikipedia Requests a table of contents (keeping you from having to scroll back up), an expandable list of cleanup templates, an expandable list of Wikiprojects, and an expandable list of categories. Underneath that (or possibly mixed in) is a list of all the noncontextual stuff. Furthermore, in some way Wikidata, page information, talkpage information, and information on those pages have all been consolidated into one link which is called Page Information as it is right now. When you go to the talkpage, there is a similar switch. There is a big button to go back to the article, but most of it is stuff about the talk page, including a list of archive links and an automated estimation of how active that talkpage is. Just design some program like ORES that guesses very broadly based on pageviews, number of editors, and edits within the past year, and have it use a traffic light system or something like that. Something totally not-quantifiable. Based on that rating, advise users to use the request system instead or to ask about the article on one of the Wikiproject pages. Oh, and since article quality is assessed the same across all Wikiprojects, it should be a major feature in the sidebar as well. Help show people that Wikipedia actually is a reliable form of learning, even if it isn't technically a reliable source of information. So in review, consolidate all metadata to the Wikidata page and use that to create adaptive content in a pretty sidebar per-page instead of wasting all that screen real-estate on unformatted links.

To the inevitable few who will say that this is making things too accessible, I think that that is completely out of line with the point of an open encyclopedia and I question why you even edit here. Wikipedia is growing and editorship is declining. Wikipedia is old and it needs a facelift just like any website. Review WP:OWN, confront your biases, and ask what is best for Wikipedia as a whole--keeping a small group of experienced editors happy, or tapping into the reserves of literally millions of people who don't yet edit here? IMO there is no way to correct implicit bias without tapping into new users. We need all kinds of users, whether you think they belong here or not. The goal is to educate people. Intentionally obfuscating information is like hiding the chalkboard from the students because they might write something naughty on it, and it's totally foolish. Let's help people join. Prometheus720 (talk) 23:20, 27 May 2019 (UTC)

Yes to accessibility and welcoming newbies, but changes over the last 15 years may be cultural rather than technological. The web has moved from being a means of CERN physicists sharing preprints to a means of venting vitriol, the latter requiring a single jab of the finger and not much dedication to learning or explication. In my experience, subject experts are put off editing less by the fine features of 'cite journal', which other editors can correct if they do get wrong, and more by the culture. Someone who isn't ever going to skim a help page is unlikely to have the attention to detail in order to corroborate multiple print references. This is not just my bias as an editor, but my bias in general. I've spent many years working with web design colleagues who I like very much, and come to wonder if the idea of a site 'facelift' isn't mostly to keep designers in work: it could be argued that the web has gone backwards from the simplicity (and code- and energy-efficiency) of the early 90s. --Cedders^tk 09:14, 28 May 2019 (UTC)

• Yes, I'm with the idea! Better talk pages will make it easier to respond to.

Jake The Great!

📞talk! 08:23, 28 May 2019 (UTC)

• I find it hard to imagine how to improve on the current talk page structure, although I'm sure there are some good ideas above. Personally I like something that behaves predictably a bit like a printed page, rather than nasty AJAX. If you want to convey useful information, that's what you want to convey. 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^tk 09:22, 28 May 2019 (UTC)

Other discussions

I've asked if it would be appropriate to have other subsections as in the phase 1 discussion; as of writing, reply is pending. Jc86035 (talk) 14:56, 18 May 2019 (UTC)

From the linked discussion, I believe it would be appropriate for participants (including unregistered users) to create new subsections here if they believe that those discussions would be useful in any way to the WMF team. Please begin new discussions under a level 3 header. Jc86035 (talk) 08:38, 19 May 2019 (UTC)

Additional questions

• How do "threads"/"sections" map to what we have now? Generally, level 2 headings?
• Possible implementation of stable thread pointers (although I don't think archiving is in the current question set)
  • {{anchor|thread ID : Page name: section name}}?
  • {{anchor|thread ID}} {{anchor|Page name: section name}}?
  • {{anchor|thread ID : sectionname}}? (Only helps if sections cannot be moved to an unrelated archive)

... — Arthur Rubin (talk) 21:19, 18 May 2019 (UTC)

(Moved from the talk page.) I think discussions would most likely map to level 2 headings, although certain extension tags would probably use all wikicode headings (probably not <h3>...</h3>-like HTML tags) as markers. I think it would be possible to make stable thread pointers by generating unique IDs for section headers (given the constraint that the entire talk page is to remain one entity with a single content model), but whether subsections would have their own IDs would be up to the implementation. The section permalinks/tags would probably work better if they were only added for level 2 headers, but I'm not sure, and obviously all of this is still hypothetical. Jc86035 (talk) 09:56, 19 May 2019 (UTC)

My question as to anchors was related to marking sections for stable archiving, rather than for section watching. (I'm assuming that once a thread is archived, there's no need to continue watching it....) I don't think improving archiving is on the table for this round. I saw mention of it in the summary of desired features, but not in the specifics of these questions. — Arthur Rubin (talk) 10:04, 19 May 2019 (UTC)

@Arthur Rubin: I'm not sure I understand what you're asking. Do you mean the process of archival itself, or are you referring to links to archived threads, or something else? What do you mean by "stable archiving"? Why would you be marking a section for archival in this situation? Jc86035 (talk) 10:08, 19 May 2019 (UTC)

By stable archiving, I mean that links to the section archived should (eventually) be repointed to the archive. In order to do this, it seems to me that the anchor should include the ORIGINAL page name as well as the ORIGINAL (or after removing improper names) section name, so that the modified pointers retain information as to what was intended. A pointer to [[Foo#Bar]] should then be modified to [[Foo/Archive 5#ID : Foo : Bar|Foo#Bar]], or possibly [[Foo/Archive 5#ID : Foo : Bar |Foo§Bar]]. — Arthur Rubin (talk) 10:21, 19 May 2019 (UTC)

@Arthur Rubin: Oh, that's what you meant. I think it's possible that these links could be fixed automatically (in theory it's already possible if it's integrated into the talk page archival bots), but it would probably involve some sort of indexing of all of the section links to talk pages with archival enabled. I don't think this is a big issue and it wouldn't really affect newcomers in a significant way, so I would probably expect it to be left for another time if the team can't accomplish everything that's desired.

I don't think including the original page name in the section header would help, since it doesn't stop the links from being broken, and the archive is usually a subpage of the original page to begin with (so no additional information is added). I think both the original section header and a hypothetical thread ID would be used as anchors (made by the software, not by templates). Modifying the actual displayed text of the section header would probably make the links more fragile, I think. Jc86035 (talk) 11:25, 19 May 2019 (UTC)

@Arthur Rubin: Perhaps to resolve section links there could be a special page which would redirect incoming requests (e.g. "Special:Threads/threadID") to the section header with the relevant ID (or to the location of an extension tag with a removed section's ID). This would avoid links being broken because of sections being moved out of talk page archives or because of section headers being changed. Then the software could attempt to replace section links (for links to pages which are discussions) with links to the special page, with respective fixes for templates in headers, translated headers and other edge cases. Jc86035 (talk) 10:54, 20 May 2019 (UTC)

Reasons for including the original page name, and possibly section name, in the link pipe are that it indicates where the pointer was when it was generated. If it is not done, you would have to follow the link to see what was intended. Whether they should be in the in the actual link is another matter. I don't see it as necessary if the current section name can be recovered without clicking through, which seems likely. — Arthur Rubin (talk) 10:08, 21 May 2019 (UTC)

• Are there any plans regarding the use of JavaScript? Currently it is possible (actually, an improvement) to edit Wikipedia and comment with scripting disabled. Will that continue? Johnuniq (talk) 10:55, 19 May 2019 (UTC)

  @Johnuniq: They're almost certainly not taking source editing away on talk pages (as indicated by the phase 1 report), so I believe the answer will be yes, it will continue. I don't think inline replies will be possible without JavaScript, and visual editing was never possible without JavaScript. Jc86035 (talk) 11:15, 19 May 2019 (UTC)

• Question: Why are talk pages rendered as a series of nested p, ul/li and dl/dd elements? That's improper semantics. One of the justifications given at the Phase 1 report for keeping the current Wikitext-based system was compliance with 3rd party tools; what about 3rd party tools that expect semantic HTML? François Robere (talk) 11:04, 23 May 2019 (UTC)

  @François Robere: There's a fair amount of discussion on this matter at the local phase 1 RFC. Looking at User talk:Jimbo Wales/Archive A and Wikipedia:Village pump/Archive A, it seems that the reason we still use list formatting is that it was already used around the time the four tildes were introduced in mid-2002. I think it's quite likely that web accessibility and semantic correctness just weren't concerns in those early years. mw:Talk pages consultation 2019/Discussion tools in the past gives a higher-level overview (not mentioning indentation at all), which can be summarized as "the developers wasted the last 15 years on dead-end projects that weren't good enough in certain important areas". Aside from the templates and the addition of the user talk page link to the default signature, this comment would have been formatted identically if posted in August 2002.

  Presumably, any sort of new interface would replace those tags with <div>s, or the indentation syntax would be changed/expanded to allow for use of list items inside indented comments. Jc86035 (talk) 19:11, 23 May 2019 (UTC)

  I would summarize that page differently, but impression would probably be just as somber. That page supports my impression that the core of the problem is in the Wikitext- and diff-centered design - concepts have been loaned from different domains and aren't well suited for academic writing.

  HTML semantics barely existed back then, and accessibility was cumbersome and partial. HTML5, however, has been around for a decade now; its article and section elements could be useful here. François Robere (talk) 20:09, 23 May 2019 (UTC)

• Question: What are the use cases of a full-length talk page, compared with separate discussions? That is, what would be impossible to achieve with a system where each discussion is an "object" in each own right vs. when they're all part of the same page of Wikitext, as is the case today? François Robere (talk) 15:12, 24 May 2019 (UTC)

  @François Robere: I think a lot of the opposition to this stems from how Flow implemented this. In Flow's implementation, it becomes impossible to view the differences between revisions of multiple threads on the same page, and it becomes impossible to edit an entire discussion page at once. Both of these are also true for LiquidThreads. I believe Flow does allow for talk page archiving, since topics can be disconnected from talk pages, but I don't know if this has ever been done. LiquidThreads supports it, in any case. This could also considered be change for change's sake (especially if it's possible to implement features without doing this), and so the phase 1 report would be seen to advise against doing this.

  I also think it would be too politically difficult to do this, specifically because of the association with how Flow and LiquidThreads handled it. The opposition isn't without reason, though. Jc86035 (talk) 16:27, 24 May 2019 (UTC)

  But why would you like to do that? If you're lucky enough to have have distinct threads discussing distinct issues, why would you need to cross-compare or edit several at once? What are the use cases? François Robere (talk) 18:14, 24 May 2019 (UTC)

  @François Robere: I'm really not sure why you're only asking this now, given that this was discussed at length in the phase 1 discussion as well as literally being the main focus of question 5 in this phase, but some people, including myself, use this to compare all new changes on a page. This matters if, say, your RFC is split into more than one section, or if you follow all the discussions on a particular noticeboard regardless of their subject matter.

  Replying in several sections at once is probably not a major use case, although for some specific workflows (e.g. AfD on certain wikis) it could be particularly useful. I don't think it should be a deciding factor, though. Jc86035 (talk) 09:45, 25 May 2019 (UTC)

  I've replied to Q5 with the very same question, and haven't been answered there.

  An RfC with disparate section in different places (rather than continuous)?

  What if you could still see all the recent changes concentrated? Would the underlying representation matter then? François Robere (talk) 11:19, 25 May 2019 (UTC)

  @François Robere: If it's continuous, on a page using the equivalent of level 2 headers (like this one) you would still have to view changes to each section individually if you couldn't view the whole page history.

  I think you could technically get around a lot of the concerns by e.g. just generating wikitext out of canonical JSON and converting it back when an edit's submitted, but I'm not sure how that would work or if that would be feasible. Jc86035 (talk) 13:30, 25 May 2019 (UTC)

Straw poll: reply-link

1. Would you, personally, prefer to use Enterprisey's reply-link or the overhauled interface proposed in the phase 1 report? (Since the latter doesn't exist yet, let's assume that it'll use something like Flow's edit box to save wikitext comments, outdent will still work, there will be equivalents to both colons and asterisks, and Flow's comment/reply order will not be used.)
2. Do you think reply-link would be preferable for new users?

Jc86035 (talk) 10:34, 20 May 2019 (UTC)

• I'm not sure which ideal version I'd prefer, but I suspect Enterprisey's will be less problematic and controversial than the WMF usually is. I don't know how wiki-agnostic Enterprisey's is, though. Nosebagbear (talk) 13:35, 20 May 2019 (UTC)

  @Nosebagbear: I think I'd probably prefer the Flow interface over reply-link, in spite of how annoying the visual mode can be. Presumably a new interface would be able to create new sections, wouldn't break because of indentation errors, wouldn't randomly appear on the wrong pages, wouldn't insert unnecessary blank list items, and would be able to handle tables, for example. That said, for about 95% of comments the interface wouldn't make a difference. Jc86035 (talk) 15:29, 20 May 2019 (UTC)

  I'd rather see Visual Editor be added for talk, with some features like "auto pinging" people you mention. — xaosflux ^Talk 18:56, 20 May 2019 (UTC)

  @Xaosflux: I don't see a full VisualEditor being a good idea, especially given the increased usability (and possibly reduced complexity) of an inline reply option. Users would probably still have to sign their own comments, it could still be confusing to reply to comments which already have replies, the interface would be slower, it would probably be more difficult to use on a mobile device, and it would be easier to cause an edit conflict. Jc86035 (talk) 00:19, 21 May 2019 (UTC)

It's hard for people to compare things they haven't used. https://test.wikipedia.org/wiki/Special:Version indicates that Flow's set up on the test wiki, and there are lots of admins there. We could probably set up a way for people to test out both things, if they wanted. Alternatively, you can enable the reply-links script in your account here, and visit mw:Talk:Sandbox to play around with Flow. (It's really helpful to see how Flow behaves when someone replies to you, so maybe everyone should add their comments to the same thread.) Whatamidoing (WMF) (talk) 20:41, 20 May 2019 (UTC)

@Whatamidoing (WMF): I hadn't considered that a lot of contributors wouldn't have used Flow in years or might never have used it at all. (I don't think there's anything better I could have used as an example that most editors would actually be familiar with, though.)

I think all of my straw poll questions are probably somewhat problematic and I'll probably have to do something about them. The second question in this section is obviously loaded (not that I tried to make it otherwise), because you wouldn't expect a new user to have to use a script with such a high failure rate (caused by incorrect indentation and such). The prioritization question compares features which are somewhat arbitrarily grouped, and it'd be difficult to consider things like development time or shared building blocks.

Somewhat off-topic, even though this is probably the right place to discuss it, but I think that questions 2 and 4–6 might also be somewhat ill-considered. I guess it's somewhat unfair of me to complain about it only after a dozen others have also shared their opinions, but it seems somewhat obvious to me that if it's possible not to change those things in pursuit of improving the interface then they shouldn't need to be changed, because it wouldn't really help anyone to change them (those things being the ability to view the full page history, the ability to surface metadata on talk pages, the ability to edit a whole discussion page at once and the ability to have discussions in content namespaces). Jc86035 (talk) 00:43, 21 May 2019 (UTC)

• I can't compare the two options until I can see them side-by-side. My experience with reply-link has been quite positive for lower-traffic pages, but less so for higher-traffic pages (e.g. the reliable sources noticeboard). Sometimes, reply-link fails to post the message with an error, and I'll have to copy and paste my reply into the normal editing interface, re-indent every paragraph, and then submit again. This happens more commonly on higher-traffic pages. After a couple incidents of another strange bug that caused me to duplicate all of the noticeboard content (Special:Diff/882479137, Special:Diff/882663449), I no longer use reply-link on noticeboards and other higher-traffic pages. Regardless of whether the WMF settles on reply-link or their own solution, I hope the WMF devotes enough resources to testing the feature, since there are a lot of edge cases that could cause such a tool to malfunction. Enterprisey did an incredible job on reply-link, and my comment is intended to be constructive feedback. — Newslinger talk 08:14, 21 May 2019 (UTC)

  @Newslinger: I discussed this in more detail on Enterprisey's talk page, but there are a number of reasons that a completely new interface would probably be a more attractive proposition to the WMF and possibly easier to implement, notably the relatively high failure rate because of incorrect indentation and the like. If the errors need to go away, that means either the parsing or the syntax has to change, and (from a "let's not hack everything together using user scripts" POV, anyway) that alone almost necessitates a MediaWiki extension already. Jc86035 (talk) 09:11, 21 May 2019 (UTC)

  ​Yes, the final solution will certainly be a MediaWiki feature or extension, regardless of where the feature draws its influences from during development. MediaWiki features receive more resources than user scripts, so I don't see any other option for something that is intended to be the default experience on Wikipedia. — Newslinger talk 09:24, 21 May 2019 (UTC)

  Jc86035, yeah the problems that reply-link runs into are EXACTLY the reason why any of these discussions are needed to begin with. The wikicode technology is terrible for building anything useful on top of, if you want to facilitate a more targeted api. And people WILL complain about those imperfections to WMF and wmf will not be let off the hook for not fixing them, the way enterprisey will. It's always been that way, anything that becomes part of core is required to be perfect. And reply-link simply can never be perfect. It doe 98%. But breaks 2% —TheDJ (talk • contribs) 18:56, 27 May 2019 (UTC)

• Comment: As always, questions like these should consider not only existing veteran users, but non-users - or future new users - as well. Considering only existing users is bound to limit the design in favor of community maintenance rather than growth. François Robere (talk) 15:38, 22 May 2019 (UTC)

  @François Robere:. It is difficult to tell what potential users would want. By definition, we can't ask them, because they're not here. — Arthur Rubin (talk) 05:03, 23 May 2019 (UTC)

  Of course not, but there are design methodologies that target just those - in fact, that's how most product and UX design works - you target a future costumer by finding a present surrogate. Current and long-term users, who are accustomed to the existing, poorly-designed systems, aren't that. François Robere (talk) 09:45, 23 May 2019 (UTC)

  The history of design decisions by the Foundation suggest that they wouldn't use the correct design methodologies. — Arthur Rubin (talk) 17:31, 23 May 2019 (UTC)

  @Arthur Rubin: Regarding interface design specifically, are there any examples of bad design (particularly design that was considered bad when it was released) that come to mind, other than perhaps the change to use serif fonts for section headers and certain bits of mobile CSS? I don't think the WMF has done a particularly terrible job in this area, and even Vector looked passably modern in 2010 (although it's certainly aged noticeably).

  I would note that LiquidThreads was started by a volunteer more than 14 years ago, and given how long ago that was it's probably unfair to criticize the current WMF for it. I've only used LiquidThreads once (on TranslateWiki), and it's not terrible.

  In terms of interface design (which is probably the most relevant factor here, since the original question is more about the interface than what's under the hood and how it affects existing talk pages) I would say that Flow actually isn't that bad, although it does suffer considerably from the add-more-padding-and-reduce-column-width mentality (especially since Wikipedia editors seem to disproportionately favour higher information density). It definitely does fail in other areas, of course. Jc86035 (talk) 19:34, 23 May 2019 (UTC)

  Oh, it was passably modern? Well now, everything must be fine!

  The main problem is that Wikipedia is really behind the times in terms of design and interaction, and it's hard to separate the "under the hood" from the UX. Take for example Twinkle and similar "gadgets" - why are they separate from core? Why aren't they integrated completely with the UI (ie lose their own buttons and integrate their functionality where needed)? And (now the rest...) why are the default tools listed in a single column on the left? Why is the logo so big? Why is Vector gray? Why do I need both "notifications" and "alerts"? Why don't we have columnar reading: with default font stacks? Why do I need to "edit the source" of talk pages - can't I just comment? Why are the buttons under this form so ugly? Bootstrap has such lovely buttons,[2] why can't we have them? And why aren't the colors and margins everywhere consistent? Why are there borders around every second element? Why are page histories and contributions lists rather than tables? Why is the "older 50" in those lists after the "oldest 50" rather than before? And why is it called "older" rather than "next"? And when comparing two revisions (say, no. 1 and no. 250), why do I need to scroll all the way back up for the "compare" button? Why is there so little AJAX around? And most importantly: why are we still using Vector? Do you know any other major site that still uses the exact same design it used a decade ago? François Robere (talk) 21:05, 23 May 2019 (UTC)

  @François Robere: Of course, of course. Obviously not everything is fine. I don't know how realistic fixing any of these would be; the WMF has put resources towards this sort of stuff in the past (see e.g. mw:Winter; sample screenshot). Twinkle is heavily customized for the English Wikipedia and might not be easily integrated. This very page is literally for community feedback on a proposal for inline replies. Have you tried the Timeless skin?

  The main problem with complaining about most of these problems here is that it's almost entirely out of scope, and so it'll be ignored because you're not complaining to the right people, your concerns aren't demonstrably shared by most other highly active editors, and the WMF would be understandably reluctant to pursue development of functionally unnecessary but possibly beneficial changes which could generate user backlash.

  If this consultation manages to result in a working new talk page interface which doesn't generate substantial backlash, I would expect the interface's launch to change how the WMF develops major bits of software. I don't think something like this consultation has been tried by the WMF before, the project leader has said that the consultation is a direct consequence of the failures of the Flow development strategy, and it would set a precedent for having users inform the WMF's development direction as much as practically possible. Jc86035 (talk) 14:36, 24 May 2019 (UTC)

  Well, you asked about "bad design decisions" and I was happy to oblige!

  I did not know about "Winter". It looks much better than Vector, but seems dev. stopped in 2014.

  Most of these are actually easier to fix than you'd think given the way the system emits them when constructing the page; others, like the tables, require either client-side JS or changes to the server-side. I've a prototype skin that does some of these - email me if you want some more info.

  I'm fairly certain, again, that my concerns are shared by the majority of readers, casual users and past future editors. I doubt the groups of frequent and recent editors, which according to stats represent 0.1% and 0.3% of all Wikipedia members, respectively[3] (unfortunately there's no stat there that combines the two), are representative of the larger group of users and readers. The dilemma between backlash and expansion is well known in other major software projects; I suspect Wikimedia leans so much towards avoiding the former, that it inadvertently avoids the latter. That being said, I must wonder: ASKING THE USERS FOR INPUT? ARE YOU CRAZY?! WHAT DO THEY KNOW?? François Robere (talk) 15:34, 24 May 2019 (UTC)

  François Robere,I think your analysis is pretty much on point. The problem is that the community ultimately rules the foundation by way of bad PR. They'd rather burn shit to the ground than give in and accept that in the end.. this is just a website. I've long since had to give in and except that this is the status quo to work with however. It's terribly annoying and possibly self destructive, but it's what there is to work with.. This is NOT a normal website, where normal website rules apply. —TheDJ (talk • contribs) 19:02, 27 May 2019 (UTC)

  A good rule of thumb with regards to human institutions is the mediocrity principle: Wikipedia may be unusual, but in most respects it's not unique. These things have been done before; we ought to learn how. François Robere (talk) 20:04, 27 May 2019 (UTC)

  François Robere, you might be interested in reading more about the mw:Talk pages consultation 2019/New user tests. Whatamidoing (WMF) (talk) 21:00, 23 May 2019 (UTC)

  Thanks, I'll check it out! François Robere (talk) 21:09, 23 May 2019 (UTC)

  Unlike "new user" investigations with WP:FLOW, this test actually seems well-designed. I'm mildly surprised. Part of the problem there seems to be the removal of "My" from the top user line; "My Talk", "My Preferences", "My Contributions", etc. I can answer some of your earlier questions, as well.

  • The separation between "alerts" and "notices" seems a good idea to me, although the selection as to which is which is somewhat problematic. In theory, "alerts" might require action, while "notices" usually do not.
  • The tools are in a single column on the left because other options reduce available real estate for the text, and (although this might not be the intent) it is relatively easy to add additional tools.
  • Twinkle is separated from the core functions because the Foundation had nothing to do with it, and WikiMedia hooks to add it to where the core functions are normally might not have been adequately documented.
  • IMO, it is called "older" rather than "next", because you may be able to invert the order.
  • Thinking about it, the FLOW interface was reasonably good. The output format is lousy, and it's missing essential functions, but what it allows you to do has fairly simple buttons.
  • My guess is that page histories are lists, rather than tables, because they are easier to scrape. But I definitely could be wrong.

  And a question for you. I can't find a Wikipedia article on AJAX. Can you point to one? — Arthur Rubin (talk) 11:31, 24 May 2019 (UTC)

  Ajax (programming). It's a name for the technique of using JavaScript to load data and update the relevant bits of the page, versus having the browser load an entirely new page (including the skin and such) each time things need updating. Drawbacks include the fact that it doesn't work for people with JavaScript blocked/disabled. Anomie⚔ 12:38, 24 May 2019 (UTC)

  • To the best of your knowledge, does this separation exists in other program or web apps?
  • There's no shortage of options for where one would place the tools, with drop down menus being the best one. There's no reason the editing tools would be split between two locations: upper right drop downs and left menu bars.
  • a) So what if it didn't? It should integrate smoothly. b) Why didn't it? Some of these tools are pretty mundane and should have been integrated. c) Documentation is a different sore point - from my limited experience it's not very good (again an extension of trying to use Wikitext for everything).
  • Yeah, but it doesn't matter much if it followed convention, does it? You'd likely know what order you choose if you change it.
  • I doubt it. Tables add data, so using a table would enable you to use a library to refer to something like table[row][col] instead of list[el#2][span#3].

  Ajax (programming) (should have a redirect from AJAX). It's basically what allows parts of a page to get updated without a complete refresh - real-time notices, search suggestions, interactive forms, collaborative editing, and much more. It's what allows web apps (rather than web pages) to exist, and is omnipresent in today's web, while Wikipedia barely makes any use of it. François Robere (talk) 13:00, 24 May 2019 (UTC)

  partial reply for some other points, although pretty much out of scope for this section

  • There are any number of programs which allow you to specify the level of alerts/notices/concerns that you want displayed. Having separate lists makes it easier for the user to remember what level he/she/it is considering. (Regardless of whether it is improper to call an editor "it", bots which scrape the alerts could also exist.) Still, WP:ECHO could have been done better.
  • I have concerns with the nested dropdown lists in some applications. There should be a bounded number of clicks to find a function, even if you don't remember where it is. That being said, some of my .js addons add a dropdown list, some add to (or modify) menubars, and some add to the vertical list at the left. The one that adds about a dozen functions to the left sidebar should have added one (or maybe two) dropdowns, but I don't feel like modifying it.
  • ...
  • I thought of another reason why the histories may be a list rather than a table: It has fields that can exceed the page width: User(on some small screens), Page name, and Edit summary. WP:Recent History would have all three of those fields. I've never seen a table implementation which handles small screens well, and I've seen commercially designed table implementations which overflow my screen (even on a modern desktop display) no matter how I set the zoom factor in my browser. A good implementation probably can be done, but with Edit summary being a user field, WhichIsNotRequiredToHaveAnySpaces, ....

  And I think it was a Foundation concern, rather than an en.Wikipedia concern, that editors without Javascript should still be able to participate. That means editors must be able to perform basic functions without Javascript or AJAX. — Arthur Rubin (talk) 17:40, 24 May 2019 (UTC)

Parts of "Winter" were turned into mw:Typography refresh. This kind of work is a bit tricky, especially when you're working with almost 300 languages. I remember that they had to make a few changes after release. (For example, I believe that one Wikipedia was basically illegible because of a font change). Then it takes time for people to get used to the changes, and during that time, lots of people very loudly insist that they absolutely, positively will never get used to this change ...until they all do, a week or two later. Now that five years have passed, I'd bet that 99% of us couldn't tell you what changes were actually made during the Typography refresh project (without going to look them up). That includes me: the change that I mentally associate with this project is one that they proposed but didn't keep in the final implementation.

I hear that Reading was looking at another round of updates to Vector. I think they were thinking at one point about offering a "simple" interface for reading, and making a more "advanced" skin for editors. I don't know whether it'll be done (the annual plan's not been finalized, and I've never read their proposal), but there might be some changes coming. Whatamidoing (WMF) (talk) 18:35, 24 May 2019 (UTC)

Frankly, given the rarity of these improvements it's pretty much out of the scope of most any discussion... One thing to remember: every design decision has a rationale - we can justify just about everything, especially if we're used to it. The question is whether that rationale actually contributes to product's goals more than its alternatives.

• Why, oh why would I want to need to use scripts and "gadgets" and whatnot to customize my notices? Neither Facebook, Twitter, nor Gmail ever told me "oh, by the way, there are external programs..." And all have just one, clearly labeled notification function - I have no idea why I'd need two, nor do I remember which goes where (in fact, every times I see either one of those on I think that I either got a message or got reverted, I just don't know which). Wouldn't it be nicer if the messages themselves would be informative enough visually, filterable and sortable, that you'd only need one button?
• If I may prod - why do you need so many modifications?... (Also: would you say this usage it typical?)
• There are solutions to this, but I doubt they're really needed: I don't have data on this, but I bet most editing is done on desktops and laptops, not on than tablets. On these devices the added information that a table can add (eg. sorting, filtering, scraping etc. - all of the "power tools" your yourself would probably need) can be integrated easily through existing libraries. Granted, you could do some of these with lists as well, but you'd still need something that is structured better than the existing lists.
• I'm sure. Again, there are ways to deal with it, like progressive enhancement. JS runs on 95%< of user agents - there's no reason not to make good use of it. François Robere (talk) 18:47, 24 May 2019 (UTC)

  Some of the arguments against Flow were of the form "we are not Facebook". Facebook isn't intended for discussions, because of the way that comments can be hidden by options. We (and I think I speak for all interested in actually writing an encyclopedia) DO NOT WANT that. And LinkedIn does advertise both their agents and external agents which access the database and modify your view. — Arthur Rubin (talk) 06:50, 25 May 2019 (UTC)

  Arthur Rubin, as a software engineer, the constant comparison with Facebook is the worst argument people ever came up with. —TheDJ (talk • contribs) 19:08, 27 May 2019 (UTC)

  TheDJ. I see your point. I was thinking of a negative about Facebook not on the list, that what parts of a discussion you see are determined by the relationship between you and the individual poster. This makes actual discussion impossible. Arguments, where posters reply to individual posts without context, are common in my feed. Discussions are possible here, although not common. — Arthur Rubin (talk) 20:22, 27 May 2019 (UTC)

  Neither are talk pages, to be frank. No other public discourse platform that I'm aware of consists of unstructured single-topic pages that anyone may mark however they wish, except perhaps physical bulletin boards and graffiti-adorned derelict buildings. As a discussion platform Facebook is well ahead of both. François Robere (talk) 20:01, 27 May 2019 (UTC)

  Nonsense. The fact that the posts that people see in "discussions" are determined by the relationship between the reader and the poster makes discussions impossible. Each person sees a different "discussion". And on both Facebook and LinkedIn, it's difficult to see which post is a reply to which, even if the poster chooses to ping. It's a little worse with Flow, and not great with WikiText, but it's usually possible. Google groups has a plausible indication, because the convention in Usenet was to visibly quote the ID (mostly done by software) and the text (mostly done by the user) of the post you are replying to. It has low actual information density, because of the pointers, but it's possible to read discussions as discussions. — Arthur Rubin (talk) 20:22, 27 May 2019 (UTC)

  On the contrary: it provides context - people have a choice who to discuss with; it's like Mediawiki's "watchlist", just that much better. We don't need to filter discussions by it, but we could certainly learn from it: follow topic, follow user, follow thread, follow category, follow section, get notified when a particular message gets replied to or when a particular type of edit is done (eg. to refs, translations or media), highlight particular messages or particular replies, and more. The design itself is also that much better: it's simpler visually, more intuitive to use, and doesn't require counting colons (*:::::) or {{od}}-ing (which, as you know, can make for some morbid humor, but are otherwise counterproductive). François Robere (talk) 10:31, 28 May 2019 (UTC)

Oh, on the question of "older" vs "next": It's "older 50" because if you aren't looking at the first or last pages, "next" is unhelpful. Look at your contributions. Labeling it (newer 50 | older 50) makes more sense than labeling it (next | next) would. Whatamidoing (WMF) (talk) 19:04, 24 May 2019 (UTC)

Is it really? I have 50 results on every Google page (default is 10, I know) and still the arrow at the bottom - there is an arrow at the bottom, because we perceive individual shapes faster than words - says "next", and it doesn't seem less informative. François Robere (talk) 21:13, 24 May 2019 (UTC)

• Going back to the original straw-poll query, I haven't touched either. The reply-to link is reportedly buggy in all the instances where it might save effort. Flow just makes my computer seize up (I edit via satellite which introduces a substantial delay), so I suppose I have a strong preference for a pure-text solution that doesn't use whatever it is in Flow that doesn't integrate with my set-up. Espresso Addict (talk) 00:21, 26 May 2019 (UTC)
• Support for Enterprisey's little gadget thing, I like it. Oaktree b (talk) 14:56, 27 May 2019 (UTC)

Straw poll: prioritization

Let's suppose the developers are given a deadline of 30 September 2020, and no more new features are to be developed after that point. Given the options (A) interface, styling and layout improvements for desktop and mobile (i.e. Vector and Minerva), (B) new discussion interface with inline replying, (C) section watchlisting, (D) automatic thread archival and link handling, and (E) some form of improvements to talk page metadata, in what order would you prioritize these? Jc86035 (talk) 10:34, 20 May 2019 (UTC)

• Having thought about this, I'd probably go with B and C first (in no particular order), then A, E and D (in that order). Jc86035 (talk) 15:31, 20 May 2019 (UTC)
• ABC. E & D maybe. Awesome Aasim 07:02, 21 May 2019 (UTC)
• From highest to lowest priority: A (with a focus on improvements to the mobile website and mobile apps), B, C, E, and D (already handled by bots). — Newslinger talk 08:26, 21 May 2019 (UTC)
• A-B-D-C-E. E should be part of B. As you're probably aware, I think the second item in the order of priorities should be redoing the entire Wikitext concept, which would in turn enable relatively easy implementation of B, C, D and E. Unfortunately, MediaWiki decided against rehauling the system in favor of incremental change. As an aside, Wikitext is not a "minimum viable product", and incremental change is not a new strategy, and using the former to justify the latter when both have been around for 15 years - as in the phase 1 report - reads somewhat ridiculous. François Robere (talk) 15:30, 22 May 2019 (UTC)

  Many of Flow's intentional features were considered show-stoppers by a strong consensus here on en.Wikipedia. It's possible that yet another complete overhaul of discussion pages might be the appropriate approach, but it seems to have been rejected in Phase 1. — Arthur Rubin (talk) 02:11, 23 May 2019 (UTC)

  I've never used Flow so I can't say, but considering the complexity of the system probably hinders many more editors than it assists, avoiding radical changes because of one bad past experiment isn't a good idea. François Robere (talk) 09:48, 23 May 2019 (UTC)

  (It's two bad experiments: LiquidThreads and Flow.) The same could be true of a new system, if it's flexible enough to be useful. I don't think 15 months is enough time for the necessary beta testing of a new system, even if based on an existing discussion system. — Arthur Rubin (talk) 17:45, 23 May 2019 (UTC)

• A-C-D-E-B. B could be a negative, if it makes existing pages unreadable using the new interface, or new pages unreadable when using the existing interface. — Arthur Rubin (talk) 02:11, 23 May 2019 (UTC)

  @Arthur Rubin: I've assumed that the new interface would either be on or off for a given page. If there's an option to turn of the new interface's interactive features, then a given user would either see both the current interface (on old talk pages) and the new interactive interface, or both the current interface and the new static interface.

  This also assumes two other things: (1) that old talk pages won't automatically be converted; (2) that there will be a transition period in which the interface doesn't change but signatures are modified so that the actual introduction of the interface doesn't break every ongoing discussion. Jc86035 (talk) 09:16, 23 May 2019 (UTC)

  @Jc86035: It seems unlikely that old talk pages would be automatically converted, just as old talk pages weren't converted to Flow. I'm not sure I understand your other assumptions. — Arthur Rubin (talk) 17:35, 23 May 2019 (UTC)

  @Arthur Rubin: The first assumption is based on the likelihood that the new features will be turned on per-namespace with exceptions allowed and enforced using a title whitelist (given that this seems to be the most reasonable option available). This means that the setting for an individual page could only be "on" or "off", with no in-between. As such, "off" pages wouldn't be able to use most of the new features (which for those pages would avoid the problems you suggested would occur altogether), and "on" pages could either support only an interactive interface or both static and interactive interfaces. (As usual, you would probably change this by changing browser, changing user preferences or adding something to the page URL).

  If this happens, that means that if the new interface and all supporting features are turned on all at once, most archived discussions would look different and/or strange things could happen to the section headers if new edits are made; and most discussions happening at the time would suffer from visual and source code problems because the new syntax (including changes to signatures) would be being mixed with the old syntax. As such, in order to mitigate this, (1) the software would have to avoid converting old talk page archives immediately, probably by using title matching and a page source search, with a built-in option for users to attempt automatic conversion of old-style talk pages to new-style talk pages and/or a bot task to attempt conversion for all old discussions and flag possible issues for human attention; and (2) in order to make a transition less bumpy, talk page signatures would be modified as soon as possible, such that it would be possible for the new software to convert comments without human attention (preferably without any changes to the actual source code) so as to avoid issues with the transition in ongoing discussions. Jc86035 (talk) 18:34, 23 May 2019 (UTC)

  Inline reply links might not require "conversion" of any pages (at least for simpler discussions). I'm sure it won't work exactly like this, but imagine something like this:

  A script searches for (UTC), and changes that to say (UTC) Reply to this comment?" on your screen. If you click the link, then imagine that it shows a plain little dialog box with one box in the middle and button to Publish or Cancel. You type your reply in the box, you click the button, and the box figures out where to paste it, how to format it, and types four tildes to sign your comment for you.

  That sort of simple change wouldn't require converting pages, opening a full editing environment, or anything else. If you were writing something more complicated (e.g., you wanted to Preview a link you added), then you could edit the talk page the old-fashioned way. Whatamidoing (WMF) (talk) 18:58, 24 May 2019 (UTC)

  That's something like the way the Reply-link script works, except it doesn't work for me on this page. — Arthur Rubin (talk) 06:32, 25 May 2019 (UTC)

  @Arthur Rubin and Whatamidoing (WMF): That's literally exactly how the reply-link script works (see line 5 of User:Enterprisey/reply-link.js, which defines TIMESTAMP_REGEX). So... what you're describing already exists, and I'm using it right now. It's not a perfect approach, though, since it's too easy for a perfectly normal line of text to result in a false positive, and of course the script fails if a talk page's source code contains formatting errors (which usually don't noticeably affect how the page looks). This was discussed in the phase 1 RFC, and I opined that it would be necessary to add an extension tag to signatures in order for the software to be able to unambiguously distinguish different comments. Jc86035 (talk) 09:29, 25 May 2019 (UTC)

• A-B-C-D. I don't know enough about "E".   - Mark D Worthen PsyD (talk) (I am a man. The traditional male pronouns are fine.) 18:46, 23 May 2019 (UTC)
• D-B-C-E, with a question mark next to A. I need more clarification on what would be meant by "interface improvements". If it means adding whitespace everywhere, it's not what Wikipedia needs. Mobile site is not a priority for me (I'm making this comment on mobile using the desktop visual editor), but not everyone will realize that the editing experiemce is greatly improved by using the "force desktop site" button, so I wouldn't object to fixing the mobile site. —pythoncoder (talk | contribs) 01:57, 26 May 2019 (UTC)
• A, B, E first, C, D after. Oaktree b (talk) 14:57, 27 May 2019 (UTC)

Human-editable text

The "modern view" on discussions seems to be that there is nothing "under the hood" which is visible; the actual, detailed, code is not human-readable. If that's the modern discussion model that some are talking about, I want no part of it, and an open-source project should want no part of it. That's why I suggest that the links to archived sections include a page name and section name of some sort, so we can see where the links went at some time. Perhaps [[Page#Section|linkname|ID#....]]. This is an ancillary part of how section links are to be handled, so I don't think this fits in any of the primary sections. But it probably should be discussed before implementation, which makes it relevant in phase 2 or phase 3. Any other comments? — Arthur Rubin (talk) 02:31, 24 May 2019 (UTC)

This would have two parts: a) whether the page is stored in whole, or in parts (eg. sections, comments etc.); and b) whether you use plaintext, a lightweight markup language like Wikitext, or "rich text" where the markup is usually hidden. There's something "under the hood" in all cases, but what and how you access it changes. I assume you're worried about transparency? François Robere (talk) 19:19, 24 May 2019 (UTC)

Rich text is unacceptable if we are to avoid vandalism. I'm thinking of one of the silly redaction schemes that some people have used on PDF files, merely changing the font colors to black-on-black, rather than black-on-white. (Yes, I've seen it done.) More subtly, we could have hidden text which is a copyright violation. We need to be able to see under the hood, which means a lightweight markup language or actual (lightweight) HTML. As another example, you may recall (one of the many) Microsoft/Apple scandals, in which there was supposed to be a Mac user who "saw the light" and praised Microsoft Windows. However, there was a Word document produced, and there were both invisible comments and file history indicating that it was generated in Redmond. — Arthur Rubin (talk) 06:30, 25 May 2019 (UTC)

@Arthur Rubin and François Robere: In defense of Flow, all it would have taken to avoid the hidden text problem would have been the ability to oversight Flow edits normally and the creation of a user group with the ability to edit others' Flow comments. That didn't happen, of course, and it's already been decided as a result of the phase 1 discussions that the direction would be narrowed to only encompass improvements to the current system (and I wouldn't expect that to change). Jc86035 (talk) 09:35, 25 May 2019 (UTC)

Flow already lets each wiki configure which users are allowed to edit other people's comments. I believe that if you go look at the first RFC for this consultation, you'll even find a link that shows me doing that. At MediaWiki.org, the config is set so that autoconfirmed editors can edit anyone else's comments. Here, I think it was originally set to admins only, but it could have been anything. It's just a matter of a config change. You don't even have to wait until WP:ITSTHURSDAY to make those.

BTW, the visual editor is a rich text editing environment. I don't recall ever seeing anyone set black-on-black font colors in it. Whatamidoing (WMF) (talk) 23:08, 25 May 2019 (UTC)

@Whatamidoing (WMF): How would you know if anyone set black-on-black font colors in it, or other additions of invisible text which could be displayed as improper. en.Wikipedia doesn't have bots that could scan Flow messages for that, and I don't think "we" are behind in the bot race. — Arthur Rubin (talk) 04:05, 26 May 2019 (UTC)

See below. You're worried about minor technical details that for the most part can be easily solved. The core question is important; these details are minor. François Robere (talk) 20:06, 27 May 2019 (UTC)

I see where you're getting. Well, rest assured that even plaintext can be used for malicious purposes, and I could certainly do black-on-black text in Wikitext too, as it admits a subset of HTML and CSS. These things can usually be mitigated in all three implementation (as well as in Word files), though I admit in a slightly less transparent way than plaintext or lightweight markup. An important question here would be whether you prefer a machine was the principal guard against these kinds of problems, or a human; I'd rather a machine did all these mundane checks, and I could concentrate on content. François Robere (talk) 10:56, 25 May 2019 (UTC)

Voting system

In addition to the existing criteria for the editing and changes, major changes like article title change and such, there should a tool for voting (non-text/gui based > click based IP/username bound). I am aware that a basic frame work exists, what I am speaking of is a simple, proper voting tool, once invoked it would collect data on two points, first which side to favour and why (references/supporting arguments this can be a simple comment box) to favour.

For instance: the article Basmala on wikipedia has a title that is very confusing for nearly all Muslims, because most do not use or even know this particular word. Most, nearly all, will recognise the word "Bismillah" instantly and that what is it referring to. Despite the fact the move has been proposed and voted for by a large number of people and editors it has not been executed. The grounds for not moving/changing the title is given (and logically so) is that in "English" language the word is predominant a few references have been provided as well, but in my opinion it does not make sense, as the article is about something exclusively related to Muslims and it should be presented as it should be "recognizable and usable" by the majority as it is the correct use as well. Also I've discussed some further details on the Basmala talk page. Moughera (talk) 17:29, 27 May 2019 (UTC)

@Moughera: that's a 2007 discussion that you've responded to. Since decisions on such things are not made simply by votes, I don't see how a tool would work. In any case, that discussion wasn't started correctly and if it had been today it would have been circulated to a wider audience. Doug Weller talk 17:51, 27 May 2019 (UTC)

@Doug Weller: the voting system discussion, i thought it's recent as the signs carry current dates? Yes I am aware such changes aren't made "only" through voting, but what I am suggesting is to make voting a factor or maybe one of the factors where this kind of situation arises. The article in question, the one i've mentioned as an example, lays out the problem very well. Moughera (talk) 18:07, 27 May 2019 (UTC)

@Moughera: On the talk page you replied to a post from User:AnonMoos from October 2007. As an aside, the person who started it was banned by the English Wikipedia and the Foundation. Doug Weller talk 18:11, 27 May 2019 (UTC)

No, voting and LIKE and DONTLIKE would be very unhelpful. POV warriors can easily canvass supporters off-wiki with dozens of consequent votes. The current system, where participants have to demonstrate some clue regarding procedures, is the encyclopedia's only protection. Johnuniq (talk) 00:41, 28 May 2019 (UTC)

Find addition/removal

Would this still exist? Doug Weller talk 17:51, 27 May 2019 (UTC)

Doug Weller, can you describe what you mean with this more accurately ? —TheDJ (talk • contribs) 19:11, 27 May 2019 (UTC)

@TheDJ: Wikiblame[4]. You click on find addition/removal on the history page to find when some text was added. Doug Weller talk 19:57, 27 May 2019 (UTC)

It certainly shouldn't exist as it does now. Searching and revision analysis should be much easier, accessible and more thorough, and completely integrated into the system. The current tools are... sub par for a system this scale. François Robere (talk) 20:08, 27 May 2019 (UTC)