Wikidata:Requests for comment/Talk pages consultation 2019, phase 2

An editor has requested the community to provide input on "Talk pages consultation 2019, phase 2" via the Requests for comment (RFC) process. This is the discussion page regarding the issue. If you have an opinion regarding this issue, feel free to comment below. Thank you!

THIS RFC IS CLOSED. Please do NOT vote nor add comments.

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, Wikidata was registered as a single "participant group"; this is to be the same in Phase 2. 16 editors participated in the local discussion, and more than 400 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) 16:15, 20 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've already made comments on the English Wikipedia, so I don't have anything to add in this section. Jc86035 (talk) 16:13, 23 May 2019 (UTC)
• This proposal sounds great - best of both worlds. Can it actually be done? I guess I'd like to see a demo, and what compromises end up being needed... ArthurPSmith (talk) 16:47, 23 May 2019 (UTC)

  @ArthurPSmith: No code has been written yet and there are no mock-ups, but I'm guessing it would look something like Reddit's new interface mixed with Flow. Jc86035 (talk) 14:49, 24 May 2019 (UTC)

• Cool. I am inclined to see a demo. But it will take a while. Sincerely, Masum Reza^☎ 15:36, 24 May 2019 (UTC)
• A design "on top of existing wikitext pages" is a pretty disappointing prospect, to be honest. If "replying, indentation and signatures" need to be improved, which I do not have any doubts about, then all of this should be handled by the software exclusively, without the possibility of interferences by users. Yes, this would break existing workflows much more than anything on top of wikitext pages, but otherwise we will not even remotely come close to a "discussion board" feeling for newbies. The proposed direction also offeres a lot of potential for mis-use of the new talk pages, either by mistake or intentionally, or because users do not want to or cannot adapt required new workflows. I have hoped for a more Flow-like approach which in many senses provides solutions to the identified core problems, and I do not think that the herein proposed direction is a good idea. —MisterSynergy (talk) 19:21, 25 May 2019 (UTC)
  • I caution against putting a halo around "newbies". I was listening to an interview with Rodney Brooks the other day, and he brought up Marvin Minsky's category of "suitcase words". I tend to supplement this concept with "trombone words", where the depth of the intended sense is highly variable, yet customarily unstated. This goes along with my long-standing habit of s/simple/simple for whom?/g (that is vim editor syntax for globally replacing every instance of the word "simple" with the question "simple for whom?" everywhere and always). The trombone-word analog is "newbie at what?". There are many, many different domains of horizontal skill transfer. These days, the world of youthful energy consists almost entirely of digital natives. Yet "newbies" continue to abound, moving the definitional yardsticks by means of the AI shuffle (rule: as soon as a computer can do, it no longer counts as AI). The underlying problem is that we're stuck with an impedance mismatch somewhere: the rules concerning what constitutes a valid citation, and how that citation is best employed are simply not "normal" in the real world. Wikipedia is also somewhat of a Klingon conlang in its underlying rules of social consensus. These are the two fundamental skills a "newbie" must eventually master to become a Wikipedia native. (The syntax is no worse than coping with stave notation for the first time, after you've already learned to play an instrument competently by ear; the Internet abounds with unreliable stories about which famous musicians can and can not read sheet music, and in what settings, to what end.) One possible perspective on this is the greedy algorithm: if we keep beating down the worst thing—in any reasonable order—the impedance mismatch will someday diminished or disappear. But I don't think this is true. The core cultural impedance mismatches between all things Wikipedia and all things not Wikipedia strike me as quite robust. So sure, we can spit-shine the welcome mat with an integrated discussion system that breaks existing workflows, but to what end? When I listen to French CBC on my radio (I have only a smattering of French) there's a limit to how much pristine radio reception abets my comprehension (it does help, but only marginally). Social is not the core product of Wikipedia. There's more involved in maintaining a viable community than creating a comfort zone for that first horrible day in boot camp. Moreover, the people who are going to stick in out in an encyclopedia culture are not your grandmother's newbies. Are they scholarship newbies? If so, they're going to struggle with the citation ground game. Are they formal-syntax newbies? If so, they're running against the grain of automation culture found in all domains IT. Are they collaborative project newbies? Then they're going to run aground on issues of ownership, prerogative, and authority. Are they seat-of-the-pants RTFM newbies? Then they're not going to enjoy being dunned by "per MOS" (or any other formal guideline). People who are rarely newbies at any of these things: white middle-aged male software engineers (I am, of course, one such person). So it's reasonable to think we can "solve" the inclusion problem by making Wikipedia slick and cuddly like an iPhone. And indeed, these devices are slick and cuddly now, and these days everyone is on social media, and sensible people are now wondering out loud whether the world as we knew it will ever recover. I personally don't see the wisdom of kicking incrementalism in the can (the aforementioned workflows), just to kick the impedance mismatch can further down the road—out of some blind faith in "social" when social in the large remains something of a shit show on its own terms (were it not so, but it is). Certainly there are many Stevie Wonders out there, and you want to bring these people into the fold as smoothly as possible, but at the same time, Wikipedia is fundamentally a sheet-music culture, and will remain so for at least a decade to come. From where I sit, re-inventing the talk pages as a fluid jam session completely misses this point. 70.67.182.26 22:26, 29 May 2019 (UTC)
• Two things: 1. The "proposed direction" page seems to consider indentation and mobile use as two separate issues, whereas the main issue on mobile is that after the fourth indentation or so you have about one character per line. 2. A problem with Flow specific to Wikidata is the handling of localized models in non-English talk pages (for example, on the French Bistro, typing {{Q|3}} will display "life (Q3)" instead of "vie (Q3)". How does the planned model solves that issue? -Ash Crow (talk) 20:57, 31 May 2019 (UTC)
• On Wikidata we have with our property proposal system, a case where we use Wikitext but it's still possible to follow individual property proposals and be notified when those change. Maybe, it's good to have a similar system for the individual discussions on talk pages that better supported by software to make it easier to use. ChristianKl ❪✉❫ 13:40, 7 June 2019 (UTC)

Marking separate discussions

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

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

• I assume this would function only at the "top" level within a given page, there wouldn't be support for subheadings etc? I suppose this is fine though. ArthurPSmith (talk) 16:53, 23 May 2019 (UTC)
• I don't think this works as long as users can manipulate the "structured definition of what counts as a single discussion". Sounds fragile as hell. —MisterSynergy (talk) 19:24, 25 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 Discussion tab. Most testers looked for a Discussion tab on the opposite side of the page, where all of the other tabs and links are. Many people also expected to see links to discussions about specific sections in the article. We may want to move the link to the talk page to the opposite side of the article page. We might add discussion functionality connected to individual sections.

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

• What about putting a link to discussion in the nav bar on the left-hand side of the page? But in general making the connection more visible sounds good. ArthurPSmith (talk) 16:56, 23 May 2019 (UTC)
• This is rather simple UI stuff, not much related to the rest of the consultation. Maybe some UI testing with different link positions and link texts (e.g. "discuss this article" rather than "Discussion") would help to identify simple and effective improvements. It might also be worth to consider different skins, particularly the modern Timeless skin, during research—do they work better out of the box than the dated Vector/Monobook skins? —MisterSynergy (talk) 19:28, 25 May 2019 (UTC)
• Personally, I'm happy the way it is. Giving more prominence to a tab that the thoughtful can find relatively easily runs the risk of encouraging unfocused posts, blogging, soapboxing to the extent that Wikipedia could become seen as a discussion forum. Dreamwoven (talk) 17:40, 28 May 2019 (UTC)

Where to show discussion tools

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

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

• NOOOO! This doesn't seem a good fit for Wikidata at least. We have a ton of pages that are basically structured discussions - property proposals for example. On the other hand there's not much point in having a "discussion" page for a discussion like that (maybe to discuss something at a meta level as we do with RFC's?). So if there could be a setting, maybe a template or something that designates a page as "discussion only", that might be useful - then there's no "Project page"/"Discussion" dichotomy, it's just a "project discussion" page. Another concern with this proposal relates to new users - if they have trouble finding discussion pages, won't they have even more trouble if every discussion is moved to the "Talk" namespace? ArthurPSmith (talk) 17:01, 23 May 2019 (UTC)
• The proposed "discussion mode" should be possible in any namespace, not only those which end with "talk". I would prefer a toggle switch in the "page information" section that is accessible for project admins, akin to "Page content language" or "Page content model". The "discussion mode" could by default be enabled in all "talk" namespaces and disabled in all other namespaces so that only a few exceptions would need to be set up manually by project admins. However, it would be desirable if the talk pages had a clearly different appearance from content pages. (Important for Wikipedias, but not that much for Wikidata which does not really have wikitext content pages.) —MisterSynergy (talk) 19:35, 25 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?

• The problem with complete page history is everything is jumbled together, it gets hard to find what you are looking for. History for a single thread would be fine. However, there also needs to be some sort of history regarding the page as a whole - when discussions were added to it or removed from it and by who for instance? ArthurPSmith (talk) 17:03, 23 May 2019 (UTC)
• I am only interested in the most recent page and/or discussion history, say the past day or so, to watch discussions and deal with vandalism. For more dated contributions, I rely on signatures only, thus I do not really care about page/discussion histories. However, If there needs to be a trade-off between those two, I weakly prefer discussion histories over page histories. —MisterSynergy (talk) 19:41, 25 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?

• Wikidata is one of those wikis that uses talk page metadata templates. It probably wouldn't be harmful if those had to be moved (unless the content model changes), particularly since most of those templates' content is automatically generated. However, the phase 1 report makes clear that change for change's sake would be undesirable, so for Wikidata this really depends on whether it's acceptable to cause some disruption and force some templates and Lua modules to be modified. Jc86035 (talk) 16:18, 23 May 2019 (UTC)
• The Status Quo is a consequence of the current talk page mess. I would be glad if that could be resolved as well, but I am not sure where it should go. A separate "meta" section on the talk page could be helpful, but many projects could consequently need a "meta" section on actual content pages as well (English Wikipedia WikiProject banners manage the content, but they are not related to the talk pages where they are placed). So: yes please, tidy this mess as well. —MisterSynergy (talk) 19:56, 25 May 2019 (UTC)

Other discussions

Based on this 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) 16:15, 20 May 2019 (UTC)

Straw poll: prioritization

(first asked on the English Wikipedia) 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) 16:31, 20 May 2019 (UTC)

• (as noted in the English Wikipedia discussion) From most to least important, B, C, A, D and E. Jc86035 (talk) 16:19, 23 May 2019 (UTC)
• If I understand these based on your description, my ranking from highest to lowest priority would be D, B, A, C, E ArthurPSmith (talk) 17:06, 23 May 2019 (UTC)
• D, C, B, A, E. --Daniel Mietchen (talk) 03:14, 28 May 2019 (UTC)
• We need to improve mobile and desktop experience for users. My order from highest to lowest priority is D, A, E, B, C. Sincerely, Masum Reza^☎ 18:47, 30 May 2019 (UTC)

Phase 2 report

Please see the mw:Talk pages consultation 2019/Phase 2 report. The main consultation is over. However, we still need to hear from you! Please put the mw:Talk pages project page on your watchlist. Whatamidoing (WMF) (talk) 17:17, 28 August 2019 (UTC)