Talk:Talk pages consultation 2019/Phase 1 report

Please find your name in this report
Hello, Akela NDE, Alexis Eco, AlvaroMolina, Andrzej19, AntonyB, Barcelona, Bruce Hemanga, 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)
 * another error (due to myself only) : mon avis sur la seconde phase a été mis dans les avis sur la première phase ; je consultais les avis déjà donnés et j'ai stupidement rajouté le mien. Cela prouve tout de même que les pages de discussion ne sont pas assez claires.
 * I thought about keeping a list of errors that I encountered during this process. Offhand, here's what I remember:  Multiple editors forgot to sign at least one comment (one of which was a joke, I think, but the others were accidents).  The use of non-matching signatures (e.g., "User:Example" for the real username vs "Example!" for the label in the signature) created repeated problems in writing this report.  We had at least three quotations that had the wrong person's username in the notes.  At least once, two consecutive comments, from different people, were initially counted as being from one person because it wasn't obvious where the first comment stopped and the second started.  As we all know, there's no automatic way to keep track of discussions on 20 wikis, except by visiting those 20 wikis separately.  There were probably more, but that's what I remember right now.  Basically, I'd say that writing this report proved all of editors' complaints correct.  Whatamidoing (WMF) (talk) 18:10, 24 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)


 * Charming. Tuvalkin (talk) 21:50, 27 May 2019 (UTC)
 * I know exactly what you mean. El komodos drago (talk) 16:06, 28 May 2019 (UTC)
 * Agree. I read most of the text about what is being proposed, but I did not see a differentiation between "What expert Editors might want" and "What new Editors might require", and it's an important distinction to make.  Before doing anything, I think the developers need to make an explicitly stated decision on what their primary focus is, and prepare in advance what they are going to do if the interests of these two groups should come into conflict, rather than being "surprised" midway through development and have to make that decision after work has been expended in one direction, and making the decision by a small number of technically-oriented types on an emergency basis, rather than having that decision made in advance by long term policy types.  You don't want the programmer to make this decision unilaterally when conflicts arise, because they are going to make their decision based on expediency.Tym Whittier (talk)
 * Maybe there could be an third-party application with a graphical user interface that shows the Wikipedia talk page as if it were a forum with different topics. I don't mind the normal way in Wikipedia, but it might confuse some new users, as has been already stated.

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)


 * MediaWiki.org is a multi-lingual wiki. You can use any language you're comfortable with.
 * I believe that User:Yodaspirine has thought about the "metadata" problem. Some notices might be important, but some re-organization might be helpful.   Whatamidoing (WMF) (talk) 18:19, 24 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)
 * Supporting multiple discussion types is definitely necessary, especially if things like deletion discussion votes/expressions-of-opinion could be emphasized through CSS. A Twitter-style inline polling system (separate from SecurePoll) could be useful as well, although it could be difficult to implement this (e.g. a "poll creator" user group might have to be created) and it could fundamentally change how decision-making discussions are held (e.g. is a supermajority necessary for consensus? would ranked-choice voting have to be implemented?). Requiring some discussion (through policy) before a vote could help. Jc86035 (talk) 12:09, 18 May 2019 (UTC)

Following separate discussion
Of course people like to follow or watchlist separate discussions on the same talk page; be able to neatly archive discussion threads, and search/find them afterwards. One option is to have each discussion on a separate sub page and list the separate discussions on the talk page by transcluding the sub pages. Archiving is easily done by removing a transclusion of the sub page from the talk page (A button next to the title of the discussion on the talk page to archive/remove/suppress the discussion would be a helpful add on). Following a specific discussion is easily done by watchlisting the sub page. (An open five pointed start next to the title of the discussion on the talk page would be a helpful add on). Nearly all functionality already exists. The 'Add topic' tab needs to be redone. Hitting 'Add topic' should in this scheme create a new sub page which is automatically transcluded on the talk page. That could be entered at the bottom of the page, or at the top of the page. The 'Edit section' putting should let the user edit the designated sub page - and after saving they might want to return to the talk page where they came from. Ad Huikeshoven (talk) 12:39, 18 May 2019 (UTC)

Is a indentation the best way to indicate start of a post?
Thank you friends for this work to summarize the contributions to a report. I see only one point clearly to improve: the discussions about the way of how to do the indentation does keep out the question, if indentation is the best way to indicate the start of a post (comment) and relation to previous posts. A common clear start of a new post e.g. on facebook and other social media shows WHO postend WHEN together with a clear end this is a frame. Only with a clear start and end of a post I can see, if the post is related to previous level of indent - else an indent only shows that there is a new post but not, if related to previous post or pre-previous. Suggestion: Username and Date-Time can be created like a signature by shortcut e.g. Charis19052509 and the old current signature can be set as End. This can be enhanced as clear identifier by anchor to relate to a post, also with a short header: Charis19052509:Clear start indicator of a post...post-body-text...Charis (talk) 09:44, 25 May 2019 (UTC)

Other discussions
Is feedback that falls outside the six given categories necessary or desirable? I personally think it could be useful, e.g. to hold straw polls. Jc86035 (talk) 14:16, 18 May 2019 (UTC)


 * Well... our own home wiki has historically been the most visible exemplar of the Polls are evil mindset, so it might not be appropriate there. Other communities take a very different approach and settle everything by a simple majority vote. I would say that you should follow the local culture, whatever that is.  If you think that a straw poll would produce useful information and would be normal in that community, then that's okay.
 * That said, it should go without saying that the outcome of this consultation isn't a vote. The team is taking in information and will make the final decisions.  Some of that information might come in the form of "13 of the 18 editors in this one discussion voted to...", but that information is equivalent to all the others.  Rationales, details, and examples matter a lot.  (And even the end of this consultation won't be the end of decision-making; if "popular" and "logical" changes fare poorly in user testing, then they'll have to change their plans.  I've been living with the "just what I asked for, but not what I want" situation in VisualEditor these last few weeks, and I would hate to see that kind of outcome on all of our talk pages.)
 * Something related that's been on my mind is prioritization. The foundation has gotten futher along in its strategic planning while this consultation has been running.  At this point, I think that convincing them to take on a multi-year "massive" project is going to be a hard sell.  I'd help you make that case, of course, if that's what people decide they need, but realistically, I think we're looking at what can be done in the space of a year or two, and then the team (which is still unassigned) will stop and let the dust settle.  So if you have ideas about which thing to do first (wikitext changes first, or moving categories into a proper metadata space first?), then that could be useful information.  Whatamidoing (WMF) (talk) 21:17, 18 May 2019 (UTC)
 * I think straw polls were a bad example; the main reason I would be starting other discussions would be to further advance the discussion so that that information could be taken into account in phase 3 (e.g. doing basic design demos by messing with HTML; asking about other topics which aren't covered by the six questions like signature customization and different indent/discussion types).
 * On prioritization itself, changing the interface on discussion pages would probably be my first priority, but this would mean doing a lot of the mildly disruptive changes as groundwork (e.g. changing syntax and the parser, introducing magic words). The disruptive changes could also allow for section watchlisting (depending on implementation, of course). Alternatively, if this is shot down, it would probably be passable (but not by any means a good solution) to translate reply-link and enable it globally after changing the mainspace interface. Jc86035 (talk) 06:30, 19 May 2019 (UTC)
 * Realistically, would it be possible to, basically, put the Flow interface over wikitext comments in the time available? I have no idea how those work under the hood so I don't know whether this would be possible. In my mind you could get a fairly sophisticated interface (diff links, user hovercards, etc.) just by dumping all the necessary metadata onto the talk page upon signing/saving a new-style comment or adding a new-style level 2 section header, but I don't know how feasible that would be. In theory, at least, you could generate something that looks like a Reddit comment out of a bunch of wikitext comprising the comment, the username, the date and the revision ID (or even just the revision ID).
 * The reason for doing the aforementioned design demos (essentially, taking four divs from Flow and putting some more CSS and fake buttons on them...) would be to get some early feedback about various possible interface features (e.g. how cluttered should the interface be, how much padding is too much padding, should hovercards be used, etc.), assuming that revamping the interface is something that's probably going to be done and that it would be done without using hacky tacked-on scripts that don't always work (i.e. the reply-link band-aid). I don't really know if the team would find this sort of thing helpful. Jc86035 (talk) 08:56, 19 May 2019 (UTC)
 * Is it possible? Well, in theory, it's all just bits, so probably.  Would we be happy?  Well, it would  put some restrictions on the people who would opt out of the changes.  Their personal cost:benefit ratio would be negative.  For example, imagine that making that interface work required a sort of AbuseFilter that won't let you save the page if you've broken the ==Section heading== like I did in this reply.  The people who used the new tools wouldn't be affected (because a typo or stray click couldn't break the section heading), but the people who used the old editors might be frustrated.  As with most changes, I assume that some people would accept this, and others wouldn't.
 * The analysis you wrote above ("On prioritization itself") is likely to be very useful. I'd be happy to see something similar from lots of people.    Whatamidoing (WMF) (talk) 22:21, 19 May 2019 (UTC)
 * Thanks. I hadn't considered that some users might be opposed to even small changes like warnings, but I think it would probably be fine if it doesn't outright prevent the edit from being saved (e.g. "you're deleting a section header; are you sure you want to do this? [publish/cancel]").
 * I agree that the changes could even be a net negative for those who continue to write comments as source (not that I can see that happening very often if the inline reply interface works exactly like a standard wikitext editor with a visual/source button), and this could actually have a fairly significant impact on user warning templates and the like, but I imagine that you could probably make something work if you were to change how four-tilde signatures work on talk pages (while keeping three- and five-tilde signatures the same). Jc86035 (talk) 07:02, 20 May 2019 (UTC)

Comments by Cedders
I followed the invitation from the top of a Wikipedia page and added my comments on the six questions at Talk_pages_consultation_2019/Individual_feedback. To summarise, I think any change should be incremental, but general across MediaWiki use cases, and wonder about testing more newbie-friendly discussion tools based on additional 'suggest' or 'reply' buttons, prefilled signatures, and an enhancement to the TOC so it can function as a more useful thread index. --Cedders (talk) 08:32, 28 May 2019 (UTC)

Mobile website has a talk page browser.
I am not sure whether it has already been mentioned, but the mobile website does have a topic browser for talk pages. --Chanc20190325 (talk) 23:50, 28 May 2019 (UTC)

Comments by IndrajalikSouvik
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 — Preceding unsigned comment added by IndrajalikSouvik (talk • contribs) 08:37, 31 May 2019 (UTC)

Women
Design is not neutral. I am convinced that design could be a differentiator between connecting to specific groups of people and putting them off. As we seem to have much less women than men editing Wikipedia content, and we would like to have that more even, any design change should explicitly be tested for and by female test groups. Titusmars (talk) 09:45, 31 May 2019 (UTC) (man, actually)