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)

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
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.