<!-- [[User:DoNotArchiveUntil]] 21:01, 21 September 2021 (UTC) -->{{User:ClueBot III/DoNotArchiveUntil|1632258084}}
| status =
{{rfc|policy|rfcid=FEAE920}}
| result = There is a (near-unanimous) '''consensus for the proposal'''; and with comments only trickling in very sporadically in the past week or so, it's clear that [[WP:SNOW]] applies, too. [[User:RandomCanadian|RandomCanadian]] ([[User talk:RandomCanadian|talk]] / [[Special:Contributions/RandomCanadian|contribs]]) 22:42, 3 September 2021 (UTC)
}}
Should administrators be allowed to apply extended-confirmed protection to [[WP:HRT|high risk templates]]? 03:59, 17 August 2021 (UTC)
Should administrators be allowed to apply extended-confirmed protection to [[WP:HRT|high risk templates]]? 03:59, 17 August 2021 (UTC)
{{Moved discussion from|Wikipedia:Administrators' noticeboard#TemplateProtector bot updated; Should we use ECP on templates?|2=<span style="white-space: nowrap;">[[User:Wugapodes|Wug·]][[User talk:Wugapodes|a·po·des]]</span> 20:45, 17 August 2021 (UTC)}}
{{Moved discussion from|Wikipedia:Administrators' noticeboard#TemplateProtector bot updated; Should we use ECP on templates?|2=<span style="white-space: nowrap;">[[User:Wugapodes|Wug·]][[User talk:Wugapodes|a·po·des]]</span> 20:45, 17 August 2021 (UTC)}}
Line 560:
Line 564:
*:::Up until yesterday, the bot only acted on templates that were completely unprotected. Now it will escalate from semi to template editor in accordance with the configuration. The technical means to do this was only made possible some months ago. So while the bot came too late to the rescue in this case, we should at least be glad our new database replicas are fast enough to make this functionality possible :) <span style="font-family:sans-serif">— <span style="font-weight:bold">[[User:MusikAnimal|<span style="color:black; font-style:italic">MusikAnimal</span>]] <sup>[[User talk:MusikAnimal|<span style="color:green">talk</span>]]</sup></span></span> 03:37, 19 August 2021 (UTC)
*:::Up until yesterday, the bot only acted on templates that were completely unprotected. Now it will escalate from semi to template editor in accordance with the configuration. The technical means to do this was only made possible some months ago. So while the bot came too late to the rescue in this case, we should at least be glad our new database replicas are fast enough to make this functionality possible :) <span style="font-family:sans-serif">— <span style="font-weight:bold">[[User:MusikAnimal|<span style="color:black; font-style:italic">MusikAnimal</span>]] <sup>[[User talk:MusikAnimal|<span style="color:green">talk</span>]]</sup></span></span> 03:37, 19 August 2021 (UTC)
*::I appreciate the desire to review the transclusion count periodically, but am not sure if a seven-day minimum period is long enough. For bot-set protection, it doesn't matter, but if an admin set the protection level, surely they considered the future potential usage of the template for more than the next week? [[User:Isaacl|isaacl]] ([[User talk:Isaacl|talk]]) 20:17, 19 August 2021 (UTC)
*::I appreciate the desire to review the transclusion count periodically, but am not sure if a seven-day minimum period is long enough. For bot-set protection, it doesn't matter, but if an admin set the protection level, surely they considered the future potential usage of the template for more than the next week? [[User:Isaacl|isaacl]] ([[User talk:Isaacl|talk]]) 20:17, 19 August 2021 (UTC)
{{closed rfc bottom}}
== Enable Article / Talk tab bar for mobile anon users ==
== Enable Article / Talk tab bar for mobile anon users ==
Gender used in messages is biased in preferences (copied from Village Pump (Technical))
Copied this over from Village Pump (Technical) because it was posted to the wrong place. I want to get community consensus on this here to send it to Phabricator...
In the preferences settings under the first tab named "User Profile" there is a section about: Gender used in messages, where a user can specify to be addressed by gender neutral, feminine, or masculine pronouns, and when another user hovers over the username the chosen pronouns will be displayed as he/him or she/her along with the user rights and other user groups of the user as well as their edit count and some other basic information about the user.
However, there is a technical issue with this feature that makes the preference appear to be biased in nature where the feature appears as if it doesn't work at all if a user chooses that they wish to remain gender neutral because if this option is chosen there is simply nothing at all displayed when you hover over the username, and there should be at least something such as they/them to indicate the user has made the choice and the feature is working.
I propose we add they/them to the feature to avoid the appearance that the preference is biased against people who choose to remain gender neutral, and to ensure that all editors will have a way of knowing the feature actually works.Huggums537 (talk) 19:03, 30 July 2021 (UTC)[reply]
[I need to make an amendment to this proposal to avoid any confusion on what it is about. I first brought it to Village Pump (Technical) because this is mostly about the feature technically not functioning properly where it will not display the choice of the user if they choose "Gender unspecified". This is not so much about the bias against they/them pronouns, but I thought I might throw that in there because it also incidentally appears to look that way. However, my main concern is the functionality, which can easily be solved with a simple text modification.
Therefore, I amend my proposal to modify the text as suggested by King of Hearts and Trappist the Monk in the manner described by Writ Keeper so that it shall say, "Gender unspecified" or "Unspecified gender" on the popup.]
Agreed, there should be a fourth option. We shouldn't force "they/them" pronouns on people who simply haven't made a choice, so we need to distinguish between actively neutral vs. passively neutral. -- King of ♥ ♦ ♣ ♠19:27, 30 July 2021 (UTC)[reply]
By when another user hovers over the username the chosen pronouns will be displayed as he/him or she/her along with the user rights and other user groups of the user as well as their edit count and some other basic information about the user, I assume you're talking about Navigation Popups? That's a locally-maintained gadget, not a piece of the Mediawiki interface, and so changes to it would not go through Phabricator; instead, an intadmin would need to make the requisite changes at MediaWiki:Gadget-popups.js (specifically, line 4185, where an option other than he/him or she/her would need to be added, and line 7276, where a corresponding l10n string would need to be added. KoH's suggestion of an explicit difference between "they/them" and "unspecified" is a different matter, of course, but that would be neither sufficient nor necessary to add they/them support to NavPopups; changes to the script would still need to be made regardless of whether such a Phab ticket were filed. Writ Keeper⚇♔19:35, 30 July 2021 (UTC)[reply]
Writ Keeper, I think this sounds correct. So, the changes under the new proposal would simply be to add "Gender unspecified" to the navigational popup so that it matches the current choices already being offered in the preferences and will show up in the popup the same as the other two choices. Huggums537 (talk) 23:18, 30 July 2021 (UTC)[reply]
(edit conflict) I don't know what you mean by when another user hovers over the username the chosen pronouns will be displayed as he/him or she/her along with the user rights and other user groups of the user as well as their edit count and some other basic information about the user. I've never experienced that. I'm not really sure that I want to.
Regardless, I don't particularly want to be addressed with they/them/their because there is (thankfully) only one of me. Alas, the default radio button 'Unspecified' doesn't really mean 'Unspecified'. So, for me the fix is to do as you say for those who prefer singular plural pronouns to select that and make 'Unspecified' really be 'Unspecified'. Or, better, dispose of the options altogether and stop the attempt to put us all into neat little boxes.
Trappist the monk, I don't want to put anyone into "neat little boxes", but I do want to give everyone the options to choose, not dispose of them. So, that is why I support the idea King of Hearts has suggested about adding a fourth option to distinguish between active or passively neutral, and the way that could be accomplished is by integrating your idea of adding an option of "unspecified gender" right along with they/them, he/him, and she/her. That way a user has complete choice over how they wish to be addressed. Huggums537 (talk) 20:57, 30 July 2021 (UTC)[reply]
Trappist says she prefers not to be referred to as they and also doesn't want to specify any pronouns; that's cool. I won't refer to her as they.
Without those neat little boxes, we end up with a default setting. That default setting has on the internet often been he/him. Allowing us to place ourselves into those neat little boxes means I don't get (too often) called he/him, which over the decades has become quite tiresome. The default setting moving toward singular they is IMO quite productive, but for those who both reject they and refuse to specify, each of us should feel free to come up with her own default setting. :) —valereee (talk) 13:46, 3 August 2021 (UTC)[reply]
Isaacl, except that "unspecified gender" does not appear when you hover over the username. As I mentioned before, it is just blank and shows nothing giving the appearance that it does not work for users who have decided to choose this option. At the very least, the text should be altered to say, "Unspecified gender" the way Writ Keeper has suggested. That way it will still be in compliance with the previous discussion while solving part of the problem as well. Huggums537 (talk) 21:03, 30 July 2021 (UTC)[reply]
Yes, I read your original post regarding what is presumably displayed by the navigation popups extension (perhaps you could confirm this). isaacl (talk) 21:24, 30 July 2021 (UTC)[reply]
So you're confirming that the popup in question is being displayed by the navigation popups gadget that you have enabled? isaacl (talk) 21:59, 30 July 2021 (UTC)[reply]
I'm only confirming the popup doesn't display all the options. I will try to verify which tool is producing the popup if I can, but I figured experienced editors around here would already know which one produces the information when you hover over a username, and Writ Keeper suggested it was the navigation extension and that sounds correct to me because I looked at the code and it has related information in it... Huggums537 (talk) 23:30, 30 July 2021 (UTC)[reply]
How does this same thing keep going in circles?? The literal options for this value are already: unspecified, male, female. This is a language setting, and is part of software used globally - including in languages that only use gendered nouns (e.g. Userio vs Useria for "User"). This proposal is very vague and seems to be the XY problem - are you really trying to change the mediawiki software, or do you really want someone to just recode the local gadget? — xaosfluxTalk22:51, 30 July 2021 (UTC)[reply]
Xaosflux, This is actually a simple and uncontroversial edit I'm proposing with no changes to the existing values in the mediawiki software. All I'm asking for is that when a user chooses "Unspecified" for gender neutral preferences that something will show up in the popup to indicate they have made that choice the same way it pops up he/him or she/her if someone chooses the male or female preferences. Currently, nothing at all shows up in the popup for "Unspecified". However, we could add two little words that say, "Gender unspecified" into the popup and that would at least show something that indicates a user has made that choice. It's not that complicated. Huggums537 (talk) 23:08, 30 July 2021 (UTC)[reply]
Unspecified is the default at Special:Preferences. If a user has never touched or looked at their preferences then Unspecified is marked. There is currently no way to tell whether a user has deliberately chosen Unspecified or never done anything. The popup is only seen by registered users who have enabled "Navigation popups" at Special:Preferences#mw-prefsection-gadgets, a script made at the English Wikipedia by the editors. It's disabled by default and cannot be used by unregistered users. It would be possible for popups to say "Gender unspecified" instead of saying nothing, but popups has no way of knowing whether the user chose that or never chose anything. That would require a change in the MediaWiki software. PrimeHunter (talk) 23:28, 30 July 2021 (UTC)[reply]
PrimeHunter, But why does it have to matter to anyone else if a user chose the option or it was defaulted to them in order for the option to be displayed like the others? Huggums537 (talk) 23:36, 30 July 2021 (UTC)[reply]
Wugapodes, Don't ask me why it matters, ask whoever decided to inform everyone else of these pronouns with the popup information, but also decided to withhold the information about the non-use of any pronouns no matter if it was decided by default or not... Huggums537 (talk) 02:42, 31 July 2021 (UTC)[reply]
My point being that you're fine with respecting the choice of those who choose a non-default option, but seem to not care about those who chose the neutral option. You may not care, but others do. — Wug·a·po·des02:56, 31 July 2021 (UTC)[reply]
Wugapodes, these assumptions of what I do or do not care about are, and should be irrelevant to the discussion because what I care about has no effect whatsoever on the simple insertion of plain "Unspecified gender" text, and the text itself does not care one way or the other either, nor does the insertion of the text imply about any caring one way or the other since the text itself applies to both options so your point about what I do or do not care about seems rather moot. Huggums537 (talk) 03:48, 31 July 2021 (UTC)[reply]
To be clear, "neutral" meaning that some people don't want the system referring to them with gendered language at all. You haven't explained how being told something is unspecified is helpful compared to just not specifying it. — Wug·a·po·des03:01, 31 July 2021 (UTC)[reply]
Wugapodes, I've explained repeatedly in great detail that the plain and simple advantage of the proposal is making it visible so others can see it. If the helpfulness of that over just leaving it invisible like an unwritten law or unspoken rule isn't obvious, then I don't know what to tell ya. Huggums537 (talk) 03:56, 31 July 2021 (UTC)[reply]
A better response here would have been that it doesn't matter if someone chooses male or female because the pronouns get displayed either way, and it should be the same with "gender unspecified" that it doesn't matter if someone chooses it, or the default chooses because the same chosen option gets displayed either way. Huggums537 (talk) 11:55, 7 August 2021 (UTC)[reply]
No changes need to be made to the Mediawiki software if you disregard the idealism that somebody needs to know if the user made the choice or it was defaulted to them. You said the navigation popups would have no way of knowing, but I think the navigation popups would be the very least concerned about needing to know that so it would be no problem to just add "Unspecified gender" to the display and it will show up either way whether a user chooses it, or it gets defaulted to them. Simple. Easy. Huggums537 (talk) 23:54, 30 July 2021 (UTC)[reply]
It keeps going in circles because a tool is misusing grammatical gender to infer personal gender which are different despite their overlap (see Grammatical gender#Grammatical vs. natural gender). The software setting is designed to serve a specific purpose in internationalizing system interface messages, but we use it on EnWiki as a stand-in for the particular gender someone chooses to perform. This leads to repeated conflict when our cultural beliefs about personal gender don't line up with how the rest of the world's languages use noun classes. Unless MediaWiki or the gadget distinguish personal gender from grammatical gender, I would expect these discussions to continue going around in circles. (edit conflict) — Wug·a·po·des23:18, 30 July 2021 (UTC)[reply]
Wugapodes, None of that makes any difference here since the proposal doesn't affect any changes to the international software. It only affects the local English Wikipedia Navigational popup so that the popup matches what the international software already says, and becomes visible to other users. It keeps going in circles because people keep seeing problems with this, and they aren't getting solved correctly. Huggums537 (talk) 07:45, 31 July 2021 (UTC)[reply]
Correct, this is why it should be removed, as its usage is incorrect. If people want to identify (gender or pronouns) somehow, they can write that on their talk page, we should not infer it from information we use for grammatical gender in the software language. —TheDJ (talk • contribs) 16:50, 31 July 2021 (UTC)[reply]
TheDJ, yeah just removing it alltogether if you can't please everyone is a novel solution, but then it deprives everyone of the feature. With this host of brilliant minds we have among us, surely we could come up with something to display that would be acceptable to everyone? I'll take any suggestions at this point. Surely there must be someone here with a better idea than mine for the display popup? Huggums537 (talk) 19:28, 31 July 2021 (UTC)[reply]
I swear. People on this site are way too freaked out about gender issues man. There really should be no big deal about simply letting other people know that a gender hasn't been specified... Huggums537 (talk) 00:06, 31 July 2021 (UTC)[reply]
Some people do specify a gender, choosing the neuter. Ignoring people who try to explain that isn't going to build consensus. If you want to be pedantic, the lack of a "he" or "she" is a way of letting you know that a gender hasn't been specified because it's not specified. It's not ambiguous, and changing it will just annoy a different group of people. Pretending this is simple won't make it so. — Wug·a·po·des00:45, 31 July 2021 (UTC)[reply]
Wugapodes, adding the text "Gender unspecified" to the popup is not ambiguous either, and it isn't changing anything. It's only as simple as making the choice visible to others. The argument that not making the choice visible to others is your invisible sign that they have made the choice would be a great one if people could see invisible signs, but pretending people can see invisible signs won't make it so. Huggums537 (talk) 03:21, 31 July 2021 (UTC)[reply]
For context, there was discussion on what text to display instead of the previously-used icons in phab:T284783, "NavPopups should not use ♂♀ icons to describe how one wants to be addressed". isaacl (talk) 04:40, 31 July 2021 (UTC)[reply]
Isaacl, I think graphical icons representing gender are irrelevant to a discussion about adding text with an unspecified gender. Also, adding "Gender unspecified" was a new idea never even talked about in that discussion. I have struck adding they/them from the proposal, and that is the only relevance I can see there might have been from that discussion, so I see no real context there. Huggums537 (talk) 07:09, 31 July 2021 (UTC)[reply]
In addition, I would just like to note that I wish I would have been able to participate in these other discussions because I darn sure would have mentioned something to these proponents of the idea that gender matters in other languages, and we need to take that into account when considering our software/language/gender etc. decisions. My message to them would be a very simple one; "This is English Wikipedia, not X-language Wikipedia". Perhaps nobody else thought of that answer in previous discussions. I didn't go through them in great detail, but glanced over it enough to get the idea that people were making a fuss about how gender is approached in other languages such as Spanish. 07:25, 31 July 2021 (UTC)
The discussion touched on why nothing is displayed when the "unspecified" option is selected in the user preferences, thus I provided a link for anyone interested in the context. The navigation popups gadget is deployed on other language Wikipedia and thus must be able to accommodate their requirements as well. isaacl (talk) 14:26, 31 July 2021 (UTC)[reply]
Ok, I guess that's fair enough context. However, I seem to be getting conflicting information about the nav popup gadget since other users have implied it's a tool local to the English Wikipedia only, suggesting it's use is different from the Mediawiki software where the preferences are used internationally. Huggums537 (talk) 16:58, 31 July 2021 (UTC)[reply]
According to Wikipedia:Database reports/User preferences#Gender (two years old), 98% of registered users have not specified gender. I assume it's lower for active users but the vast majority of unspecified are not real-life gender-neutral people but just users who haven't seen the option (it didn't always exist) or don't see a good reason to specify their gender. I don't think popups should use space on that, and I think many popups users do realize that if no gender info is shown then it's because the user hasn't given it. Displaying "Gender unspecified" may make users worry about whether they ought to specify their gender when they don't want to. I support just continuing to say nothing when nothing is specified. PrimeHunter (talk) 09:51, 31 July 2021 (UTC)[reply]
PrimeHunter, sure, to some negative nelly it might make users worry, but positive polly tells me there is every bit as good of a chance that the display may make users more aware that they have the option, and they very well may be more grateful that they have been shown they can now choose if they want to. I also think there are more than plenty enough users who don't realize that if they choose "gender unspecified" it will show nothing [there is any meaning at all behind nothing being shown] so enabling visibility is well worth it. Huggums537 (talk) 11:17, 31 July 2021 (UTC)[reply]
@Huggums537: Or maybe they'll feel compelled to leave it blank but now be unable to? If they object to having "they/them" next to their name, the only thing they can do is change to "he/him" or "she/her". Gone is the option to blank it. That's a problem. Convince the devs to add a fourth gender preference and then maybe something can be done here. As is, this is unworkable. ProcrastinatingReader (talk) 12:26, 31 July 2021 (UTC)[reply]
ProcrastinatingReader, I *think* you are describing a problem that already pre-exists and trying to ascribe it to my proposal because users who might object to having they/them next to their name already have no other choice but to change to he/him or she/her if they want something different. Adding "Gender unspecified" to the popup display does not affect that, it only puts on display what currently already exists. Perhaps it's not my proposal that's unworkable, but the underlying preferences my proposal would represent that's unworkable. Huggums537 (talk) 13:27, 31 July 2021 (UTC)[reply]
From my perspective, I only came here to perform the ordinary task of enabling the display of simple user information, but I an not able to go ahead and do so because those who came before me already implemented the unworkable system that doesn't seem to allow that to happen. Huggums537 (talk) 20:02, 31 July 2021 (UTC)[reply]
Comment I think others from previous relevant conversations would benefit from being pinged to this discussion. Especially those that were specific to this exact particular topic such as [1] where a user brought up the exact same issue on Jimbo Wales talk page, and several users responded there including; Cullen328, Indy beetle, Sdkb, TheDJ, Floquenbeam (noping set), RGloucester, valereee, Khajidha, and Xaosflux. The other most pertinent conversation was: MediaWiki_talk:Yourgender#July_2021_follow_up_from_UTJW, where the only real new contributors were Whatamidoing (WMF) and SandyGeorgia. Both of these conversations focus on pretty much the same issue, and I think this is a good place to get it resolved now. If it says, "Gender unspecified" in the popup, then it would simply be an exact match to what we have already decided would be there in the preferences. The only difference is that it would now be visible to others, and I think this more transparent approach is much better. What are we hiding anyway? Huggums537 (talk) 11:09, 31 July 2021 (UTC)[reply]
Maybe I'm missing something, but the options here are 1) display "they/them" in pop-up, encouraging others to refer to the person as they/them; 2) display nothing in the pop-up, encouraging others to refer to the person as they/them, because that is the normal thing to do for most English speakers. It feels like we're being asked whether to print "This page intentionally left blank" or just leave the page blank. – Joe (talk) 11:33, 31 July 2021 (UTC)[reply]
Joe Roe, those are the same old tired options of yesterday. There is a brand new brilliant option out now that is the wave of the future! Add "Gender unspecified" to the popup display. Huggums537 (talk) 11:59, 31 July 2021 (UTC)[reply]
Ah, I did miss something then. In that case, that falls afoul of a very good point made in phab:T284783: someone's gender does not equal how they want to be referred to. That's why the popup now has the pronouns directly, rather than an indication of personal gender. If somebody indicates that they want to be referred to as they, that doesn't mean that their gender is unspecified. Silence really seems to say more than words here. Or another option could be to let people customise what is included in the popup? – Joe (talk) 12:08, 31 July 2021 (UTC)[reply]
You didn't miss anything. I was just tryna be funny. Silence really seems to say more than words here. Adding "Gender unspecified" doesn't "say" anything less than silence currently does. In fact, it says more because it informs other users of information that many were not aware of before. The point about whether somebody wants to be referred to as they or not is moot in this case because that has already been decided for us by default. All we are trying to determine in this discussion is if we want to display that decision or not. It's really that simple. If we stand by our decision, then we should have no problem putting that decision on display. Huggums537 (talk) 13:01, 31 July 2021 (UTC)[reply]
Whether one wants the software to refer to them by gendered pronouns or not, that choice could not, and would not mean one wants the software to publicly refer to them by the phrase 'unspecified gender', 'unspecified gender' is not a pronoun, and 'unspecified gender' is not a public statement they are being asked to make, however vague and ambiguous that would be, they are only being asked if they want a gendered public pronoun in communications. -- Alanscottwalker (talk) 15:30, 31 July 2021 (UTC)[reply]
Alanscottwalker, whatever one chooses the software to "refer" to them as when they are asked to pick a username could not, and would not mean one wants the software to publicly refer to them by the phrase, "User". "User" is also not a public statement they are being asked to make either. Yet, "User" appears twice in the nav popup and many other places across Wikipedia (very prominently on a userpage) because it is simple descriptive data used to convey information. So it is with adding "Gender unspecified". This idea that anyone is somehow being "referred" to something against their will is just ridiculous. Nobody is bitching about being "referred" to as "User" against their will, and rightfully so. It's getting way out hand. Huggums537 (talk) 17:50, 31 July 2021 (UTC)[reply]
They are a User. That's the word for anyone who uses a website. If anything, this proposal is what's ridiculous, and no need to bitch, at all. Alanscottwalker (talk) 19:33, 31 July 2021 (UTC)[reply]
Alanscottwalker, some really strange and far out weirdos might argue with you that they aren't a "User" at all. They might say they don't "use" anyone, and it offends them to be "referred" to as a "User". Just think about that for a moment because it's essentially the same strange argument that says one doesn't want to be "referred" to as "Gender Unspecified". Yet, "Gender unspecified" is just words to describe anyone who has that option enabled just as "User" is just a word to describe anyone who uses a website. So, hopefully you can see what I'm talking about when I say that kind of argument is "ridiculous". Huggums537 (talk) 20:41, 31 July 2021 (UTC)[reply]
Unconvincing -- one seems intentionally or inevitably unlikely to arrive at anything like hope, through a comment that begins with what looks like trolling or baiting, followed by irrelevant other stuff exists, and mangling of referent with respect to pronouns. -- Alanscottwalker (talk) 12:55, 1 August 2021 (UTC)[reply]
Alanscottwalker, I've participated very heavily in this thread, interacting with at least 95% of the participants, and nobody else has complained or suggested anything about trolling or baiting aside from yourself. Unfounded accusations against other editors can be seen as personal attacks. However, since you have not outright accused me of anything, I'm willing to forgive you this trespass if you are willing to understand that making such a suggestion is almost just as bad as making the accusation itself, and avoid doing it again in the future. Thanks. Huggums537 (talk) 14:50, 1 August 2021 (UTC)[reply]
The only thing unfounded would be that PA suggestion, my comment was on contribution, not person, founded in the prior comment. That your other comments may also be alot is no relief. Your arguments have not convinced apparently any of the others either; for my part, I've tried to explain, but I think we are at or passed any useful further discussion, here. -- Alanscottwalker (talk) 15:32, 1 August 2021 (UTC)[reply]
i have said what i wanted to say about this before. I also have no illusions this discussion will be resolved to everyone’s liking. —TheDJ (talk • contribs) 16:12, 31 July 2021 (UTC)[reply]
Hi! I made the Navigation Popups change that switched from the symbols to the current display of pronouns per Phab ticket T284783. I would be similarly happy to implement the result of this current discussion. Anyway, while I understand why you'd want "gender unspecified" in there, from what I can see from this thread and the previous linked discussions, there's no consensus for such a move. Heck, I think a pretty decent way to express an "unspecified" preferences setting is simply by not specifying a gender in the interface; I also agree with the rest of what Wugapodes said above. Tangentially, we could introduce a new preference specifically for pronouns and that would solve some issues, but people would just object that we already have a preference for that. Also, my worst-case estimate for how long that work (PHP, database, etc etc) would take is "forever", based on previous experience. So... not sure what to do, but I'll keep following the discussion. Again, feel free to ping me if anything gets decided, although I see the precise code change necessary has already been identified above by Writ Keeper. Enterprisey (talk!) 08:00, 1 August 2021 (UTC)[reply]
As Wikipedians, we have no gender. As humans (behind our accounts) we're either male or female. You can't change your XY or XX chromsome combinations, no matter what you identify as. GoodDay (talk) 15:15, 1 August 2021 (UTC)[reply]
I would support having a fourth option per User:King of Hearts, such as the following:
She/Her - shows she/her in the nav popups
He/Him - shows he/him in the nav popups
They/Them - shows they/them in the nav popups
Unspecified - empty/blank/nothing appears in the nav popups like it currently does right now
That way editors who "actively" choose to use the pronouns They/Them will now have an option to see 'they/them' in the nav popups for their usernames if they wish; while editors who don't care enough or don't want to have their pronouns listed on Wikipedia can use the 'Unspecified' option. In both cases, the system will use the singular 'they' for the 'They/Them' and 'Unspecified' options, but the nav popups will show they/them for the former option and as blank/empty for the latter option. I also oppose any explicit "Gender unspecified/undisclosed/withheld, etc." wording in the nav popups; nothing should appear in the nav popups pronouns spot for the Unspecified option. Some1 (talk) 16:27, 1 August 2021 (UTC)[reply]
Support this proposal for a fourth option. – There is a difference between preferring to have one's gender identity undisclosed and actively expressing a nonbinary identity through the use of they pronouns. They pronouns should not be imposed on those who prefer to have their gender identity undisclosed on Wikipedia. RGloucester — ☎16:39, 1 August 2021 (UTC)[reply]
The pursuit of an inclusive editing environment demands that we respect editors' gender identities. It does not demand that we let editors rewrite the English language. The singular they has achieved widespread use in English as a singular pronoun that does not connote anything about the person's gender, and as an English-language website, I really struggle to see any issue with us using it that way. {{u|Sdkb}}talk18:41, 2 August 2021 (UTC)[reply]
Sdkb, the great irony of this argument is that it proudly waves the banner of inclusive editing high and mighty for a minority group of gender identities, while simultaneously excluding a majority group of "singular they" English speakers and writers it admits has achieved widespread use as evidenced by the Wikipedia link. This does nothing to further the cause of "inclusive editing" and makes the minority group appear to be hypocritical.Huggums537 (talk) 02:36, 3 August 2021 (UTC)[reply]
Huggums, in the three days this discussion has been open, you've commented 37 times. It's okay to engage the discussion, but there's a limit past which you go into WP:BLUDGEON territory. Please be mindful of that. If you are going to reply, please be clearer about your argument; I do not follow your point. {{u|Sdkb}}talk02:45, 3 August 2021 (UTC)[reply]
Having just read your comment again, I think I might have totally misinterpreted it as being against using "they", when it is actually ok with using "they", and totally responded incorrectly. A thousand apologies. I shall strike it from the record since it was a misunderstanding. Huggums537 (talk) 03:10, 3 August 2021 (UTC)[reply]
Yes, my comment is in favor of singular they. Thanks for the striking; perhaps it's me who needs to be clearer. {{u|Sdkb}}talk14:58, 3 August 2021 (UTC)[reply]
Support the proposal to have allow a fourth option of completely unspecified if the User's wishes to. We should not impose singular they on user's who do not want just like we should not impose generic he. We should allow flexiablity. As someone who rejects the use of my gender pronouns on Wikipedia (as my gender pronouns are not relevant to my editing here), whilst also rejecting "they" it is frustating to be forced into one, allow the flexiablity to have none. Regards Spy-cicle💥 Talk?20:59, 2 August 2021 (UTC)[reply]
Singular They -- already abled? Noticed in examining [2], that the User on the right, in the Popup display is able to convey 'he' and 'they'. The pop-up, shows, quote: "Personal pronoun: he/his, singular they is OK too." So there might already be flexibility for rendering "they" or other pronoun choices, too. Enterprisey, Xaosflux or others familiar with pop-up, is that explained somewhere? Alanscottwalker (talk) 13:33, 3 August 2021 (UTC)[reply]
@Alanscottwalker: nav pops does a few things; for your example of User:Reyk, they have set their interface to male - and navpopus uses this to populate the value in the top left corner of the popup. Navpops also provides some preview-text of a page, in this case the user has put the prose Personal pronoun: he/... on to his userpage, and navpopus has fetched it and delivered it in the preview section at the bottom of the box. — xaosfluxTalk14:00, 3 August 2021 (UTC)[reply]
Ah, Thanks! So there is a way to get 'they' or something else in the popup. Is there a way to know what the popup will fetch and make sure it fetched that? -- Alanscottwalker (talk) 14:14, 3 August 2021 (UTC)[reply]
@Alanscottwalker: I wouldn't count on it - NavPopups is primarily designed as an aid to fetch a popup for articles, it certainly is possible that it could fetch and include things based on keywords in the wikitext of userpages. However, it would bloat the script and require those wanting to use it to wave magic chickens over their userpage. The script is here: MediaWiki:Gadget-popups.js. It generally will include the first few lines of text on any page. — xaosfluxTalk14:39, 3 August 2021 (UTC)[reply]
Xaosflux and Alanscottwalker, I have also noticed it will capture the first image [and Wikilink] on the userpage as well. [See my popup for example.] So, if someone in the LGBTQ community wanted to fly an image of a rainbow flag, they could do that if they wanted to trouble themselves with setting up their userpage that way. Also, thanks Alan for sharing the link and bringing this up. Huggums537 (talk) 08:40, 4 August 2021 (UTC)[reply]
That gets me thinking... maybe you could write {{PrefersPronoun|(insert whatever pronouns)}} on your userpage and popups will replace its current display with that. Thoughts? Enterprisey (talk!) 08:07, 4 August 2021 (UTC)[reply]
@Enterprisey: seems like that would be quite an edge case, keep in mind that statistically most editors don't use navpopups, and even less editors would discover and use magic keywords on their userpage to feed in to it (also would probably need some sort of input validation to prevent garbage values from messing up navpop). — xaosfluxTalk09:56, 4 August 2021 (UTC)[reply]
I would suggest that an addition be made to Wikipedia:Tools/Navigation popups/FAQ (not that that is terribly easy to find). I would need help with technical wording/links, but something like:
"Pronoun preference display:
A User has a choice in ________ to choose gendered pronouns (she/he, her/his), otherwise the system defaults to singular they. When the User chooses gendered pronouns, their choice is displayed in popups. Another way to display various pronoun choices in popups, including neutral pronouns, is to configure your User Page so that the first untemplated prose on the page states something like, 'Personal pronouns: (your pronoun preferences, here).' "
Edge case it may be, but that's a weak argument given that it would be incredibly useful for people who actually need it. I can personally assure you that the Popups code is enough of a trainwreck that a few more lines of code won't "bloat" anything. Anyway, I just found Category:Pronoun user templates, so going through those and having Popups read them (in addition to allowing custom pronouns - but because that appears at the beginning of the popups message, people might use them as generic statuses!) Enterprisey (talk!) 18:14, 4 August 2021 (UTC)[reply]
Ahh, it's possible I misunderstood. I thought you meant "edge case" as in "too much of an edge case to be worth supporting", but if you meant "edge case" as in "we should do this in preferences and/or make it more visible to the user because 'a niche template to influence a niche gadget' is very undiscoverable and thus useless to most people", yes, I completely agree. Enterprisey (talk!) 22:00, 4 August 2021 (UTC)[reply]
Enterprisey, if I understand things correctly, a user can already use the popups as a generic status by simply adding the status before the first line of text on the userpage, right? Huggums537 (talk) 06:44, 5 August 2021 (UTC)[reply]
Like others have written the existing messages are written so that if an user does not define a gender it is assumed that is because of privacy reasons, not gender ones. If this proposal gets through, it does need to create/edit all messages with the gender magic word and reword them from being worded for privancy conserned editors to editors that do not define themselves as either male or female. If that is not done, then we end up with an mess where gender neutral users get fustrated with inappropriate messages. This is not just a matter of pronouns, some messages are worded in a specific way based on which pronoun should be used.--Snævar (talk) 23:43, 3 August 2021 (UTC)[reply]
A few comments scattered throughout this discussion have made claims about what the purpose of the gender preference setting is. I've been looking at this off and on for a couple of months now, and I've come to some conclusions: The first is: This setting doesn't exist because of English. The second is: It's not really about your identity.
Languages being what they are, every language has its own idea of how to cope with write about gender. Some few, including English, pay little attention to it compared to others. In some, linguistic nods to the gender of the speaker and/or the subject is pervasive. Russian is a typical example of this. You'll see in some Special:Log pages a statement like "WhatamIdoing moved Tyop to Typo". In Russian, you have to assign a grammatical gender to the verb for this sentence. You have to write "WhatamIdoing she-moved Tyop to Typo" or "That guy he-moved Tyop to Typo". There is not "neutral-moved" option in Russian. You either have to know, or you have to use the unspecified-gender default for that language.
In the event that you are writing about someone whose gender is unknown to you, different languages take different approaches. In English, we often default to singular they if personal pronouns are necessary, but mostly pronouns aren't necessary, and gender doesn't otherwise affect English grammar. In Russian, I understand that they (currently/still) default to masculine for unknown subjects. In German, even if you know the person's gender, you use the grammatical gender that belongs to the noun, rather than the person: "Die Person moved her page; der Editor edited his page; das Neue needs help with its question" – using all three personal pronouns to refer to the same person.
Main message: The point of this setting is to enable automated messages to make sensible grammatical choices in every language. For this setting to be functional, it needs to correspond to grammar needs. It is possible to construct an grammatically correct sentence in English with any of the three existing options. Therefore English doesn't need a fourth grammar option. (Swedish might; their four pronouns are roughly he/she/it/other it.) If you want an option for announcing your personal identity, then it really shouldn't get mixed up in this translation-focused setting. Whatamidoing (WMF) (talk) 20:06, 6 August 2021 (UTC)[reply]
Hear, hear! To my understanding this is 100% accurate. Further, the impression I got from people who were deeply into working on these translations is that the existing three options are sufficient to the purpose for basically all languages.Note that, even if you're speaking English, the same value of the preference needs to be used for people who have their interface language set to Klingon or Sindarin or Simlish or whatever. While some languages have distinctions between animate/inanimate (e.g. "it"), formal/informal, adult/child, and the like, these can probably be ignored in the interest of not having a confusingly complex preference that wouldn't make much sense in many languages. "It", for example, seems likely to only really be relevant for people who don't want to anthropomorphize bots.Personally, I see the recent changes to the preference texts described at MediaWiki talk:Yourgender as a step backwards, as they seem to have confused people into thinking there's a meaningful distinction between "unspecified" and "specified the neutral default". All the preference is intended for is literally "How should MediaWiki describe you grammatically?", and it doesn't matter whether MediaWiki uses "they" because you haven't specified or because you specifically chose "they" or because you chose "they" because you didn't want to pick "he" or "she". That's also how Popups should represent it, in whatever specific manner the developers of that tool want to realize that. Anomie⚔03:25, 7 August 2021 (UTC)[reply]
Not really, you can't hide your actions from others. The only solution is to not make any actions in the first place. Note that even creating an account is an action, which will generate a log entry along the lines of "User account X was created", so you'd have to start by not creating an account. Anomie⚔12:49, 7 August 2021 (UTC)[reply]
Before this thread closes, I'd like an opportunity to point out that the proposal was not aimed at changing any grammatical structures of the gender settings, and the whole point of it all was only to merely make all of the currently existing settings visible in navigational the popup, which currently excludes the default singular they pronouns setting, but includes the male/female pronouns settings. However, there is no good reason for the excluding the visibility of the setting if the grammatical functionalities of the settings are the same regardless of whether the setting is visible in the navigational popup or not. Huggums537 (talk) 17:01, 28 August 2021 (UTC)[reply]
With all due respect to the freedom of choice and everything related, I oppose all of these suggestions, including the fact that we're even discussing it, for the simple reason that we are dealing with anonymity. We are not face to face discussing things - we don't even know who we're collaborating with, for Pete's sake. This isn't a university campus - it's a virtual community of anonymous volunteers, all of whom are supposed to be here to help build the encyclopedia. Why are we focusing on gender and not the work and reason we're here? If the article isn't gender-related, move along. We don't have time to go check pronoun preferences of anonymous editors when we're in the throws of an important discussion that is directly related to building this encyclopedia. We should not have to focus on the volunteers. I do believe that being respectful toward one another is expected, regardless of race, color, creed or gender - none of which we know because of anonymity, and I'm happy not knowing. Everyone's time here is valuable and deserves equal consideration. Most of all, I dread the thought of an editor forgetting the proper pronoun of an anonymous editor they oppose in a TP discussion, and then find themselves at the dramah board because they used the wrong pronoun. I've already seen that happen. There are too many variables, and we have far too many wikilawyers on WP. I'll share the advice I got from an admin when I was feeling offended: "grow thicker skin". Atsme💬📧13:42, 7 August 2021 (UTC)[reply]
With all due respect Atsme, those were people purposefully and intentionally misgendering someone over an extended period of time, which I'm pretty sure you already knew. There's no need to be an alarmist. Mistakes are occasionally made, and I've never seen that escalate to what you're "afraid of". If it ever did, it would be dismissed almost immediately. Symmachus Auxiliarus (talk) 00:54, 8 August 2021 (UTC)[reply]
Atsme, you've also oversimplified the entire conversation into being merely about focusing on anonymous volunteers and their gender in order to justify a position opposing the entire discussion on the basis it's not related to building Wikipedia. However, the very fact that so many have participated here with their thoughts and opinions regarding privacy, and rights to choose as well as gender is ample evidence there are issues in this discussion that are of importance to Wikipedians, and obviously worth considering in a community discussion, otherwise we wouldn't participate at all. I see no valid reasons for any support of you implying a spirit of building Wikipedia while simultaneously dismissing a whole community for their participation in the discussion - keeping in mind that community discussion itself is an important part of "building an encyclopedia". Without discussion there is no consensus, without that, there's no Wikipedia to build. Huggums537 (talk) 07:31, 8 August 2021 (UTC)[reply]
Symmachus Auxiliarus, I was not referring to that case. Huggums537, I understand and sympathize with your concerns, but the bottomline hasn't changed. We are here to focus on editing, not editors. We did not volunteer our time for any other purpose than to help build the encyclopedia; i.e., create content, copyedit articles, stop vandalism, help newbies edit articles, etc. We are not a social platform to advocate for social issues, and there is also WP:RGW. Those are things we dedicate to the time we spend in real life, not here on WP as editors who have graciously volunteered our valuable time to help build the encyclopedia. We are either going to choose anonymity (all the way around which would include gender), or choose to make our real life identity known. Which is it? Beyond that, there should be no obligation for us to be anything beyond polite (collegial) and helpful. Anything short of that, such as launching hurtful PAs and creating unambiguous disruption at an article or other WP venue, would be actionable, but that is why we have administrators. It is also not an editor's responsibility to act as "thought police". Perhaps this essay will help put things in perspective, as it did for me (rather shockingly) when I first read it; it applies to all of us. I have adopted a sticks and stones approach to words because it is a more realistic approach to living in the real world. Atsme💬📧16:11, 8 August 2021 (UTC)[reply]
Atsme, it seems to me the only one here focusing on other editors, advocating for (or against) social issues, or righting the great wrong of not building an encyclopedia is actually yourself. I personally strongly disagree with Wikipedia:Wikipedia does not need you (even though I respect the author), for the very simple fact that there would be no Wikipedia without "you". The only real world purpose that type of essay serves is to scorn [ostracize] others. Even you admit it was "rather shockingly" put into your perspective, and I think someone would almost have to be in a state of shock allowing for [adopting] such a perspective. However, some other essays (with far less shocking perspectives) worth considering are: Wikipedia:Editors matter and Wikipedia:Wikipedia is a community. Huggums537 (talk) 19:55, 8 August 2021 (UTC)[reply]
Survey (alternatives)
What do editors contributing here think about some alternative wording other than what has been suggested in this proposal that we could use in the navigational popup display to indicate to others that the neutral option has been selected? A few examples that come to my mind are:
Support option 3 or 4 as these do not use gender language, and refer only to the pronoun usage just as the he/him and she/her model does so this is more in line with past discussions about how this whole thing is about language, and how pronouns are used rather than gender. Huggums537 (talk) 01:27, 1 August 2021 (UTC)[reply]
Option 5, none of the above. This is not about specifying gender, but specifying pronouns. There is no way in natural English to easily avoid using pronouns for somebody. The only viable options are (a) leave it as he/him, she/her, they/them; (b) introduce more options to choose from (e.g. sie/hir); (c) have free text boxes where people write in what they want for each part of speech; or (d) a combination of a+c or b+c. In all cases there would need to be either a default (which would be they/them) or a requirement for people to explicitly choose before being allowed to edit (this is incompatible with allowing unregistered users to edit). While I would happily support a, b or d (and maybe c) this is not what is being proposed here. Thryduulf (talk) 11:15, 1 August 2021 (UTC)[reply]
Thinking more about this, unless there are changes to the current three options, then all of 1, 2 and 4 imply that only he or she are valid options and so should be opposed as actively harmful and 3 is essentially the status quo - default to gender neutral unless someone has actively chosen something else. Thryduulf (talk) 13:41, 1 August 2021 (UTC)[reply]
Support options 3 or 4 per Huggums537. Ideally we would have a free text option where people can choose whatever pronouns they want in order to accommodate the less common options without us needing to enumerate them all and maybe miss some valid options. Unfortunately, that would need some policing as I'm sure that the "attack helicopter" weenies would try to have their idea of "fun" with it. That doesn't seem to be an option here anyway as all we know is that the user has chosen one of three options. Without further information about what the user wants, 3 or 4 is the best we can do. --DanielRigal (talk) 13:15, 1 August 2021 (UTC)[reply]
None of the above - I don’t want anything to appear about my gender or my pronouns when you hover over my name. I don’t want it to say “this user did not choose” or “unspecified”, or anything. I like the fact that if you do not click a button, nothing appears. Blueboar (talk) 14:29, 1 August 2021 (UTC)[reply]
I would assume (perhaps incorrectly) that a banjo would want “it/its” displayed as its preferred pronoun when someone hovers over its username. Or at least have that as an option. Blueboar (talk) 17:35, 1 August 2021 (UTC)[reply]
This comment, especially considering the context of its author, appears to be mocking individuals who identify as non-binary. That's absolutely unacceptable. {{u|Sdkb}}talk18:31, 2 August 2021 (UTC)[reply]
Completely meaningless whether GoodDay has a "history of mocking individuals" or not. At worst it's an uncalled for comment mocking other users, and at best it adds absolutely nothing to the conversation. Aza24 (talk) 20:00, 7 August 2021 (UTC)[reply]
Indeed, I'm not a fan of Wikipedia bending political correctness to the breaking point, on this topic. Thus my overall reluctance to participate in such discussion. Now, please folks, no more pinging me :) GoodDay (talk) 13:51, 8 August 2021 (UTC)[reply]
Support option 4 the usage of completely unspecified if the User's wishes to. We should not impose singular they on user's who do not want just like we should not impose generic he. We should allow flexiablity. As someone who rejects the use of my gender pronouns on Wikipedia (as my gender pronouns are not relevant to my editing here), whilst also rejecting "they" it is frustating to be forced into one. Just simply allow the flexiablity to have none. Regards Spy-cicle💥 Talk?20:59, 2 August 2021 (UTC)[reply]
To clarify Alanscottwalker as the first discussion question was not clear. I support any option which allows users to have an unspecified gender/gender pronoun (or the option to opt out entirely) whilst allowing those who choose an unspecified gender/gender pronoun to have the option to not have "they/them". Hope that helps. Regards Spy-cicle💥 Talk?15:55, 6 August 2021 (UTC)[reply]
@Blueboar: no, even if the schema for this database value were expanded to allow "nul" as a value - something would still be the 'default' (even it is were "nul"). The current default is unspecified. — xaosfluxTalk15:01, 3 August 2021 (UTC)[reply]
Option 5, fix MediaWiki settings I've used Nav Pops for years. At some point I noticed that there was a male or female symbol in the popup (they were recently changed to he/she). I also noticed that some users (like myself) didn't have a symbol, because they had not chosen their gender (pronouns). There is no need to clutter the tiny popup with any additional "gender unspecified" text, because most users who use the gadget will eventually understand how it works. If you don't see he/she, you can use "they", or check the editor's user page to see if they have more information about their preferences there. However, I do think it would be best if the MediaWiki settings had a fourth option, so that there would be a real option for users who want to actually choose something else than male/female pronouns. Then the Nav Pops gadget could show "they" for those who had really chosen it. -kyykaarme (talk) 19:41, 3 August 2021 (UTC)[reply]
Support 3 and 4: users who have not specified their gender should default to "unspecified" and have nothing render in the popup. Users whose pronouns are they/them should be able to select that setting so that "they/them" appears in the popup. "Not disclosed" and "withheld" both fall under "unspecified" unless we want this to be used for soapboxing. Ideally we would have a fifth free text setting which would tell popups to render whatever the user specifies but that the software would treat the same as gender neutral (for templates and whatnot), but without admins being able to override the setting this would be an open door to vandalism. Ivanvector's squirrel (trees/nuts) 15:06, 5 August 2021 (UTC)[reply]
50..., for what its worth - absolutely none of any part of this discussion will have any impact of editors without accounts. — xaosfluxTalk17:24, 7 August 2021 (UTC)[reply]
Oppose all per my comment above. Despite being labeled a survey, this section does not have the possibility of reaching an actionable consensus, since any survey that leaves out the status quo option is inherently leading. {{u|Sdkb}}talk17:56, 7 August 2021 (UTC)[reply]
Sdkb and Stifle, I did not think to add the status quo as one of the selections, and wasn't intentionally leading anyone. Would either of you consider choosing an option if the status quo was also a choice? Also, do you think everyone would be okay if I retroactively add the status quo to the selection in order to avoid leading anyone? Huggums537 (talk) 22:41, 9 August 2021 (UTC)[reply]
Ok, that's fine since it doesn't need to be there anyway because I have observed that plenty of other people have been able to choose the status quo option without the selection being made available to them and without them making any insinuations about anyone leading them either. So, it should seem fairly obvious in anyone what good faith that the option is not truly needed anyway. Huggums537 (talk) 23:10, 9 August 2021 (UTC)[reply]
There has been some conversation above between Xaosflux, Alanscottwalker and Enterprisey about enabling a user generated script, or maybe simply placing a notice letting users know they can generate their own popup if they choose to alter their userpage. I also noticed users such as Valereee were in favor of such an idea while Kyykaarme and TheDJ suggested people check userpages indicating this might be a viable option for such users. I'd like to get thoughts from the community on this option as well. Whatever the outcome of this entire thread, I've already recently enabled this option on my own userpage as an example that can be seen if you hover over my username and have the navigation gadget enabled in your preferences. Huggums537 (talk) 11:45, 7 August 2021 (UTC)[reply]
@Huggums537: I currently use the {{User They them pronouns}} infobox in my profile to let others know my preference. Right now, that's the best option, seconded only to have one's pronouns in their signature (which I'd rather not do, for aesthetic reasons). I think that having a way to transpose that information to the pop-up gadget would just make things easier for all. I personally use the pop-up to check other user's pronouns when talking to someone I haven't talked to before. Isabelle🔔13:40, 8 August 2021 (UTC)[reply]
Isabelle Belato, yes, I'm also using the same userbox for my selection as well. However, the selection doesn't appear in the nav popup either. I had not thought of putting it in the signature. That's a novel idea, but I rather like approach I'm currently using to add the line of text to my userpage and allow nav popups to fetch it for me because it solves my problem, and it looks like nothing I've suggested in my proposal is going to pass, but hopefully the community will put a notation somewhere to let others know they can do the same thing I've done if they choose to. Huggums537 (talk) 18:10, 8 August 2021 (UTC)[reply]
Dispense with "In popular culture" because there is no such thing.
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
Should Wikipedia continue to have sections titled "In popular culture? 20:40, 12 August 2021 (UTC)
Executive summary: It's not 1887 anymore. "Popular culture" is just "culture". This is why we don't have commensurate "High culture" sections. It all runs together now, and "In popular culture" sections should be called something else -- "In other media" or "In general culture" or "Other uses and references" or whatever. I'm going to start doing that. You should too.
Extended exposition: The distinction between "high culture" and "popular culture" is so permeable to be no longer useful. In older times some people went only to the symphony and read Livy in the original Latin. And disdained or know nothing about folk songs and banjo music and boxing and Sherlock Holmes etc.
I mean I could have maybe sorted all that into two sections, "In popular culture" and "In high culture" (or maybe "In obscure culture"), but that would be nonsensical. Instead I renamed the section. We don't have any guidance on that so I made up "Use and references in other works". Could have been something else.
(Also, FWIW, the term "In popular culture" makes some editors claw the draperies and call the maid for smelling salts. There's no point in triggering our bourgeois colleagues, so something less suggestive of the tenements is in order.)
"In popular culture" might belong in Snobopedia, but not here. I fully realize that making a rule changing stuff like is near impossible in this hidebound environment, so I'm not even suggesting a !vote, but I'll tell you what. I'm done with "In popular culture" and I'm not going to write that title for sections, and I aim to change them when I see them. That's my proposal: if you buy the argument, vote with your feet and do it too. If you don't, don't. Herostratus (talk) 22:08, 11 August 2021 (UTC)[reply]
Interesting thoughts, Herostratus. It bothers me when I see something like this and think, "well, yeah, why didn't I notice that myself (sooner, consciously)"? I believe I'll consider renaming such sections to something like "Notable cultural references" where it fits, when I see such things. Certainly something to think about. — JohnFromPinckney (talk / edits)22:38, 11 August 2021 (UTC)[reply]
There are probably essays and maybe even guidelines about it. I label those sections "Influences", it's a form of notability. Something is "influential" when it has "influenced" significant works or people, making it notable, not a list of random trivia. -- GreenC00:01, 12 August 2021 (UTC)[reply]
I don't think there's a one-size solution here, but I do agree that most sections that are labeled "in popular culture" can likely renamed to something more broad. What that is depends; if there's only a handful, such a list might fall under a Legacy or Influence section and not be sectioned off on its own, while longer sections may need something of its own section like "References in other works" as suggested. But I would say that if we are making a distinction between pop culture (the masses) and high culture (the elite), then there are likely cases of older works (thinking Shakespeare-type classics) where we are more likely documenting what is a high piece of culture being reused by the popular culture. I don't know of any immediate examples but I would not be surprised nor balk at an article called "Romeo & Juliet in popular culture". But again, I can't propose a hard-set rule in this area when this would be appropriate, so I would be hesitant to simply say "scrub all 'popular culture' use". --Masem (t) 01:50, 12 August 2021 (UTC)[reply]
I disagree, both in terms of the naming issue, and with the utility of content falling under such headings. The widespread use of the header indicates the intuitive understanding that people (including readers) have of the term, and is no more snobby than referring to popular music. Speaking of the readers, in terms of inclusion of such content, let's Give the People What They Want (to the extent that it can be cited to sources). BD2412T01:51, 12 August 2021 (UTC)[reply]
But there is a point that WP is not TV Tropes, and such sections often are kudzu for weak or unsourced assertions of pop culture, which we can read as being what people want. We are here to provide educational material for the readers, and to that end we focus often on content that the average reader doesn't want but what a slim minority will want. This is perhaps due to many users expecting WP to provide certain types of content, thinking it a one-stop shop, that are simply outside our bounds established in policy. Hence we really need to be careful if we try to craft policy or guideline around readers' preferences. --Masem (t) 02:17, 12 August 2021 (UTC)[reply]
Considering that our most viewed pages for the past week include The Suicide Squad and Jungle Cruise, and that our most viewed topics routinely include pop culture and entertainment topics, I suspect that it more than "a slim minority" who have an interest in this sort of content. BD2412T02:46, 12 August 2021 (UTC)[reply]
I mean that if you take the type of content we want editors to focus on based on what we are not per WP:NOT, that type of content tends to cater to a slim segment of the readers but that's because that's the key academic content of an encyclopedia. I'm sure those movies had huge page views but I also would suspect that the bulk of readers were only reading them for the plot summary, cast list, and reception, and little about development/filming/etc. (which is the more academic core of those articles). That type of popular content is basically one step removed from what IMDB or TV Tropes offers, and while can offer it, its there to augment the more academic facets which typically do not interest the majority of readers but are still good reference for some. --Masem (t) 02:54, 12 August 2021 (UTC)[reply]
I think that we are ultimately just talking about the title of a subsection, and it really doesn't matter to me which title is used, but I will say the cookie cutter "in popular culture" gets old after awhile, and the titles that have been suggested as alternative options are refreshing, but in the end, I really don't mind which title is used as long as we continue to add the pertinent information. Huggums537 (talk) 02:07, 12 August 2021 (UTC)[reply]
I also want to add that the logic of the comments suggesting disposal of "In popular culture" for no sound reason other than because it invites trivia, and list cruft etc. totally escapes me. This is the logical equivalent of saying, x could be used for something silly, stupid, bad, or evil; therefore we should dispose of x. Proponents of this type of logic usually like to insert some kind of exaggerated example of where this has occurred with x. The two problems facing this type of logic is that it completely ignores all of the places where it has not occurred with x, and x has worked out just fine. The second problem is that it overlooks the obvious fact that x can always be used for something silly, stupid, bad, or evil, so that in and of itself really isn't justification enough, otherwise we would be able to simply dispose of anything and everything we just don't like, and can replace with x. Huggums537 (talk) 20:24, 12 August 2021 (UTC)[reply]
I also want to add an example: Let's say x is Wikipedia lists. Someone could argue that lists invite cruft and should be disposed of. They might provide an example of an exceptionally bad list to prove their point, while ignoring the hundreds of good ones. They might argue some lists could be used to damage Wikipedia, and we should eliminate lists all together, while glossing over the fact that we have a process in place to eliminate individual lists that might be damaging. Is the possibility of a thing being used for the wrong purpose sufficient grounds alone for the disposal of that thing as a solitary rationale? I hope not, and I hope this is a good illustration... Huggums537 (talk) 20:50, 12 August 2021 (UTC)[reply]
Another fine example of this wrong thinking is that there are way more than enough documented cases of road rage where a vehicle has been intentionally used to harm people or property that proponents of this flawed logic might argue we should dispose of vehicles all together or put some kind of restrictions on them to prevent people from using them in such destructive ways. However, this overlooks the overwhelming majority of evidence that most vehicles are not used in destructive ways, and it also ignores that the minority of them that are used this way are currently being handled by other processes we already have in place, making a blanket ban and more restrictions not only redundant, but an un-necessary burden on the moral majority. Huggums537 (talk) 11:31, 20 August 2021 (UTC)[reply]
WP:IPC does encourage editors to use a section name other than "In popular culture", though that is just an essay. Personally I don't especially care what the section is named; the content is of greater concern to me. I'm not sure what this proposal's goal is: to make calling a section "In popular culture" a warnable offense? To suggest an update to the MoS? If everyone agrees that IPC is poor section-naming, what's the practical result? As far as concerns about the content, I would say that WP:IPCV and the associated RfC were a godsend as they provided bright-line guidance that IPC items require independent sourcing as a means of establishing the items' significance for inclusion purposes. DonIago (talk) 02:22, 12 August 2021 (UTC)[reply]
Usually the term / section name just serves as an entre / coatrack for fandom or promotional items that don't belong in the article. I don't want yet another rule but it would be good to put a Scarlet Letter painted on that phase as being such, or discouraging it's use.North8000 (talk) 02:28, 12 August 2021 (UTC)[reply]
Drawing from the above comments by JohnFromPinckney and Blake Gripling, "Cultural influence" may be a better header. It implies the subject is the topic itself, rather than the subject being the "popular culture" influenced by it. This may help reduce the propensity for off-topic information. CMD (talk) 02:41, 12 August 2021 (UTC)[reply]
Subcultures still exist, and they have various levels of prestige. I think it's funny that all the examples of how culture has blended together are stuff my middle-aged dad would talk about at a party but don't include any band I listen to or any author I've read (and I read Latin). This of course isn't a coincidence because "popular culture" is stuff middle aged dads talk about at parties, not the whole extent of cultural experience. Perhaps the popular culture section includes people you know because that's the point? You know them because they're in popular culture---because they're popular? If you didn't recognize someone on those lists, now that would be remarkable. Idk, this whole thing reads like you're projecting your cultural experience as if it's universal when it remarkably isn't. — Wug·a·po·des03:11, 12 August 2021 (UTC)[reply]
I'm inclined to agree with BD2412 - you're right that our current use doesn't match the old definition of "popular culture". However it does match the way the term is used by the majority of people (and sources) now, and thus is a reasonable term. Nosebagbear (talk) 06:37, 12 August 2021 (UTC)[reply]
Drawing a distinction between "high culture" and "modern popular culture" or whatever you want to call them isn't really that important. The point is to stop endless lists of off-topic trivia. ReykYO!08:01, 12 August 2021 (UTC)[reply]
Reminds me of the now-deleted article about Miami Vice in popular culture. I mean sure, the series is indeed iconic for perpetuating popular 80s stereotypes, but imo such cultural impact is best described in a "Legacy" section. WP:MILPOP handled it better like in the Thompson submachine gun where its significance in pop culture is well-integrated into the history section rather than as a listcruft of all known instances of where the Tommy gun was used. A separate popular culture article wouldn't hurt if it is well-written in pose and there is exceptional proof that the subject gained notoriety e.g. Adolf Hitler. Blake Gripling (talk) 11:23, 12 August 2021 (UTC)[reply]
"In popular culture" is now itself a phrase ingrained in (popular) culture, perhaps our most infamous section title. As such, I don't think much misunderstanding or literalism about the connotations of "popular culture" is in the minds of our readers. Such sections are almost always bad, and should either be removed as fancruft or adapted into a proper "Legacy" or "Impact" section (such as Black Mirror#Cultural impact) that doesn't aim just to enumerate random references but to convey the scope and significance of the work on future art or the public consciousness. — Bilorv (talk) 11:31, 12 August 2021 (UTC)[reply]
The wording of the section heading can make quite a difference. Headings such as "In popular culture" or even worse "References in popular culture" attract editors who seem to think it's important to add a bare mention of the subject in episode 12 season 23 of their favourite show. Much less likely to attract that sort of thing is a section headed "Cultural impact" or "Notable cultural developments". I'd like to see us much more strongly discourage the old "In popular culture" wording. MichaelMaggs (talk) 12:22, 12 August 2021 (UTC)[reply]
What Jpgordon said. To the best of my knowledge, its origin on Wikipedia was Gunpowder Plot in popular culture, and (as the person who originally suggested it), I can confirm that the intent in that case was quite deliberately to restrict the edit-warring over every TV show that mentions Guy Fawkes to a single section where people could fight it out without disrupting the main body of the article. It sounds patronizing, but it does serve a valid purpose; IPC sections and subpages means people don't try in good faith to rewrite entire articles just because a movie on the topic comes out or it gets mentioned on Star Trek.
I have no attachment to "in popular culture" as a name, if anyone can think of something better. It's literally the first name that occurred to me and was subsequently picked up on and copied by other articles; it has no particular significance. ‑ Iridescent14:45, 12 August 2021 (UTC)[reply]
Wait.. you are the one who started IPC? This is notable Wikipedia history, given how influential it has been (for better or worse!). If you don't mind, this should be in a "history" section at WP:IPC -- GreenC15:48, 12 August 2021 (UTC)[reply]
I thought I'd coined the phrase, but on doing some digging there were already a few IPC pages existing prior to that—the oldest I can find on a very quick dig is Librarians in popular culture (a candidate for "Wikipedia's worst article"). I do believe the Gunpowder Plot one was the first one set up explicitly to keep the IPC froth off the main topic, though. (I am responsible for "civility police", "indefinite not infinite" and "ANI flu"; my footnote in Wikipedia's history is secure.) ‑ Iridescent16:07, 12 August 2021 (UTC)[reply]
The oldest deleted page titled "...in popular culture" - where I can't find evidence that it was moved there later, like, say, Evocation in popular culture, created at Conjuration and moved there in 2010 - is Teaching in popular culture, created 17:50, 29 April 2004. The oldest existing article with such a title is Adolf Hitler in popular culture, originally created at Hitler in popular culture at 15:20, 2 October 2004. (There may be older pages that started with IPC titles and were later moved to non-IPC titles, but that's laborious to search for.) The phrase was likely used in section headers even earlier. —Cryptic18:45, 12 August 2021 (UTC)[reply]
IIRC these started showing up as sections in articles in early 2004, but I wouldn’t be surprised if someone dug up a diff from late 2003, see for example 123; even Exploding whale had one 4. Eventually those sections grew so much they were spun off into separate articles to avoid overwhelming the page, indeed some comprised the majority of an articles content at the time of spin-off e.g. 5. The whole process took place more or less organically; then as now people often just copied what they saw others doing. In hindsight, in popular culture is probably not best, but a lot of the time the thought process was just to be bold and assume that it would be improved upon later.In fact people have been trying alternatives for some time now 6, see also, Cultural influence of Plato's Republic, Venus in culture, Cultural references to Hamlet , Women warriors in literature and culture, Synesthesia in fiction etc. Doubtless someone with a bit more free time available will be able to find other formulations in current use. Regards, 81.177.3.8 (talk) 19:20, 13 August 2021 (UTC)[reply]
What I was thinking was using "Cultural influence" or "Cultural allusions" or maybe "Cultural influence and allusions". in WP:VG, we don't have "in pop culture" sections but just "Legacy" sections instead.Blue Pumpkin Pie (talk) 16:02, 12 August 2021 (UTC)[reply]
Oh but now here's a thought regarding the content rather than the name of these sections. There's plusses and minuses, but to my mind, the purpose of these sections is to indicate how well known the entity is. So, let's take "Do not go gentle into that good night"... is this an obscure poem like say "The Legend of Novgorode" or thousands of others, or is it more well known? That's a very important point for the reader to know! But we can't just assert it. If we have a source saying "This poem is super well known!" fine, but first of all we usually don't, and second even if we do it's just one guy asserting it.
But... remember Writing 101: show, not tell. Well, Do not go gentle into that good night#Use and references in other works shows very well that the poem's reasonably famous. Important info. Even minor examples can help with that. If somebody says a line in passing on some HBO show, that that's another demonstration that it's floating around in the culturespace, unlike say Trilce.
But then: as we all know, these sections can grow out of control, too. So here's what I've tried, and I think it maybe works OK: Make the "References in other works" short but dump the excess examples down into either the Notes or the References sections, where they are they are still there but don't bother anybody. At Anyone for tennis? I gave some examples (basically the bluelinked ones), then added "And so forth" with the ref for that containing all the extra non-bluelinked examples. You can also use a Note instead. Reasonable approach? Herostratus (talk) 16:16, 12 August 2021 (UTC)[reply]
I don’t think that works particularly well— feels like hiding cruft that shouldn’t really be in the article. But I have no problem with ‘in popular culture’ sections at all, when put together properly. This whole discussion seems, to me, a waste of energy that would be more productively expended in other endeavors, such as writing content. Eddie891TalkWork16:26, 12 August 2021 (UTC)[reply]
Yeah how about not telling other people how to spend their volunteer hobby time maybe. I've got 500 articles created and many thousands of article edits, how about you. Herostratus (talk) 16:43, 12 August 2021 (UTC)[reply]
since you asked, in the past five years since I began editing, I’ve created over 300 articles and made over 40,000 edits and written several featured content (incl one fa with an in popular culture section) and had almost 100 dyks. In that time, you’ve created 156 articles and made about 11,000 edits. Eddie891TalkWork18:25, 12 August 2021 (UTC)[reply]
I'm going to nicely ask to stay on topic and remain civil. And if you feel its a waste of time, you can contribute to the articles you want. it's ok to not find a topic productive. Others don't feel the same way.Blue Pumpkin Pie (talk) 18:29, 12 August 2021 (UTC)[reply]
? I don’t see the problem with my conduct. I said what I thought, herostratus replied to say ‘yeah, no’— which I understand— and I answered his explicitly posed question. Eddie891TalkWork18:55, 12 August 2021 (UTC)[reply]
Since it has come up, I have over 1,800,000 edits, with over a million being article edits. I have created over 6,000 articles. To reiterate my earlier position, I think "in popular culture" sections are fine. If you want to police them for proper citation to sources, go ahead. If you want to structure them into prose, have at it. Trying to remove them altogether is counter to the information-sharing function of the encyclopedia, and is indeed a waste of volunteer time. BD2412T20:09, 12 August 2021 (UTC)[reply]
Whatever such sections should be called, they should not encourage every casual reader to think, "Hey, this list doesn't include the fact that in the third episode of the fifth season of Family Man, it is revealed that the neighbor's cat is named Crookshanks." Calling them "In popular culture" seems to do exactly that. —valereee (talk) 17:07, 12 August 2021 (UTC)[reply]
This also brings up that, it's also the list format that many of these take. Lists "look" easy to add onto so draw in every trivial mention. It is far better to try to encapsulate how a topic has entered popular culture by prose, if possible, as I've found new editors tend to be a bit more adverse to trying to alter that and making a mistake. --Masem (t) 17:21, 12 August 2021 (UTC)[reply]
It does draw in every trivial mention, but that also means it's drawing in first posts by readers, sometimes. That's key. We get them to add a reference to say something the saw on American Dad. That's the start. Then we sloooowly reel them into our dysfunctional little group here, and one day they wake up and they're writing articles about ninth-century Inner Mongolian minor poets. But by then it's too late for them to rejoin the world of normal people. BWAHAHAHAHA Herostratus (talk) 19:07, 12 August 2021 (UTC)[reply]
OTOH, when that edit gets reverted five minutes later with an annoyed edit summary of "rem trivia"...the bait is doing its job, the reel not so much. :D —valereee (talk) 19:17, 12 August 2021 (UTC)[reply]
While lists are a good way for first edits of new editors, 99 times out of 100, when added to a pop culture section, it is unsourced. Which if unchecked creates a self-replicating problem. --Masem (t) 20:54, 12 August 2021 (UTC)[reply]
I think this gets well off-topic, but it's not specific to IPC: we have a huge problem because no-one's first 100 edits are good, but 100 bad edits in 2006 is alright because at least it creates something new, and 100 bad edits in 2021 is not fine because it makes existing alright content worse. So whatever you do is wrong and you'll get reverted and scared off the website. Or you don't get reverted initially, but someone finally notices you and tells you everything you've spent many hours on is wrong, and now you get scared off the website but you're also in tears. My best answer to this so far is "people should start off at Fandom and then come here when they're already used to the website design and some of the culture". — Bilorv (talk) 01:29, 13 August 2021 (UTC)[reply]
Oh $deity no don't send people to Fandom for a good experience. It's as good as testwiki for learning Wikitext I suppose, but does absolutely nothing for learning to edit in a collaborative environment. AntiCompositeNumber (talk) 03:51, 15 August 2021 (UTC)[reply]
With the levels of hostility expressed to both newcomers and old hands, there's not much collaborative environment in Wikipedia either. — Bilorv (talk) 12:15, 22 August 2021 (UTC)[reply]
I think that most of the posts are getting away from the main point, which is that the word "popular" shouldn't be used here. For example opera and ballet are not considered "popular", but mentions in such are just as valid or invalid as mentions in Hollywood films or pop music or computer games. Phil Bridger (talk) 19:37, 12 August 2021 (UTC)[reply]
This is a fairly interesting point, and I would add my voice to those that more or less hate these sections as they almost inevitably become long lists of unsourced cruft. I'm not sure changing the name will solve that core problem, but I'm nt opposed to the idea of trying it. My personal approach is to just remove anything without a source since that's pretty basic, and also remove mentions based on one throwaway line from a tv show, and maybe add things like hidden comments or edit notices if they persist. (Not that it always works, it's been over a decade of trying get people to stop posting that Commander Riker is "from" Valdez, Alaska). Beeblebrox (talk) 20:29, 12 August 2021 (UTC)[reply]
Where there are also things like opera & novels, I tend to use headings like "Cultural references", which might also cover a whole themed episode of say South Park, but not a passing reference. Johnbod (talk) 01:36, 13 August 2021 (UTC)[reply]
I have no real opinion on the title discussion, "popular culture" is intuitive if not dictionary perfect. Like many above I too generally dislike these sections, principally because they are usually an unsourced dumping ground for passing mentions in an single episode of a sitcom or the like. I think a good start may be to make MOS:POPCULT more succinct and punchy, emphasising the 2015 RfC, possibly elevating the sourcing requirements from that RfC into a guideline itself. Cavalryman (talk) 04:00, 13 August 2021 (UTC).[reply]
I suggest "Society and culture" as a title (used in WP:MEDMOS) which I think does a better job of reflecting this. What's popular culture now is usually not even in 10 or 20 time (which are now timespans relevant to Wikipedia!) In general I also find that sections "In popular culture" are almost always WP:TRIVIA and could be completely blanked.Tom (LT) (talk) 10:32, 13 August 2021 (UTC)[reply]
Strong oppose to a change (although hopefully this isn't a decision that is being taken here). On individual pages I'd guess that 'In popular culture' sections are themselves quite popular, have likely been a Wikipedia mainstay since 2001, and have a name which is both extremely recognizable and a more-than-adequate descriptor. On stand-alone article pages the idea of changing this ramps the "Huh?" factor up a level or six. Important pages such as World War I in popular culture, World War II in popular culture, Apollo 11 in popular culture and dozens if not hundreds more have educated readers about cultural events which have themselves educated the public since their inception. A good discussion, but let's leave it at that. Randy Kryn (talk) 11:12, 13 August 2021 (UTC)[reply]
I think that the underlying issue is this. The normal practice is that In the normal inclusion / exclusion decisions are made based on a multitude of factors including degree of relevance and degree of importance to the topic. Headings should be for material that inherently belongs in the article. Certain headings distort that process towards bringing in material that would not have otherwise been included. Headings like "in popular culture" are of that type. Particularly promotional or fandom items. North8000 (talk) 17:28, 13 August 2021 (UTC)[reply]
Oppose. I'm not going to talk about whether or not we should have these sections in the first place, because that doesn't seem to be the point of this RfC. But I don't think most people intend a negative implication when they're talking about popular culture. I also agree with Randy Kryn's reasoning. Clovermoss(talk)22:03, 13 August 2021 (UTC)[reply]
The existence of the article Mermaids in popular culture is presumably what allows the article Mermaid to pursue a purely zoological examination of these alluring beasts. The former article includes such pop culture phenomena as Zemlinsky's Die Seejungfrau; which seems only right as Die Seejungfrau has been put out on at least ten commercial recordings, AFAIK five times as many as there have been of Tubular Bells. -- Hoary (talk) 22:34, 13 August 2021 (UTC)[reply]
Oppose any across-the-board deprecation of "in popular culture" sections, which to me is where you place mentions of snippets of musical pieces heard in video games, TV shows, etc., instead of discussing modalities, orchestration, and influences (which probably fairly applies to the Dylan poem referenced above), etc. The lack of sourcing in such sections is notorious, but that's for editors of individual articles to decide how much original reporting to let in. Dhtwiki (talk) 09:03, 14 August 2021 (UTC)[reply]
The lack of sourcing in such sections is notorious, but that's for editors of individual articles to decide how much original reporting to let in. We already decided that; the answer is "none," and we wrote that up on a core content policy page called WP:No original research, which is global consensus that editors of individual articles cannot change. Levivich14:39, 16 August 2021 (UTC)[reply]
I tend to let plausible, innocuous statements stand, not to violate policy but in the hope that other editors will come along and find sources for them. Leaving unsourced a statement that a subway's door-closing chime is inspired by a piece by Handel isn't at the same level as, say, leaving an unsourced statement alleging criminal wrongdoing. If left unsourced, even the innocuous statements may eventually be swept away by more deletionist editors; and I won't object. Dhtwiki (talk) 01:32, 21 August 2021 (UTC)[reply]
Oppose deprecating the term 'in popular culture'. It's merely one of several acceptable titles for such sections/articles, and I see no need for any new rules. LEPRICAVARK (talk) 23:14, 14 August 2021 (UTC)[reply]
You are iVoting in the wrong discussion, TompaDompa. This is just about the changing of the section title, "In popular culture", not about whether the sections should exist or not. (That is for a whole different discussion.) GenQuest"scribble"07:02, 15 August 2021 (UTC)[reply]
I'm not at the wrong discussion, I'm just proposing a more radical solution – one that would cut the Gordian Knot, so to speak. The text at T:CENT says Should articles continue to have sections titled "in popular culture"? My answer is no—not because the title is bad, but because having such sections is. TompaDompa (talk) 03:24, 16 August 2021 (UTC)[reply]
Oppose deprecating the term 'in popular culture'. Like it or not, this content is going to continue to be added to the articles, and we have to put this junk somewhere, and the un-cited and trivia can then be easily deleted from these sections. Now, someone start a discussion about whether these sections should even continue to exist and things will get quite interesting. GenQuest"scribble"07:02, 15 August 2021 (UTC)[reply]
Comment I don't understand your reasoning for the opposition. You just commented that this discussion isn't about removal of these sections, but you used that very reason for that. What do you mean by "we have to put this junk somewhere". Would it hurt the article if we don't?Blue Pumpkin Pie (talk) 16:13, 15 August 2021 (UTC)[reply]
So I'm seeing kind of three questions:
1) There's the question of whether sections should even exist' at the end of articles that have things "In Joyce Carol Oates's 2000 novel Blonde, the character of The Ex-Athlete is based on DiMaggio" and "In Seinfeld, Season 3, episode 1 "The Note, Kramer spots DiMaggio in a Dinky Donuts" and "DiMaggio appears in Harvey Comics' Babe Ruth Sports Comics (August 1949)"
2) There's the question of, if they do continue to exist, (and they will) how should they be named (the original and basic question of this thread).
3) And then there's also always the eternal the question of, if they do exist, how to curate? Should stuff like the first item above (important character in a serious novel) be in them and stuff like the second (passing mention in a vulgar and witless, but very popular, TV program) or the third (cover appearance in a long forgotten and lost children's comic) not? (And other questions of details.) And what practical procedures might be used to curate them?
So, for the first question, there are a lot of decent arguments either way, but as a practical matter, come on. We're always going to have these sections. It's entirely legit to express your opinion for/against them, but it's not going to change anything. So moving on.
For the third, well the current procedure is for editors -- driveby anon readers often enough -- to keep adding stuff (some good, some marginal, a whole lot silly; some well ref'd, some poorly ref'd, some unref'd) and for other editors to come across them, mutter "oh my God" under their breath and trim them (or even delete them), and for people to occasionally argue about it, since ultimately it's a matter of opinion how to curate. That's kind of kludging along (like a lot of the Wikipedia!), but it's OK, and I honesty don't think there's a better way. It's alright. It works OK. The project is not going to collapse over this. I can't imagine any rules that could be put in place ("No more than ten items" or "No refs to non-bluelinked sources" or whatever).
For the second, that's the question.
Should these sections continue to be named "In popular culture" as is usual (altho far from universal)?
If not, should they mostly be named one other single name, or let 1000 flowers bloom?
I just don't think there's any way to make a rule. There is the general practice of naming them "In popular culture", and rules are to codify common practice, so there could be a formal guideline made to that effect, such that someone could come along and rename your "In art and literature" to "In popular culture" and have the high ground. But I mean that's not going to happen. You're not going to get even 60% of a large group to agree to that. So just forget it. Trying to make a rule to have the sections be named some other thing is forget it squared.
It would be preferable to have a (generally common) name. As we do for "Early life" and "Personal life" "Discography" and "See also" etc. That's a good point. And they only possible generally common name is "In popular culture", barring a long-term sea change. So it's fine for individual editors to keep doing that.
For my part, personally, in my personal opinion it just sticks in my craw. In my article, I don't want to put "Chaucer says this..." and "Juan Ruiz de Alarcón says that..." under popular culture. Yes they're in the vulgar tongue, and yes in their time they were for the common people, but I mean not anymore. Mostly people only read them in college classes. Few people say "Pick me up a guilty-pleasure novel, Jackie Collins or Cervantes or Melville or something like that; I'm just not in the mood for Boethius today". They just don't. Chaucer and Richard III (1699 play) are closer to Terance and Quintilian than to Nicholas Sparks or Tom Clancy, n'est-ce pas? It's just incorrect. It's misleading the reader. I don't want to do that, so for my part I'm not going to.
Oppose deprecating the Popular Culture sections. That is the name that Wikipedia has had for those sections, and usually they are useful additions to the encyclopedia. In cases where they are silly or useless, we can get into ugly edit-wars that go to WP:ANI and keep the tone of WP:ANI a little less heavy. That's only half humorous. But the sections are useful and the name is as good as anything else. Robert McClenon (talk) 19:45, 15 August 2021 (UTC)[reply]
Deprecate the sections as WP:UNDUE/WP:OR. When writing about the topic "Foo," what we're supposed to be doing is summarizing WP:RS about Foo. If the RS state that Foo was mentioned on The Simpsons, then yes, that should be included in our article, probably in a section called "Impact" or "Legacy" or something like that. But if no RS mentions it, and an editor adds to the Wikipedia article that Foo was mentioned on The Simpsons (or in a song lyric, or as part of a plot of a book, or whatever), then that's WP:UNDUE and WP:OR because it's including something in the Wikipedia article Foo that isn't mentioned in any of the RSes about Foo. Anything not mentioned in the Foo RSes doesn't belong in the Foo Wikipedia article at all. Levivich14:34, 16 August 2021 (UTC)[reply]
Oppose change This is a solution looking for a problem. There is nothing wrong with the phrase "in popular culture"; everyone knows what it means. I don't see any good reason to change it. Mlb96 (talk) 20:49, 17 August 2021 (UTC)[reply]
This is a proposal to expand the functionality of {{find sources}}, a template frequently used in {{Talk header}} (example) to help editors find sources to improve articles. Specifically, we seek to make it possible for different sets of links to appear for different types of articles, such as links to medical sources for medical articles.
Currently, there are threefour related templates that generate find sources links:
{{find sources}}, the basic set of sources starting with five Google links, plus JSTOR, NYT, and a couple more
{{find video game sources}}, which contains the basic set above, plus three more links targeted to video gaming
We anticipate that additional templates in this family for other subject areas may be created in the future. Under this proposal, talk header will choose between the available templates, either automatically or on the basis of a manually set parameter, to display the one most appropriate for a given page.
Approaches for selection
We are considering several possible approaches for how to select which set of links to use:
Through a new parameter that can be manually set (i.e. to display medical links at Talk:Giardiasis, we'd change {{talk header}} to {{talk header|search-domain=medical}} at that page)
Through auto-detection of WikiProject banners (i.e. Talk:Giardiasis would switch to using medical links because it includes the {{WikiProject Medicine}} banner)
Through auto-detection of Wikidata properties (i.e. Talk:Giardiasis would switch to using medical links because an automated analysis of its Wikidata item identifies it as a medical topic)
It would be possible to combine these approaches, such as implementing a combined option 2 – 1 approach, which in the case of {{Talk header}} would default to option 2 (project auto-detect) but would allow any editor to set a parameter (e.g., {{talk header|search-domain=medical}}) which would then take precedence over the project auto-detect. Having the parameter available would also be extensible to use by other templates on article pages where project detection isn't applicable; see below.
Previous discussion is at Template talk:Talk header, and we have created functional prototypes of options 1 and 2 in the talk header sandbox, which can be seen at the associated test page. (Current sandbox revision uses method 2, so testcases for method 1 currently fail, but pass successfully with the correct sandbox revision in place.)
Which approach(es) would you prefer?
Design
We are considering implementation via a wrapper template (here) which does all the detection of search domain, and transcludes the correct flavor of template. By placing the wrapper template at the current title (Template:Find sources) and moving the old content to Template:Find general sources, this remains transparent at the top level; all current transclusions of Template:Find sources after the changeover will invoke the wrapper, which invokes {{Find general sources}} by default. Outside of the Talk header template, this means a seamless transition for all other transclusions which will do exactly the same thing after go-live as they did before; that is, they will continue to invoke the basic "Find sources" link set, albeit by one extra call where {{Find sources}} transcludes {{Find general sources}} which invokes the Module.
Currently Template:Talk header includes the basic set of source links for all articles where it is not suppressed by parameter. After go-live, the behavior of "find sources" in Template:Talk header may change, depending which solution is chosen. If the parameter method is chosen, then the links in the Talk header would remain the same, until someone added the parameter. If auto-detect by WikiProject is chosen, then the links in the Talk header of pages on medically-related topics will switch to the medical links, and on video-related topics will switch to the video links; all other Talk headers would remain as before.
Impact on other templates
Other templates use the {{find sources}} templates, such as {{unsourced}} and other maintenance templates, as well as many others. Depending which approach is chosen, this could affect whether the other templates will be able to take advantage of them. A combined approach allowing auto-detect and via param would permit both.
Support as helpfully expanding the utility of this talk page banner. I would in particular be a fan of the wrapper template idea, as it is the least disruptive imo. I think the parameter approach via "search-domain=medical" is the best solution for how to label pages as needing MEDRS in the banner, though I think the auto-labelling is a good idea. My suggestion would be to try the auto-labelling first, and revert to manual labelling anything that is medical if it goes haywire and labels a lot of unnecessary things.--Shibbolethink(♔♕)23:57, 12 August 2021 (UTC)[reply]
As co-nominator, I obviously support this. Given how widely the find sources links appear, I think it's important that they are as useful as possible, and this will help with that by making them more appropriate to their context.Regarding selection approaches, I favor mainly option 2 (project banners), with the ability to override via option 1 (manual parameter setting). That's because I think it's important to have an element of automation to get this adopted on a wide scale. Option 3 (Wikidata) doesn't seem technically feasible, so that leaves project banners. I think "Is this tagged with {{WikiProject Medicine}}?" is an excellent metric, because the project tag belongs on all medicine-related articles, which is also basically the set we want to have the medicine links. However, it's nice to have the ability to override the default for the rare cases where it isn't working as expected, and having the parameters from option 1 will allow that. The only thing weighing against them is added code complexity, which isn't a huge downside.Regarding the wrapper template implementation, that's been more Mathglot's area of focus, so I'll defer to them and others who comment here. Also, I realize all this is more complex than some of the stuff that comes across VPR, so if anyone has questions or wants clarification, please don't be afraid to ask! Cheers, {{u|Sdkb}}talk05:50, 13 August 2021 (UTC)[reply]
I support the general proposal. I do have some questions about the implementation - I think if an automated detection system is implemented it will need to have a bit more subtlety than 'does this have a WikiProject Medicine banner?'. Articles about people in medicine, healthcare companies, medical books or journals, the history or social/political aspects of medicine, etc. are usually tagged with WPMed, but these articles do not necessarily require MEDRS sourcing for all claims. I wouldn't say this is a 'rare' case. If it's possible to take the intersection of WikiProject banners into account (e.g. don't default to 'find medical sources' if there is a WPBiography tag on the page in addition to WPMed) that might help, but I think this might need to be handled via a supervised AWB run or similar. Also, a hybrid of the 'find medical sources' and 'find general sources' template could be helpful for topics that might contain claims needing MEDRS sources but which are not strictly medical. Spicy (talk) 19:54, 13 August 2021 (UTC)[reply]
I like the thought of the hybrid template, since for the examples you gave, most sources wouldn't need the MEDRS standard but several might. For instance, a medical researcher would need it for the part of the page discussing their discoveries, a company for discussing their products, a journal for discussing medical controversies about their work, a history page for discussing medical details about viruses involved in a pandemic, etc. {{u|Sdkb}}talk20:40, 13 August 2021 (UTC)[reply]
@Spicy:, regarding "don't default to 'find medical sources' if there is a WPBiography tag on the page in addition to WPMed" this could definitely be added; it poses no great difficulty and would be isolated in the wrapper. It just depends on whether that idea gains consensus.
Another option to consider, is that there's no need to choose only one set of "find sources" links. If the article is in both projects as in your example, one could imagine various outcomes: we could let the Talk header template grab the medical links automatically, and then add a biographical links below it, the second one either added automatically as well, or manually by adding {{biographical sources box}}. Yet another possibility, would be to have the order of WikiProjects matter: if Med is first and Biog second, then you only get the "find medical links" automatically, anything else you'd have to add manually; if Biography WikiProject was first, then it would be the other way round. But maybe it's too subtle operationally, even if well documented ("You mean, I'm spozed to read the stinkin' documentation?") Not sure why AWB would be involved; I think it's all doable in the wrapper.
Sometimes having too much choice gets to be a problem because you can get paralyzed with all the possibilities, so at the outset I'm inclined to go with the simplest useful proposal that gains consensus; not because that makes it easier for template writers, but because that will give editors some time to see and use the new functionality, which may subsequently percolate into a more specific and informed wish list of increased functionality based on their real-world experience with the early version. Mathglot (talk) 22:11, 13 August 2021 (UTC)[reply]
The reason why I suggested AWB is because I think human judgment could be required for some of the edge cases - I don't think we should be giving people the impression that a MEDRS-compliant source is required to cite a medical device company's yearly revenue, for example. I suppose this could be handled in other ways, like the system you've described or Sdkb's hybrid template idea (although both of those rely on the assumption that the WikiProject tagging is accurate, which isn't always the case)... Spicy (talk) 06:16, 31 August 2021 (UTC)[reply]
Not too familiar with AWB but would there be any significant downside to first using Mathglot's logic-based approached based on WikiProject with a manual override? Centralizing the logic where possible seems preferable. In the case of a medical company, maybe just add priority logic to check for 'WikiProject Companies' and assign those topics to display the general link set. AWB could still be used to mass apply overrides if there's a scenario that can't be accounted for in the root logic. - Wikmoz (talk) 20:48, 31 August 2021 (UTC)[reply]
@Spicy:, Hopefully as people see it live and perhaps read the expanded /doc, they'll see some of the options and apply whatever makes sense to get the desired display. As far as not requiring MEDRS links for the medical devices company revenue case, two possibilities occur to me without changing anything said prior (although these examples are no doubt not obvious since it's not live, and there's no doc):
Add an additional set of links to the header outside the scope of the new header functionality, by separately adding {{General sources box}} after the Talk header, so that you have both the medrs links automatically added by the new template functionality per Med project presence, and the "regular" links. You can see how this would look in this mocked up Talk page for the "Cochlear Limited" article (note: the actual Cochlear article TP does *not* have WikiProject Medicine on the Talk page; I had to add it to the mockup for the purposes of this test)
turn off find-source links with the existing 'hide' param, and add {{General sources box}} (i.e., the Talk page will look the way it does now) (the third, "hybrid" solution has been mentioned already)
I was trying to find a medical devices company with the Medicine WikiProject already present so it would be a good example of your concern, but I gave up and had to force project medicine into the mockup for the test. (I didn't look very hard.) The question, I suppose, is this: "Is the benefit of having medrs links produced automatically via project detection worth the disruption that might be caused by losing the general "find sources" links for cases like medical device companies tagged with project Medicine, or in other cases where the correct WikiProjects are not applied and so the general link set would be better?" Is that a fair statement of your concern? I'm not sure we know the answer to that until we try it, unless someone wants to do some clever analysis and see what's out there now. I'm not opposed to undoing the installation after the fact, if on balance it turns out that the new approach is not helping editors improve the articles concerned by proposing a better set of reliable source links for most articles most of the time, because that is the whole point, right? Mathglot (talk) 01:47, 1 September 2021 (UTC)[reply]
Support. Very cool idea and great work Mathglot and Sdkb! I think Option 2 (with the manual override function) sounds like the best approach. It's probably not worth getting too hung up on the edge cases. For those, I'd favor whichever approach is easiest to engineer and maintain with a slight preference to avoid hybrid or stacked link sets. - Wikmoz (talk) 01:35, 22 August 2021 (UTC)[reply]
Thanks for the follow-up, Wikmoz. This hasn't garnered too much participation, but since it's been in a visible location and reactions so far have been positive, I'd say it's safe to move forward with implementation using option 2 with manual override function. {{u|Sdkb}}talk20:31, 31 August 2021 (UTC)[reply]
Yes, that sounds reasonable to me. Once it's been moved live in template form and had time to gain some page views, we could take another look to see if more tweaks or other changes are needed based on any feedback from those encountering it for the first time. Perhaps subsequent to that, I imagine one would check to see about moving parts of it into the module. Adding Sdkb. Mathglot (talk) 20:48, 31 August 2021 (UTC)[reply]
Proposal to Improve Template:Infobox artist by adding parameter for existing works...
It seems to be snowing against this change as proposed. If you want to refine the proposal, I suggest discussing it on the appropriate WikiProject, template talk, or similar venue. Adding a parameter to a template does not require a WP:VPR discussion in any case, so a consensus there will be sufficient. ProcrastinatingReader (talk) 11:46, 17 August 2021 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Request to add info box parameter: existing works
Description: the number of existing or surviving paintings, drawings, engravings or other attributed art works
The following info box parameter would tell how many paintings survived. For example El Greco has 500 existing paintings.
This will help historians understand how many paintings are attributed to each artist, Monet has 2500 existing works.
Oppose (and this should have been raised at the Visual arts project, not here). In many/most cases the numbers are uncertain, especially for drawings. There are often many disagreements as to attribution. Too detailed for an infobox, adding to clutter. What do you do for artists who are still working? Bad idea all round. By all means add the info to the article, but not box-suitable. El Greco actually illustrates the problems very well, as the number of his paintings is highly controversial: El_Greco#Debates_on_attribution gives several numbers, none very close to your 500 at all. Johnbod (talk) 20:06, 14 August 2021 (UTC)[reply]
Oppose This is why info-boxes, which I happily use for individual works, are unsuited to artist bios, especially late medieval/early modern, when, very often, almost nothing is known about the artist, and attribution is hotly debated. Tzim78 is obv acting IGF, but also see snow here. Ceoil (talk) 23:27, 14 August 2021 (UTC)[reply]
Oppose Numbers would be all over the place depending on the source cited, for reasons already mentioned. Better dealt with in the body of the article. Ewulp (talk) 00:10, 15 August 2021 (UTC)[reply]
Oppose - Too much room for error. There is no central database or clearinghouse of such statistics for artists whose works have not been cataloged across institutions, countries and continents. That is especially true of contemporary artists whose work has not yet been cataloged by an archivist or those without a catalogue raisonné. (Thousands of artists.) These statistics belong in individual articles not the infobox. Netherzone (talk) 03:06, 15 August 2021 (UTC)[reply]
Oppose, echoing others – for the proposed examples in particular, much more context than reasonably could or should be supplied via an infobox would be needed for an accurate representation of differing sources. This is blatantly information that's best left to the body. AngryHarpytalk11:57, 16 August 2021 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
@0mtwb9gd5wx: I'm not sure what you're asking here - could you give a few more details on what you are proposing? Mediawiki already included a HTML cleaner that fixes a lot of invalid markup, and anything that the parser can't fix automatically is tagged by the wp:linter for wikignomes to fix up. If you're referring to edits that make no changes to the rendered HTML of a page but make the wikitext look nicer - that is called Wp:Cosmetic editing and bots that exclusively make them are expressly forbidden per WP:COSMETICBOT. 192.76.8.74 (talk) 04:26, 17 August 2021 (UTC)[reply]
unfortunately there isn't really such a tool possible, as whitespace is very important in wikicode (unlike in most other programming languages). There is a syntax highlighter tool available in the editor though; the , left of "Advanced" in some toolbars (not the pencil icon on the far right). If "New wikitext mode" or "Automatically enable all new beta features" is enabled at Special:Preferences#mw-prefsection-betafeatures then it is available on the menu icon . —TheDJ (talk • contribs) 08:11, 17 August 2021 (UTC)[reply]
@TheDJ:@192.76.8.74:Actually, some pretty formatting is possible, such as: <ref name="N">NEWLINE{{cite web |last1=L |first1=F |title=T |url=U |website=W |access-date=D}}NEWLINE</ref> and naming refs then putting cites between refbegin and refend. .... 0mtwb9gd5wx (talk) 00:36, 24 August 2021 (UTC)[reply]
Should we use ECP on templates?
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
In response to the August 16 incident (permalink), and subsequent pings I've received on several of platforms, I've gone ahead and changed the behaviour of User:MusikBot II/TemplateProtector to elevate protection levels based on the configuration. Prior to today, the bot only looked for templates that were completely unprotected. In the past this was mainly a necessity for performance, but I believe this is no longer a problem. After today's events, I hope we recognize the necessity for this extra layer of automation.
That said, prior to running the bot, I tediously reviewed the full list of affected pages. The ones that have had their protection changed I'm fairly confident in. I either verified few or no previous editors would be unable to edit it, or that the content rarely if ever changes (i.e. redirects). For the few outliers, I used a little WP:IAR and applied extended-confirmed protection so that prior editors can still contribute. A few others I added to the bot's exclusion list so they will forever be ignored.
Which brings me to my next question, should we allow preemptive use of ECP on templates? Currently the policy states Extended confirmed protection should not be used as a preemptive measure against disruption that has not yet occurred. I agree with this sentiment wholeheartedly, but the situation is obviously different for templates and modules that are vulnerable to causing massive disruption. Take Template:Australian politics/party colours as an example. It is regularly edited by experienced users. All are extended confirmed, but none are template editors, and probably wouldn't become one solely to edit a template like this. The transclusions meanwhile are political in nature and hence are higher risk for targeted vandalism. So extended confirmed seems like a very nice compromise, which is why I applied it in this case (the bot would have otherwise raised to template protection).
If we do formally permit use of ECP for preemptive purposes, I suggest modifying the bot configuration to say, >500 transclusions for autoconfirmed (status-quo), then >5000 for extended confirmed, and perhaps >8000-10000 for template editor (currently set to >5000). With ECP in the picture, that should in my opinion take out a lot of potential for vandalism. However it's worth mentioning that, to my knowledge, since February 2019 there have been a but a handful of cases where someone lowered from template protection after the bot applied it. So that suggests 5000 is reasonable for template editor, in which case you might put ECP at 3000 or something. But we have to agree on using ECP first :)
I agree that this would be a reasonable compromise, especially for templates that are more content-oriented than technical. I'd also be interested in the viability of, for some highly visible content-oriented templates, breaking them into a TPE-protected template that covers the logic and XCP-protected subtemplates that cover the content (maybe with a mediating Lua module to sanitize potential attempts at CSS vandalism). But that's just spitballing there.-- Tamzin[cetacean needed] (she/they)03:43, 17 August 2021 (UTC)[reply]
Thanks for all the work and I support preemptive ECP. Perhaps there should be an exclusion method to allow only semi-protection for templates/modules in a certain category, but the exclusion would be ignored if the translusion count is above some threshold. The numbers proposed for the thresholds are too high. We don't want 3000 articles easily damaged by one malcontent. Johnuniq (talk) 04:04, 17 August 2021 (UTC)[reply]
Thanks for your work on this, MusikAnimal. I also support ECP, and I concur with Johnuniq that the thresholds are too high. The 2018 RfC found consensus for semi-protecting above 200–250, so I'd suggest that as a better cutoff. I think often, as humans, we're bad at grasping what big numbers mean, so here's a way to look at it: How would we feel if an unconfirmed or IP editor decided to rapidly make 500 similar edits to a set of pages? Even if they were good faith, I think the response would be (ideally a friendly version of) "woah, slow down a bit, take some time to get acquainted with things around here before doing something that substantial". That isn't quite analogous to editing a template with 500 transclusions since the latter is more easily reverted, but still, we're talking about the same impact, and it should come with a similar level of restriction to prevent disruption. {{u|Sdkb}}talk04:41, 17 August 2021 (UTC)[reply]
Yes, absolutely. I'm not seeing a significant downside here. If we have pages we're reluctant to use TP on, this is a good compromise. As with Schwede66 above, I would support lowering the threshold. Vanamonde (Talk)06:26, 17 August 2021 (UTC)[reply]
Support pre-emptive ECP at whatever threshold is deemed appropriate within the 4-digit range. ECP is widely available, so this should not be a significant block on updates. If such a change would allow for an increase in the Template protected threshold, so much the better as that remains quite an exclusive right. CMD (talk) 09:33, 17 August 2021 (UTC)[reply]
Also, would non-EC TEs now also need EC to edit ‘less high visibility’ templates?I’d be more happy with this proposal if EC could be granted at WP:PERM, so editors with less than 500 edits can request the perm if they have a need to edit one of these templates. ProcrastinatingReader (talk) 10:27, 17 August 2021 (UTC)[reply]
"EC doesn’t correlate well with template writing ability" - It's not the correlation to template writing which is the issue. Some vandals, as yesterday's episode proved, are quite adept. The key is that EC has some correlation to a common investment in the Wiki. Cabayi (talk) 10:33, 17 August 2021 (UTC)[reply]
It goes over the top. It may well exclude all vandals, but it excludes legitimate editors too. One editor adding Nazi symbols shouldn’t cause us to knee-jerk stop the thousands who edit them productively. Let them request it at WP:PERM. ProcrastinatingReader (talk) 10:35, 17 August 2021 (UTC)[reply]
I'd like to see some actual examples of editors who would be shut out and bitten by this. As a general rule of them, somebody with less than 30 days' tenure and 500 edits is only interested in writing articles or improving content. The back end work of templates is only of interest to experienced editors who've been around the block a bit. Ritchie333(talk)(cont)10:42, 17 August 2021 (UTC)[reply]
There's not really a roadmap like that. Some editors only do anti-vandalism, some editors only write templates, some editors only write content, some do a mix of them all. I think we can all think of editors in each of these groups. I'd have been shut out by this, if I didn't happen to have my account registered earlier than I actually started editing. If I registered slightly later, would I have been any more of a vandal?
Also it only just occurs to me... The two things that fix this Nazi issue are: 1) the protection bot not skipping already-protected pages, which is critical; 2) the change to the filter MusikAnimal applied. Those two things have already been done. It's not clear what this third change is preventing. The current config TE-protects >5000. This is proposing changing that to 8000-10000, and doing ECP for >5000. So... we're proposing letting more editors edit through the protection? ProcrastinatingReader (talk) 11:05, 17 August 2021 (UTC)[reply]
Agreed with Ritchie. Additionally, anyone who cannot edit a template directly can always make an edit request on its talk page. Doing that from the view source page is not hard (and if someone finds it hard...maybe they aren't ready to be editing templates yet). {{u|Sdkb}}talk11:06, 17 August 2021 (UTC)[reply]
I remember before I had the TE perm it was pretty frustrating having to make edit requests. Anything more complex takes ages to get reviewed, or just doesn't get reviewed, because someone else (likely someone unfamiliar with the template) has to take responsibility for the code being functioning and fairly representing consensus, which sucks up so much time even reviewing them. I suspect that'll be less-so for ECP, since a lot more editors have the perm, but at the same time only a subset of ECP editors will review requests to edit templates (likely the same subset as those who are TEs, so similar numbers). There's also various changes one wouldn't want to approve but also wouldn't revert, and those are all incremental improvements. I don't think being able to edit a sandbox and request an edit is a replacement for being able to edit directly. ProcrastinatingReader (talk) 11:21, 17 August 2021 (UTC)[reply]
@ProcrastinatingReader To be clear, you can request EC at WP:PERM/EC. Also remember this isn't about template writing ability, it's about guarding highly visible templates from disruption. Many of these templates require no template editing skills whatsoever, but any intentional vandalism will have far-reaching effects. Right now we go from semi to template protection, which is quite a big jump. It'd be nice to have an in between in there. The 2016 RfC also predates the many waves of template vandalism we've had. I do not believe the points raised there have merit today, which is why many admins, myself included, have continued to use ECP on templates when it made sense to do so (high number of transclusions, but the regular editors are not TEs). I don't have the time or energy for another RfC, so if we feel that is needed, someone else will have to spearhead that effort. — MusikAnimaltalk15:37, 17 August 2021 (UTC)[reply]
People can request it for alt accounts. All other requests are denied. So I don’t think it really counts. As I understand, the change you made to your bot would’ve prevented this Nazi issue, as it has 55k transclusions, so I don’t see the need for even more layers of pre-emptive protections when the problem has already been patched. The only other reasonable idea is to TE protect, in addition to the automatic protections, any simple template that realistically does not need to be changed. (eg a hypothetical 1k transclusions variant of Template:Wbr.) But EC protecting basically anything meaningful in the template space seems overkill. ProcrastinatingReader (talk) 15:46, 17 August 2021 (UTC)[reply]
WP:PERM/EC's banner leaves the door open for granting the perm to non-alt accounts in rare circumstances; and even if it didn't, WP:IAR does. If there were a situation where it would clearly benefit the encyclopedia for a non-EC editor to start editing ECP templates, it would be within standard administrative discretion to grant them the perm. I do know of at least one newer user who was offered EC for merit by several admins and declined. (An eon ago in 2012, I was given confirmed at the 3-day mark and rollback at the 13-day mark; that probably doesn't happen anymore.)-- Tamzin[cetacean needed] (she/they)18:00, 17 August 2021 (UTC)[reply]
@Tamzin: Can you link me a successful EC request by a non-EC editor (with no EC alts, and not a case of ECP being granted after it was initially pulled for gaming the system)? Ideally in the past year or two. ProcrastinatingReader (talk) 18:15, 17 August 2021 (UTC)[reply]
Looking back a few months I don't see any, but that's not my point. My point is that it's allowed by policy, and in a scenario where a good-faith new user starts flooding the system with edit requests for ECP'd templates, any admin has the authority to grant them the bit. It's just that that's a rather unlikely scenario to occur. Under the current use cases for ECP, on the other hand, it's hard to think of a need-based reason to grant the bit, especially since, IIRC, granting ECP to a not-usually-eligible editor doesn't exempt them from DS/GS 30/500 sanctions.-- Tamzin[cetacean needed] (she/they)18:34, 17 August 2021 (UTC)[reply]
@ProcrastinatingReader: I'm not going to go dig through my logs, but I have rarely given out ECP early, think it was related to a well established editor on another project wanting to do content translation here. It came with a strong reminder that it does not override the 500/30 arbcom remedies that they should now take extra care to avoid. — xaosfluxTalk19:00, 17 August 2021 (UTC)[reply]
The more important decision is to let the bot re-assess templates which have already been protected. Semi protection on a template which has crept up to 10 times the threshold for TE protection is a major red flag (without any embellishment). Cabayi (talk) 10:24, 17 August 2021 (UTC)[reply]
Support increasing the preemptive usage for security reasons, and also encouraging editors to get more involved with Template editing practices in general. Not discussed here, but of inverse concern are lightly transcluded templates, that are added to several popular pages, but I don't have a policy change for that. Shushugah (he/him • talk) 10:30, 17 August 2021 (UTC)[reply]
Comment: does anyone know how long the disruption yesterday actually went on for? It seems to me that a large part of the problem is that vandalism can be undone on the template within 5 minutes but may not quickly propagate to all of the pages it's transcluded on for caching reasons. Anyone can manually purge a page but is there a tool to automatically purge all pages in a particular category or list (here, the list of transclusions)? If not, can one be created or does that open us up to some denial of service attack? If vandalism like this can be undone in 5 minutes then I will likely oppose an increase in stringency, but if there's no other way to stop a repeat of yesterday then I'll likely support it. Notice that all we needed to stop this attack was the MusikBox elevation fix (which I completely support). — Bilorv (talk) 15:39, 17 August 2021 (UTC)[reply]
Okay, so was it really just a few minutes or so (5? 10? 20?) that the vandalism yesterday was up for? Also, just spitballing, but has anyone considered some method of bot protection that gets to the root cause of the aim of this vandalism—to damage highly-viewed pages? A vandal wouldn't do this on 50,000 less-than-a-view-per-day non-mainspace pages, I would guess. We could have a cascading protection like we use for the main page but on a lower scale, applied by bot to anything with above X views in the last month. Just interested in the feasibility. — Bilorv (talk) 16:06, 17 August 2021 (UTC)[reply]
@Bilorv: I suspect, after the change was reverted, that propagated to the pages within a minute. (It would take my bot 1 minute to purge 55k pages; job queue is currently not backlogged, and rarely is, if the statistics are accurate.) As for your idea, it sounds feasible. One possible approach: WMF provides this data dump that can be used. Using that, one can bulk fetch the templates used by each page above X pageviews and then sum it all up. ProcrastinatingReader (talk) 14:07, 18 August 2021 (UTC)[reply]
Yes Bilorv, it was 5 minutes to fix (well done those who were on the ball). It was also 15+ emails to WP:VRT and at least one press enquiry (just counting the ones I saw & handled myself), 2+ press reports, and the reputational damage to Wikipedia. The loss of 5 minutes effort was the least of the damage. Cabayi (talk) 09:51, 18 August 2021 (UTC)[reply]
Support and I'm frankly surprised this wasn't already done. Arguments about how this might bite new template editors aren't compelling: you can be patient and get your 500 edits! It's not hard! Further, we should do what we can to minimize harm done to readers and our subjects (especially BLP pages); "accidentally" suggesting that someone is a Nazi in a BLP seems like a bright line we shouldn't be crossing - or even provide the road that could be used to cross it. Jorm (talk) 19:33, 17 August 2021 (UTC)[reply]
Support. If they'd done this on some template that is used on fewer, it probably wouldn't have been caught for much longer. I get that this means there are some people who could make positive direct contributions and instead for a short time will have to make edit requests, but that's true for many articles, and those are single articles. —valereee (talk) 21:11, 17 August 2021 (UTC)[reply]
Support reasonable actions to make it harder to vandalize thousands of our most highly viewed pages in a few mouseclicks. Unprotected templates transcluded into huge numbers of highly salient pages, especially BLPs, make mass-scale vandalism ridiculously too easy and common. - Astrophobe (talk) 21:31, 17 August 2021 (UTC)[reply]
’’’Support’’’ templates are highly visible so the impact of vandalism / test edits / not understanding template workings/code or formatting is high. I support lower thresholds for this reason: eg > 100 transclusions for autoconfirmed > 250 for EC and > 1000 for TE. Tom (LT) (talk) 22:00, 17 August 2021 (UTC)[reply]
Support. Our long-standing policy on High-risk templates (and it is a policy despite its guideline tag) pre-dates the EC policy by a long way. I'm never a fan of specifying exact thresholds for these things, but should we use EC for high-risk templates where appropriate? Sure. -- zzuuzz(talk)22:18, 17 August 2021 (UTC)[reply]
Support protection, regardless of whether we classify it as ECP. Regarding "high-risk", I'd go so far as to say that the template namespace should be protected by default, with a whitelist to allow editing e.g. DYK nominations. Has anyone ever seen a new user make meaningful positive contributions to any template such that it wouldn't be better handled through a protected edit request? — Rhododendritestalk \\ 22:35, 17 August 2021 (UTC)[reply]
Oh, lots. Some templates are maintained almost entirely by anons - notably sports templates but also many other types. To get some idea of the massive backlogs and content deficit that would create, take a look at recent changes. -- zzuuzz(talk)22:46, 17 August 2021 (UTC)[reply]
I agree that protecting the entire template space would be a significant change and that it's not unusual for templates such as sports season standings to be updated productively by new or unregistered editors. Plus since transclusion from any namespace is permitted, editors would just start putting more templates into project space. isaacl (talk) 23:14, 17 August 2021 (UTC)[reply]
It might be worth having an edit filter that watches for new images being added to templates by non-EC editors. If we can't restrict access to the whole namespace we can at least make oversight easier. I'll run it over to WP:EFN. — Wug·a·po·des00:30, 18 August 2021 (UTC)[reply]
Support for so many reasons it would take all day to list them. Worthwhile, though, to verify that the template editor permission will allow editing of ECP-protected templates. There may be occasional rare exceptions where this is warranted. Risker (talk) 02:42, 18 August 2021 (UTC)[reply]
Support This is the only viable alternative to more extensive use of full protection. I think however that admins will need to be reminded they can grant EC. I had forgotten until I saw this here. DGG ( talk ) 03:24, 18 August 2021 (UTC)[reply]
Support as there is a clear need for templates with more than auto-confirmed and less than template-editor protection. The language Extended confirmed protection should not be used as a preemptive measure against disruption that has not yet occurred should be removed from the ECP policy page. User:力 (power~enwiki, π, ν) 03:54, 18 August 2021 (UTC)[reply]
Support - as a very reasonable compromise between semi-protection, and TPE protection (which it seems would impose barriers to some content templates being updated). I am also very glad to see that MusikBot II will now raise protection levels as transclusion counts increase, given the performance issues have been elided. Nice work MusikAnimal :) firefly ( t · c ) 06:24, 18 August 2021 (UTC)[reply]
Support I have long supported this and believe it could have a significant impact on reducing template vandalism while minimizing the harm for legitimate users. --Trialpears (talk) 08:39, 18 August 2021 (UTC)[reply]
Support the introduction of ECP as an extra level in protecting templates. Oppose the increase in threshold for TE protection. Support the bot re-assessing previously assessed templates. Noting the need for the bot to respect manual adjustments to the protection, preferably it would flag up somewhere (pinging the adjusting admin) that the protection level is out of sync with the norm. Also noting that many sensitive templates are substed & that the transclusion numbers are not the whole story. Cabayi (talk) 09:57, 18 August 2021 (UTC)[reply]
Oppose - I realize I'm coming to this late and it's already snowing, but hear me out. ECP is a game-able protection level - it takes a more dedicated vandal to game it but trust from my experience at SPI that it's very little deterrent over semi, and with templates the payoff is having your vandalism immediately appear in maybe tens of thousands of articles all at once. Plus, the disruption you cause still produces ANI complaints three days later and serious reactions like this proposal here with widespread ramifications. In exchange for 500 nonsense edits (or one edit plus a script that clicks undo 499 times over a few days) and a 30 day hold (set a reminder in your calendar), this would've been a pretty sweet deal for our recent Nazi vandal. On the other hand, template protection secures high-risk templates to only editors who have been vetted by other members of the community, which is a process that's far more difficult to game. If template vandalism is becoming a widespread problem (I would argue it has been for quite some time already) then we should consider some form of pending changes protection for templates that appear in article space. Ivanvector's squirrel (trees/nuts) 13:55, 18 August 2021 (UTC)[reply]
If I understand correctly (in no way a given!), this proposal is whether to allow ECP on templates, with the specific levels to be determined later. On re-reading the proposal it seems that the example given would indeed lower the protection of some templates - which I would disagree with were it proposed formally. I'd probably suggest keeping the current thresholds and then inserting another at 2500 transclusions for ECP. MusikAnimal - thoughts? :) firefly ( t · c ) 14:45, 18 August 2021 (UTC)[reply]
Yes, we will decide on adjustments to the thresholds in a separate discussion (I don't think that requires an RfC). Regardless, even if the bot doesn't use ECP, I would still like to see use of it in preemptive fashion written in our policy. As noted above, Template:Australian politics/party colours is a prime example, given the usual template editor protection would have shut out all editors. — MusikAnimaltalk16:13, 18 August 2021 (UTC)[reply]
Support. It seems like it would be sensible to have another level of protection available here, since the two current options are basically "everyone can edit" and "only administrators + a very small number of users can edit". Yes, of course it is possible to game the EC permission, but I don't see how restricting ourselves to a permission that is even easier to game is the right solution. 192.76.8.74 (talk) 21:28, 18 August 2021 (UTC)[reply]
Support adding ECP as an intermediary step, but Oppose raising the 5000 transclusion threshold for TEP. I think something like the 250/2500/5000 proposed above would make more sense than lowering the protection levels on highly-used templates. --Ahecht (TALK PAGE) 21:30, 23 August 2021 (UTC)[reply]
Support — As for Ivanvector's oppose, I think that instead of lowering the threshold for template protection, this should mainly be used for templates that are currently semi-protected but are high-risk enough to warrant extended-confirmed protection. Tol (talk | contribs) @ 20:25, 1 September 2021 (UTC)[reply]
I was just about to ask someone close this, because I don't have the stomach for a proper RfC, but it looks like we're doing it anyway! For those of you who are just now seeing this thread: This started as an update about the bot I maintain, in response to a recent vandalism incident. I was gauging interest on using ECP, as many of the articles that would have been raised to template protection by the bot seemed to call for it. So anyway, for the purposes of this RfC, !voters can ignore all the proposals regarding the bot such as what thresholds we will use. That can be ironed out later once consensus for the use of ECP is established. Thanks, — MusikAnimaltalk21:20, 17 August 2021 (UTC)[reply]
Thanks for the clarification. I was about to say essentially what you said about dealing separately with any changes to the bot. I have a personal bias that appreciates having a step between semi-protected and template-editor protected, so this may be hindering me from evaluating the downside of using extended-confirmed protection. (There is a module I wrote, before the template editor role existed, that later got template-editor protected; an admin kindly lowered it and the corresponding template to semi-protected so I could continue to support it as needed. I know it could get raised back to template-editor protected any time and then I'd have to rely on edit requests. It's not a huge deal and changes are infrequent, but it's a potential future impediment.) isaacl (talk) 21:37, 17 August 2021 (UTC)[reply]
Comment - although ECP is certainly a lot safer than semi-protection, it's still something a dedicated vandal could overcome without anyone else needing to cast eyes on them. Signing up a new account, doing 500 edits, and waiting 30 days, is not beyond the realm of imagination. Wouldn't it be better for us to use template protection for these high-visibility templates? Obviously this will cause irritation for other legitimate users wishing to make tweaks to those, but I think that's a better solution than risking the 16 August fiasco again. — Amakuru (talk) 08:14, 18 August 2021 (UTC)[reply]
Some vandals might go to that extent - we always see it elsewhere - although it is definitely a significant barrier. Many will be caught on their way to EC, but some will get there. At least we might get a few typos fixed in the process. We've previously had administrators who are mass sockpuppeteers and some who have deleted the main page, so nothing will ever be perfect. It's just a matter of getting the cost/benefit balance right, and this proposal gives us an extra option to do that. -- zzuuzz(talk)09:02, 18 August 2021 (UTC)[reply]
Please excuse me if I've missed some discussion, I haven't read everything related to this incident. I know MusikBOT doesn't escalate protections to avoid the bot overriding admins delibretly setting a lower protection level. Wouldn't it make more sense to control these cases using the {{bots}} template to prevent the bot from changing it in those cases? --Trialpears (talk) 08:34, 18 August 2021 (UTC)[reply]
By "using the template", I'm assuming you mean {{bots}}? I don't think this task should be exclusion compliant in this way because a vandal could also do this to prevent it from being protected, say right before they transclude it into a much more visible template (which should also be automatically protected, but for the sake of the argument let's pretend that's not the case). The bot only ignores pages with recent page protection changes in the past 7 days, according to the ignore_offset option in the User:MusikBot II/TemplateProtector/config. We don't want this to last for eternity because humans won't bother to go back and check that a template with just 500 transclusions now has several million. Humans forget, the bot will not :) However admins can also explicitly exclude specific pages via the config, so there's still a means to make the bot ignore a template. — MusikAnimaltalk15:53, 18 August 2021 (UTC)[reply]
That's indeed the template, just forgot the {{t}}. You're probably right about the bot being exclusion complaint isn't a great idea, but your config solution seems sufficient. The ignore offset of 7 days also seems find, but then why didn't it escalate protection at {{wbr}} and others mentioned in related discussions. --Trialpears (talk) 21:31, 18 August 2021 (UTC)[reply]
Up until yesterday, the bot only acted on templates that were completely unprotected. Now it will escalate from semi to template editor in accordance with the configuration. The technical means to do this was only made possible some months ago. So while the bot came too late to the rescue in this case, we should at least be glad our new database replicas are fast enough to make this functionality possible :) — MusikAnimaltalk03:37, 19 August 2021 (UTC)[reply]
I appreciate the desire to review the transclusion count periodically, but am not sure if a seven-day minimum period is long enough. For bot-set protection, it doesn't matter, but if an admin set the protection level, surely they considered the future potential usage of the template for more than the next week? isaacl (talk) 20:17, 19 August 2021 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Enable Article / Talk tab bar for mobile anon users
If you visit https://en.m.wikipedia.org/wiki/Mona_Lisa while logged in, you'll see the "ArticleTalk" tab bar. ("minerva__tab-container" element) But if you're logged out, this tab bar goes missing and there's no way to access the talk page unless you manually alter the URL. This turns out to be by design and now consensus is required for a configuration change to ensure that anyone who can edit can also reach talk pages. — Alexis Jazz (talk or ping me) 11:29, 22 August 2021 (UTC)[reply]
Support, Obviously. Sometimes I really do question if the WMF understands the site that they run, this is supposed to be a collaborative encyclopaedia building site - how on earth is collaboration supposed to occur when you hide the main methods of communicating from the vast majority of users? The requirement for consensus seems to be backward here - removing the ability for anonns to communicate on mobile should have required community engagement, restoring longstanding functionality should be the default. The rationale for removing talk page access for all mobile annons seems to be a combination of "mobile IP users are obviously too stupid to understand the concept of a talk page and would just fill them up with nonsense and spam" (I'd like to see the data that supports this, according to the phabricator task this is based on them putting a talk page link in a rarely visited settings page and being surprised that people didn't understand what it did???) and that the mobile talk pages are too buggy to be publicly available (In which case they need fixing, not hiding.). I just can't see the sense in having a huge body of users who are allowed to edit the site but are barred from discussing their editing - it just seems dumb. 192.76.8.74 (talk) 12:42, 22 August 2021 (UTC)[reply]
For background, talk pages were never removed, rather they were added. The mobile site was built from the ground up. In fact, we didn't have editing for a long time as it was communicated to WMF by editors that notifications were mandatory before we could do that. We added notifications, then editing. Talk page access was only added in current form circa 2019 because communities spoke up and helped drive that priority.
Building the mobile site has always been based on priorities, so nobody in WMF has ever removed this functionality as you are alleging here. Please assume good faith. Our software is extremely complex with very few maintainers. Jdlrobson (talk) 19:16, 23 August 2021 (UTC)[reply]
I'm a bit torn here, in that I only partially agree that this is supposed to be a collaborative encyclopaedia building site. The primary purpose of this site is to be an encyclopedia serving our readers. Obviously, to have an encyclopedia, you need to write an encyclopedia, but the writing is not the primary purpose. It's just a means to the end. Screen real estate on a mobile device is precious, and wasting pixels on a feature that's mainly of benefit to writers degrades the experience of our readers. -- RoySmith(talk)16:41, 22 August 2021 (UTC)[reply]
RoySmith, that's a valid argument, but you can't have it both ways. Either mobile anon users can edit (which they currently can) and they need to be able to reach talk pages. Or you remove their edit button (that saves even more pixels) so they won't have a pressing need for talk pages anymore, but that's a difficult topic. — Alexis Jazz (talk or ping me) 17:09, 22 August 2021 (UTC)[reply]
I'd be happy to see all anonymous editing go away. Want to edit? Make an account and the editing buttons and links become visible. IMHO, the amount of effort we put into making anonymous editing work isn't justified by the value it adds. For example, the whole "IP Masking" effort that's currently underway. -- RoySmith(talk)17:41, 22 August 2021 (UTC)[reply]
RoySmith, I don't oppose, but unless/until we manage to establish a consensus to end IP-editing (this recent effort went nowhere) we have to deal with it. So that's what I'm trying to do. As long as they have an edit button, they should have a talk page link. — Alexis Jazz (talk or ping me) 18:04, 22 August 2021 (UTC)[reply]
@RoySmith and Alexis Jazz: I don't think we should make the fork for showing editing features logged in vs. not. We want users to log in even if they never plan to edit so that if they do decide later on to fix a typo it'll be a smoother journey from there down the editing rabbit hole. But if their first reaction when they create an account is "ack, this just introduced all these ugly buttons I don't want", they'll never stay logged in. {{u|Sdkb}}talk07:23, 24 August 2021 (UTC)[reply]
Support Paid employees have missed the boat here. An IP user edits, is constantly reverted, but doesn't see explanations on their talk page. Effectively a campaign to frustrate and drive away IP editors, while further stigmatizing IP users to the community.—Bagumba (talk) 11:13, 23 August 2021 (UTC)[reply]
This is now a forked discussion, can I suggest redirecting this back to the WP:VPP section, as that is also diverging into something separate from what the section author originally wrote. ProcrastinatingReader (talk) 12:34, 23 August 2021 (UTC)[reply]
I agree with Bagumba: this is a specific proposal for a skin and should be allowed to reach its own conclusion. The other discussion is a broader one covering all clients. Regardless of its outcome, the skin can be changed as per community consensus. isaacl (talk) 15:20, 23 August 2021 (UTC)[reply]
@RoySmith: oppose early closure. This is a specific proposal to do a specific actionable thing. The thing is boolean as well so it is very easy to determine the result. That VPP discussion is extremely broad and vague. — xaosfluxTalk15:49, 23 August 2021 (UTC)[reply]
Question I agree that giving everyone (including logged-out folks) access to the talk page is a good idea. However screen space is indeed limited on mobile, as RoySmith mentioned, and we know from our data that most logged-out people are not visiting Wikipedia with the intention of editing. They want to read articles, and the Article Talk tabs push the article down the page a bit, so does that design align with what they want? Additionally I wonder if the "Talk" tab, as it is currently presented to logged-in folks, might be confusing logged-out folks and newcomers in general (i.e. what does "Talk" mean? what will happen if I tap on it?)? Which brings me to these mockups made a few years ago by User:Npangarkar_(WMF), of an expanded article footer that has additional tools and information (including a link to the talk page). I feel like the inclusion of an icon, and the more descriptive title ("Discuss" vs. "Talk") make it easier for newcomers to understand what they might find if they tap on it. It could be even more helpful if the button/link included the number of discussions (something like "2 active discussions"), which was an idea explored in Winter. AHollender (WMF) (talk) 18:40, 23 August 2021 (UTC)[reply]
@AHollender (WMF): The note about screen real estate makes sense, but nobody really scrolls to the bottom either. There is a pencil icon on each section to edit it. Editing and discussion workflows should ideally go hand in hand, so if it's prominent and easy to edit there needs to be a complimentary method of discussion. Perhaps a button on the warning message that shows up when you click "Edit" is one way forward. For logged in users, the 'advanced mobile' mode (which shows the talk button) should perhaps be default, since most logged-in people do probably edit (?) ProcrastinatingReader (talk) 19:31, 23 August 2021 (UTC)[reply]
That's a good point about wanting the workflows to go hand in hand, ProcReader. Maybe we want some more mockups of what that could look like.
AHollender, regarding "discuss" vs. "talk", I believe the desktop tab used to say "discuss" instead. I'm not sure why it was changed, but that's probably a discussion to seek out. The biggest issue I tend to see is WP:NOTFORUM—it's not always intuitive that the discussion page is for discussing improvements to the article, not a general comment thread for discussion about the topic. We designed {{Talk header}} to help explain this, but the mobile developers got fed up with the banner bloat on talk pages and just shoved them into an "about this page" submenu no newcomer will ever click on, so ¯\_(ツ)_/¯. {{u|Sdkb}}talk20:22, 23 August 2021 (UTC)[reply]
A common trap is for people to do mobile mockups in English, then be surprised when the German version is a mess because "Diskussion", "Quelltext bearbeiten" and "Versionsgeschichte" don't fit into the space allotted for "Talk", Edit", and "History". -- RoySmith(talk)21:20, 23 August 2021 (UTC)[reply]
It traditionally was Talk, then globally it was changed to "discussion" and then en.wp freaked out because "discussion" was too long (taking up more space in their monobook skin) and different from "talk" and they feared that "discussion" would invite discussions on the topic instead of the article, so en.wp changed it back to talk. —TheDJ (talk • contribs) 10:17, 24 August 2021 (UTC)[reply]
Back then definitely. And the bar is all filled up with additional portlet actions for administrative actions as well, because dropdown menus are BAD :D —TheDJ (talk • contribs) 10:26, 24 August 2021 (UTC)[reply]
I absolutely do. Tried Vector for a while, but never could get used to it. Too much clutter. Monobook is clean and simple, and that's exactly what I want in an interface. SeraphimbladeTalk to me05:56, 25 August 2021 (UTC)[reply]
Qualified support. This is a classic example of systemic bias toward editor desires over WP:READER desires. I agree with everyone that it's essential to have some way to access talk pages from every editable page, but I agree with RoySmith and AHollender (WMF) that we don't want to give it inappropriate emphasis. The mockup of what it could look like from the bottom of the page looks quite nice, although I'd want to see some more discussion around what we'd want to go in the edit overview section or whether we should just keep the current "last edited by JimboWales" bar. {{u|Sdkb}}talk20:14, 23 August 2021 (UTC)[reply]
Support, and (probably deserves its own section) switch from text labels on tabs, to icons with tooltips (ha-ha, the mobile folks won't see the tips). RoySmith's comment about the length of terms like Quelltext bearbeiten raises a good point, but the solution is to follow the example of European road signs and come up with good icons for 'Read', 'Edit', 'History', and so on, and relegate text equivalents to second place. I can visualize one for 'Talk' involving two little talking heads facing each other. It's well established[citation needed] that people process images faster than text, and it would also be a god-send for those of us who occasionally wander off to other language Wikipedias in languages we can't read, and just want to check history, or find a related discussion or compose a diff or something. Mathglot (talk) 22:16, 23 August 2021 (UTC)[reply]
Icons works well in addition to text, but on their own are known to sometimes increase confusion, esp the more there are and the more esoteric they become to try to convey the many meanings that have to be conveyed. Especially on mobile, where you have no hover labels etc this actually reduces discovery. Anyways, mobile already uses a lot more icons than desktop does. The Advanced mode for editors on mobile, currently has language, a watch star, a clock winding back, a pencil and a dropdown menu.... and I think most people on first glance have no idea what any of them do...... —TheDJ (talk • contribs) 10:25, 24 August 2021 (UTC)[reply]
Support. However, as other editors have suggested, it might be better to find an alternative to the [Article | Talk] tabs to save some screen real estate. There's a lot of blank space between the language icon and the edit icon. Maybe slip in a Talk page icon in that row? Alternatively, the proposed Tools section at the end of the page looks great. - Wikmoz (talk) 04:56, 24 August 2021 (UTC)[reply]
Actually, it looks like the problem was already solved in the Wikipedia app. At the bottom of each article, there is an ABOUT THIS ARTICLE section with links to View talk page and View edit history. - Wikmoz (talk) 05:16, 25 August 2021 (UTC)[reply]
Support as at least a start. Mobile or not, we should always make the channels of communication clear and easy to find, and treat every reader as a potential editor. SeraphimbladeTalk to me06:56, 24 August 2021 (UTC)[reply]
Support. It doesn't make sense that a group that is allowed to edit cannot even view talkpages and edit-histories. Why not make pressing the existing "edit" button on the mobile site open up a sub-menu with the options "Edit article", "Go to talk page", and "View history"? I think it's unlikely that anyone technically inclined enough to edit a page would be confused by this additional step. Rabbitflyer (talk) 22:19, 31 August 2021 (UTC)[reply]
Strong support - Talk pages are the backbone of Wikipedia. It would help me tremendously with my work on Wikipedia in mobile. If we did it in the userspace, we should do it to others as well. Interstellarity (talk) 16:34, 1 September 2021 (UTC)[reply]
With this in mind, can you please review – what I currently understand to be – the issues you all have raised here and let us know what issues you think are missing from this list and/or what about this list needs to be edited?
For added context: I'm asking the above because it's important to me that our team accurately and exhaustively understand the issues y'all are raising here, so that we can make sure the issues we prioritize working on in the next few months are the issues that will be the most impactful to address.
Issues
Meta
Talking is a core part of editing and there is a large segment of people who can edit and not talk. As 192.76.8.74[1], @Alexis Jazz[2], @RoySmith[3], @MarioGom[4], @ProcrastinatingReader[5] , and others in previous conversations have articulated[6][7][8][9][10]: collaborating is an important part of writing an encyclopedia. In order to collaborate, you need to be able to talk to people. Currently, there is a large segment of people (anons editing on mobile), who are: A) able to edit and B) not able to collaborate, by way of them not having access to talk pages.
The above, "...wastes time and energy for editors to post explanations/guidance/warnings for contributors who cannot respond" @Johnuniq[11]
It also helps contextualize why anons editing on mobile not having access to talk pages is problematic.
It's disconcerting to learn that we – volunteers and WMF staff – do not seem to share a core assumption/understanding that people who can edit, must also need to be able to talk.
Talk page design
People do not intuitively recognize discussion pages as places to talk about improvements to articles.[12]
People accessing talk pages on mobile lack access to important context about the conventions that guide how these pages can be used constructively.E.g. Talk page banners/templates are difficult to discover and edit notices are absent.[13].
Additional context
Considering there are three teams within the Foundation working on improvements to talk pages, I thought it would be worth making sure you all were aware of the work that is being planned and done to improve volunteers' ability to communicate with one another.
A series of improvements intended to help iOS participants to know when they have a new notification without them having to check Wikipedia’s website or check pages in the app, so that they can take timely action on their notifications.
*You can experiment with the Reply and New Discussion Tools right on desktop, by enabling the DiscussionTools beta feature in Special:Preferences.
I inserted a subheading to make this more easy to respond to. A quick additional point is that there needs to be a way of alerting users of mobile devices that is different from the normal semi-spam that occurs with nearly all apps competing for user attention. I have seen phones where a dozen apps have badges showing notifications—the owner ignores them as background noise. For Wikipedia use, when a user opens their browser or app, and if there are outstanding talk-page messages, there must be something like the orange-bar-of-death that more or less compels the user to respond. The suggestion that real-estate on a phone is important completely misses the point that the first thing the user should do is at least view their talk. That raises another tricky point. By convention, we bottom-post, but on a phone that might require a bunch of scrolling. I'm not sure what to do about that but ideally the current sections would be shown. Johnuniq (talk) 00:18, 28 August 2021 (UTC)[reply]
I inserted a subheading to make this more easy to respond to.
Oh, wonderful! Thank you for doing that @Johnuniq.
there needs to be a way of alerting users of mobile devices that is different from the normal semi-spam that occurs with nearly all apps competing for user attention.
@Johnuniq: would it be accurate for me to understand the issue that's prompted you to share the above as: "Anonymous editors do not respond to the messages others leave for them on their talk pages."
Note: I appreciate the language I proposed above does not include the solution/requirement you proposed. I've done this intentionally so as to ensure I'm accurately understanding the underlying issue any solution(s) would need to address.
By convention, we bottom-post, but on a phone that might require a bunch of scrolling.
This is a great callout and something we will need to consider as part of the work we have planned to help people identify new talk page activity. I've documented – what I understand to be – the question inside of what you are saying on Phabricator: "How might bottom-posting impact the likelihood that people accessing talk pages, particularly on mobile, will see the new messages others have left for them?". PPelberg (WMF) (talk) 01:47, 2 September 2021 (UTC)[reply]
@PPelberg (WMF): It's not quite right to sum up the issue that's prompted me in the terms above. First, some IP editors are experienced and do respond to talk page messages (so "do not respond" is over generalized). Second, that wording makes it sound as if the anonymous editor might have made a choice to not respond whereas my original concern was for the many edits made by mobile IPs and accounts where the UI does not show them that they have a talk message, and/or does not rub it in their face that the message might be something they "must" see as opposed to the normal spam from many social media platforms, and/or does not provide a simple way to respond. Finally, I am one of many editors who occasionally write detailed explanations for new users and it is destructive for editors like me to later learn that the recipient probably never even knew about my explanation. My point is that the UI is damaging the collaborative community because people like me now think that all IPs/accounts using inoperative software should be banned. Regarding "simple way to respond": I think there should be an orange bar with suitable wording that is hard to avoid. Clicking that bar would take them to the first section on their talk with the most recent date. I understand enough about code to know that would be difficult, but something much better is needed. Perhaps force all new contributors (with a cookie?) to follow a quick tutorial. That might be mandatory if any of their edits have been reverted. Thanks for taking the time to engage here. Johnuniq (talk) 05:11, 2 September 2021 (UTC)[reply]
"Anonymous editors do not respond to the messages others leave for them on their talk pages." I'd say "Anonymous users do not realize that there are messages/that others are trying to tell them something, and if by chance they do realize, they have a hard time responding to those messages/notifications" —TheDJ (talk • contribs) 20:43, 3 September 2021 (UTC)[reply]
I assume we're talking about talk pages only here? If so, I think this question is broken down into two parts. The first is deficiencies compared to the desktop editing experience. However, deficiencies compared to desktop is not the full list of problems with mobile talk pages or things that should be done differently on mobile, but I would have to think harder on that part to produce a list. One example: if you see a protected page and want to edit it, the workflow on enwiki is via a talk page edit request. It's a pretty poor UI esp on mobile (you can explore it by going to Donald Trump in incognito on your phone and trying to edit). Some of this falls on the community but there's not really a much better workflow possible without software changes. IIRC(?) not too long ago the "View source" button wasn't shown at all so it wasn't clear how to request a change, so I guess the situation is improving...
Although I suspect 'solutions' is separate to 'issues' I would like to take the opportunity to note, in regards to 2.2 (talk page banners), that I have some feelings on the usefulness of the banners on many talk pages. They're a mess, like look at this. It wouldn't be reasonable to show it all to mobile users, and very often there is nothing useful in them IMO (but I suspect I may be a minority view there). Conversely, see here for a useful non-generic banner and toggle "read as wiki page" on and off to see it. It's a hack used to make the message visible on mobile but apparently still only displays when you "read as wiki page"; I don't know why that feature even exists? If a solution to the talk banner issue can't be figured out, showing editnotices (somehow) would be a feasible solution. A talk page editnotice should only be placed when there's something substantive to say about that particular article. ProcrastinatingReader (talk) 01:02, 28 August 2021 (UTC)[reply]
The problem with not showing banners to mobile users is that we expect all users who use the talk page to have read them. It is not reasonable to expect Desktop users to be aware which banners are visible to other editors and which are not. —Kusma (talk) 19:09, 28 August 2021 (UTC)[reply]
But I agree that we have far too many banners (and many of them are useless). The whole Wikiproject and assessment stuff really should be in a "meta" area, not taking up space on a discussion page. —Kusma (talk) 19:16, 28 August 2021 (UTC)[reply]
@ProcrastinatingReader – I appreciate you sharing these thoughts. Comments and questions in response to the points you raised are below...
I assume we're talking about talk pages only here?
Yep, exactly.
if you see a protected page and want to edit it, the workflow on enwiki is via a talk page edit request. It's a pretty poor UI esp on mobile...
To confirm: are you referring to how people wanting to edit a protected page on mobile need to submit an edit request by way of starting a conversation on said page's talk page and that workflow not being straightforward? [i]
...the usefulness of the banners on many talk pages. They're a mess, like look at this. It wouldn't be reasonable to show it all to mobile users, and very often there is nothing useful in them IMO...Conversely, see here for a useful non-generic banner and toggle "read as wiki page" on and off to see it.
I've tried to put what you described into my "own words" to ensure I'm understanding this as you intended it. Can you please let me know if there is anything you would change in order for it to better reflect what you are communicating?
Peter's "own words": "Volunteers need to be able to display information to people, across devices, in ways that will enhance their understanding of: A) The subject page they are likely reading about and/or B) What to consider before participating on the talk page."
Also, these examples are great. Particularly the Talk:COVID-19 lab leak theory example. Thank you for sharing them; it's clarifying to be able to see what you are imagining in your mind.
---
i.The workflow for submitting an edit request as an anon volunteer on mobile, by my count, requires ~7 less-than-intuitive steps: 1) Click edit pencil, 2) Click the View source link that temporarily appears at the bottom of the page, 3) Scroll the page, 4) Locate and click the Submit an edit request button, 5) Scroll to the bottom of the talk page's source, 6) Draft a message, and 7) Post said message. PPelberg (WMF) (talk) 02:20, 2 September 2021 (UTC)[reply]
@PPelberg (WMF): I find the "new section" interface is pretty intuitive for new users. If that link could be more easily accessible, not just the talk page link, I think it would be more useful. I tend to use the &preloadtitle=Foo so that the subject line is filled with some default text, and I've found this useful for action links like leaving me messages about user scripts or questions about things from other projects. — Wug·a·po·des17:53, 28 August 2021 (UTC)[reply]
@Wugapodes: you sharing the experience you've had with, what we've been calling, the New Discussion Tool is helpful to know, especially as we approach offering as an on-by-default feature at the first set of Wikipedias in the coming weeks (see: phab:T271964).
If that link could be more easily accessible, not just the talk page link, I think it would be more useful.
Agreed...can you say a bit more here? What about its current location, how it appears, etc. do you think detracts from it's usefulness? Also: have you seen gadgets here, or on other wikis, that you think are effective at addressing the issue(s) that prompted you to share this feedback? For context: you sharing this is timely as well because we will soon be thinking about ways to make the affordance for starting new discussions easier for people to identify and access, regardless of where they are on a given page.
I tend to use the &preloadtitle=Foo so that the subject line is filled with some default text, and I've found this useful for action links like leaving me messages about user scripts or questions about things from other projects.
@PPelberg (WMF): You can see an example at User:Wugapodes/Capricorn#Feedback and bugs. The feedback link is created using the fullurl parser function which also allows you to specify the url query. So for that link, I have it add action=edit§ion=new to the url which opens the new section interface as well as preloadtitle=... which fills the subject line with the currentuser parser function so that the title is unique and I know who sent it regardless of whether they remember to sign. The full code for that link is {{fullurl:User_talk:Wugapodes|action=edit§ion=new&preloadtitle=Message%20regarding%20Capricorn%20from%20%7B%7Bsubst%3Acurrentuser%7D%7D}} At Wikipedia:20th anniversary we did something very similar for the "Say happy birthday" button. I set that button up so that it opened a specific section on the talk page that we made for the purpose, and it used &summary=Wishing Wikipedia a happy birthday to prefill the edit summary for readers.W/r/t the link placement, full disclosure, I use responsive monobook on my mobile so take my feedback with a grain of salt. At least as I've seen, the links on articles tend to just be to the talk page which for lots of readers doesn't mean much. Getting from article to talk post is a couple extra clicks in my experience. If the link were "ask a question" or "suggest an improvement" instead of (or in addition to) a talk page link, I think it would encourage more use of talk and depending on the phrasing make the posts more useful. — Wug·a·po·des07:08, 3 September 2021 (UTC)[reply]
Thanks for that info, PPelberg. At a glance, the issues summary you put together looks good and seems to capture the main points. {{u|Sdkb}}talk03:29, 2 September 2021 (UTC)[reply]
At a glance, the issues summary you put together looks good and seems to capture the main points.
Proposal: Split the biographies from the main vital articles
The biographies are in 3 levels. I think it would be beneficial to split them off into their own list with 5 levels rather than the current list. If you oppose this, I would like to know your thoughts on adding in-between levels such as level 3.5 or level 4.5. I look forward to your comments. Interstellarity (talk) 14:56, 27 August 2021 (UTC)[reply]
Oppose for the same reasons I and others opposed at the previous discussion. The Vital Articles lists are hard enough to maintain at their present size without expanding them further, and I've seen no justification for this other than as a way to create more room in (i.e. expand) the sets. {{u|Sdkb}}talk16:36, 27 August 2021 (UTC)[reply]
Oppose. As I see it, the main purpose of WP:VA is to identify sets of 100, 1000 and 10,000 articles which are considered the most important, to help endeavours like WP:The Core Contest, classify the quality of our most important articles, and also to give editors a hand in choosing which articles to prioritize for work. None of that benefits from splitting the list into people and non-people though. Rather, it just creates inconsistency with editors having to check both lists, with perhaps lower participation by those selecting the articles. Note that Wikipedia is not split along these lines in any other area - we don't have Featured articles / Featured people, or Articles for deletion / People for deletion. Finally, to address some specific points:
I can see the argument that biographies and non-biographies are hard to compare with each other as to which is more important, the same goes for any other diverse categories. Evaluating which of Jupiter, World War II, Clothing and Christianity is the most "vital" is almost meaningless, but the VA project still lumps them together.
It's been said that an advantage is the freeing up of 127 new slots for articles at level 3, but that's not something I think we want. Per Sdkb the lists are intentionally kept at specific levels, and if the 1000 level 3s are not enough then either look at level 4, or get consensus to expand it to 1200.
As for needing to classify people into 5 separate levels, I again don't see the need or rationale for that. Looking at Wikipedia:Vital articles/Level/5/People/Writers and journalists, I already don't know who the majority of those are, and I think they rightly represent the lower bound of vitality. Yes, they're important people, but anyone below that shouldn't be classified as such IMHO, and the exercise becomes increasingly unwieldy and arbitrary too. A desire to add a level 6 probably exists in other areas too, but I'd oppose that for similar reasons.
In summary, I think the VA process has worked well down the years, and this large-scale split down the middle wouldn't be beneficial. Cheers — Amakuru (talk) 08:07, 28 August 2021 (UTC)[reply]
Comment: I am neutral on this, but the project pages should be placed under Wikipedia:WikiProject Vital Articles if it is needed to get rid of unnecessary essay templates. They are unintentionally undermining, they don't encourage to edit pages when the opposite is needed. Interstellarity's project has already been useful. Currently Level 5 needs more development and alternative listing would be useful in finding the most vital biographies and for example listing them alphabetically. --Thi (talk) 15:42, 28 August 2021 (UTC)[reply]
Add Albanian Wikipedia to the bottom of English Wikipedia page - section 50.000+ articled
Requirement of 2 votes for template deletion. I understand most experienced editors avoid deletion talks like a plague ....but...Think we need a basic number of votes for template deletion. As of now we have many templates deleted by 1 vote...in many cases that 1 vote is by an editor here editing for only a year or so.--Moxy-20:03, 30 August 2021 (UTC)[reply]
Bad idea. A ton of TfDs are rubber stamping following cleanups like migrations of rail templates to Module:Adjacent stations. Sometimes they have no participation but it's obvious to a closer how they'll go, given years of precedent. Closers are qualified to evaluate how contentious a deletion is likely to be. Same principle applies at AfD (see WP:SOFTDELETE). Is there actually any evidence of a problem here, such as links to DRVs showing TfDs closed in this manner reached incorrect decisions and thus were overturned? ProcrastinatingReader (talk) 20:09, 30 August 2021 (UTC)[reply]
Agree with proc. A lot of TfDs don't get any votes, and like AfD and RfD, those can be deleted after a week. Of course, I think most admins would be willing to undelete upon request if the consensus is very weak. Elli (talk | contribs) 20:12, 30 August 2021 (UTC)[reply]
Proc said it well. A ton of TfDs are completely uncontroversial with many similar deletions occurring in the past with more discussion. These are often unused and not used on hundreds or thousands of pages like most of the templates that editors know about. If you have concrete TfDs you have issues with I'm sure the regulars are willing to discuss or change as appropriate. While there are a lot of problems with having a quite small pool of closers it does make changing norms a lot easier. --Trialpears (talk) 20:28, 30 August 2021 (UTC)[reply]
Oppose. Agree with Proc's analysis of the situation. Also, strictly speaking, there are no votes in deletion discussions. Editors make recommendations, and the closing party decides based on quality of arguments as well as quantity. —C.Fred (talk) 20:32, 30 August 2021 (UTC)[reply]
Oppose I guess per above. It the closers are admins, they're probably pretty good at figuring it out. Just treat it like a PROD I guess... somebody nominated it, nobody objected after a fair amount of time, the admin can deleted BUT use her discretion not to, and anyway yea undelete upon request in a case like that. I guess. Herostratus (talk) 00:47, 3 September 2021 (UTC)[reply]
Add a contact us button and a help button to the mobile view
I've found that newbies make good use of the growth team features for essentially this purpose. I agree we should look into expanding its use if possible. — Wug·a·po·des20:28, 1 September 2021 (UTC)[reply]
The proposed contact us link would link to Wikipedia:Contact us and the help link would like to Help:Contents. In the mobile sidebar (the image to the right), I think both links are best placed next to the About Wikipedia and Disclaimers link. I'm not sure if it can be technically implemented by English Wikipedia editors, but I hope I provided enough information on this in detail. Interstellarity (talk) 18:19, 1 September 2021 (UTC)[reply]
There does not appear to be anywhere for us to do this locally, you could start by inquiring with the mobilefrontend developers to see if: (a) project-specific sidebar links could be supported here such as they are on the webui; (b) possibly if project specific parameters would be supported here; (c) if this is something they would want to incorporate in to the master extension. — xaosfluxTalk18:53, 1 September 2021 (UTC)[reply]
Proposal to expand trial of Growth team features
Hi everyone – I'm Marshall Miller, the product manager for the Growth team at WMF. Over the past three years, the Growth team has been developing a set of features meant to improve the experience for new editors. The goal of our work is to help newcomers make successful first edits, instead of them leaving from frustration or confusion. Thank you to the many community members who participated on this page and helped put together this proposal!
Following a VPR discussion in April 2021, the features have been applied to 2% of new accounts as a trial. The community members following along have agreed that the initial trial has had positive outcomes, and so we now propose increasing the share of new accounts receiving the features from 2% to 25% (with some caveats).
The Growth features aim to guide newcomers as explained on the project page. The most important elements are:
Newcomer homepage on English Wikipedia
Newcomer homepage: a special page with useful actions that newcomers are encouraged to visit immediately after account creation.
Suggested edits: a feed of articles that have maintenance templates such as {{Advert}} and {{Underlinked}}. Newcomers can choose topics of interest to filter the feed, like "Fashion", "History", or "Physics".
Mentorship: newcomers are assigned a mentor from a list of experienced volunteers. A pop-up form helps them submit a question to their mentor's talk page using a simple interface. Whereas Adopt-a-user is meant to be an enduring connection for a newcomer, "mentorship" in the Growth features is meant for quick questions.
Help panel: when the newcomer is editing an article, the help panel is like a collapsible mini-homepage, providing relevant help links and the ability to ask mentor questions.
Help panel on English Wikipedia
The Growth features are now on 50 Wikipedias, including large ones like French, Spanish, Russian, and Portuguese -- and with German and Dutch Wikipedias having recently started trials. Evidence shows that the features improve newcomer engagement without burdening communities.
In April 2021 we discussed testing the features on the English Wikipedia at this page. We started giving the features to 2% of new accounts in June (about 2,000 new accounts per month), and posted data and results after a month. There were two main outcomes:
The "suggested edits" feature seems to be leading to many good edits with low revert rates. During the test period in June, the revert rate was 9% (with the baseline revert rate for newcomer edits that month being 27%). To date, 2,325 article edits have been made. Many users do dozens of these edits. You can see these diffs by filtering to the "newcomer task" edit tag in Recent Changes.
The "mentorship" feature yields some good questions and some low-quality or nonsense questions. To date, there have been 329 questions asked to the 22 mentors who have signed up. We're still discussing how best to scale up the mentor capacity and how to encourage high-quality questions. You can see these diffs by filtering to the "mentorship module question" and "mentorship panel question" edit tags in Recent Changes.
We think the next step is to give the Growth features to 25% of new accounts for one month (about 25,000 new accounts). The exception would be the mentorship features, for which we have open questions mostly discussed here. We want to increase the share of newcomers getting mentorship to only 5%, so as not to overwhelm the mentors. We would run this phase of the test for one month, and then bring the results back here to decide whether to further increase the share of newcomers with the features. In looking at the data, we will think about these questions:
Revert rate of suggested edits. Are high-quality edits being generated without an undue burden on patrollers?
Volume of mentor questions. This would allow us to extrapolate how many mentors would be needed to handle 100% of new accounts, or how the mentorship features might need to be improved to handle increased volume.
Quality of mentor questions. Are there improvements we could make to the features to help newcomers ask useful questions?
We're interested to hear any questions, ideas, or concerns -- and we're hoping there's general support for moving to this next phase of testing the Growth features. We also are looking for about 20 more people to sign up as mentors to handle the increased volume of questions that will come in with the next phase. Mentors should expect to get 3-4 questions per week on their talk page. You can learn more about that and sign up on this page. Thank you! -- MMiller (WMF) (talk) 23:33, 2 September 2021 (UTC)[reply]
I like the "Your impact" section. It can be really discouraging when you're starting out with something new to not get any feedback on whether what you're doing is making a difference. I'd be interested to learn more about what goes into picking the suggested edits, but certainly the idea of presenting a newbie with specific things they can do right now is great. And I like the tinder-esque "swipe left, swipe right" U/I in the mockup. -- RoySmith(talk)00:00, 3 September 2021 (UTC)[reply]
Thanks for checking things out, @RoySmith! Seeing your questions made me realize I should have posted instructions for how anyone can turn on the Growth features and try them out. You can do it with these instructions.
About your comments and questions: I'm glad to hear that you think the Impact module is on the right track. The goal is to help newcomers have that realization that editing Wikipedia is valuable and exciting. It's definitely really rudimentary right now, and we're planning to make it more powerful in the coming year (we'll eventually be posting ideas on this currently barebones page).
In terms of suggested edits, we want newcomers to find interesting pages that need easy edits, so they can quickly have success on the wiki. We're currently sourcing them through maintenance templates, like {{Advert}}, which is one of the templates we draw on to find articles for the "copyediting" task. You can actually see (and edit!) exactly which templates are used for which type of task through a new Special page we created to enable community members to configure the Growth features: Special:EditGrowthConfig. With this page, much of the control over how newcomers experience the Growth features is in the hands of community admins.
Beyond the user-applied maintenance templates, we've been experimenting with creating suggested edits algorithmically. One way that's currently being tested on several wikis is called "add a link", which uses an algorithm to suggest words and phrases that could be made into wikilinks. It's going well so far, and the details are here on this project page. And in that vein, we're also building a first attempt at a task that suggests images that could be added to unillustrated articles. That one has many more open questions and risks, and so we hope to hear from more community members on its talk page.
And in terms of allowing users to choose topics of interest (e.g. "Music", "Sports", "Europe"), those come from a machine-learning model that tries to assess which topics an article is about based on the words used in it. It is trained using WikiProject tags from English Wikipedia, and tends to be pretty accurate. The information about how that model works is here.
Support the increase to 25%. MMiller and the rest of the Growth team have done an exemplary job collaborating with us in the community on the development of these features, and as summarized above, the results have been very promising so far. This rollout is suitably cautious and will allow more newcomers to benefit from them while giving us more information to inform the final launch. {{u|Sdkb}}talk00:20, 3 September 2021 (UTC)[reply]
Support - MMiller and his team have both an excellent project and have been doing a fantastic job at working with the community, adapting to our specific requests (one example is they added the functionality to decouple the % getting the Growth panel and the % getting mentors to adapt to our trialling wishes). I think this is a great next step in rolling it out, and will give enough trial data to better predict benefits and risks. Nosebagbear (talk) 00:53, 3 September 2021 (UTC)[reply]
According to the current tally, the number of articles with link rot issues slowly but steadily approaches the 300K mark. Even though that's less than 5% of the English Wikipedia and mostly we deal with articles that have most of the citations being all right, I believe that becomes quite a problem when we have articles referenced to a page which can't be found on any archive, and in particular favts referenced to that source. The info, in that case, might require update, deletion (based on WP:V or WP:BLP concerns) or simply we might need to change the link in the reference, none of which can be handled by bots alone. This is also an area which seems not to be particularly touched by Wikipedia editors in general, as this is simply routine maintenance of encyclopedia instead of badges/honors connected with the more pleasant parts.
Since this is my first post at Village Pump, please assure me this is the proper venue for that proposal (or else redirect me to another forum), and, of course, I'd like to hear your opinions on it. Szmenderowiecki (talk) 14:40, 3 September 2021 (UTC)[reply]
Thanks for the idea, Szmenderowiecki! This village pump is used for proposals like this all the time, so you're at the proper venue. Resolving link rot is certainly a plus, so anyone who helps resolve it is doing good. I wouldn't say it's our most urgent backlog, though, as it's less severe than {{Citation needed}} (dead references at least likely supported the material, even if they're no longer verifiable, whereas citation needed references mark totally unsupported material) and we're never going to get through the citation needed backlog without radically increasing the number of editors.
One thing I'm wondering is where the more recently tagged instances of link rot are coming from, as Internet Archive is theoretically supposed to be archiving every outgoing link from Wikipedia. Are they old links from before IA was doing that, or editors mistaking links as permanently dead when actually they're available through IA, or is IA failing to capture everything? {{u|Sdkb}}talk18:55, 3 September 2021 (UTC)[reply]
Probably all those things. Systematic saving of links at Wayback and Archive.today wasn't done prior to about 2012. Current save methods are not 100% for a couple reasons. Some percentage of {{dead link}} tags are resolvable but a bot or person has not done so yet. IMO a bigger problem is false negatives ie. links that are dead but not marked or being saved by the bots due to soft-404s and other issues. The methods we are using are problematic. The solution is every link is born archived ie. the archive URL is part of the rendered page automatically, no bots. -- GreenC19:37, 3 September 2021 (UTC)[reply]
Not done for now: please establish a consensus for this alteration before using the 
, left of "Advanced" in some toolbars (not the pencil icon on the far right). If "New wikitext mode" or "Automatically enable all new beta features" is enabled at Special:Preferences#mw-prefsection-betafeatures then it is available on the menu icon 
. —TheDJ (talk • contribs) 08:11, 17 August 2021 (UTC)
20:03, 30 August 2021 (UTC)
