Talk:Talk pages consultation 2019/Phase 1 report

Please find your name in this report
Hello, Akela NDE, Alexis Eco, AlvaroMolina, Andrzej19, AntonyB, Barcelona, Chnutz, Ciell, Designer1959, Dimaniznik, Edgouno, Enyavar, Fanaliceful, Floflo, Flugaal, Frigory, Geonuch, Grasyop, Gżdacz, H7, Jaluj, Jamain, Jckowal, Jeblad, Jpgibert, Jules78120, Lamiot, Liquendatalab, Louis H. G., MarioFinale, Matthiasb, Nattes à chat, Neitram, Niridya, O. Morand, Oleg3280, Oscar ., Pamputt, PaulSch, Reem Al-Kashif, Retired electrician, RonnieV, 百無一用是書生, Sumek101, Thieu1972, Tortliena, Tximit, Vriullop, Wargo, Wiesios, Wikilover90, Yellow Horror, Yodaspirine, Zellmer, そらたこ, リボンちゃん, and 無聊龍:

You have been quoted in this report. Please find (Ctrl or Command) your name in the report. Some people were quoted more than once. Please tell me if the translation is not good. Whatamidoing (WMF) (talk) 20:12, 17 May 2019 (UTC)

Also Waldir, (from Flow/Research/Experienced User Responses) and Kippenvlees1, Prométhée, and Tom (LT) (from the 2019 Community Wishlist Survey on Meta): Your comments, from previous relevant discussions, are quoted in this report. I'm pinging you in case that might be surprising. Whatamidoing (WMF) (talk) 20:22, 17 May 2019 (UTC)


 * Fixed minor errors. Feel free to edit if necessary. Jeblad (talk) 20:46, 17 May 2019 (UTC)
 * Same. Best regards, Jules78120 (talk) 11:02, 18 May 2019 (UTC)

Some thoughts
For the most part, I'm rather indifferent at this stage as it's high-level planning rather than specifics. But I do have some thoughts. HTH. Anomie (talk) 20:51, 17 May 2019 (UTC)
 * I see several mentions of "new buttons" for accomplishing things, but no specifics of how those buttons would work.
 * If you're creating new special pages (like Special:MovePage) or index.php actions (like action=edit and action=history) for manipulating "threads" and such, keep in mind that your MVP must include ways to accomplish everything via the Action API as well.
 * If you're creating your new features using JavaScript, I'd guess that'll already be using the Action API. But remember that many of our users use browser extensions like NoScript or otherwise disable JavaScript and would like to be able to continue using talk pages. It's ok if the experience isn't as convenient (e.g. they may have to manually type some wikitext and remember ~ on their own), but they should still be able to accomplish everything.
 * As much as possible, make sure that someone (or some bot!) who uses the old syntax doesn't break everything. For example, if you introduce some new syntax for headings and someone adds a section using the old syntax. At the same time, forbidding the old syntax would likely be counterproductive.
 * Remember that major changes to the syntax go against #Stability. Switching from colons/asterisks for indentation to some new character would be less disruptive than wrapping every comment in XML-ish tags. Normal "==" headings would be less disruptive than some new syntax for headings, even "=/="; on every page I'm aware of, "a discussion" is almost always indicated by the same level of heading, so all you might really need is some way to know that e.g. each separate discussion on w:en:Wikipedia:Templates for discussion/Log/2019 May 16 is the "====" level rather than "==".
 * At least on enwiki, people do sometimes use the Wikipedia_talk pages of Wikipedia-namespace discussion boards to separate discussion about the board itself from whatever topic is supposed to be being discussed on the board. While in my experience the meta-discussion tends to be infrequent, expect pushback if you try to force all boards to move to Wikipedia_talk. The wikitext magic word (like the existing  magic word that adds the "add topic" tab) strikes me as more likely to be accepted.
 * Regarding per-page history versus per-discussion history, I personally would prefer to keep the per-page history as that's how I keep up with discussion boards.
 * Regarding moving the top-of-page templates, I'd expect pushback on that one along the lines of "if you hide them somewhere else, no one will ever see the important information!". Likely no matter how objectively useless the information actually is to a newbie trying to use the talk page.

Once upon a time…
I was involved in a project to replace a really ancient and crappy system. We were trying to rebuild the system, to create something better and more usable. It should even have a graphical user interface! After several year the system emerged. Strangely, it had all the bad interaction gadgets, but now the exact same weird handles were recreated in the graphical user interface. The users still typed the actual numeric action codes. What had happen? We did one major error, we asked expert users what they wanted. Everybody thought they know best how to make an efficient system, but what they did was to recreate a system with all the original flaws because the did know how to work around those flaws.

The lesson learned; don't make an expert group of old users with bad habits. ;) Jeblad (talk) 21:44, 17 May 2019 (UTC)

Comments by Alsee
I thought phase 2 would include more detail.

1: What do you think of the proposed product direction?

I am greatly relieved that the proposal is to add functionality to what we already have. The specifics will still be key, but the direction sounds very promising.

I would like to add some advice on how to conceptualize the project. It appears the team is still in the mindset of building talk page features. I think it may help if you can think from the viewpoint that "a page is a page". You're not building talk page features, you're building page features. In some ways it narrows down the options that make sense, and in some ways it may make some of the issues vanish.

2: Marking separate discussions

I would split this into two kinds of change. First, a style change such as =/=SECTION=/=. It is unclear to me why that would be needed, but I can see that being viable if it really is needed. The second kind of change is what I'd call "not human writable". Something like software-generated Globally Unique IDs (ge09834h534uo3g) is obviously something a human can't click edit and write. That raises a much more serious hurdle. I would want to carefully examine what's possible without that. I think there may be some flexibility in "expected functionality" that may help avoid that kind of approach.

3: Helping newcomers find the talk pages

I suspect that the Vector skin is part of the problem here. It makes Talk and other links-for-editors literally fade into the background. That aside, increasing the visibility of Talk pages for new users sounds fine. It's unclear what "discussion functionality connected to individual sections" would look like, so I have no view on that.

4: Where to show discussion tools

It's not completely clear yet what these would look like, but if you can follow the model that "a page is a page", that may solve itself.

One of them is to move all discussions to a talk namespace.

That's rather awkward. Sometimes the primary workflow-page is a discussion page, and we need a Talk page behind it for discussions about that workflow. For example Village Pump, requests for promotion to administrator (RFA), and deletion-discussion pages (AFD). This option would leave us with a useless/not-created non-talk page, and it would leave us nowhere to have discussions about workflow happening on the Talk page.

In a sense, the real problem here is that this violates the model that a page is a page. It tries to create types of pages, with technical differences between them. That breaks the "pageness" of a page. I'm sorry of that comes across as too zen or too abstract, but part of the simplicity and flexibility of a wiki is that a page is just a generic page.

5: History tradeoffs

I'd be willing to consider ideas here, but like you, I don't see how this would work. There have been very rare times when it would have been convenient if an archive page gave more direct access to a discussion edit history, but overall I'm not seeing much opportunity for a net positive. I'm pretty sure we need to retain the full history on the original page, and trying to duplicate the relevant entries onto the archive history would almost surely be a disaster.

6: Metadata location

Some templates really do need to be at the top of the page, and some are clutter that I'd gladly see moved out of sight. Some are a difficult call that would involve significant internal community debate&grumbling. I think for simplicity we can just call it "half" that could be moved. I don't think the Foundation should even ask which ones. That would be handled by the community.

Currently all pages come in pairs (a page and a linked Talk page). I was stunned for a moment by the idea that we might convert all pages into triplets, to have a place to put this kind of stuff. That is a bold and unexpected notion. I'm not sure what I think about it. However I would say it is effectively independent of the Talk page discussion. If you really want to consider that, I'd split it off as an essentially separate proposal.

Other than making pages into triplets, I'm not sure where else that stuff would go. However I would like to note that the community already has some of these templates default to collapsed mode, and in some cases we already put multiple templates behind a single collapse. Even without Foundation action, the community could immediately start moving all hideable templates behind a single show/hide collapse if we decide that is worth doing. Alsee (talk) 08:11, 18 May 2019 (UTC)

Comments by Jules
Hi,


 * 1) I really like this orientation: not replace the wikitext discussion by something like Flow, but add a functionnalities that make easier the use of wikitext discussions. A bit like VisualEditor did not replace Wikitext, but came over wikitext interface. I think this orientation is the more likely to make consensus inside communities.
 * 2) I think Wikimedians can adapt to minor changes in the way in which discussions are separated. It won't affect too much flexibility, if it is still possible to merge or split discussions.
 * 3) Great Idea. The only disadvantage I can see is, as a side effect, an increase of vandalisms and/or irrelevant comments (remember the feedback feature?) on talk pages. If talkpages are more visible (for both readers and newcommers), it would probably be needed to think how to inform Wikipedia readers about what is relevant (discussing about article content) and irrelevant (how to contact this personnality, your opinion about this singer, etc. ;-))
 * 4) The best thing would be to encourage to move all talk spaces on 'talk page' namespace, but also allow exceptions with a magic_word or template (as fr:Modèle:Page de discussion on French Wikipedia) which can be added on top of a page to give it talk pages features. This would keep the current flexibility.
 * 5) As an experimented editor, I prefer complete page history, but I can understand that topics histories could be nice, in addition. But these topics histories should be like (look the same) the complete page history. Currently, Flow topics histories are not built in the same way classic histories are; it's a mess ^^. To implement those two histories in parallel, maybe just keep the "History" tab as it is now (complete page history is displayed) and add a "Topic history" tab near each topic title?
 * 6) I'm not sure I understand this question. Metadata information should imho stay on top of talk pages (on article talk pages, there can be advices or warnings when the topic is hot/controversial; on community talk pages like Admin noticeboards, there can be explanations that should be read before publishing; etc.). But maybe could they be identified with markup/tags/template so, with the new discussion overlay (if we can call new features this way?), it would be explicit that it is not a discussion content, not a talk topic.

Sorry for mistakes, my English need improvements ;-). Regards, Jules78120 (talk) 11:32, 18 May 2019 (UTC)

Preliminary thoughts

 * This is a good summary and I think it's good that individual comments from the discussions have been presented.
 * I somewhat doubt that no one defended signatures, considering how many users customize them. I think it could be beneficial to allow signature customization to live on in some way, even if they're removed from the discussion interface (e.g. showing them in popups when hovering over usernames).
 * I think it would be a bad idea to give each section of a talk page its own history. This would almost certainly conflict with the desires to view all changes on a page at once and edit all of a page at once. (It also wouldn't take into account messages moved between discussions.) I think – if it would be possible – a better approach would be to automatically add diff links to comments and allow modified level 2 section headers to serve as "real" markers for watchlist notifications, possibly by generating short tags for each section and keeping them in the wikitext. This would also help for section links on wikis like Commons and Wikidata, where section headers appear differently for different users because translation parser functions and templates are used in them. (Perhaps by using an edit-tagging system based on this you could filter relevant edits in page histories, rather than keeping two copies of every thread's history.)
 * Using an actual template, à la FlowMention, could be difficult to manage (why not use a software-defined parser function or magic word?). In general, syntax should probably be kept lightweight and unobtrusive.
 * I would support something like a pair of  and   magic words to enable and disable the talk page upgrades.
 * As a Timeless user, I think many of the interface problems (e.g. contributors clicking on the wrong "Talk" link) can be attributed to Vector. The important links aren't emphasized enough, and there are so many links that almost no one looks at them unless they're really bored. Even in Timeless, where the "User talk" link is always hidden under a drop-down, I'm not sure whether ten new contributors would all find the "Talk" link.
 * As a Wikidata user, I think changing the to indicate more clearly that a page is a discussion page could be helpful interface-wise. It doesn't have to be exactly the same as the title indicated in the URL.
 * I think a mechanism to notify more than 50 editors at once could be helpful. Perhaps transcluding a page where users can only add their own username but not someone else's, and user renames are automatically reflected? Jc86035 (talk) 11:46, 18 May 2019 (UTC)