Jump to content

Wikipedia:Village pump (proposals)/Archive 177

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215

RfC: Pronouns placed in signature for new users

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.
No change. — Preceding unsigned comment added by Theleekycauldron (talk • contribs) 09:20, 3 March 2021 (UTC)

Should we add pronouns to the signatures of new users? Should we add pronouns to the signatures of old users? What format should these pronouns be in, if they are added?

Options for new users:

A: Add new pronouns to signature automatically when they sign up, choosing their pronouns in the sign-up screen.
B: Give new users the option to add their pronouns to their signature when they sign up
C: Do nothing, do not give users the option to easily add their pronouns to their signature.

Options for already existing users:

A: A drive to encourage Wikipedians to add their pronouns to their signature in the way they choose
B: Automatically affixing the pronouns on file to the end of the signature
C: Not encouraging users to add pronouns to their signature

Options for format (using they/them as an example):

A: (They/Them)
B: (they/them)
C: [they/them]

theleekycauldron (talk • contribs) (they/them) 23:35, 1 March 2021 (UTC)

Meh... You are overthinking it... those who care about their pronouns usually let others know their preference. Some put it on their user page (so it is a good practice to check), most simply correct you (politely) if you use something “incorrect”. As long as we respect another editors wishes when informed of their desires, we all get along. Blueboar (talk) 00:49, 2 March 2021 (UTC)
I agree with Blueboar. But a real problem (for me) is that I am now forced by the software to choose between they, she and he, which is really irritating. I don’t care how people refer to me, but that I am forced to choose between a gender and “they” is off. No choice, or prefer not to say, should be an option in the preference settings. SandyGeorgia (Talk) 00:54, 2 March 2021 (UTC)
  • Just for ease of use, I think we should have an option in preferences that helps editors add pronouns to their signature, but I'm suspicious of going further than that. There are risks to identifying as a non-cisgendered man (i.e., woman, non-binary, or trans man) on the internet, and without advising new editors of that reality, we should avoid encouraging editors to reveal personal info they may one day wish to take back. Of course, we should allow them to make that decision, and even make it easy once they have come to a decision, but we should not force anyone to reveal information about themselves that could put them at risk of harassment. For that reason, I think adding pronouns to the signatures of new users automatically is a bad idea, and even having an option at sign-up is something to avoid. For existing users, we should not add pronouns automatically. Personally, I have gender neutral references set in my options, but I'm fine with editors using any pronouns to refer to me. Adding pronouns automatically to my signature would make it seem as if I want editors to use "they" exclusively when that is in fact not necessarily the case. I also like my signature as it is and don't want others futzing with it unless it's breaking something. As for how to format pronouns in signatures, I would avoid using square brackets or curly brackets since those are used to denote links and templates and could cause problems with the software or bots. I don't care about the capitalization. — Wug·a·po·des​ 01:14, 2 March 2021 (UTC)
  • Pretty much what Wugapodes said. I would support making it easier for those who wish to add them to do so, but do not support making it mandatory. I'm not even sure what I would choose, as my pronouns vary situationally. --Khajidha (talk) 01:29, 2 March 2021 (UTC)
  • I don't think this is a good idea for a two main reasons:
    1. Not every user wants to reveal this information - especially those are typically targets of online harassment for their gender - and including this in a sign-up form makes the implication that gender revealing is required, no matter clearly worded otherwise; and
    2. Pronoun selection is not a simple enumeration; pronoun policies are far more complex than a trinary of he/she/they. The correct way to handle this is as a free-form field, but in English alone a pronoun has multiple forms, so we'd have to provide multiple fields, which makes for a UX nightmare
    The reasoning behind this is good faith, but I just don't think it's achievable in the way the OP is wanting.--Jorm (talk) 01:45, 2 March 2021 (UTC)
  • I find myself agreeing with Jorm in large part here. The implementation of this, if done correctly, would simply be another free-form field for users to put things in... and those who know how to find and use it would likely be those who can handle adding them to their signature manually if they really want them there. I also do not want to get into this idea that people should "have" to or even be encouraged to display a set of pronouns - there are many people who wish to be referred to as different pronouns depending on the situation, and people shouldn't feel like they need to reveal information that for some people is hard to reveal. I am especially worried that non-cis-gender editors (or those who use other pronouns) will be caught between a rock and a hard place - using their preferred pronouns and the potential harm that could come from that, or using non-preferred pronouns and having to see them often. TLDR: People who want their pronouns in their signature can do so already, and I do not see any policy based reason they can't go manually add it now. I am undecided on an alternative to have an option in settings - if this were implemented, I think it needs to be optional, and the viewing of pronouns in signatures should be opt-in - i.e. they should not automatically appear. Again, this is because if it was mandatory or built in, people would be harmed by that. Not to mention that we can simply talk to each other - hell, people don't even know whether I'm a male, female, non-cisgender/non-binary (I can't include all options here, obviously), etc. I have had multiple editors refer to me as a she based on my username, and I've had others refer to me as a he based on my username, and I've had a few people refer to me as "they" as an attempt to be respectful of not knowing my preference. If I had a strong feeling, I would simply just send a simple reply to the person stating my preferred pronouns and requesting they attempt to comply. And that's how it should continue. -bɜ:ʳkənhɪmez (User/say hi!) 01:54, 2 March 2021 (UTC)
  • No change per above. As stated, we need to avoid making it seem like revealing one's gender is an expectation or imperative, and then some people either have to misgender themselves or reveal something about themselves they may not be comfortable revealing. And really, adding these to one's signature is already very easy if one is so inclined. One's "preferences" at the top of the page, when clicked, has a field where it's easy to type them in as part of the signature. Editors can also reveal their gender on their userpage, as many do. Crossroads -talk- 06:17, 2 March 2021 (UTC)
    I also oppose any text in guidelines that mention this practice. For Wikipedia to seem to engage in WP:ADVOCACY for this practice is extremely inappropriate. And given the real-world advocacy for it, any statement on it is inherently suggesting it be done and thus joining-in the exerting of social pressure. Again, typing them in that box in preferences is very easy and needs no specific instruction, and people can already easily write something on their userpage if they wish. Crossroads -talk- 06:00, 3 March 2021 (UTC)
  • No change (C and C) per Wug and others above. Editors very much ought to learn to stop using the male default, editors who use the male default should be gently reminded not to do so, and editors who choose to specify pronouns in their signature should certainly be welcome to do so. However, I don't think that calling attention to editors' genders by making pronouns default would help us build a better encyclopedia, and indeed I could see it possibly worsening harassment against non-male editors by making them stand out. I think the status quo of using singular they by default works fine. {{u|Sdkb}} talk 07:14, 2 March 2021 (UTC)
  • No change This seems like a solution looking for a problem. The above comments offer a buffet of good reasons why this is a bad idea, so I won't rehash them. Dennis Brown - 2¢ 11:56, 2 March 2021 (UTC)
  • No change At Preferences → User profile I have deliberately left "How do you prefer to be described?" set to "They edit wiki pages" (IIRC the gender-neutral option was "I prefer not to say" until about 2014/15). In discussions, some people use a gender-specific pronoun when referring to me and a proportion of those people get it wrong: I never correct them. Curiously, people who have actually met me rarely use a gender-specific pronoun for me. Even so, I find it amusing when people flip a coin and it falls wrong-side up. --Redrose64 🌹 (talk) 14:12, 2 March 2021 (UTC)
  • No change I'm opposed to encouraging adding extra wikitext to every signature for this, if someone wants to do it for themselves then whatever, but we shouldn't encourage it. I'd be strongly opposed to any sort of requirement that all old wikitext signatures needs to be edited to add/change for something like this - or if someone decides to change from "he" to "they" and back in the future. As far as the preferences section about what terms someone prefers in the interface, SandyGeorgia while it does say "they", "he", or "she" - you shouldn't be running in to much (any?) occurrence of actually seeing 'they' by the software are you? I tend to use singular they when referring to other editors when I type something about them (if they do not specify a preference) just because it is how I use natural language otherwise. @Theleekycauldron: are you aware that an editor's opt-in to request certain descriptors is already public and can be seen on tools like popups when you hover a user's linked name? — xaosflux Talk 16:04, 2 March 2021 (UTC)
    @Xaosflux: I don’t know; I don’t know where these preferences are used, or how they may be affecting what others see about me. It bothers me as much to be a “they” as it would bother me to be expected to reveal gender. I suppose my concern is how this preference setting might eventually be used, if it is not now. All I know is I am not allowed to not say in preferences. SandyGeorgia (Talk) 17:03, 2 March 2021 (UTC)
    @SandyGeorgia: I'll follow up on your talk. — xaosflux Talk 17:06, 2 March 2021 (UTC)
  • No change (C/C) We absolutely shouldn't be requiring the addition of pronouns to every signature for multiple reasons - the technical/pragmatic (i.e. the extra wikitext will only serve to clutter up talk pages, and any kind of automated solution would require developer time that is sorely needed elsewhere), and the 'political' (i.e. we shouldn't require anyone to disclose anything they're not comfortable with). ƒirefly ( t · c ) 16:16, 2 March 2021 (UTC)
  • Nothing mandatory - English Wikipedia has users in many countries and places where revealing one's non-binary gender opens them to persecution or real physical danger. We cannot force users to do this. As for encouraging users who wish to do so, writing up a guide would be a good first step, before we talk about how to promote it. This would include: how to set your gender pronouns in the software, how to add code to your signature to display your pronouns, and how to find/use the templates (like {{he or she}} and {{they}}) which fill pronouns from a user's software gender setting. And how about a category of users willing to prepare code for less technically proficient users? I'd be willing to help write such a guide. Ivanvector's squirrel (trees/nuts) 16:20, 2 March 2021 (UTC)
    To Jorm's point about free-form pronouns: I think you're overthinking it. In general you can get away with three fields: the third-person subject (he/she/xe/they), the third-person object (him/her/xem/them), and (really optionally) the third-person possessive (his/hers/xyr/their), at least as far as doing things automatically; other forms can be derived manually. The site pronoun.is demonstrates this pretty simply (see for example the site's entry for singular they). I don't know how big of a project this would be and the devs probably have more important things to do already, but I think this is the simplest approach if software changes are on the table. Ivanvector's squirrel (trees/nuts) 16:37, 2 March 2021 (UTC)
    I really like the idea of guidance on how to do this, and I could imagine putting some text in WP:SIG to the effect of
    Some editors choose to include their personal pronouns in their signatures using a structure like [[User:Example]] ( [[User talk:Example|talk]] · they/them ) 20:42, 2 March 2021 (UTC).
    Even if this discussion results in no action on the software side (as seems likely), I would like the closer to summarize community sentiment around this practice so that we can draft some accurate text for guideline pages. For that reason I hope this doesn't get SNOW closed. — Wug·a·po·des​ 20:42, 2 March 2021 (UTC)
  • No change can't see why this is needed or helpful when neutral pronouns exist that are quick and easy to use. It also makes the signatures longer and more confusing. I prefer that editors are judged by there edits and attitude and avoid any bias/accusations based on non-contributing attributes. KylieTastic (talk) 16:27, 2 March 2021 (UTC)
  • No change I encourage and support (personally) any user who feels comfortable doing so to create a custom signature to add their pronouns to it. I think that is perfectly allowable, and every user who wishes should feel comfortable doing so. I see no benefit in forcing or encouraging people who do NOT feel comfortable doing so to basically make it required and/or mandated and/or heavily encouraged that they do so. I have not seen anyone be chastised for voluntarily putting their pronouns in their signatures, and if they were I would be there to defend them every time; however I don't think we need to mandate these things. --Jayron32 17:12, 2 March 2021 (UTC)
  • I have no desire to find out about the contents of other Wikipedians' underwear, nor whether they're happy with the manufacturer fitted equipment, nor whether they've modified it, nor what they do (or don't do) with it. I'd rather keep my equipment out of the conversation too. Cabayi (talk) 17:31, 2 March 2021 (UTC)
  • No change Users can edit their signature to be (almost) anything — adding (they/them) etc. is already possible — GhostInTheMachine talk to me 17:35, 2 March 2021 (UTC)
  • No change (after a discussion on my talk with Xaosflux, who helped me understand how the current preference settings are used[1]). SandyGeorgia (Talk) 17:54, 2 March 2021 (UTC)
  • No change A distraction. The less known about the intimate identity of users, the better. An author who cares that much about such things should probably be writing elsewhere. Rollo (talk) 22:18, 2 March 2021 (UTC)
  • No change defaulting to add pronouns to signatures placed in Wikitext will not improve Wikipedia. I believe editors can enable a tooltip (like popups) to view the information now. power~enwiki (π, ν) 22:23, 2 March 2021 (UTC)
  • Nothing mandatory. We should make it trivially easy for people to add their pronouns, if they want to, and make sure that people know how to do this, if they want to, but we should not not push anybody into either doing it or not doing it. Personally, I would, but then my pronouns are he/him, which are the one set that are least likely to attract any unwanted attention. I have the specifically cis male privilege to be able to do this without risk. I can easily understand why other people, with other pronouns, might be far more wary. --DanielRigal (talk) 22:44, 2 March 2021 (UTC)
  • Oppose, We have the right to self-disclose, and likewise we have the right not to. There's plenty of existing infrastructure in MW for discerning how to refer to a user - some of us do choose to disclose, but having it forced upon me would seem incredibly condescending. -- a they/them | argue | contribs 07:24, 3 March 2021 (UTC)
As a non-binary person, i completely agree– but i do think it should be much more accessible to add pronouns to a signature. theleekycauldron (talk • contribs) (they/them) 09:19, 3 March 2021 (UTC)
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.

User pages

In my opinion it would be better to allow the edits of the user page and its sub-pages only to the "page owner" For example, if user X creates his page, only he will be able to edit it --Dr Salvus (talk) 15:15, 25 February 2021 (UTC)

There are many reasons why non-"owners" would want to edit such pages. Userfying articles. Moving AfC drafts. Tagging for deletion. Tagging socks. Fixing syntax errors. Disabling mainspace categories. Removing fair use images. Removing offensive content. Removing copyright violations. The user may be an alternate account. It may be a bot account. It may host a public page/list for editing/maintenance. And then there's user talk page archives. Etc. etc. —  HELLKNOWZ   ▎TALK 15:21, 25 February 2021 (UTC)
Note that non-autoconfirmed users are already prohibited from editing userpages via an edit filter. I don't believe there's any reason why user pages should be restricted in such a manner, there are plenty of reasons (as articulated above) to edit pages in someone else's userspace. — csc-1 20:49, 25 February 2021 (UTC)
Would be totally against existing community consensus at Wikipedia:Ownership of content and Wikipedia:User pages#Ownership and editing of user pages. As mentioned, there's already an edit filter to prevent vandalism by unconfirmed editors to user pages that are not their own. ✨ Ed talk! ✨ 21:06, 25 February 2021 (UTC)
In the past year, I've seen this proposed thrice here. Why not make it a WP:PERENNIAL proposal? 🐔 Chicdat  Bawk to me! 11:54, 1 March 2021 (UTC)
  • Are we including all pages within a user’s USERSPACE (the primary user page, its associated talk page... as well as any draft/sandbox pages and their associated talk pages) or are we limiting this discussion to just a user’s primary page? Blueboar (talk) 13:34, 1 March 2021 (UTC)
  • That goes against the spirit of the WP:Five Pillars, so I don't think that is a good idea. Dennis Brown - 2¢ 11:59, 2 March 2021 (UTC)
  • As said above their are many valid reasons not to lock down this much - I would support a block on anonymous/ip editors editing others user-pages (other than talk) as this by far the most disruptive and they could report copy-vios, abuse etc to many other places to resolve issues if required. KylieTastic (talk) 16:35, 2 March 2021 (UTC)
  • No way. If a user makes a non-constructive change to your userspace, it's easy enough to revert - and they can be blocked for vandalism. Many users do things such as running polls in their user space, or essays which don't mind other users making edits to. Possibly limiting it to autoconfirmed users can be reasonable - I'm pretty sure new users can't make new pages in other peoples' userspace. Additionally, admins are generally willing to protect userpages from what I've seen. Elliot321 (talk | contribs) 20:34, 3 March 2021 (UTC)

Class date stamps

Several articles have on the talk page a label of quality in the form of Class levels. However, it is quite difficult to find out when the assessment was made and often the assessment may be several years old and not corresponding to the current level of the article. Would it be possible to add a time stamp on these assessments (in the same way as for the templates indicating need of editing in the article itself)? Ideally, this would be done retroactively with robots going through and adding time stamps to all those assessments already made. --Olle Terenius (UU) (talk) 11:17, 16 February 2021 (UTC)

Hmm, interesting thought! The benefit would have to be weighed against the potential for watchlist clutter. I think the first reform that needs to happen with quality assessments is getting them unified to one per article, rather than having one per project per article. {{u|Sdkb}} talk 03:14, 17 February 2021 (UTC)
Not that I have any clue or involvement in article-assessing projects whatsoever, but wouldn't such a unification be potentially difficult, esp. when there are more than just a couple projects involved? I mean, consider the (currently fictional) article Military music of Poland as a hypothetical case. The Polish project is happy with it and assesses it highly, but the Music project folks see that it's missing a bunch of the necessary music, um, stuff they require. The Military crew might have a third opinion of the quality of the article. And again, I have no idea how realistic this scenario is. — JohnFromPinckney (talk) 03:30, 17 February 2021 (UTC)
[Edit conflict] While I can see some people don't like cluttering talk pages with multiple assessments, it's common for different projects to have different standards and for one project's material to be well covered while another one's is lacking. How would we decide whose opinion prevails? Also, if the assessments were unified, what would happen to the importance assessments, which clearly differ between projects? Espresso Addict (talk) 03:38, 17 February 2021 (UTC)
I think it makes sense to keep the multiple assessments. As said, different topics in the article may have very different levels of coverage and/or quality and it would help the person editing the article to know where to put the emphasis. --Olle Terenius (UU) (talk) 11:41, 4 March 2021 (UTC)
I mostly agree with this, but some projects (like the military wikiproject) do their own assessment (eg A class ratings). That would have to be allowed to continue. But most projects are not really that active or well organised as MILHIST, and most ratings are not even done by WP members but just page patrollers etc. So something should improve about the system, probably. ProcrastinatingReader (talk) 05:26, 18 February 2021 (UTC)
Per-wikiproject assessment is dead, and should simply be deprecated. It is already formally overwritten for GAs and FAs, and I'm not sure it ever happens outside of MILHIST A-class. If MILHIST rates an article as A-class, that rating should apply to the quality of the article as a whole, and could receive a single timestamp much as GA and FA currently do. CMD (talk) 07:21, 23 February 2021 (UTC)
  • This sounds like a good idea, and if it could be done by bots, it might not prove too difficult to do. Rollo August (talk) 09:18, 20 February 2021 (UTC)
  • Support. I agree with CMD and some of the other comments. It's interesting that there is a formal process for GA and FA but when it comes to the ratings B and C it's very loose and we allow multiple ratings to co-exist on the talk page, given by different WikiProjects, potentially. We wouldn't allow that for GA and FA, so why for B and C? Also, I like that information called "milestones" that is available for the FA articles, see e.g. for "sea" here. It might only be a small technical change that would be useful would be to indicate when the last assessment was made (if it's too difficult to do it retrospectively, it could just be done from now on). So that if I come to an article and it says C on the talk page, I can see immediately when the C rating was provided, and by whom. If the rating was 5 years old then it might spur me into action to check if the rating needs updating. EMsmile (talk) 01:28, 4 March 2021 (UTC)

What should we do with the links to Commons in categories? Mike Peel (talk) 09:23, 12 December 2020 (UTC)

Hi all. We currently link from categories here to Wikimedia Commons categories using {{Commons category}}. Over the last few years, we have been working on synchronizing the links to Commons categories between enwp and Wikidata, and for the Category namespace these are now fully synchronized. These links use sitelinks on Wikidata, which are robust against vandalism (a Commons category has to exist to sitelink to it), and these also match the sidebar link to Commons. They are also used to display links back to enwp from the Commons categories (both in the sidebar and the infoboxes there).

In 2018 I posted an RfC to switch to using Wikidata for interwiki links to Wikimedia Commons, which led to conditional approval to implement the changes here, and the creation of a new set of tracking categories at Category:Commons category Wikidata tracking categories. A subsequent RfC in 2019 on removing locally-defined links to Commons categories if they match the Wikidata sitelinks resulted in no consensus to remove locally defined links to Commons.

I would like to revisit this as it applies to categories only (i.e., this proposal does not apply to articles). At some future point this may also be applied to articles, but for those we need to fix the issue that causes Commons sitelinks to not appear in the sidebar (on the Community Wishlist Survey 2021), and there are ~15k articles that aren't synchronised to Wikidata yet (cases with e.g., multiple, mismatched, or misplaced links) out of 560k articles. These are not issues for links in the Category namespace, which are now fully synchronized with Wikidata.

Changes to current links

I suggest the following options for the use of {{Commons category}}, which would only apply in the Category namespace:

A1. Remove {{Commons category}} and just have the sidebar link. This is the easiest option to maintain here as MediaWiki will automatically display it where available. This would affect around 310k categories (the tracking categories listed in A2 and A3). An example of how the Commons link would look like after this change is Category:1817 in Vermont.
A2. Remove the locally defined links from categories, i.e., {{Commons category|Example}} -> {{Commons category}}. This is the second easiest to maintain, as e.g., renames of categories will be automatically updated. Manually defined links would only be removed where they match the Commons sitelink on Wikidata, so this would also allow local overrides. This would affect around 290k categories at Category:Commons category link is on Wikidata. An example of how the Commons link would look like after this change is Category:Data modeling.
A3. Always locally define the link, i.e., {{Commons category}} -> {{Commons category|Example}}. This is the most difficult to maintain, as it requires bot or manual edits when the link changes. This would affect around 20k categories at Category:Commons category link from Wikidata. An example of how the Commons link would look like after this change is Category:Bodies of water of Lebanon.
Adding new links

I also propose:

B. Bot-adding {{Commons category}} where a Commons category sitelink is available on Wikidata

Many links have been added between Wikidata and Commons over the last few years (now totaling over 3 million links). If we go for (A2) or (A3) above, then bot-adding them would significantly increase the number of links to Commons. These links are already available in the sidebar, so if we go for (A1) above then this isn't needed. Mike Peel (talk) 19:52, 11 December 2020 (UTC)

Discussion (Commons category links)

I suggest !voting for A1, A2 or A3 and saying yes/no to B. If we reach consensus for any of these options, I will code a bot to implement it and propose it at Wikipedia:Bot requests for final discussion before implementation. Thanks. Mike Peel (talk) 19:52, 11 December 2020 (UTC)

It's not clear from the RFC as written which options would still allow us to customise the displayed text and whether we could link to multiple categories, both of which are something that arises fairly often (Commons has a slight tendency to split categories so we want to provide links to more than one, and has a very strong tendency to give categories really peculiar names which don't tally with the English common name). I'd be strongly inclined to reject any option that wouldn't allow us at minimum to add explanatory text to the link (e.g. for an biography of an architect, have one link for portraits of the subject and one link for images of their buildings, clearly labelled which is which). ‑ Iridescent 20:15, 11 December 2020 (UTC)
@Iridescent: Those are rare occurrences in categories (but somewhat more common in articles, which is out of scope for this RfC). I can implement something for A2 that will continue to allow customised display text if really necessary, but that can easily be used to mislead the reader. Linking to multiple categories never makes sense anyway, since you can either link directly to the appropriate category from "Category:Buildings by X", or just link to 'Category:X" for the architect, and readers can then look at the subcategories on Commons for the rest - or you can improve the categories in Commons. Thanks. Mike Peel (talk) 21:02, 11 December 2020 (UTC)
P.S., are those intentionally missing links noted/explained somewhere, please? If not, perhaps they could be noted somehow? Thanks. Mike Peel (talk) 21:34, 11 December 2020 (UTC)

@Mike Peel: what is your brief and neutral statement? At over 4,500 bytes, the statement above (from the {{rfc}} tag to the next timestamp) is far too long for Legobot (talk · contribs) to handle, and so it is not being shown correctly at Wikipedia:Requests for comment/Wikipedia technical issues and templates. --Redrose64 🌹 (talk) 23:37, 11 December 2020 (UTC)

@Redrose64: The title was kinda the summary, I've paraphrased it just below the RfC tag for the bot. Thanks. Mike Peel (talk) 09:23, 12 December 2020 (UTC)

Just to note, I've posted a neutral note about this RfC at commons:Commons:Village_pump#Commons_links_from_enwp_categories (diff), since this directly relates to Commons. Thanks. Mike Peel (talk) 20:11, 12 December 2020 (UTC)

Survey (Commons category links)

Commons category links should be removed (or not added) except where a manual override is necessary to link properly to Commons. A summary precedes the discussion. — Wug·a·po·des​ 19:38, 5 March 2021 (UTC)

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.

To start, there's a consensus against A1 so we should not not remove {{Commons category}}, but instead have it in addition to the sidebar link. Editors give a number of reasons for this, but the main points are that mobile readers cannot see our sidebar (making the commons cat template their only link) and desktop readers do not pay much attention to our sidebar (making the commons cat template their primary interwiki link). This opinion is not unanimous, and the three editors in support of removal point to the reduced maintenance burden (why maintain a whole template when the links are there automatically) and hope that removal might pressure MediaWikians to improve the mobile interface.

There is a general consensus in favor of A2 so manually defining the Commons category name should be removed or not added, but with the important caveat that manual overrides be used when the automatic links do not fit our needs. Editors in support point out the reduced maintenance cost as links would not need to be manually changed (or break) when Commons moves a categoryMuch of the opposition to A2 comes from a good-faith misunderstanding as editors are strongly opposed to losing editorial control of our cross-project linking practices. Editors were in vigorous agreement on that point, but as was pointed out, the proposal would not remove the technical ability from the template nor prohibit its use when doing so best serves our readers. Most importantly, this should not be done programmatically (i.e., by bot) and any removals should be done by a human using their best judgment.

Editors are divided on A3 (always define links) but there is no consensus to always manually define links. In general, supporters of this option are arguing against a perceived mass deletion and loss of editorial control, but this seems to be a case of c2:HeatedAgreement. Editors who choose to remove manually-defined commons links should keep these concerns in mind and do so slowly and cautiously (see WP:MEATBOT) so that other editors familiar with the topic have time to review the decision and raise concerns about whether a manually defined link is necessary.

For largely similar reasons, there's a rough consensus against option B, so any bot task that adds the template to categories does not have consensus (and again, see WP:MEATBOT for how this affects high-frequency or semi-automated editing)

— Wug·a·po·des​ 19:38, 5 March 2021 (UTC)

  • Oppose A1 without even blinking. I'm certain 99.9% of readers aren't aware the sidebar is even there, and on a topic with a lot of interlanguage links readers are never going to see it. Weakly oppose A2 as I can't see any particular advantage to removing the ability to override the displayed label. If these are the only three alternatives then support A3, although I could accept A2 provided there were a means to override or disable it in circumstances where what's on Wikidata isn't considered appropriate. Definitely oppose B, as there are occasions when we intentionally don't link to Commons for a given subject. ‑ Iridescent 20:18, 11 December 2020 (UTC)
    @Iridescent: As stated in the A2 description, "this would also allow local overrides". Thanks. Mike Peel (talk) 09:17, 12 December 2020 (UTC)
  • Oppose A1 and Support A3 To always have local control over the destination of the link, makes it easier for users. Keith D (talk) 20:30, 11 December 2020 (UTC)
    @Keith D: Can you elaborate on how that 'makes it easier for users' please? Thanks. Mike Peel (talk) 21:03, 11 December 2020 (UTC)
  • Concern (not opposition)... We here at WP.en have become very leery of linking to Wikidata (in any form). There are times when the two projects just don’t seem to speak the same language, and that has caused headaches for both projects. I have no idea if this is an exception or not... but please go with caution. Blueboar (talk) 01:28, 12 December 2020 (UTC)
  • Support A1 is the easiest to maintain with the tools at our disposal and with common sense protections against vandalism. A1 is a question of getting used to it and knowing where to look. The template can have a deprecation period where it says "See sidebar left for link to Commons" to help educate during the transition period. Failing A1, would also support A2 w/ Bot add (sigh.. see how much better A1 is?). Oppose A3. -- GreenC 02:38, 12 December 2020 (UTC)
    Genuine question and not being snotty, but how do you think "getting used to it" would work? In the skin in which more than 50% of readers see Wikipedia, A1 wouldn't just change the location of the link but would remove it altogether; from the perspective of readers this wouldn't be a matter of looking somewhere else to navigate to Commons, but of Commons suddenly apparently ceasing to exist. (Existing readers would probably know to ask where it had gone, but new readers would have no reason to suspect the links ever existed.) Plus, Wikipedia doesn't just have a single cohort of readers; new people discover us all the time. Most people viewing a category have either got there via a search or via the links on a Wikipedia article and aren't insiders who understand the quirks of MediaWiki, and "the links from Wikipedia pages to related content appear on that page" is a very well-established convention reinforced by 20 years of categories and navbox templates. A typical reader couldn't possibly be expected to know that if they're looking for the media associated with a category, they need to switch to desktop view if they're not already there, and then once there click a cryptic "In other projects: Wikimedia Commons" link hidden in the sidebar. ‑ Iridescent 06:40, 12 December 2020 (UTC)
    Ouch, that's a pretty major bug. I hadn't noticed that since I never use the mobile interface. I had a look on Phabricator to see if there was an existing bug report, but I couldn't find one, so I've started phab:T269992. Thanks. Mike Peel (talk) 09:17, 12 December 2020 (UTC)
    Repeating my plug for the gadget discussed here which adds a one-click button to preview how pages will look to readers (who mostly use the mobile view) rather than editors (who rarely if ever do). You'll be astonished how many things you take for granted are either missing completely or behave completely differently (see what a mess User:Mike Peel looks in mobile view, for an obvious example). If I had my way we'd deprecate mobile view and start again from scratch—I think the current skin is irredeemably bad both for readers and for editors—but I can't imagine the WMF ever admitting that a pet project they've spent a decade promoting is a complete lemon. ‑ Iridescent 13:22, 12 December 2020 (UTC)
  • Support A1. The Commons link is just one example of the "other projects" links, and displaying them automatically as part of the user interface makes more sense than adding one or more templates to every category. If the mobile interface isn't displaying these links, then it should be fixed. Perhaps removal of the existing templates should be delayed until it's fixed. ghouston (talk) 02:18, 13 December 2020 (UTC)
  • Oppose A1, Oppose A2, Support A3 To always have local control over the destination of the link, makes it easier for users. As Keith_D put it. Or, as I put it during the last RFC: Oppose. Kerry put it well. I have long been troubled by persistent efforts for systematic bulk deletion of content from Wikipedia, in favor of obscure remote-ownership of everything by the bot-farm known as Wikidata. One of these days we need to reach a community consensus on the practice in general. Either we should transfer everything possible over to Wikidata and accept that that Wikidata is going to manage everything from now on, or we need to roll back Wikidata to tracking-categories and rare purposes of specific value. This endless struggle to roll Wikidata forwards (or backwards) one inch at a time is wasteful at best and disruptive at worst. Alsee (talk) 16:26, 8 May 2019 (UTC)[2] A tiny number of Wikidata enthusiasts have been persistently trying to bulk-delete content screwing over other editors in a holy crusade to make Wikidata lord&ruler of all they survey. Among other problems, the typical editor is going hit CTRL-F trying to find the content they want to change, and it wouldn't be there. They maybe eventually find the would-be-completely-useless template in the wikitext, but there would be no value there. The editor is left stranded with an impossible edit, absolutely no indication anywhere WTF is going on, and no path forward. Alsee (talk) 16:31, 13 December 2020 (UTC)
  • Support A2 and B. The typical editor does not need to edit technical interproject links. Ruslik_Zero 20:38, 13 December 2020 (UTC)
  • Oppose A1, Oppose A2, Support A3 noting that we would need to explicitly discourage well-meaning editors removing labels "because it's on Wikidata", as has already happened with the A3 example. Sometimes the difference between the Commons category name and the local name is going to be jarring, all the more so if this is used as a precedent for changing how Commons category links are presented in articles: Commons has a more worldwide focus on titling categories than any individual Wikipedia has on titling pages, and has evolved different conventions as a result, and although this doesn't arise much on categories ("in" vs. "of" Lebanon in the A3 example is barely noticeable), it will be jarring in the cases where it does matter. I've frequently created categories on Commons with different names from the Wikipedia articles, for example using a disambiguator instead of "The". On the broad issue, concur with Alsee; having what the reader sees on a page determined at Wikidata rather than on the individual project is unacceptably risky with regards to vandalism or simple error (I corrected a Wikidata description in Dutch the other day that assigned something to the wrong US state) and makes editing unacceptably difficult; "anyone can edit" is one of our foundational principles, we want readers to be drawn to correct or update something and have the satisfaction of seeing their change live, and we want those who add or expand something to fix things linked to it (WP:SOFIXIT). Wikidata is intentionally behind a steep accessibility wall because it's a thing for information professionals and because errors there potentially affect all the projects. So I must oppose A2 and especially A1 (Iridescent's point being also hugely important regarding A1, and I am astonished the WMF was unaware of it). That said, I can see no harm in the bot run so long as we retain the ability to pipe the links when our category moves to a new title and no longer matches that at Wikidata: support B providing A3 is implemented. Yngvadottir (talk) 21:01, 13 December 2020 (UTC)
  • Oppose A1, Oppose A2, Support A3 Local control provides needed flexibility. Another aspect is language - my impression Commons tends yo make more use of local language names where as enWikipedia often uses names translated into English - more likely to cause category names to need local control. Changes other than A3 assume a 1-to-1 correspondence between Wikipedia articles and Commons Categories; there have been Wikipedia changed where I've wanted to add more than one Commons Category link. PsamatheM (talk) 23:21, 13 December 2020 (UTC)
  • As nominator, in case it wasn't obvious, my long term preference is A1 (but that bug with the mobile site needs to be fixed first), right now I would prefer A2 since it minimises data duplication - which is the fundamental problem here. If you have multiple copies of the same data, then you have to fix each of them separately. By storing that link on Wikidata, in the same way as we store interwikis there, is the simplest option: it is then the same dataset here, on Wikidata, and on Commons (where that link is used to display the multilingual infobox). Then there are more eyes on the links, and more chance that someone will spot bad links and fix them. I'm saying this as someone that has gone through and corrected thousands of incorrect commons links from enwp over the last year.
I could live with A3 if needed, but it means continuing to bot/manually sync changes between Commons/Wikidata/here, which is just duplicate effort. Vandalism-wise, using the sitelinks/interwiki links is the safest way, since the category has to exist to be linked to (you can't change it to any random bit of text). There are currently no categories that link to multiple Commons categories, and there should rarely be a need to do that - but A2 would still let that be possible if needed. Similar with local text if really needed (but Commons category names are English by default). A tiny number of Wikidata-haters tend to trot out the same rhetoric whenever Wikidata is mentioned, which isn't really helpful (it's like arguing that all websites should go back to static rendering rather than using databases: it doesn't scale). With B, I'm happy either way - if we don't do that, I don't have to code up the bot, but we also don't get a lot more links to Commons (and bear in mind these have historically been bot-added to categories anyway). Thanks. Mike Peel (talk) 18:05, 14 December 2020 (UTC)
  • Support A2. This is the best of both worlds option. It eliminates a need to maintain two different systems to link a WP category to its equivalent Commons category, but also allows flexibility and control in handling special cases. – Finnusertop (talk ⋅ contribs) 16:42, 15 December 2020 (UTC)
  • Oppose A1 unless and until the mobile view is fixed (as per the nominator). Support A2 provided it isn't seen as a step to not allowing local over-riding, which will remain necessary for all the reasons others have explained above. Peter coxhead (talk) 17:50, 15 December 2020 (UTC)
  • Oppose A1, week oppose on A2 and support A3 for the reasons outlined by Iridescent. -- Euryalus (talk) 23:12, 15 December 2020 (UTC)
  • Oppose A1, A2, B, - Support A3 for reasons above already given. Only in death does duty end (talk) 15:36, 16 December 2020 (UTC)
  • Oppose A1 and A2 (very strongly), B, - Support A3 per Iri & others above. The problem with A2 is that (as I understand it) the current category links will all be removed, and the "local overides" would have to manually re-added. "Matching Wikidata" is a totally untrustworthy test. This would be a nightmare. Johnbod (talk) 15:44, 16 December 2020 (UTC)
    @Johnbod: The check is that the links between enwp + Wikidata + Commons are all in sync, not just 'matching Wikidata'. If you disagree with the link, then in A2 you would have to fix the link (e.g., by adding the local override, which we'd then check and correct on Wikidata/Commons - or better by fixing it on Wikidata so it's then fixed everywhere), or in A3 then you would have to fix the link (e.g., by changing the local override, which we'd then check and correct on Wikidata/Commons). Either way, the work you would have to do is very similar, it's hardly a nightmare. Reminder that enwp/wikidata is currently 100% synced for the categories we're talking about. Thanks. Mike Peel (talk) 20:44, 16 December 2020 (UTC)
  • Weekly Oppose A1, Strongly support A2 and Strongly Oppose A3 as explained hereafter
  • I generally support A1, but I think that's a question better left for a more general RFC on the boxes we put at the ends of articles. I also support A2 as a minimum result since it removes duplication of what is just another interwiki link at the end of the day, which we already accepted managing interwiki links at Wikidata. Hard oppose A3. I also oppose B as I do not want to see a continuing spread of these boxes; secondarily, enforcing the inclusion by bot of these seems to override the apparent editors' will in editing particular pages. --Izno (talk) 18:17, 20 December 2020 (UTC)
  • Support A2 for better visibility of the connection, but A1 is okay for me too. We should leverage Wikidata as much as possible in uncontroversial scenarios like this one. --MarioGom (talk) 14:16, 4 January 2021 (UTC)
  • Oppose A1, Support A2, Neutral A3, Support B. This gives the best combination of visibility and avoiding unnecessary duplication of effort. Thryduulf (talk) 16:05, 9 January 2021 (UTC)
  • I don't care too much about A1-A3 (though I think that local definition is better, goals of en.wikipedia and wikidata do not always align and definitions are sometimes different). I however strongly oppose any automated or blind additions of the 'commons category' (and I guess that is then also an agreement with selective A1). There are many cases where commons category has nothing that is adding to our articles (all images are already used, and, albeit in rare cases, commons has less than what en.wikipedia has), and sending people off to commons to find less (or the same) than what is here is silly and just clogging our articles (especially when you get the whole series of sisterlinks). Note that commons sometimes has different croppings of 1 image, so even if the number of images on commons is higher, it still does not add. --Dirk Beetstra T C 14:11, 10 January 2021 (UTC)
  • A3 (and A2 when the names are the same). Commons categories too often do not have names that match ours.  — SMcCandlish ☏ ¢ 😼  08:33, 15 January 2021 (UTC)
  • Oppose A1 and A2. And support A3. And support B but only if it says "Bot-added link". And Mike Peel, please stop removing commons category links that don't exactly match up with the English article name or English article categories. See this diff. You don't have that authority as far as I know. It is an example of why a bot shouldn't be removing commons categories. Humans like you shouldn't be doing it either. I noticed from your contributions that you are on a bot-like spree in doing so. Just because you are an admin doesn't mean you have the right to do so. Show me the guideline. I have tens of thousands of edits on both the commons and Wikipedia. I know many of these attempts at synchronization will not work due to the many idiosyncrasies of Commons work and Wikipedia work. I prefer an additive approach. Let the bot add commons links, but not let a bot remove commons links. --Timeshifter (talk) 04:18, 9 February 2021 (UTC)
  • Oppose A1/A3, strong support B, since a large part of the readers probably don't even know what "Wikimedia Commons" is, and "media related to ..." is just much easier to understand. --TheImaCow (talk) 06:26, 23 February 2021 (UTC)
  • Support A2 and B, oppose others. Locally defining the link is a bad idea in 99% of cases - though the option should still exist - and only having a sidebar link is a reduction in visibility for no good reason. Elliot321 (talk | contribs) 01:43, 28 February 2021 (UTC)
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.

CentralNotice banner for WikiGap 2021 Russia

Dear colleagues, please comment on CentralNotice banner proposal for WikiGap 2021 Russia article contest. (8 March - 8 May, all IPs from Russia, WPs only, 1 banner impression per week). Thank you.--Dmitry Rozhkov (talk) 00:10, 7 March 2021 (UTC)

An example might be https://en.wikipedia.org/wiki/Jaguar would have a link to https://species.wikimedia.org/wiki/Parphorus_jaguar, and https://simple.wikipedia.org/wiki/Jaguar. Let me know what you think. AidTheWiki (talk) 16:06, 7 March 2021 (UTC)

Duplicate discussion. {{u|Sdkb}} talk 17:29, 10 March 2021 (UTC)

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.

At this point, it's almost a given that when a featured article is chosen, it will be a high target by vandals. It will be better semi-protect (or at least pending changes) featured articles for the duration that they're featured. Eridian314 (talk) 17:20, 10 March 2021 (UTC)

@Eridian314: You will be interested in #Pending-changes protection of Today's featured article. --Izno (talk) 17:24, 10 March 2021 (UTC)
Thanks. I didn't see that. Eridian314 (talk) 17:27, 10 March 2021 (UTC)
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.

Wikipedia:List of Wikipedians by number of edits

Hi! I propose to extend this ranking to the topbest 20,000 Wikipedians by number of edits, instead 10,000. Dr Salvus (talk) 14:17, 28 February 2021 (UTC)

@Dr Salvus: I have changed your "best" to "top" to try to avoid derailing the discussion. English is not your native language and I guess "top" better covers what you mean. PrimeHunter (talk) 14:37, 28 February 2021 (UTC)
Would this be possible to do? The obvious problem is that it might encourage Wikipedia: Editcountitis. Rollo August (talk) 19:32, 28 February 2021 (UTC)
It's certainly possible, but it's a bot-generated report, so is the bot operator (MZMcBride) willing to make the change? If they are, does the community desire it? I've placed a note at Wikipedia talk:List of Wikipedians by number of edits. --Redrose64 🌹 (talk) 09:58, 1 March 2021 (UTC)

Removal of "List of Transgendered People"

I have decided to write this once about it, but I think we should get rid of the "List of Transgendered People" article, even if it is blank. It may be a bit upsetting that it still exists. We have an updated article with "transgender" instead of the less respectful "Transgendered", so I suggest removing it. What's the use of keeping it if we already have a better one? [1] — Preceding unsigned comment added by 2603:6080:3040:2c2:10b9:203f:84e1:2a84 (talk)

List of transgendered people is a redirect to the "right" term List of transgender people. We keep it because it is a possible search term by readers that may not be aware of the more accepted terminology regarding transgender people - that is, while in the past "transgendered" was a term in use, it is discouraged over simply "transgender" but not everyone may know that. Those searching on the old term will get to the page with the right term and will be informed why this is the right term. --Masem (t) 17:13, 10 March 2021 (UTC)
Agreed with Masem. This discussion would go at WP:RfD. It should be closed here if it continues to draw responses. {{u|Sdkb}} talk 17:26, 10 March 2021 (UTC)
Also, it's a very old {{redirect with history}} that gets about 4 page views a day so deleting it might break external links. — Wug·a·po·des​ 04:27, 11 March 2021 (UTC)

References

  1. ^ List of Transgender People

Block the edit for non-registered users

I think to combat vandalism a solution might be blocked from editing for unregistered users. I think because many IPs are shared and vandal IPs are not punished. DrSalvus (talk) 23:06, 12 March 2021 (UTC)

Hi Dr. Salvus. See WP:PEREN#Editing for some background. This has been proposed a number of times. Also see WP:5P3. Thank you. Killiondude (talk) 23:23, 12 March 2021 (UTC)

Subpages of redirects should redirect

I propose that subpages of redirects should redirect to the supage of the target page. This should apply unless there is an existing page at the subpage. For example, if you had a page ExampleRedirect which had a target of ExampleTarget, going to ExampleRedirect/SubpageA would send you to ExampleTarget/SubpageA. Now imagine that for whatever reason there was a subpage on ExampleRedirect/SubpageB that did have content on it. Going to ExampleRedirect/SubpageB would not redirect, as there was already content. I also have a proposed way for the system to do this. When you go to an empty page that is a subpage of another page, the code would check whether or not there was a redirect at that page. If there was it would redirect you as explained above. Like I said, it would only activate if you were at an empty subpage. One example of the effect of this change would be with Wikipedia:Criteria for speedy deletion. This change would cause going to WP:CSD/Creating a new criterion to redirect to Wikipedia:Criteria for speedy deletion/Creating a new criterion. βӪᑸᙥӴ • Talk • Contribs 13:33, 11 March 2021 (UTC)

It cannot be implemented with the current MediaWiki unless we add some global JavaScript (which would only work for users with JavaScript but that's most users). MediaWiki:Noarticletext could examine whether there is a parent page, whether it is a redirect, see where it redirects, and suggest it as a link, but it cannot make a redirect. PrimeHunter (talk) 13:55, 11 March 2021 (UTC)
I'm surprised that we still don't have this functionality after nearly 20 years. I'm sure this is something that will eventually be added into the software. --Heymid (contribs) 16:43, 12 March 2021 (UTC)
Unless I am misreading the scope of this proposal, in general I do not think this is necessary. For example, the full name Eric Barry Wilfred Chappelow redirects to Eric Chappelow, as does the abbreviated form E. B. W. Chappelow. I see no reason for Talk:Eric Barry Wilfred Chappelow/GA1 or Talk:E. B. W. Chappelow/GA1 to be created as redirects to Talk:Eric Chappelow/GA1. There are probably at least a handful of redirects going to every GA candidate in Wikipedia, to begin with. BD2412 T 17:15, 12 March 2021 (UTC)
The suggestion is not to create redirect pages but to automatically redirect if there is no page. There are many cases where a redirect would be pointless but probably do no harm. PrimeHunter (talk) 17:26, 12 March 2021 (UTC)
It would be useful in Wikipedia space, so for example WP:MOS/Abbreviations would automatically redirect to Wikipedia:Manual of Style/Abbreviations. (Whether or not this feature warrants the cost, I'm not clear.) isaacl (talk) 04:36, 13 March 2021 (UTC)
What do you mean is the cost? It's not hard to implement. --Heymid (contribs) 12:14, 13 March 2021 (UTC)
Every feature has a cost to develop, to test, to review, to get accepted for integration, to deploy, and to maintain. There is also an opportunity cost. Anyone is of course welcome to proceed with development and testing; you need support and effort from those managing MediaWiki development for other steps, which is more cost for the developer and others. Without more information, I'm not commenting on the relative priority of this particular feature in terms of its cost and in relation to all other backlog items. isaacl (talk) 19:49, 13 March 2021 (UTC)

Wiki meets Sustainable Fashion

Hello, we are PulloJesicaNoemi and Irinarosarina. We are presenting a Grant, Wiki meets Sustainable Fashion. We are a group of Latin women interested in sustainable fashion, and our goal is to bring in and train 360 female volunteers to edit pre-existing articles and to create articles related to this subject. If you could please check out our project here and leave your comments, it would be greatly appreciated! PulloJesicaNoemi (talk) 14:00, 14 March 2021 (UTC)

Please feel free to respond on the RfC on whether to say in the UPE template that the payer isn't necessarily the subject of the article

Just to try to keep it brief the instructions at WP:RFC#Publicizing_an_RfC say:

To get more input, you may publicize the RfC by posting a notice at one or more of the following locations:

  • One of the Village Pump forums, such as those for policy issues, proposals, or miscellaneous

I posted the RfC at 09:12, 25 February 2021 (UTC) and so far there has only been two editors (me and CUPIDICAE💕) without any clear consensus.

So please feel free to share any thoughts there at the RfC.

Jjjjjjjjjj (talk) 20:46, 16 March 2021 (UTC)

RfC: Should we allow custom DISPLAYTITLE?

Should we use custom DISPLAYTITLE? We have dozens of titles where custom DISPLAYTITLE would be useful, such as thatPower and C Sharp (programming language). Using custom DISPLAYTITLE would allow us to bypass these restrictions and allow us to use any DISPLAYTITLE and deprecate the template {{correct title}} Aasim (talk) 20:22, 9 February 2021 (UTC)

There would need to be some system to only allow "valid" alternate names—currently only modifications that result in the same text (ignoring formatting/normalization) are allowed. For C#, you'd need to allow adding "#" (maybe reasonable to code in as an unsupported character), but also removing "Sharp" (harder to code in, because it already bans hiding arbitrary parts of the page title). One possibility is a separate software feature so the title could only be edited by users with a certain permission, but I don't think this will get much support and it would be a lot of work for fairly minor gain. And there's still the problem that the displayed title won't work if you copy it into the search box or try to link to it. — The Earwig ⟨talk⟩ 22:40, 9 February 2021 (UTC)
@The Earwig: Removing chars from the title is already supported via the font-size=0 trick, though I think it's generally seen as bad practice. – SD0001 (talk) 14:03, 10 February 2021 (UTC)
From Wikipedia:Page name#Changing the displayed title, it was formerly possible to hide text with display: none; but this is no longer allowed. It makes sense there are other workarounds, but I'm certain this is a bad idea. For one, I'm not sure how screen readers will handle that. — The Earwig ⟨talk⟩ 14:39, 10 February 2021 (UTC)
In theory there could be a list of valid substitutions defined by regex somewhere or something, so the complete word "sharp" can be substituted for "#" or the like. --Aquillion (talk) 21:56, 15 February 2021 (UTC)
IMHO I think abuse is a bit unlikely given that most people dropping by Wikipedia to edit it are here in good faith and probably know nothing about how "DISPLAYTITLE" works. Also it appears DISPLAYTITLE is hidden deep in VisualEditor anyway, so I do not think abuse is likely to happen.
And messing with the "DISPLAYTITLE" of a page could just be treated as disruptive editing, just as we treat page move wars, tendentious comments, etc. Aasim (talk) 00:55, 10 February 2021 (UTC)

Modifications to the 'blocked user' frame for partial blocks

I think that on the contributions page for partially-blocked users, their block frame should have a less red background color, perhaps orange or even white. It should also state "This user is currently partially blocked." --Heymid (contribs) 12:13, 13 March 2021 (UTC)

I am fairly certain this is not possible today. --Izno (talk) 18:29, 13 March 2021 (UTC)
That's surprising, given that the block message is colored yellow on the Swedish Wikipedia. --Heymid (contribs) 20:48, 13 March 2021 (UTC)
Aren't the block frame and text fetched from MediaWiki-namespace pages? --Heymid (contribs) 20:56, 13 March 2021 (UTC)
It's customisable with the CSS class linked below, and probably MediaWiki:Logentry-partialblock-block, though I don't currently see how the proposed text can be gracefully added. Anecdotally, on more than one occasion I've seen the red block box and not noticed that it's a partial block. I think some slight differentiation might be useful. -- zzuuzz (talk) 21:47, 16 March 2021 (UTC)
Actually, I see the text already been added with MediaWiki:sp-contributions-blocked-notice-partial and MediaWiki:Sp-contributions-blocked-notice-anon-partial. -- zzuuzz (talk) 21:58, 16 March 2021 (UTC)


Warns of vandals

Resolved

I hate vandalism. I propose that if a vandal damages Wikipedia after just one warn he will be immediately blocked Dr Salvus 23:53, 27 March 2021 (UTC)

See Assume Good Faith. GenQuest "scribble" 02:55, 28 March 2021 (UTC)

Handling this with the editor, we don't need a pile on here for all the reasons we well know this won't work. Please let it archive. StarM 13:56, 28 March 2021 (UTC)

Monetization of Wikipedia

I read today that "the Wikimedia Foundation ... is announcing the launch of a commercial product, Wikimedia Enterprise. The new service is designed for the sale and efficient delivery of Wikipedia's content directly to these online behemoths (and eventually, to smaller companies too)." [4] Have we had any community discussions about this plan? Did the WMF consult with us? Should we (English Wikipedia) be taking any position on this? Tony Tan · talk 15:43, 17 March 2021 (UTC)

Tony Tan, Have you read all the documentation ? Also there are existing threads in several places, prominently Wikipedia:Village_pump_(WMF)#A_commercial_subsidy_of_WMF and I suggest its best to continue the discussion there. —TheDJ (talk • contribs) 15:59, 17 March 2021 (UTC)

Bringing back the GA Cup

I simply propose bringing back the GA Cup, which was abandoned a few years ago, to reduce GA nomination backlog. You can read a bit more about my proposal here. If you would want to be involved in the GA Cup, let me know in the comments below. X-Editor (talk) 06:21, 3 March 2021 (UTC)

Exactly! This will help with the backlog a lot. Seeing as quite a bit of this year has passed already, maybe we could start the next GA Cup in mid-2021 and end it in mid-2022. The one after that will then start at the beginning of 2023 and end at the end of 2023. X-Editor (talk) 21:36, 4 March 2021 (UTC)
  • Support: That sounds helpful, the current backlog is extremely discouraging. - Astrophobe (talk) 23:11, 4 March 2021 (UTC)
  • Support I support anything that reduces the backlog. 🐔 Chicdat  Bawk to me! 12:17, 8 March 2021 (UTC)
  • For anyone interested in this topic, there's a current GA Backlog Drive through the month of March. Since around the start of the pandemic they've been running a drive every few months. Ajpolino (talk) 16:12, 8 March 2021 (UTC)
    As Ajpolino notes, there has been a GA drive every six months with decent levels of success. I guess it couldn't hurt to trial the GA cup again and I'd certainly participate, but I question whether interest in reviewing could be sustained for more than a month at a time.
    If we're looking for more radical solutions, what I will always say is to look at the report and note those with a lot of nominations open. Right now there are two users with a combined eighty nominations open who have conducted forty reviews ever. That's quite possibly the biggest single contributing factor to the backlog— people who write copious amounts of content but cannot be bothered to review in return. (Of course, most prolific ga writers restrict themselves to a reasonable number open at a time or review in turn (Sturmvogel 66 and The Rambling Man come to mind as prolific writers and reviewers), but there are a few who don't. And it's frustrating) Eddie891 Talk Work 16:29, 8 March 2021 (UTC)
    Eddie891, Why not use the quid pro quo system like they do at DYK? -- RoySmith (talk) 22:34, 8 March 2021 (UTC)
    We could also just limit editors to two or three open GANs. ~ HAL333 00:22, 15 March 2021 (UTC)
    Both of these are extremely reasonable options... even one GA review for every two GAs would do wonders... Aza24 (talk) 00:26, 15 March 2021 (UTC)
    In a world where Eddie designed the GA process, I would institute something along the lines of up to five GANs open at a time and a QPQ of two GANs for every one review above that baseline; but that sounds like a logistical nightmare Eddie891 Talk Work 01:04, 15 March 2021 (UTC)
    It's funny you say that, I had a similar thought process a few months ago. During the last GA drive I considered what GAN would look like if mirroring DYK, but it occurred to me that making QPQ would probably result in more low-quality reviews in addition to putting off prolific GA nominators (as much as they fill the backlog, there content creation is still extremely valuable). Having a different ratio seemed the ideal solution (1 for every 2, or 2 for every 3 etc.) but I came to the same conclusion that the logistics would be unrealistic... Having a limit on pending GANs seems more feasible though, this is already done at PR, FLC and FAC. Aza24 (talk) 01:35, 15 March 2021 (UTC)

A limit on pending GANs would be nasty unless the backlog was already slashed. The people who write a billion GAs aren't actually a very large population, and tend to be concentrated in a couple topics; the effect for the average writer would be to still have to wait several months to do anything, and without even the happiness of getting to have any of your individual GANs looked at while you wait for the rest. A mandatory QPQ would lead to the same issue as DYK, i.e. reviews being perfunctory. It's something that concerns me myself -- I still have more reviews than I do GAs, but I really don't enjoy reviewing, so it's a chore to maintain. Vaticidalprophet 13:57, 21 March 2021 (UTC)

@The Rambling Man: I'm not sure what the format of a new GA Cup would be, but I imagine it would be similar to formats of the previous GA Cups that were done several years ago. X-Editor (talk) 22:29, 8 March 2021 (UTC)
Before we all get carried away and vote for this, it needs to be properly defined. The Rambling Man (Stay alert! Control the virus! Save lives!!!!) 22:31, 8 March 2021 (UTC)
@The Rambling Man: I agree, which is why I want to ask you what you would do if you had the chance to organize this GA Cup? X-Editor (talk) 23:28, 8 March 2021 (UTC)
I haven't got a clue. I have never participated in it before, but you can't just vote to resurrect something without saying what it is you're going to actually do. The Rambling Man (Stay alert! Control the virus! Save lives!!!!) 07:40, 9 March 2021 (UTC)
@The Rambling Man: I think a similar format to the GA Cups done previously would be the best option. X-Editor (talk) 21:43, 9 March 2021 (UTC)
  • Oppose a certain editor's style of writing and nominating GAs springs to mind, and that I don't want to encourage. If you've been reviewing for a little while, you'll probably know who I'm talking about. Kind regards, Willbb234Talk (please {{ping}} me in replies) 18:05, 15 March 2021 (UTC)

Deleting part of an edit history

  • Currently, admins cannot delete only some of the edits in a page's edit history and leave the rest visible; he can only delete the page completely, and then undelete some of its edits, this wasting his time and the internet's time and Wikipedia's server's time. It would be useful if an admin could delete some of the edits in a page's edit history and leave the rest visible, all in one action. Anthony Appleyard (talk) 17:15, 14 March 2021 (UTC)
The features you mention leave the history in place, but just hide the contents. I imagine what Anthony is referring to is a way to actually delete these revisions (Selective deletion). This is used to be fairly common, especially when dealing with voluminous vandalism. It can still be useful when dealing with these and other slightly niche things like history splits, or user pages. I imagine the introduction of Special:MergeHistory / Special:Log/merge has reduced the need for selective deletion even further, and that there is not really enough application left to introduce it as a new feature. There's almost certainly going to be an extension for MediaWiki which could do it, but I think it would be a hard sell. -- zzuuzz (talk) 18:44, 14 March 2021 (UTC)
When I first joined the oversight team, this was how it worked. Then revision deletion with the option to suppress as well came along and... it's just so much better, and the old way was deprecated. Easier to use, at least slightly more transparent, and allows an admin to revdel before asking for outright suppression, reducing potential harm. Beeblebrox (talk) 20:44, 14 March 2021 (UTC)

Adding the MediaWiki Tabs Extension

Hi, I'd like to propose adding the Tabs extension to Wikipedia. I was editing this article which contains projected data for 2021, 2022, 2023 and so on. The article also has a nice map, which makes the data easier to visualize, but it can only show the data from one year at the time. I wanted to add a map for each year to show how countries have changed/will change throughout the years, but obviously adding that many maps to the page would just clutter it. A tabbed structure with years for tabs, each having a map would work well here, something like this. This way someone could easily switch between years and instantly see the evolution of various economies.

I looked for a way to create tabs but only found page tabs which require creating multiple subpages. Not exactly elegant. Instead of tabs, this could also be done using Template:Hidden, however it would be a pretty clunky way to do it. In-page tabs work best in this case. But currently there isn't any functionality that allows editors to create in-page tabs on the English Wikipedia. I found the MediaWiki Tabs Extension which seems to be well adapted for this purpose but when I checked Special:Version it didn't show up in the list of installed extensions.

I searched the Village pump for any previous proposals discussing this and found this proposal from last year which also suggested adding the Tabber extension but that proposal didn't reach consensus. I want submit a second proposal for adding this functionality to Wikipedia since tabs can be used effectively in all sorts of situations and are a great tool for displaying data. In-page tabs are particularly useful for articles that with deal large amounts of data and can help make that data easier to interpret and to navigate. The only options those pages have right now in terms of sorting are limited: they can either split the data with HTML anchors which require you to scroll back to the top every time you want to go to another section or divide the content into multiple subpages which isn't always optimal or possible. Or even have to use both in some cases.

Pages like Lists of films for example could be greatly simplified, and would remove the necessity of having to go from page to page through sublists (ex: Lists of films → Lists of Hong Kong films → List of Hong Kong films of the 1960s → List of Hong Kong films of 1963). All those sublists would become irrelevant, and the end pages could be accessed easier using nested tabs, like this.

I'm honestly a bit surprised that the English language Wikipedia lacks this functionality, since tabs are a basic and well established interface element that a majority of internet users are familiar with. Page tabs feel like a strange workaround which in some cases just complicates things both for editing the content and navigating it (a separate page needs to load every single time a user switches to another tab, wasting bandwidth needlessly - for example switching between 4-5 tabs wastes around 1MB just for reloading the WP interface over and over again).

Another reason and the most common one they've been requested before was because editors want to use them in meta or user pages, which I also think is a good idea. A few people had some valid concerns about the usage of tabs, but applying the same rules that apply to subpages to tabs solves most of those issues. This extension also doesn't have the same problem as collapsible content has regarding hidden content disappearing on page load for users using Google Web Lite - I tested a page using tabs and all the content was displayed, even with JS and CSS disabled.

OUT 06:34, 22 March 2021 (UTC)

Discussion on COI article-space templates

 You are invited to join the discussion at Wikipedia:Templates for discussion/Log/2021 March 19 § COI article-space templates. {{u|Sdkb}} talk 01:55, 23 March 2021 (UTC)

Deprecate linking to Wikipedia books in templates and articles

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.
There's a strong consensus to deprecate these links on the grounds that they're not serving our readers well, as judged by the low number of pageviews. (non-admin closure) (t · c) buidhe 10:37, 23 March 2021 (UTC)


I'm proposing that we formally deprecate linking Wikipedia:Books in templates and articles. Wikipedia books have not worked for many years now but are still included in various templates (e.g. {{Star Wars universe}}, {{Mercury (planet)}}, {{Abraham Lincoln}}) and maybe some articles—I recall seeing some in various "see also" sections. It seems unhelpful and unproductive to lead readers to a page that says the service in question is unavailable and points the reader towards external (third-party) sources; I speculate that most readers will see this as a dead end and not pursue it further. Around two years ago {{Wikipedia books}} and the relevant sidebar were suppressed, so I don't see why we should contradict that practice by still providing useless links in templates (and supposably articles). Aza24 (talk) 06:48, 13 March 2021 (UTC)

More info available at Wikipedia:Wikipedia book creator status.
Past discussion on the template itself - Wikipedia:Templates_for_discussion/Log/2021_January_16#Template:Wikipedia_books
  • Support. I'm not fully read up on the history of Wikipedia Books, but it seems like an experiment we tried and that failed. We should clean up after ourselves, which means not continuing to link to it after it's dead. {{u|Sdkb}} talk 05:04, 14 March 2021 (UTC)
  • Support: as Sdkb says, let's clean-up after ourselves. GenQuest "scribble" 08:48, 14 March 2021 (UTC)
  • Support As a loose end to failed project, as Aza points out, this is just a dead end that does no service to our readers. Beeblebrox (talk) 20:45, 14 March 2021 (UTC)
  • Support Not a contentious suggestion and understandable. I like the principle of "cleaning up after ourselves." doktorb wordsdeeds 21:37, 14 March 2021 (UTC)
  • Support Wow, I had never even heard of these (which says a lot). ~ HAL333 00:18, 15 March 2021 (UTC)
  • Support Failed experiment, should be deprecated.--Vulphere 04:52, 16 March 2021 (UTC)
  • Support I have a ton of opinions about books and think it is a really difficult problem how to handle them. I think they have a non-negligible value if they ever get working properly again and even now there are a handful of people finding value in them. At the same time the namespace is filled with a lot of crap, the category system is in most cases a better tool for reading about a subject and linking to pages with large warning banners doesn't look good at all. I have previously proposed a technical way to hide these links without removing them so we could put them back if the issues are fixed at Wikipedia:Village pump (technical)/Archive 183#Mainspace book links but to be honest I am absolutley fine with just removing them as well. My solution, while workable, would definitely cause some confusion for non-technical editors and possibly weird formatting in places if someone touched whitespace around them. Straight up removal would also have the benefit of pruning the links if they ever need be re-added and should in theory only link to decent quality books. --Trialpears (talk) 16:19, 16 March 2021 (UTC)
    @Trialpears: The problem with the Category system is that its lists are essentially unstructured and can be very large; Books allow intelligent design. Also, book links are currently suppressed, much as you suggested. — Cheers, Steelpillow (Talk) 17:35, 16 March 2021 (UTC)
  • Strong object. The OP's "service in question", as described at Wikipedia:Books, is the Collection extension (aka Book Creator). It is very much here and working. And w have a Books: namespace with lots of books in it. We deservedly ditched our useless in-house renderer, but the idea that it is nowadays "the service in question" is nonsense. As stated on Wikipedia:Books and elsewhere, "As a result of anticipated future solutions, template transclusions should not be removed from articles." We would first need to establish a consensus to abandon any thought of such future services, such as adopting the long-anticipated Collector, and also of supporting external services such as MediaWiki2LaTex at WMFlabs. Then we'd have to agree to abandoning the Book: namespace. Let's discuss those first and not go round breaking them. — Cheers, Steelpillow (Talk) 17:35, 16 March 2021 (UTC)
  • Support per WP:NOTPAPER. If readers want to use an external service to print collections of articles, they may do so, but we have no need to maintain support indefinitely for services unrelated to our goal of building a wiki. As sdkb says, we tried books and it failed. Book:Star Wars and Book:Abraham Lincoln average 3 views a day each. Star Wars got more page views yesterday than the book gets in an entire year. Mark the namespace as historical, remove reader-facing links to it, and let it collect dust (I oppose deleting the namespace or pages per m:Keep history). We don't need to waste time maintaining support for a feature no one uses. — Wug·a·po·des​ 19:27, 16 March 2021 (UTC)
  • Support I sometimes have seen the links at the bottom of articles and wondered what additional info they offer. Seems in some cases they are more of a fork to out of date content. Jtbobwaysf (talk) 05:59, 19 March 2021 (UTC)
  • Support Essentially these are an external link. Reading the guidelines here Wikipedia:External links#What to link indicates that Wikibooks no longer meets most (if not all) of them. MarnetteD|Talk 06:46, 19 March 2021 (UTC)
  • Support no more linking to dead namespaces. 🐔 Chicdat  Bawk to me! 11:10, 20 March 2021 (UTC)
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.

RfC: Disable minor edits on English Wikipedia

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.
There is a strong consensus against limiting minor edits to anti-vandalism as suggested in the proposal. Alternate proposals of limiting minor edits to autoconfirmed or extended-confirmed editors have attracted considerable support in the discussion, but it's difficult to tell how extensive it is since many respondents did not mention the alternate proposals in their comments. Therefore, another RfC to limit the use of minor edits to autoconfirmed editors may be in order. (non-admin closure) (t · c) buidhe 10:52, 23 March 2021 (UTC)


Proposed: Effectively disable the "minor edits" functionality on the English Wikipedia. Its usage will be limited by policy for anti-vandalism reverts only. Technically, the permission to mark as minor will be limited to rollbackers, admins and bots. ProcrastinatingReader (talk) 19:56, 15 February 2021 (UTC)

Survey (minor edits)

  • Support The point is apparently for some editors to ignore "m" edits on watchlists. No experienced editor would do so because "m" edits can be as wrong, disruptive, or destructive as a "major" edit. Vandals can use them for vandalism, newbie editors in good faith with problematic changes, and experienced editors may make something they believe is minor but other editors disagree. Really, all edits are subject to dispute. The point of a watchlist is to monitor articles. What's more, we apparently block editors for minor edits related issues. The functionality is not only useless, it's a net negative. Minor edits can be communicated via the edit summary and the diff count. ProcrastinatingReader (talk) 19:56, 15 February 2021 (UTC)
  • Oppose. I mark edits as minor all the time when they are, in fact, minor. Fixing typos and the like need not bother editors who don't want to see those edits. If there is a problem with non-minor edits being marked as minor, figure out how to figure those out. We already flag, for example, possible changes in birth and death dates. BD2412 T 20:03, 15 February 2021 (UTC)
    • Note: I support the below proposals to limit minor edits to either autoconfirmed or extended confirmed editors (preferably the latter). BD2412 T 04:56, 3 March 2021 (UTC)
  • Oppose a policy that minor should only be for vandalism reversion; I agree with BD2412 that actions such as small typo fixes, small whitespace adjustments, etc should still qualify as "minor" for patrolling and review purposes. Nuetral on an overlapping component of this, the removal of the minoredit permission from "All Users" - if it is being misused frequently by newer users might be helpful - but if so I think it should go to +extendedconfirmed and/or other groups (i.e. rollbacker/patroller) that otherwise help recognize that an editor has a modicum of experience here. — xaosflux Talk 20:23, 15 February 2021 (UTC)
    • A perfectly cromulent use case is by a bot that has to make a non-content clean up to user talk pages, by declaring the edit minor and leveraging their nominornewtalk permission - the operator can avoid bothering users with a new messages notification. While "bots" were in the original proposal, this use case fails the "anti-vandalism reverts only" criteria. — xaosflux Talk 20:41, 15 February 2021 (UTC)
      For clarity, I meant anti-vandalism only for human editors (bots being able to use it as they do). ProcrastinatingReader (talk) 20:44, 15 February 2021 (UTC)
      @ProcrastinatingReader: OK thanks, any bot use should already be governed by a specific WP:BRFA for whatever it is they are doing (and this is almost always used in addition to the 'b'ot flag). — xaosflux Talk 20:52, 15 February 2021 (UTC)
      Re typos, a typo fix can still be disputed. Perhaps the editor got it wrong and the 'typo' was intentional. More importantly, Suffusion of Yellow's comment, especially about the evil bit, is a good way to phrase the issue imo. So long as some disputed edits can flow through it, the entire feature is worthless. The anti-vandalism allowance is because that's already governed by existing policy, WP:ROLLBACKUSE and WP:VAND etc, and allows pure 'junk' to be filtered out. Though I'm also okay with removing this exemption. ProcrastinatingReader (talk) 20:55, 15 February 2021 (UTC)
  • Support. So long as this feature is available to spammers, vandals, and the clueless, it's as useless as the evil bit. It's also a source of needless drama, when users innocently overuse it. But if people think this proposal goes too far, limiting it to extendedconfirmed would be a good start. Suffusion of Yellow (talk) 20:33, 15 February 2021 (UTC)
  • Oppose Why? Mike Peel (talk) 20:35, 15 February 2021 (UTC)
  • Support, tentatively, disabling the option when making a manual edit. It's simply not that useful; even experienced users don't agree on what it means, and don't use it consistently. The byte count is a much more effective way to identify "minor" changes at a glance, since it's less prone to manipulation. Because the minor flag can be set inappropriately, it's almost never reasonable to completely filter out minor edits, so it simply acts as a weak signal of intent on page histories, redundant to edit summary and byte count. Not convinced about making it antivandalism-only, though. — The Earwig ⟨talk⟩ 20:37, 15 February 2021 (UTC)
    After reading the comments in opposition and consideration of alternate solutions for the problem, I don't think this proposal as written is the way to go. — The Earwig ⟨talk⟩ 19:13, 16 February 2021 (UTC)
    Support limiting to autoconfirmed as a first step. Oppose limiting to extended confirmed. I understand the arguments in favor, but I generally oppose expanding the role of EC by taking privileges away from autoconfirmed users (giving EC users privileges otherwise only available to more restricted users is another thing). Even with this we could not prevent every mistagging of edits as minor, nor should we strive to. The majority of minor edits tagged by someone with, say, 2 months of experience and 100 edits will be fine, and if they aren't, they're not likely to figure it out by the 500th edit. — The Earwig (talk) 06:46, 3 March 2021 (UTC)
  • Oppose as written. It might make sense to further limit who can mark edits as minor, but eliminating them nearly wholesale as this proposal does goes too far. This is using a bunker buster to wipeout a few hornets. -- Calidum 21:11, 15 February 2021 (UTC)
  • Support the idea of disabling the option to mark edits as minor when editing manually. I don’t really see the point of making the ‘minor’ flag CV only, or granting it to admins or rollbackers. If we think it’s useless, then let’s deprecate it fully, rather than trying to debate who is experienced enough to use it. The only truly clear use for minor edits is bots editing user talk pages as Xaosflux sagely said above, so bots should obviously keep the right for that reason. Bot edits can already be filtered from watchlists, so other than on user talk pages it doesn’t matter whether bot edits are minor or not. ƒirefly ( t · c ) 21:35, 15 February 2021 (UTC)
    Other uses of minor edits include (but are not limited to):
    • Spelling fixes
    • Capitalisation fixes
    • Typo fixes
    • Grammar fixes
    • bold/italic fixes
    • List order fixes
    • Markup fixes (templates, tables, etc)
    • Small corrections to comments (e.g. missing words)
    • Signing unsigned comments
    • Whitespace fixes
    • Addition of templates that have no or minimal impact on content (e.g. {{As of}}, {{Update after}}, {{convert}})
    • Adjusting links
    • Adding/adjusting hatnotes
    • Protecting/unprotecting pages (automatically marked minor). Thryduulf (talk) 21:53, 15 February 2021 (UTC)
  • Very strong oppose. There is (probably) an issue that needs resolving behind this proposal, but there is no evidence presented for any of (a) the problem being widespread (i.e. that the solution lies with something other than educating and/or blocking individual users), (b) restricting minor edits will solve the underlying issue, (c) that restricting minor edits as much as is proposed is either necessary or proportionate, or (d) that the inevitable collateral damage will cause fewer and less significant problems than the original one. It is therefore way, way too premature to be bringing this to this board, let alone an RfC - it has very clearly not been thought through quickly, let alone repeatedly, fully and in-depth. Thryduulf (talk) 21:37, 15 February 2021 (UTC)
    it has very clearly not been thought through quickly, let alone repeatedly, fully and in-depth I've discussed this with other editors in multiple AN/ANIs last and this year, and this directly came from a VPT from this week. So that's not true. ProcrastinatingReader (talk) 22:26, 15 February 2021 (UTC)
    This is vague and lacking in so many ways I'm truly gobsmacked that multiple editors thought this was viable proposal. Thryduulf (talk) 23:02, 15 February 2021 (UTC)
  • Oppose. Most experienced editors use minor a lot when performing wholly uncontroversial typo fixes, minor formatting changes, wikifying and the like. This feels like a baby–bathwater situation. Espresso Addict (talk) 00:36, 16 February 2021 (UTC)
    The thing is in order for some people to gain some benefit from ignoring edits flagged as minor, others must continue to monitor all edits. At present it's like some people just play with the baby without taking a turn dealing with the bathwater. Which is OK when there's enough people who don't filter out minor edits, but it means that minor edit filtering inherently fails to scale up, and that makes me uneasy about touting its benefits for all. isaacl (talk) 00:59, 16 February 2021 (UTC)
    I think we're talking about slightly different things here. I see it as a signal from experienced editor to experienced editor that says nothing to see here, which seems unambiguously useful. You, I think, are complaining that editors who filter out minor edits in watchlists (or, like me, don't bother with a watchlist at all) are placing a burden on others to check them. That seems more a problem in the way watchlists are configured, rather than with the principle of edits being marked as minor/not. Perhaps an edit filter could be devised to flag edits that are clearly not minor, and remove the designation? Espresso Addict (talk) 02:02, 16 February 2021 (UTC)
    The signal is unfortunately not a reliable one. It's an AI problem to automatically detect minor edits. If it works well enough, then there wouldn't be any need for manual flagging. That might be a good idea, but I'm not sure if it should be given priority over other developer tasks, particularly given the likely high effort-to-benefit ratio. (I appreciate the advantage of the signal, when accurate, and have written about it in the discussion section.) isaacl (talk) 03:13, 16 February 2021 (UTC)
    I wouldn't object strongly to restricting the ability to mark edits as minor to, say, extended confirmed editors; or more usefully, letting inexperienced editors continue to mark them (so that they learn to do it to community norms), but ignoring the mark (from inexperienced editors) in watchlist presentations. I don't think AI is going to differentiate them accurately enough any time soon. Espresso Addict (talk) 03:48, 16 February 2021 (UTC)
    It already has the ability to filter based on experience and minor edits (as well as a contribution quality prediction), but I don't think it can be set for all edits from inexperienced editors plus non-minor edits from experienced editors. The reliability issue remains, even with experienced editors, so someone ought to be checking all minor edits. isaacl (talk) 04:06, 16 February 2021 (UTC)
  • Oppose, but open to reform. The minor edit designation is a piece of information, just like the edit summary, that has to be taken in context. When I see an "m" next to a reputable username, that saves me the effort of reviewing the edit. When it's next to a giant edit from an IP a redlinked user with a suspicious summary, that's different. For that reason, I don't filter them from my watchlist, but if someone else wants to do so, they can. That said, I agree misuse of the minor edit box is a problem. Here's a more modest proposal: limit it to autoconfirmed editors, and the first time someone checks it, have the software generate a popup that quickly explains what we mean by "minor". With that, we could take a harder stance on misuse of the box, since no one could claim they just didn't know. That might get us closer to a point where more editors feel comfortable filtering minor edits from their watchlist. {{u|Sdkb}} talk 07:19, 16 February 2021 (UTC)
    @Sdkb: unless I'm missing something, IP's can't tag edits as minor today (please point to any diff if you can see one). Unconfirmed users can - so the next "small step" up would be to remove that access from "All users" and give it to "autoconfirmed" users. — xaosflux Talk 14:30, 16 February 2021 (UTC)
    You're correct; I've fixed my hypothetical. {{u|Sdkb}} talk 18:34, 16 February 2021 (UTC)
    @Sdkb: those are both steps that I can support, along with perhaps a byte limit for the size of a change to still be marked minor. BD2412 T 17:57, 16 February 2021 (UTC)
    A byte limit might be tricky; reverting a vandal blanking a page is a very valid minor edit, as it's clearly uncontroversial. As an alternative, maybe disallow if ORES flags it as possibly unconstructive? {{u|Sdkb}} talk 18:38, 16 February 2021 (UTC)
    Something like that would definitely be useful, yes. BD2412 T 00:20, 17 February 2021 (UTC)
  • Support The checkbox adds complexity to the process of making each edit, with very little benefit to other editors, and just a little anxiety at perhaps getting it wrong. On average, I guess I spend half a second to a second on this decision each time. Doing the math, that adds up to 2 to 4 working weeks of my life over the past decade. -- John of Reading (talk) 08:28, 16 February 2021 (UTC)
    @John of Reading: if it bothers you personally you can add this one line to your Special:MyPage/common.css and you won't have to see that box anymore:
    #mw-editpage-minoredit {display: none;}
    — xaosflux Talk 19:57, 16 February 2021 (UTC)
    @Xaosflux: The checkbox I use most is the one in AWB, not the one in the edit window. But if I hide the checkbox, or always leave it unchecked, and some other editors think the distinction is important, then I'll be failing to signal correctly to them that most of my edits are minor. -- John of Reading (talk) 20:09, 16 February 2021 (UTC)
  • Strong oppose as unnecessary and counter-helpful. A large percentage of my own edits are minor, and I like the ability to keep the groups separated (if only for myself). No reason other people should have to pore through my edits when all I did was correct spelling or fix date formats or eliminate the spaces before <ref>, etc. — JohnFromPinckney (talk) 18:11, 16 February 2021 (UTC)
  • Support limiting the "minor edit" checkmark to experienced users. It is very unreliable when used by newbies. - Vis M (talk) 21:04, 16 February 2021 (UTC)
  • Oppose A supposed vandalism revert isn't necessarily minor. And the fact that the flag might not be accurate is just like everything else on Wikpiedia. Every single page, edit, summary or whatever might not be accurate. Per the disclaimer "WIKIPEDIA MAKES NO GUARANTEE OF VALIDITY". Andrew🐉(talk) 23:12, 16 February 2021 (UTC)
  • Oppose per BD2412 and xaosflux. While I'm open to stopping non-autoconfirmed editors from marking edits as 'minor', I am in disagreement with the bulk of the proposal. Sdrqaz (talk) 20:42, 18 February 2021 (UTC)
  • Limit to autoconfirmed Any potential damage from misusing the minor edit flag is minimal---on par with moving a page. It takes time to figure out what's minor and what's not, and we already restrict IPs. While we can certainly improve our guidance on using the minor edit flag, the threat level doesn't warrant restricting autoconfirmed editors who we already trust with much more powerful tools in their hands. — Wug·a·po·des​ 22:31, 18 February 2021 (UTC)
  • Limit to autoconfirmed. We already prevent IPs from using the box, and new users can be assumed to be similarly inexperienced. However it is definitely useful for exconf+, and seeing as it's, well, a minor feature, autoconf should have access to it as well. Would be open to Sdkb's idea of having a popup the first time someone ticks the box, though I'm not sure as to the feasability of this on the software end. —pythoncoder (talk | contribs) 19:54, 19 February 2021 (UTC)
  • Nein - minor edits are edits that well, are minor. If we mark them as major edits, then it will only waste more editors time in the RC patrol backlog. — Preceding unsigned comment added by Awesome Aasim (talk • contribs) 03:15, 21 February 2021 (UTC)
  • Limit to autoconfirmed. For experienced users, especially when working with other editors, this is an important flag. Anyone who does not trust the minor edit flag can still look at all edits, so why could there possibly be a need to remove this functionality?ThoughtIdRetired (talk) 15:07, 21 February 2021 (UTC)
  • I very strongly oppose the idea as proposed, but agree with Pythoncoder (this is the second RfC today I've agreed with him on) that limiting it to autoconfirmed is a good idea. JJP...MASTER![talk to] JJP... master? 01:55, 22 February 2021 (UTC)
  • Support with comments: (1) Admins should be permitted to mark any of their edits, vandalism-related or not, as ‘minor’ if they they deem doing so beneficial to the community. For the rest of us (non-bot editors), rollback seems as good a threshold as any. (2) ‘Minor’ may cease to be the optimal name for the tag. ‘Procedural’ might be more apt? No idea if there’s anyway to change that for the sake of new editors. —jameslucas ▄▄▄ ▄ ▄▄▄ ▄▄▄ ▄ 03:14, 23 February 2021 (UTC)
  • Oppose Minor edits are important - the little changes to markup, spellings, white space, capitalisation, changes/updates to numbers, correcting typos: they are the little things that make the bigger machine work. By removing "minor edits" as a tag, you run the risk of flooding timelines with clutter, and potentially dissuade editors from making necessary minor changes in the first place. doktorb wordsdeeds 07:25, 23 February 2021 (UTC)
  • Oppose per Mike Peel. --Jayron32 19:31, 24 February 2021 (UTC)
  • Oppose. If someone is inappropriately flagging non-minor edits as minor, that's a user conduct issue, not a reason to deprecate minor edits. Speaking as someone who's apparently made 318,850 minor edits, it's of no benefit and causes obvious disruption if readers who don't need to be made aware every time I quietly search-and-replace the misspelling "targetted" are unable to filter it from their watchlist. It would also make reviewing editors' contribution histories (whether it be for processes like RFA, or just "I'm looking for the diff of that edit you made last week") orders of magnitude more complicated, for no obvious benefit. ‑ Iridescent 19:45, 24 February 2021 (UTC)
  • Oppose - Personally I don't ever use it even if I'm indeed making minor edits... It really is too much effort clicking on one box everytime I want to save changes... that being said not using it isn't a reason to support and no reason has been given as to why this should be disabled in the first place. –Davey2010Talk 23:12, 24 February 2021 (UTC)
  • Oppose. I am somewhat sympathetic to the proposal but the problem and its scope need to be much better defined, and the proposed solution appears to be too radical. I mark copyedits as minor all the time; same for manual delsort edits. If the feature is used properly, I find it quite useful; if an edit is marked as minor in my watchlist or in a page history, I am much more likely to ignore that edit. I agree probably is some issue with the misuse of this feature, but at the moment I am unsure about the extent of the problem. Perhaps less radical solutions, such as limiting the class of users with the userrights to mark edits as minor, and trying to provide a more precise definition of what constitutes a minor edit would be useful and should be attempted first. Nsk92 (talk) 23:50, 24 February 2021 (UTC)
  • Oppose minor edits are useful to distinguish, well, which edits are minor. If minor edits are disabled, we have no way to distinguish here, so we lose information. Potentially faulty information - as improperly marked minor edits are - is worse than no information. Maybe limit to autoconfirmed, and in the worst possible case limit to extended confirmed, but removing entirely is not a good idea. Elliot321 (talk | contribs) 01:53, 28 February 2021 (UTC)
  • Oppose as proposed per Xaosflux. I am open to limiting minor edits to autoconfirmed or extendedconfirmed, but not as proposed. Twassman | Talk | Contribs 06:48, 28 February 2021 (UTC)
  • Support this makes "request minor edits feature" a main value of the rollback permission. Once somebody knows enough to want it, we should give it to them. power~enwiki (π, ν) 03:03, 2 March 2021 (UTC)
  • Oppose A solution which would be far worse than the problem it seeks to address. Minor edits are useful. Limiting it to autoconfirmed users might solve most abuse (since most vandals are non-AC); if there is such abuse in the first place. RandomCanadian (talk / contribs) 03:44, 2 March 2021 (UTC)
  • Oppose. While marking edits as minor isn't super useful, it does have some benefits when going through the edit history of an article. Of course the "minor edit" flag is just as reliable as the edit summary there (i.e. not very) and you shouldn't do anything automated based on the presence or absence of the flag. —Kusma (t·c) 11:55, 2 March 2021 (UTC)
  • Support. Should be a privilege. At present it's worse than useless for vandalism and just superfluous cognitive overload for good-faith editors. Rollo (talk) 22:06, 2 March 2021 (UTC)
  • Limit to extended-confirmed (autoconfirmed is too easy to get around) because only experienced editors should be able to mark edits minor. Then if I ignore minor-flagged edits, I won't have to worry about missing any non-EC edits. Levivich harass/hound 04:42, 3 March 2021 (UTC)
  • Oppose I don't think there is an Issue that needs solving. I think minor edits are a useful tool for actual minor edits. jort⁹³|talk 19:56, 4 March 2021 (UTC)
  • Oppose This is a solution in search of a problem. Many users, myself included, do not abuse minor edits. This is like not allowing anyone to eat food because some people eat too much. Thank you, 🐔 Chicdat  Bawk to me! 11:58, 6 March 2021 (UTC)
  • Oppose Just sanction those who abuse it. Minor edits are beneficial to this project overall. ~ HAL333 22:16, 7 March 2021 (UTC)
  • Oppose as written. Support limiting it to autoconfirmed or extended confirmed. --Ahecht (TALK
    PAGE    ) 20:23, 9 March 2021 (UTC)
  • Oppose Minor edits are clearly defined in WP:MINOR, and they have a good purpose. Besides, many people who revert vandalism are not rollbackers (like me) — Preceding unsigned comment added by Bop34 (talk • contribs) 20:46, 9 March 2021 (UTC)
  • Oppose Just becuase some people may abuse minor edits it does not mean we should essentially remove their use to editors almost entirely.  Spy-cicle💥  Talk? 18:49, 10 March 2021 (UTC)
  • Oppose, but open to reform, if we just got rid of minor edits, then it would either discourage people from making edits that are simply just spelling or grammar fixes or it would make it harder for those who moderate editing to figure out what is and isn't spam. A way we could reform this would be my making it so all edits under a certain size (say 100 bytes, this is simply an example) will be marked as minor and cannot be unmarked as minor. When I edited on Fandom (similar to Wikipedia except more for games) I would mark edits that are just me making small edits to articles (like fixing spelling or grammar) as minor because, well, they are. If we just removed the option to mark edits as minor then it might make people feel like they have to radically change the article. I'm probably repeating myself so I'm going to give another way to reform it. Just have all edits marked as minor by default. Yes, there is an option for this but I think people don't know that. Another way to reform, is, like I said above, have all edits under a certain size marked as minor and if someone attempts to unmark it as minor and its still under that size, a warning message pops up, letting the user know what the point of it being marked as minor is. When it gets over a certain size, it cannot be unmarked as minor unless the user has special permissions to do so (I.e they're a trusted Wikipedia editor). This is just my opinion but after reading all the stuff above I felt like I should contribute. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) 01:08, 16 March 2021 (UTC)
    • Diff size is not a reliable way to determine what is and isn't a minor edit. A rewrite of an entire paragraph is not a minor edit but if it used the same number of characters it would have a diff size of 0 bytes. At the other end of the scale, adding an archive link to sources can add 50-100 bytes of text per URI but as it makes no change to the prose it would be valid to mark that as a minor edit. Thryduulf (talk) 01:23, 16 March 2021 (UTC)
  • Oppose as proposed, Support for limiting minor edit to autoconfirmed/extendedconfirmed editors.--Vulphere 04:56, 16 March 2021 (UTC)
  • Strongest Oppose There are other solutions to the dishonest use of the "minor" button. This, as proposed, should not be implemented. GenQuest "scribble" 16:38, 16 March 2021 (UTC)
  • Support Bots, reverts have an obvious place for minor edits. While experienced users don't all agree on definition of a minor edit, they'll at least use it consistently, which can be useful for reviewing edits of a particular user. They are less useful however, when monitoring recent changes of a watchlist. In order to make them more useful, I'd recommend limiting the ability to enable minor edits to WP:ECP users who'd at least have a consistent rationale for what's minor/major. Shushugah (talk) 16:52, 16 March 2021 (UTC)
  • Oppose Minor edits are useful. Not only for me to use when correcting typos, or to help me bypass minor edits by editors I recognize, but also because the "minor edit" checked plus a canned edit summary like "Fixed typo" is a clear red flag to check for vandalism or other disruptive editing. – Muboshgu (talk) 16:54, 16 March 2021 (UTC)
  • Oppose - when looking at an article's history, it can be useful to see that an edit has been marked

as minor, for example, changing a single letter to correct a typing error. This is useful because it helps to distinguish minor edits from more major changes in an article. Rollo August (talk) 20:15, 20 March 2021 (UTC)

Discussion (minor edits)

Although the minor edits flag isn't a reliable one to use for filtering all edits, it can be used (visually) to filter edits from editors you know. This advantage is, of course, only available to you if some of your known editors actually use the flag. isaacl (talk) 21:13, 15 February 2021 (UTC)

@ProcrastinatingReader, would your actual problem be solved by changing the default prefs settings to show minor edits? Whatamidoing (WMF) (talk) 21:55, 15 February 2021 (UTC)
The issue I have is that the functionality doesn't make sense. I don't think it ever makes sense to actually hide minor edits in a watchlist. The indicator itself may be helpful nevertheless, but is still redundant to the summary + byte count. I think Suffusion of Yellow and The Earwig's comments put my concerns succinctly. My second issue is individual admins thinking blocking even a single editor for their use of the minor indicator (eg or blocking individual users) is appropriate. I think the issue is frequent enough, per it having a section in a policy page (Wikipedia:Vandalism#Gaming_the_system). ProcrastinatingReader (talk) 22:22, 15 February 2021 (UTC)
If you could configure specific editors for which minor edits would be filtered out, it might be more useful. But given the low amount of usage, and the amount of overhead processing required for that level of filtering, I don't think it's worth the development and ongoing sustaining cost. isaacl (talk) 22:40, 15 February 2021 (UTC)
How do you know which editors to filter out? I think it'd be difficult to create an exhaustive list of editors who are incapable of using the feature. If it's a local list, it'd be very difficult for editors to maintain it (besides, if you have minor edits hidden, how do you know which editors are misusing the minor feature to add to the list since, well, you won't see their edits?) If it's a global list, I sense more pointless ANI drama. Plus, it may just be one-off edits that require more scrutiny rather than continuous inability to determine what is minor or isn't. ProcrastinatingReader (talk) 22:44, 15 February 2021 (UTC)
It would be up to individual users to decide whom they trusted to properly flag minor edits, and then configure their watchlist accordingly. But like I said, I don't think the work to implement this warrants the benefit. I didn't realize the current filtering capability allowed for level of experience to be configured; I'm not sure if that is useful or not for one's watchlist. isaacl (talk) 00:03, 16 February 2021 (UTC)
@ProcrastinatingReader, if the function doesn't make sense to you, then why do you propose that certain editors should continue to use it?
I think that whether it makes sense depends upon which version of the watchlist you're looking at. If you have each edit displayed separately, then it could let you skip a lot of edits that you don't want to see (e.g., ClueBot reverting simple vandalism, which is marked 'minor' but not as a 'bot' edit).
The minor edit flag is displayed in Special:RecentChanges as well. This allows interested editors to filter (for example) for minor edits by less-experienced editors that are the most current version of the page. I imagine that this would be an interesting list for both anti-vandalism patrollers and people seeking out promising editors. Whatamidoing (WMF) (talk) 23:05, 15 February 2021 (UTC)
The answer to the first paragraph is your second paragraph: so that ClueBot, and Hugglers, reverting simple vandalism can continue to be filtered out of watchlists. It's less restricting it to certain editors, and rather restricting it for a certain purpose. Even rollbackers and admins wouldn't be allowed to mark as minor "grammar changes", for example, under this proposal. ProcrastinatingReader (talk) 23:21, 15 February 2021 (UTC)
That's the problem with this proposal - vandalism fixing is only one of many valid reasons to mark an editor minor, including grammar changes (a I wrote a non-exhaustive list above). You seem to be assuming that everybody uses Wikipedia in the exact same way you do, which is flat out wrong. Thryduulf (talk) 12:28, 16 February 2021 (UTC)
As an example, this edit is very clearly a minor edit yet it has nothing to do with vandalism. Thryduulf (talk) 12:39, 16 February 2021 (UTC)
  • Since this proposal is unlikely to get consensus as written, here's a completely different suggestion, more narrowly targeted at what I see is the most egregious problem: the fact that we occasionally block otherwise productive editors for misuse of the minor edit feature. Allow admins to disable the minor edit flag for an editor as part of the blocking interface, in the same vein as partial blocks or disabling email, but without restricting the ability to edit. — The Earwig ⟨talk⟩ 15:21, 16 February 2021 (UTC)
    • Two thoughts. The first, is it actually technically possible? If not, I think it’s unlikely to get through phab and even if it did we run the issue of having people reporting each other even more than now to ANI for “minor edit marking violations” for a “minor edit block”. The second, the feature would still be useless imo, but that’s just my idealism talking I suppose; if editors aren’t being site blocked for it then I don’t care as much. ProcrastinatingReader (talk) 16:40, 16 February 2021 (UTC)
      Not currently possible, would require developer time. That alone makes it a bit hopeless, I suppose. But I'm still interested in how we can solve this problem in a more targeted way. — The Earwig ⟨talk⟩ 16:52, 16 February 2021 (UTC)
      Indeed it isn't currently technically possible, but a lot of work has recently been done on partial blocks and marking edits as minor is something that is given to only a subset of users so it strikes me that it is something that going to be possible with a reasonable amount of work (I'm not a developer though). Thinking of ways to solve the actual problem in a focused way that doesn't cause massive collateral damage is absolutely the right thing to be doing though - indeed this is the sort of thing that should have been done before coming here with a proposal, let alone an RFC. Thryduulf (talk) 17:25, 16 February 2021 (UTC)
      @The Earwig and ProcrastinatingReader: I've created a phab task for this, see phab:T274911. Thryduulf (talk) 17:29, 16 February 2021 (UTC)
      Since minoredit is a separate user right, if it were to be assigned by bot instead of being a permission set for all users, then it could be removed from anyone who used it inappropriately. isaacl (talk) 19:36, 16 February 2021 (UTC)
      @Isaacl: I think you might be mixing up some terms here? It could be possible to make a group that includes the minoredit permission; and it would be possible to make it auto-assign-once on a threshold (like extendedconfirmed) such that it could be revoked - but that is a lot of overhead for such a small permission (and I don't think we'd get "bots" involved with this process at all). — xaosflux Talk 19:50, 16 February 2021 (UTC)
      It's not something I know a lot about, so almost certainly. I elided talking about groups for simplicity, and I didn't know (or forgot) about auto-assign-once; my apologies. Yes, it would be overhead, but less than enhancing the partial block capability to support blocking a user from flagging minor edits. isaacl (talk) 19:55, 16 February 2021 (UTC)
      It would also be possible, without any overhead in the common case or coding effort, to create a group that removes the ability to make a minor edit using $wgRevokePermissions. This way of doing it also avoids the issue of blocks being seen as a stain on people's record that was pointed out by Suffusion of Yellow below. That said, I am far from convinced that any of this is actually a good idea. * Pppery * it has begun... 23:38, 16 February 2021 (UTC)
      @Pppery: from a quick check we have exactly one project using that setting in all of WMF, and it looks like they haven't used it in over 10 years so I'm shocked it is still around (looks like may get merged in t pblocks - see phab:T227618). It does leave a "stain" on the user's rights log of course (e.g. w:ta:Special:Redirect/logid/58001. — xaosflux Talk 00:11, 17 February 2021 (UTC)
      As I recall when I was working with another Wiki implementation that had similar functionality, it can be useful in a corporate setting when defining user groups and managing their permissions. isaacl (talk) 00:20, 17 February 2021 (UTC)
    • This would be a fantastic source of drama. A block (even a partial block) isn't just the technical inability to do something, it's (for better or worse) going to be viewed by the user as a "stain" on their record. For something as trivial as this, that doesn't seem worth it. Suffusion of Yellow (talk) 20:00, 16 February 2021 (UTC)
  • When you see a ±10k edit marked as minor, you know that the editor is almost certainly up to no good. Narky Blert (talk) 17:55, 16 February 2021 (UTC)
  • Apparently more than seven thousand users have been warned for marking non-minor edits as minor. Has the opposite ever happened? I.E. "you're making typo fixes but not marking them as minor, please start using the flag or I'll drag you to AN/I". Suffusion of Yellow (talk) 19:52, 16 February 2021 (UTC)
    When training I always say that if you are in any doubt about whether and edit is minor assume it isn't as the worst that will happen is someone will give you friendly advice, but marking a major edit as minor could lead to people getting angry at you. Thryduulf (talk) 21:06, 16 February 2021 (UTC)
  • I'm surprised that productive editors are being blocked for their use of minor edit marking. Are there more cases than the one mentioned by The Earwig above? That particular case seems highly unusual as the editor is apparently using an iOS app that does not receive notifications, and hence is not responding to feedback. Someone being blocked for vandalism marked as minor is clearly being blocked for vandalism. Espresso Addict (talk) 00:44, 17 February 2021 (UTC)
    Good question, Espresso Addict. I dug up some examples of editors being blocked for marking edits as minor. In most cases, there are other reasons for the blocks, of course: [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]. — The Earwig ⟨talk⟩ 07:37, 17 February 2021 (UTC)
  • Comment. I voted oppose above and indicated I would be open to limiting who can mark edits as minor. I've noticed several people have since suggested only allowing autoconfirmed users to mark edits as minor, but I was under the impression it was already limited to autoconfirmed users. If not, I see no reason why that shouldn't be the case. -- Calidum 21:11, 24 February 2021 (UTC)
    @Calidum: The present situation is that you dn't need to be autoconforemed to mark edits as minor, just be logged-in. --Redrose64 🌹 (talk) 17:12, 25 February 2021 (UTC)
  • Some of the topics I keep my eye on are prone to POV vandalism. Often the vandals attempt to hide their vandalism behind a “minor edit” tag. This is (counterintuitively) quite helpful when it comes to spotting and cleaning up such vandalism ... I have learned to pay extra close attention to edits that are marked as being “minor”. Thus, I would oppose doing away with the tag. Blueboar (talk) 23:03, 24 February 2021 (UTC)
    We should rename it to Honeytrap 😅 Shushugah (talk) 11:08, 22 March 2021 (UTC)
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.

RfC: No Nazis

There's an ongoing RfC at WT:NAZI#Proposal. Feel free to participate. Firestar464 (talk) 01:54, 23 March 2021 (UTC)

That was closed with an oppose. Emir of Wikipedia (talk) 14:32, 28 March 2021 (UTC)

Should we sell Wikipedia while the Wikimedia Foundation isn’t looking and pocket the proceeds?

WP:FOOLS

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.

So I was recently in contact with a friend and mentioned that I edit Wikipedia in my spare time. He mistakenly assumed that I owned Wikipedia and offered to purchase the project off of me. I’m positive I can get $5 billion dollars from all of this, and I’m happy to split this with our ~150,000 active editors (which comes in at around $3 millions dollars and change per person). Wikipedia is a community first and foremost, so it would be unethical to knowingly sell false title to the project without first getting consensus from my fellow editors. So what say you: do you want to become a millionaire? Answer quickly please: I’m pretty sure its illegal to sell things you don’t own, so we should probably close this deal within the next 24 hours.[April Fools!] Spirit of Eagle (talk) 00:00, 1 April 2021 (UTC)

We definitely should. As well, we should probably round up all the $3 donations Wikipedia has received and spilt that among us, so we make the most money possible, because the more money we get, the better. All us editors bust our butts all day as unpaid volunteers making an encyclopedia better, it’s time we get some money from it. Now quick, before the WMF finds out.[April Fools!] D🐶ggy54321 (let's chat!) 00:11, 1 April 2021 (UTC)
  • This is an excellent idea. The WMF had their chance and failed. However, my friend William just made me a counter offer of $6 billion on the condition that we put the encyclopedia on wheels. Should we go for it? —pythoncoder (talk | contribs) 00:23, 1 April 2021 (UTC)
I did the math and that should just about double our take home pay. Do it! Spirit of Eagle (talk) 00:32, 1 April 2021 (UTC)
Uh oh https://en.wikipedia.org/wiki/Wikipedia:Sockpuppet_investigations/Pythoncoder Natureium (talk) 00:32, 1 April 2021 (UTC)
Busted... https://en.wikipedia.org/wiki/Special:Diff/1015361823/1015427072 —pythoncoder (talk | contribs) 12:55, 1 April 2021 (UTC)
That probably means that we're all going to get stacks of coal when St Jimbo comes around. REDMAN 2019 (talk) 13:47, 1 April 2021 (UTC)
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.

Mass-deletion of more than 5500 stubs

Main page: Wikipedia:Administrators' noticeboard § Large batch deletion probably needed

There has been a mass-creation of more than 5500 articles which contain nothing but a coördinate, a Farsi name, and a statement that something is a "village". Unfortunately, the source database that was used to mass-create these actually includes pumps (fa:تلمبه), wells (fa:چاه), farms, and so forth; and the one prose fact in the resultant article is actually false, making these bad stubs that do not even give correct context for expansion. We have a specific list of articles that are likely these, based upon the article then asserting that "no population is reported" for the database entry; and editors are seeking consensus for an administrator to mass-delete them. There is also a separate discussion of the article creator. Please see, and discuss at, the hyperlinked noticeboard. Uncle G (talk) 08:47, 28 March 2021 (UTC)

Make access date automatically inserted for visual edit citation tool whenever we enter a new citation

As a VisualEditor user I found it quite enjoying to use their visual citation services, but quite annoying to fill out the access date every time I create a new citation. It would be better for it to be automatically inserted whenever we made a new citation with the citation. --Regards, Jeromi Mikhael 02:08, 31 March 2021 (UTC)

The accessdate refers to when you checked the page the URL points to, not to when you made the citation or edited the article. How would a tool know when you last checked the URL? Martin of Sheffield (talk) 06:04, 31 March 2021 (UTC)
@Martin of Sheffield: Defaults to current day, I guess? When we make a citation we always see the page on the same day. --Regards, Jeromi Mikhael 07:32, 31 March 2021 (UTC)
I don't think this will work. For instance, there are many instances where people just copy over a citation from one place to another, often without checking it anew. If it didn't have an access date in its original location, your mechanism would now give it the appearance of having been freshly checked, which in many cases would be false. Fut.Perf. ☼ 07:42, 31 March 2021 (UTC)
Exactly. Also if I have a citation coming from Zotero that needs to reflect the date that the copy of the PDF (or whatever) was saved. Martin of Sheffield (talk) 07:45, 31 March 2021 (UTC)
Alas, defaulting to current date is just what happens with WP:ReFill (sample edit). Just one more reason why that tool should be killed.
—Trappist the monk (talk) 10:35, 31 March 2021 (UTC)

RfC: make Template:Authority control more reader-friendly

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.
There's a strong support for an overhaul of the authority control template that uses human-readable names of the resources, in the interest of being recognizable to more editors. There is general support that Fram's proposal is preferable to the current version, but not any consensus on the exact form that an improved version might take. An alternative proposal which attracted some support is to scrap the entire template or replace with a link to wikidata, which could be discussed at another RfC to gauge if that proposal has consensus. (non-admin closure) (t · c) buidhe 01:24, 1 April 2021 (UTC)


Should Template:Authority control be rewritten to make it more reader-friendly? Fram (talk) 10:12, 18 March 2021 (UTC)

Authority control background

Authority Control is a template that is included in 1.7 million enwiki articles by now: it shows as links a number of "unique identifiers" from organisations around the world. All the data is stored on Wikidata, nothing is stored here. The proposed RfCs won't change anything about how Wikidata deals with these: it is purely about how we want to show these at Enwiki.

With an example taken from Kenzaburō Ōe, the current result of the Authority Control template looks like this;

Authority control proposal

Change the links to authority IDs: currently they are an acronym plus a unique but often meaningless ID. In the proposal they would become a readable, textbased link. The links could also be organized to make their use clearer, and to avoid repetition.

The above is a very simple mockup of how it could look. This is an example, and not necessarily the end result. For other common groups of IDs (e.g. art-related websites), another line can be added. Fram (talk) 10:14, 18 March 2021 (UTC)

I would like to ask people not to focus too much on the look of the proposal: the RfC is about the principles, the actual new look can be decided by people with more knowledge of and talent for user experience design. Fram (talk) 10:16, 18 March 2021 (UTC)

  • There's probably something I'm missing, but the lead reference "Integrated Authority File" leads to a German language website for the Deutsche Nationalbibliothek which I would have expected under "National Libraries"? Other than that issue it does seem a good and sensible proposal. Martin of Sheffield (talk) 10:25, 18 March 2021 (UTC)
    Yes, I wasn't certain where to put this one. It is, to my best knowledge, an international standard, but maintained by the German National Library, and the text on the page is in German. These details (well, it's an important one) will need to be decided upon if the general principle of the proposal gets accepted. Fram (talk) 10:43, 18 March 2021 (UTC)
  • Comment: Is the term "Authority control" even reader-friendly? Few readers other than librarians will have any idea what it means, and it sounds ... authoritarian? Should we talk about "Unique identifiers" for clarity? PamD 11:29, 18 March 2021 (UTC)
    No not really. Its a data/library term not a reader term. Only in death does duty end (talk) 11:41, 18 March 2021 (UTC)
    That would be better but is a separate discussion, I think. Fram (talk) 11:54, 18 March 2021 (UTC)
    I don't fully mind the term, as it is wikilinked, but it's not a major deal either way. Most casual readers likely don't even make it that far on the page. ɱ (talk) 13:58, 20 March 2021 (UTC)
  • Oppose removing WP links - I'm pretty sure this has been discussed before, but that hasn't stopped Fram before, either. The links to, for example, LCCN inform the user of the AC-granting institution, and the ID link(s) n81033861 provide the information. Both are needed.   ~ Tom.Reding (talk ⋅dgaf)  11:39, 18 March 2021 (UTC)
    • Why should you require a reader to click on obscure acronyms to get the information about who issued the ID string, if you can include it much more clearly in the template directly like above? Most readers of the Oë article will have no clue at all what "NLG: 71274" is. In the new template, they see directly that it is a link to the National Library of Greece. Do they need an actual link to National Library of Greece from the Oe article? I doubt it, it is not relevant information for that article. Do they still have the link to the NLG ID page? Yes, that is still included. But now at least they will have a better idea of what they are presented with, without needing to click either link. Your two reasons are "informing the reader of the granting institution", which is in the proposed version done directly instead of requiring a click: and the ID links to provide the information, which is in the proposed version also still there, as it still is a link which still leads to the same information. Oh, and feel free to link to previous discussions, perhaps without the personal comments though. Fram (talk) 11:53, 18 March 2021 (UTC)
      • You brought it up, here, at this Village pump (proposal) in June 2018. Search "Option 2Names", which spawned "Option 2Wikidata", "Option 2pencil", and "Option 2edit". I too, at first, and others, liked these options, before realizing my statement above. Nothing personal, just facts about your person. Unfortunately, they seem like WP:I didn't hear that and/or slow-motion WP:FORUMSHOPPING.   ~ Tom.Reding (talk ⋅dgaf)  15:43, 18 March 2021 (UTC)
        • Oh, that trainwreck discussion ending in no consensus, but with a lot of support for the type of changes I propose here? Yes, that kind of discussion doesn't stop me from bringing a new RfC two years later. I do like the "Nothing personal, just facts about your person." though. Fram (talk) 16:22, 18 March 2021 (UTC)
    • LCCN, etc., links serve the additional purpose of notifying the editor which parameter they may use (|LCCN=) to either override the WD ID, or to suppress the ID altogether. With the proposed scheme, this is much more difficult to determine. Such a lack of foresight could have been avoided if there had been any discussion on the talk page, instead resulting in this very poor RfC.   ~ Tom.Reding (talk ⋅dgaf)  00:42, 19 March 2021 (UTC)
      • Despit the template being used on 1.7 million articles, the possibility to suppress links was used on 43 pages before I created the ACArt template recently. Such a barely used possibility (which will remain available anyway, but may if the RfC is successful need better documentation) hardly justifies making the template much harder to understand (and thus less likely to be used) for our readers. This is not a "lack of foresight", this is getting your priorities right. Fram (talk) 08:23, 19 March 2021 (UTC)
        • You're ignoring the ~2400 pages using Category:Pages using authority control with parameters (0). Par for the course though.   ~ Tom.Reding (talk ⋅dgaf)  10:18, 19 March 2021 (UTC)
          • For a start, hundreds of those seem to be redirects, which shouldn't have an authority control templatein the first place. But let's look at some actual articles instead. First one I checked at random, Anthony St. John Baker, has the same ID in the parameter as in Wikidata. Siddharth Basrur, added by same editor on Wikidata and a minute later on enwiki, so not necessary either. And in any case, the possibility isn't removed, in the few cases where it is needed they will just have to check a bit harder to get it right. Fram (talk) 10:43, 19 March 2021 (UTC)
            • At least we agree that this proposal will hamper functionality.
              Also, 353 redirects, on which AC is encouraged per Wikipedia:Authority control "If necessary, create a new redirect to carry the template." For an RfC, you are stunningly misinformed.   ~ Tom.Reding (talk ⋅dgaf)  11:37, 19 March 2021 (UTC)
              Maybe it's time to stop attacking Fram ("IDHT", "FORUMSHOPPING", "stunningly misinformed", "just facts about your person", and others)? Read the room: consensus doesn't agree with you. ProcrastinatingReader (talk) 12:02, 19 March 2021 (UTC)
              All facts relevant to the discussion.
              "Read the room"? This isn't a vote; this is based on merit, of which there's none, other than "it looks pretty". Introduce a version where WP links are kept, then we can move on to discussing how much taller the template will get, but that's a better starting point than this.   ~ Tom.Reding (talk ⋅dgaf)  12:39, 19 March 2021 (UTC)
              If all you see in the proposal is "it looks pretty", then I think we are done discussing things. Uses of this template on redirects, which no one will ever see and which serve no practical purpose on enwiki, are hardly a reason to keep a template as uninformative and opaque as possible. Fram (talk) 13:13, 19 March 2021 (UTC)
  • Support improvements - Fram is right. The weird acronyms that no reader can be reasonably expected to know are utterly useless. You can hover over them to see what they mean, since they link to the respective article, but readers shouldn't have to do that to make sense of it. The presentation of the template currently is useless, and Fram's mock-up above is a leap of an improvement. Still, I think more can be done with this template. The "National libraries" presentation is good, the rest is still iffy imo. ProcrastinatingReader (talk) 15:19, 18 March 2021 (UTC)
    • When I hover of them, I get "Bibsys (identifier)", "BNF (identifier)", "CiNii (identifier)" and so on. Not very helpful. Fram (talk) 15:10, 19 March 2021 (UTC)
      When I hover over them, I get "BIBSYS is an administrative agency set up and organized by the Ministry of Education and Research in Norway. They provide the exchange, storage and retrieval of data pertaining to research, teaching and learning – historically metadata related to library resources." and other similar previews of the articles. I think it depends on whether you've got page previews (Preferences -> Appearance -> Enable page previews) or navigation popups (Preferences -> Gadgets -> Navigation) enabled. --rchard2scout (talk) 09:15, 22 March 2021 (UTC)
  • As stated at the VPI discussion, I support the general change. I have some nits about the suggested appearance, but as requested, that's not the focus. --Izno (talk) 15:35, 18 March 2021 (UTC)
  • Support, broadly speaking, making it more readable. It's currently just acronyms no one knows with numbers that mean nothing. I exaggerate, but if a general reader would want more encyclopedic "structured" information, these should be easy to identify for them. I get that the acronyms link to the articles about the authorities, but this seems a secondary goal to achieve. —  HELLKNOWZ   ▎TALK 17:00, 18 March 2021 (UTC)
  • Support, to make the display more human-friendly. There is room for more improvement but the suggested display is vastly superior to the current example above. Schazjmd (talk) 17:02, 18 March 2021 (UTC)
  • Support the general idea of making the template more accessible to readers. Breaking it into categories is a good step. I'm less sure about removing the identifiers and linked acronyms: the former is useful if a reader wants to copy and paste it, the latter for understanding what they actually are. But those are details that can be worked out incrementally. I also agree with the sentiment below that, now Wikidata is a mature project, this template (which is a few years older) is now largely redundant. It might be an idea to go further and suppress links to authorities that don't provide any useful extra information, essentially turning the template into an automated component of the external links section. – Joe (talk) 17:12, 18 March 2021 (UTC)
  • Support of course, a no-brainer. Maybe add a TfD tag so more people see this discussion? Elli (talk | contribs) 17:15, 18 March 2021 (UTC)
  • Support in a very general sense, as I believe there's room for improvement of the template. I'm hesitant about some of the specific changes proposed, though. Converting to just external links without wikilinks or numbers looks great for an item like the example above with tons of identifiers, but might not for items with fewer identifiers. Adding sections makes the template longer and more likely to be confused with a navbox. {{u|Sdkb}} talk 17:37, 18 March 2021 (UTC)
  • Oppose While the the template could definitely be made better looking, I don't trust Fram to do it. This RfC was started without any previous discussion that I've seen at Template talk:Authority control, which would have been the logical venue. Fram has nominated the template for deletion, campaigned for removal of properties from it (e.g., Musicbrainz), and most recently created {{ACArt}} to systematically remove content from it (it is currently up for deletion). They are generally hostile to Wikidata, and seek to reduce the use of Wikidata here. It feels like this RfC is a trojan horse to continue doing that. Thanks. Mike Peel (talk) 17:40, 18 March 2021 (UTC)
    That isn't a valid oppose reason. The proposal doesn't say who will implement it, and presumably the implementation itself will be subject to further discussions and/or scrutiny (+ AGF etc). The idea behind the proposal is sound (as you've said), which is the matter of discussion here. Fram left a link to this RfC at that template talk when the RfC was written (a local consensus cannot override community sentiment on this template, which is present on 1.75 million articles). ProcrastinatingReader (talk) 17:53, 18 March 2021 (UTC)
    If Fram's not going to implement it, then they should have found someone that would before starting the discussion here (like discussing it on the template talk page, not just posting a link to this discussion). I said that it can be made better looking, which is generally true of most templates, but not necessarily like this (some extra whitespace would make reading it easier). Thanks. Mike Peel (talk) 17:59, 18 March 2021 (UTC)
    It doesn't look like a particularly difficult LUA change. 力 (power~enwiki, π, ν) 18:06, 18 March 2021 (UTC)
    This opposition is unfounded. I too disagreed with Fram's decision to create and add AC art without seeking a community consensus (and as such, supported deletion at TFD) but this proposal a clear backtracking of Fram to go through the system properly; seeking community consensus for what is (demonstrably—by the amount of support) a reasonable suggestion. Its also worth noting reminding everyone that this proposal does not change the amount of links being shown, which was the cause for dispute at the AC art TFD in the first place. I would urge Mike to AGF. Aza24 (talk) 08:31, 19 March 2021 (UTC)
    @Aza24: I have interacted with Fram on numerous times about Wikidata-related issues. Assuming good faith with them has long been worn out, I stand by my opposition here. They are not the right person to do this. Thanks. Mike Peel (talk) 09:31, 19 March 2021 (UTC)
    Dude I hope you never propose an RFC. Levivich harass/hound 17:22, 20 March 2021 (UTC)
    @Levivich: I propose them regularly, but I do the background work first (including discussion with at least some people) so that it can be implemented if passed. Thanks. Mike Peel (talk) 20:17, 20 March 2021 (UTC)
  • Support, broadly, improving the template, though I'm not sure exactly what this would look like, I trust our technically minded editors. I somehow doubt that Fram is trying to secretly attack wikidata or something by proposing this at a highly visible page, certainly much more visible than the authority control talk itself. Eddie891 Talk Work 17:58, 18 March 2021 (UTC)
  • (edit conflict) Strong support These are inscrutable to readers -- you know, the people Wikipedia is supposed to serve -- in their current state. Honestly, I don't expect them to turn into the most earth-shatteringly popular part of the project after this either, but they'd be a lot better than "actively useless". Vaticidalprophet 18:00, 18 March 2021 (UTC)
  • Support There may be users who need the ID numbers, but this is a definite improvement. SportingFlyer T·C 18:51, 18 March 2021 (UTC)
  • Support Don't need wikilinks to the IDs for every instance of the template. That is what the general help link is for. Likewise the new version is more descriptive as to what the IDs are, and doesn't look like a binary dump of abstracted codes. -- GreenC 20:49, 18 March 2021 (UTC)
  • Support anything that makes this business easier for readers to understand, or else why are we even doing it? Beeblebrox (talk) 23:54, 18 March 2021 (UTC)
  • Support Common sense proposal, it's far easier to understand than the existing method. ThePlatypusofDoom (talk) 01:20, 19 March 2021 (UTC)
  • Support Removing the link to the identifiers Wikipedia article is a tradeoff that I'm more than willing to make in order to get a more understandable template where you don't need to know obscure acronyms and look at meaningless IDs when using. Clear improvement for readers. --Trialpears (talk) 10:14, 19 March 2021 (UTC)
  • Unsure - I think I support the basic question at the top -- that it could be more user friendly -- but regarding the actual example I'm not so sure... and that makes me unsure whether there is a straightforward way to make it more user friendly without significantly increasing the amount of space it takes up.
    For example, while the section for libraries seems helpful, why is a direct link to "SUDOC (France)" more helpful to a reader than wikilinking what that even is before linking to the identifier? I agree that displaying the identifiers themselves probably doesn't add all that much value, but it does seem valuable to have both a wikilink and an external link (in which case, why not link the identifier rather than something arbitrary like "external" or "link"). — Rhododendrites talk \\ 14:54, 19 March 2021 (UTC)
    • The SUDOC identifier is used on 235000 pages, but Sudoc only gets 12 pageviews a day (unclear how many of those through the current authority control template, and how many in another way). The proposed version (which can be improved upon, and the "other" section may be one opportunity for this) immediately indicates to our readers where the info comes from: perhaps it would be better to indicate in which language the linked page is instead, but the basics are the same: if you are interested in Norwegian authority control for Ôe, by all means click on Bibsys: but you don't need to visit our Bibsys page first to be aware of this. Fram (talk) 15:08, 19 March 2021 (UTC)
      • But this doesn't explain why a direct link which just adds "France" (or even "French") is more user friendly than wikilinking to what that resource is in addition to the direct link. It seems like removing the wikilinks is a major part of this proposal. What I'm worried about is that the wikilinks seem quite useful, and that retaining them and breaking the template into sections and/or spelling out what they are may increase the amount of space it takes up to a degree some find unacceptable. Here's another idea (one which I'm not entirely convinced of myself, but while we're spitballing a bit...): have a section for the non-English sources and collapse it by default? We obviously cover topics from outside the English-speaking world, so retaining them would be important, but it's true that the vast majority of users of the English Wikipedia would not be looking for non-English resources. — Rhododendrites talk \\ 15:22, 19 March 2021 (UTC)
  • Support per proposal. ~ ToBeFree (talk) 13:53, 20 March 2021 (UTC)
  • Support change so long as implementation is thoroughly discussed. ɱ (talk) 14:04, 20 March 2021 (UTC)
  • Mixed - my first choice would be to shift the entire Authority Control process over to Wikidata (so all we would have here on WP would be a small unobtrusive box pointing editors to WD.)... however, if we are going to have Authority control links here on WP articles, I agree with Fram that we need to make them clearer for the average reader to understand. Unexplained abbreviations and ID strings are not helpful. So a more expansive template gets my hesitant support. Blueboar (talk) 16:34, 20 March 2021 (UTC)
  • Alternative proposal, like User:Blueboar, I'd prefer if Wikidata handled this directly, with Authority Control being a default template, instead of something people manually add. That said, with the current template, I'd keep/use the wiki links, but improve the readability by adding sections (National libraries etc..) and more descriptive names. It would become a fatter template, and that's worth testing. We can measure its effectiveness, by tracking the view count of the Wikilinks before/after. It doesn't need to be useful to everyone, but for the few people it's useful for, experimenting is worth a try! Shushugah (talk) 19:26, 20 March 2021 (UTC)
  • Support; removing numbers with no human-readable meaning improves the signal-to-noise ratio. I would also support going further and displaying the links only on Wikidata; pace librarians and archivists, these links are only of interest to such specialists. The links by and large do not help readers, do not meet the standards of usefulness, excessive length, etc. that we would require of external links in any other context, and do not merit blanket inclusion across over a million articles. Adumbrativus (talk) 22:29, 20 March 2021 (UTC)
  • Alternative / support-ish: I agree with the general gist of this, including better layout and using more plain English. However, I agree with Blueboar that interfacing more directly with Wikidata would make sense, and with Tom.Reding that the wikilinks are important (they allow the reader to find out what these databases and other sources are and what RS say about them, i.e. why they should care about / trust what they're about to click an external link to.  — SMcCandlish ☏ ¢ 😼  21:11, 21 March 2021 (UTC)
  • Support the proposal as written, but ... I am more supportive of scrapping the template altogether per several others below. I am always wary of anything that removes control of what appears in an enwiki article from enwiki editors (acknowledging the less preferred option to manually override the template’s parameters), a simple link to Wikidata would be more appropriate. Cavalryman (talk) 22:17, 21 March 2021 (UTC).
  • Support the general principle. A bunch of random numbers and letters won't mean much to most readers, so I think adding context will help. I'm fine with using WikiData as well, as long as we still have the template for readers to easily click to. — Wug·a·po·des​ 22:20, 21 March 2021 (UTC)
  • Support a change like this. I think that, from a reader's perspective, the current blob of data looks like something only relevant for computers, something Wikipedia-internal that's not relevant for me. With this change, I think readers would be more likely to click through to the libraries etc. for more information. For the links to our own articles on these systems (all the (identifier) links), I think they should be added to Help:Authority control. That'll only be one click more for interested readers, and they won't clutter up every single article. --rchard2scout (talk) 09:15, 22 March 2021 (UTC)
  • Support I was today years old when I actually figured out... vaguely...what authority control is. If it took me years to figure it out, then it's practically meaningless to newbies or readers. Our pages shouldn't have cryptic gobbledegook, it should all be plainly useful to the reader. CaptainEek Edits Ho Cap'n!⚓ 22:01, 22 March 2021 (UTC)
  • Support the concept or making this clearer. If it were collapsed by default, it would take less space and be more removed from the majority of readers who could care less while having the entire title bar to explain what it is to those that could make use of it: MB 03:45, 23 March 2021 (UTC)
  • Strong support all proposed changes: the encyclopedia serves readers, not editors or bots. The template is very non-user friendly. If it makes the information twice as accessible then it's worth halving the amount of it. Someone looking for the identifiers can find it from hovering over the URL, visiting the URL or visiting Wikidata. Fram makes a good argument about low pageviews meaning no-one is clicking on these wikilinks for identifiers that are supposedly useful to the reader (from what I can tell this is true as a rule, not just the one example given), so it's not a loss to remove them. Even if all else fails, I hope reorganization into sections by provenance of identifier, rather than the current alphabet soup, will be implemented as I don't think the opposers are opposed to specifically that part of the proposal. — Bilorv (talk) 00:47, 24 March 2021 (UTC)
  • Support I sympathize with those that want links the Wikipedia articles on the various databases, but that feature is not worth the inherit confusion that stems from giving readers a large set of unfamiliar acronyms, this is much clearer. Aza24 (talk) 02:06, 24 March 2021 (UTC)
  • Support making the template more human-readable. The specifics can be worked out later, but even if the exact proposed template was adopted, I think that would be an improvement. Ajpolino (talk) 21:21, 25 March 2021 (UTC)
  • Support anything to make the template more user-friendly, but prefer the suggestions of User:Blueboar and others of a more drastic overhaul and or replacement. TheEmeraldBeyond (talk) 23:04, 26 March 2021 (UTC)
  • Support making the template readableto the average reader Asartea Talk | Contribs 09:01, 28 March 2021 (UTC)

Alternate formatting

Discussion re: Authority control itself

I am still confused by the purpose the Authority control template. I looked at the template page itself, and it explains WHAT it does, but not WHY it does it. Is there a page or discussion that explains the purpose of having such metadata in our articles? Blueboar (talk) 12:12, 18 March 2021 (UTC)

It's linked in the template... Help:Authority control. Izno (talk) 15:03, 18 March 2021 (UTC)
A lot of the information on that page is wrong though or severely outdated (compare the concise 5-link authority control template shown for Alexander Graham Bell with the current 27-link bloat). Basically, everything that is described there is done through Wikidata (and if there are outside applications that rely on the template on enwiki directly, they should be rewritten by someone more competent), not through Enwiki, except linking readers to some of the databases listed. Every researcher and application that needs unique IDs should do this through Wikidata, which is the source, and not through enwiki, which is a partial mirror for this information only. Bus this discussion, while necessary, is separate from the RfC. Fram (talk) 15:17, 18 March 2021 (UTC)
I feel like this template only exists so folks can mass-add it to articles. Pretty sure it offers 0 benefit to readers, at least in its current structure which is just an obscure bunch of numbers and abbreviations. ProcrastinatingReader (talk) 15:22, 18 March 2021 (UTC)
For what it's worth, I have found it useful in several cases, especially with regard to reconciling data about BLPs (not as a reliable source, of course). Occasionally I've had dates of births that didn't match across cross-wiki articles and I was able to use the various authority control to figure out what was most likely correct. I've basically treated it as an alternative to WikiData when needing structured information about somebody. The pitfall, of course, is that authority control isn't a reliable source in the same way that WikiData isn't. I would be interested to know what possible use cases it has for actual readers who aren't looking to edit the page it's on. Perryprog (talk) 13:05, 19 March 2021 (UTC)
Agree with those above saying that the template is pretty useless almost anywhere in Wikipedia. Wikidata should do the matching of unique identifiers. Mirroring that in Wikipedia is odd at best (that is, for those understanding what it means); and completely incomprehensible for the majority. I can't support Fram's OP proposal of this RfC (neatly organized redundancy... is still redundancy... it just occupies even more space while I would reduce that space to zero), but I'd gladly support any proposal that would discourage the widespread usage of the template in English Wikipedia. --Francis Schonken (talk) 16:00, 18 March 2021 (UTC)
It’s already been mass-added to every other article. With 1.75 million transclusions, I think the ship has sailed to discourage even more use. If we can’t get it blanked/removed (which I’d support), reforming it to not be useless is the next best thing imo. ProcrastinatingReader (talk) 16:09, 18 March 2021 (UTC)
This isn't really mirroring it, it's displaying it. You could make a similar argument for removal of infoboxes. Elli (talk | contribs) 16:47, 18 March 2021 (UTC)
Most infoboxes don't mirror Wikidata info though, but get their input locally: and more importantly, most infoboxes are self-explanatory, they add on their own understandable info with direct use for many readers (though there as well a significant group doesn't like them). Fram (talk) 17:01, 18 March 2021 (UTC)
The infoboxes getting their input locally is arguable more of a "mirroring" than authority control pulling from Wikidata is. I do generally like your idea for reforming the template. Elli (talk | contribs) 17:03, 18 March 2021 (UTC)
It's useful in the same way that references are. You can find more info in the links, or confirm content in the article. Thanks. Mike Peel (talk) 17:43, 18 March 2021 (UTC)
References verify information written in the article. External links, which do not, are bound by the WP:EL guideline, which states: it is not Wikipedia's purpose to include a lengthy or comprehensive list of external links related to each topic. No page should be linked from a Wikipedia article unless its inclusion is justifiable according to this guideline and common sense. The burden of providing this justification is on the person who wants to include an external link. Authority control is the exemption to the rule, not the rule. ProcrastinatingReader (talk) 18:24, 18 March 2021 (UTC)
"External links... are bound by the WP:EL guideline" Nope. It's a guideline. Nothing is "bound" by it. Besides, Wikipedia guidelines are supposed to describe, not proscribe, current practice. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:41, 19 March 2021 (UTC)
As usual, WP:JUSTAGUIDELINE is the weakest of all possible rationales. How about WP:NOT#LINK? ProcrastinatingReader (talk) 15:52, 19 March 2021 (UTC)
  • Thank you for the pointer. Wouldn’t a simple (small) box with a link to Wikidata (perhaps saying: “Wikidata has a page on this subject: see here”) serve the same purpose? Blueboar (talk) 18:05, 18 March 2021 (UTC)
Much like the link to Commons or Wikiquote? Thats sounds like a good idea too. Lugnuts Fire Walk with Me 08:04, 19 March 2021 (UTC)
Wikidata is not exactly meant to be browsed, and it shows in its design, so directing readers that way is not ideal. It's meant for retrieval, which is what the AC template accomplishes. – Finnusertop (talk ⋅ contribs) 10:35, 19 March 2021 (UTC)
  • Beyond doing what's in the name, authority control puts a Wikipedia article about a subject in connection with other resources about the same subject. It basically does what our external links section does. But whereas lots of links in an EL section quickly bloat and take up too much page space, this template packs a ton of resources into a [relatively] small box tucked away at the bottom of a page. While most users probably don't notice it (ditto categories and other elements on the fringes of an article), I've talked to an awful lot of librarians, researchers, archivists, etc. who really value it. (This is a response to this sub-section, not an opinion about the RfC itself). — Rhododendrites talk \\ 14:41, 19 March 2021 (UTC)
  • Isn't itpart of the idea behind Wikidata that this sort of information woould be moved there? DGG ( talk ) 06:02, 21 March 2021 (UTC)
    @DGG: the data lives on Wikidata, this just makes it visible on Wikipedia. Elli (talk | contribs) 05:36, 22 March 2021 (UTC)
    • There is no question that the data is useful for librarians, etc. The question is: Do we actually need/want that data visible here on WP... or do we want the data to be visible at Wikidata. Blueboar (talk) 13:02, 22 March 2021 (UTC)
there are times when such identifiers are needed to make it clear what the article is actually about, and they can be the best entry point into further information. But they are sometimes inconsistent, sometime erroneous, notably OCLC, and often reflect mere format variations, notably ISBN,. The practice of libraries confronted with this chaos is to record all available identifiers without trying to harmonize them--that's more in the realm of bibliographers. (Though I have sometimes resorted to analyzing them on WP, to elucidate the publication history of a periodical, usually on a talk p, because it is in a sense OR,). I have never tried to work with this on wikidata, as in the past the quality has been so erratic as to be discouraging, but I know the editors there are trying to clean it up as they can). The question then , as was said just above, is what part of this belongs in WP. For journal articles, I think the doi does--it's quite reliable. For books, I usually enter one ISBN, if possible for the print edition which tends to be more stable (unless OCLC record only th electronic version of what is actually a print book also). For identifying individuals, nothing that I know of is reliable. The one source for authors I know and can prove to be totally unreliable is LC after around 1960-70, and OCLC records or international cataloging records derived from LC, for if the information about the identity of the author is not immediately obvious from the title page of the book, they simply copy it from Wikipedia--and they seem to be doing so increasingly. . DGG ( talk ) 20:45, 22 March 2021 (UTC)
Remember WP:SAYWHEREYOUREADIT If you've read it in a book, then use the ISBN printed in the book. Martin of Sheffield (talk) 22:23, 22 March 2021 (UTC)

Authority control in mobile view

This is another thing to consider about changing Authority control to be more reader friendly. Currently the template is not visible in mobile view at all. A template used in over 1.7 million articles must be visible to mobile device readers, who form a significant part of readership. current result of the Authority Control template looks like this; I am reading this from mobile and all I see is a blank line. AVSmalnad77 talk 17:47, 18 March 2021 (UTC)

This is under discussion at the authority control talk page. That said, this is true of all navboxes today, which is a hard problem to solve. Izno (talk) 18:01, 18 March 2021 (UTC)
{{Authority control}} is a navbox, and all navboxes are disabled in the mobile view. It's been an outstanding bug for several years; see T124168. – Joe (talk) 18:08, 18 March 2021 (UTC)
Sad that it has been tagged as low priority. That explains why it has been pending for years. I hope they will provide more support for mobile users. AVSmalnad77 talk 02:55, 19 March 2021 (UTC)
It is trivial to enable again, but if we did it would look like in this video https://www.youtube.com/watch?v=eaos1s3UfLs. I think that is worse than the status quo and the template would need a significant redesign to solve it. If we had an agreed direction to go in to improve it I guess it would be doable. --Trialpears (talk) 10:10, 19 March 2021 (UTC)
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.

RfC: Modification of Agatheira for syntactic compliance with linguistic precision guidelines

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.
Edit replacing hyphen with en-dash made. Please yell at me for closing my own RfC next April 1.[April Fools!] {{u|Sdkb}} talk 03:24, 2 April 2021 (UTC)

Following workshopping at the most recent Wikimania and extensive consultation with the WMF, Blippers, and an external archeological consultant I happen to know off-wiki, I am pleased to present this landmark RfC regarding a significant stylistic overhaul of Agatheira that could establish an enduring precedent for our ancient Turkish city articles and reaffirm the Manual of Style's authoritative status vis a vis matters of punctuation.

Background

First, some essential context. Agatheira has long been known as one of WikiProject Classical Greece and Rome's articles. Although it arguably suffered an indignity or two on its talk page early on, its five primary editors have worked to develop it to its current status as a standout example of our coverage of ancient Lydian towns located near Halitpaşa. It has averaged pageviews per day and experienced a particular surge of popularity last August for obvious reasons. Many of you who edit in the area may also recall the major overhaul it underwent last December.

Guiding principles

Wikipedia's Manual of Style (MOS, Mos, or MoS) has provided authoritative guidance on grammatical matters on Wikipedia since its creation in October 2001. During this time, it has served as a crucial force for standardization of capitalization, punctuation, and more. One of the most comprehensive sections of the Mos, the section on dashes, stretches to more than 14,000 characters and covers a variety of dash-related concerns. Of particular relevance to this RfC is the clause within the "In ranges that might otherwise be expressed with to or through" level-5 subsection, which states the following: For ranges between numbers, dates, or times, use an en dash. The precise date when this clause was added is not currently known, but it has been present at least since last April.

Proposal

In the current revision of Agatheira, the second sentence of the second paragraph includes the phrase during the reign of Eumenes II (188-158 BC). This RfC asks whether it should be changed to during the reign of Eumenes II (188–158 BC), replacing the current hyphen with an en-dash. Feel free to share your thoughts on that question below. Given the potentially charged and controversial nature of this area, please remember to keep personal attacks to a minimum and to ground your arguments in Wikipedia policy (including IAR as needed). Please also remember to keep your comments concise to respect the volunteer nature of the project. - {{u|Sdkb}} talk 01:00, 1 April 2021 (UTC)[April Fools!]

Survey (Agatheira)

  • Support in the strongest possible terms, but only if "BC" is changed to "BCE" in this and all related articles (where the definition of "related" is determined by a new RFC to be started immediately after the closure of this one). This is a hill I will die on, so come at me! – Jonesey95 (talk) 02:05, 1 April 2021 (UTC)
  • Opport or Suppose as long as a thin space is included somewhere on the page, or perhaps a hair space, but no minus signs, indifferent on whether the page has hyphen minus, and does anyone actually care about the em dash vs spaced en dash thingie. So confusing. 2A03:F80:32:194:71:227:81:1 (talk) 02:07, 1 April 2021 (UTC)
  • Prefer a 3/4 em-dash. –Fredddie™ 02:25, 1 April 2021 (UTC)
  • Please follow contemporary reliable sources. What did the historians at the time of Eumenes II prefer? Is there archeological evidence regarding the preferred chisel blade widths? What did the Library of Alexandria style manual specify? isaacl (talk) 02:28, 1 April 2021 (UTC)
Question: is this a serious RfC or has the {{humor}} template been forgotten? JavaHurricane 04:06, 1 April 2021 (UTC)
@JavaHurricane: the proposal is tagged with {{April Fools}}, though the fact that some people are aren't sure is a good sign this is at least somewhat clever. 2A03:F80:32:194:71:227:81:1 (talk) 05:26, 1 April 2021 (UTC)
Either these are not true spies I wear in my head, or I don't see the relevant template anywhere. JavaHurricane 05:49, 1 April 2021 (UTC)
@JavaHurricane: Probably the former as it's right after the signature (ctrl+f may be helpful). 2A03:F80:32:194:71:227:81:1 (talk) 13:55, 1 April 2021 (UTC)
I see it now. It is already a small template; and on mobile it is hard to catch. JavaHurricane 14:20, 1 April 2021 (UTC)
  • Counter-proposal: the en-dash is slightly longer than the hyphen and it would therefore seem logical to link its usage to the period of time being described. My proposal is that, for spans of years of fifty and above, the en-dash be used - with the hyphen then reserved for shorter periods. This would give the alert reader a visual clue as to the length of time being described, even if they aren’t so good at mental arithmetic. The only potential flaw I can see with this proposal is that some editors may not cope with there actually being some logic behind WP's policy on dashes. MapReader (talk) 06:17, 1 April 2021 (UTC)
Excellent idea. Could we use a central dot (•) for periods of less than a year. An em dash (—) ought to be used for millennia except for US-related issues when it could be used for centuries due to their shorter history. Martin of Sheffield (talk) 08:40, 1 April 2021 (UTC)
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.

Portal needs new section giving latest updates in the portal

Each portal of the Wikipedia should have two more sections giving 1. new pages added last month and 2. major edits done last month within the scope of the perticular portal. That would assist in knowing the current trends in the subject area. --Dattatray Sankpal (talk) 15:48, 2 April 2021 (UTC)

That would be totally unworkable. Most Wikipedia portals are totally moribund; those that are still active, like Portal:History, have such broad scopes that there are probably upwards of 100,000 non-minor edits within their purview in any given month. See a typical Article Alerts page for an idea of just how sprawling such a list would be, noting that Article Alerts only covers major changes in status like deletion proposals, and doesn't include vanilla editing. If you want a list of new articles within a given project's scope, see User:AlexNewArtBot#Currently supported. ‑ Iridescent 16:37, 2 April 2021 (UTC)

RFC: Should certain succession box content be deleted?

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.
(non-admin closure) There is consensus not to have "Oldest-living British prime minister" as a succession box due to its trivial nature. There is no consensus on anything else. User:力 (power~enwiki, π, ν) 19:21, 2 April 2021 (UTC) There is a clear sense that "trivial" succession boxes should be removed, but no consensus as to what makes a succession box trivial (apart from on the specific example mentioned in the RFC statement). There is no consensus on how or where discussions to remove succession boxes should proceed; the status quo is that either this page or a WikiProject could host an RFC. There is no consensus on whether succession boxes in general should be re-worked or removed completely. User:力 (power~enwiki, π, ν) 19:21, 2 April 2021 (UTC)


Should we delete succession box content such as the following? Examples: "Oldest-living British prime minister". What say all of you? GoodDay (talk) 21:57, 4 February 2021 (UTC)

Survey (succession boxes)

  • Yes. We ought not to have any of that trivia in succession boxes. There are often many boxes, dozens even, and additional clutter is unhelpful. One would be very hard-pressed to find reliable sources discussing how James Callaghan "succeeded" Alex Douglas-Home as the oldest British prime minister, and I dare say that no biography of either of them mentions it. Surtsicna (talk) 22:15, 4 February 2021 (UTC)
  • Yes. Only posts with transitions (or successions) would need succession boxes. -- Kautilya3 (talk) 22:56, 4 February 2021 (UTC)
  • Not here. Trivia should be deleted, non-trivia should not be. Whether any specific succession is or is not trivia needs discussing individually at an appropriate forum - that forum is very much not here. Thryduulf (talk) 02:21, 5 February 2021 (UTC)
  • No As Thryduulf says trivial ones should be, non-trivial ones should not be. That needs to be done on a case by case basis. -DJSasso (talk) 18:03, 5 February 2021 (UTC)
  • Yes I find succession boxes unnecessary in general since they usually duplicate the infobox, a navbox, and/or the text. When it's not duplicative like this example, it's often trivial that doesn't need a box to itself. Reywas92Talk 19:36, 5 February 2021 (UTC)
    • You dislike them, whereas I find the clear, consistent presentation extremely useful. Succession boxes, infoboxes, navboxes and prose all serve different functions and so the same link appearing in more than one place is a Good Thing. Some succession boxes should be removed, but most should not be. Which is the case for any given succession box can only be determined by a consensus discussion about the succession box in question. Thryduulf (talk) 01:04, 6 February 2021 (UTC)
  • Yes and would support getting rid of them all. Redundant and pointless clutter. Why not have separate boxes for marriages, spouses, and works dispersed througout the article while we're at it? ~ HAL333 02:50, 6 February 2021 (UTC)
    • What are they redundant to? Links in prose and links in succession boxes have different purposes so they are not redundant to each other. Boxes (for anything) scattered throughout the prose would be completely disruptive to the prose, which is why succession boxes are not placed in the middle of the prose? Thryduulf (talk) 11:58, 6 February 2021 (UTC)
  • Yes - Not sure we even need them for positions, but definitely not for superlatives. Levivich harass/hound 17:22, 6 February 2021 (UTC)
  • Comment: I feel the validity or triviality of succession boxes should be discussed on a case by case basis on their respective talk page. Not sure what a global decision one way or another on "trivial" succession boxes could achieve, when it does nothing to establish what is trivial and what is not. PraiseVivec (talk) 14:01, 7 February 2021 (UTC)
  • Yes for purely trivia succession box such as "oldest living X" - unless said role is notable in its own right (not sure if this actually applies anywhere). Elliot321 (talk | contribs) 05:54, 14 February 2021 (UTC)
  • Yes certain ones should be deleted. At a minimum, the spirit of WP:NAVBOX #4 seems applicable: There should be a Wikipedia article on the subject of the succession box.—Bagumba (talk) 10:11, 22 February 2021 (UTC)
  • Depends - Yes for "Oldest-living British prime minister" "successions" as trivia, but without a discussion on others is will depend on the case, this should not be used as consensus to delete non-cited examples. KylieTastic (talk) 10:15, 23 February 2021 (UTC)
  • Yes Succession boxes are not needed, in most cases it's a duplicate.Sea Ane (talk) 21:43, 26 February 2021 (UTC)
  • Oppose deciding this specific one here, support a general rethink of succession/navboxes and what they are good for (if anything). Most of the succession boxes at John Major are less trivial, but there are so many of them that they are not a useful way to navigate anything, and are hidden away by default (just like the ungodly amount of navboxes). Once an article has more than three succession boxes, they tend to stop being useful. —Kusma (t·c) 21:50, 1 March 2021 (UTC)
  • Yes - A lot of succession boxes seem to be pure trivia. If there isn't an article for the topic it shouldn't exist as a succession box. Nosferattus (talk) 04:05, 9 March 2021 (UTC)
  • ? Oppose Confused, how can this RFC decide anything? The RFC is vague and the answers equally ambiguous; everyone saying "Yes" is supporting something different. Who decides which ones are trivial? Aza24 (talk) 23:34, 15 March 2021 (UTC)
  • Yes, some succession box material should be eliminated, In the example given, Oldest-living Prime Minister is treated like being an athletic record holder, a recognized and lauded accomplishment as opposed to the simple inconsequential happenstance that it is. You might as well have 'Tallest living Prime Minister'. 'Poorest living Prime Minister', or 'Living Prime Minister with the smallest left testicle'. Agricolae (talk) 19:09, 2 April 2021 (UTC)

Discussion (succession boxes)

  • Why? Ivanvector's squirrel (trees/nuts) 22:17, 4 February 2021 (UTC)
    Because, those are not political or party offices. They're merely trivial. GoodDay (talk) 22:19, 4 February 2021 (UTC)
    Why do we need a global policy or guideline or anything about this? If you think a given succession box is trivia, discuss that specific succession box somewhere (talk page, WikiProject, TfD, there are plenty of venues). I genuinely don't understand what you are trying to achieve here - there is no chance that there will be a consensus that we should have succession boxes for everything (10th place qualifier in a British Touring Car Championship race as an unquestionable example), but with the wording of the discussion you cannot get consensus (for or against) regarding any individual example. Thryduulf (talk) 02:18, 5 February 2021 (UTC)
    You expect there to be a separate discussion on each individual bio article? Anyways, I don't exactly know what you're posting about. GoodDay (talk) 17:29, 5 February 2021 (UTC)
    I expect you to get consensus for each individual succession. That could be on an article talk page or a centralised discussion. e.g. if you want to get rid of oldest living British Prime Minister, you need to have a discussion specifically about removing the "oldest living British Prime Minister" succession box from every article it appears on, with notifications to (at least) the talk page of all the affected articles. In other words you need to do exactly the same as you would for any other bulk change. Thryduulf (talk) 22:26, 5 February 2021 (UTC)
    That's too time consuming. There's too many 'useless' topics in these succession boxes, to go through one-by-one. GoodDay (talk) 22:30, 5 February 2021 (UTC)
    A centralised discussion about the succ boxes for oldest living British Prime Minister could be held at Wikipedia talk:WikiProject Politics of the United Kingdom. --Redrose64 🌹 (talk) 23:40, 5 February 2021 (UTC)
    But the British prime ministers example, is just one example of these trivial topics in suc-boxes. GoodDay (talk) 23:41, 5 February 2021 (UTC)
    The issue is that we have no idea what other succession boxes you regard as trivial so we (and most importantly editors of the articles they appear on) have no way of knowing whether we agree or disagree. While oldest living British Prime Minister doesn't seem very useful, others such as Prime Minister of the United Kingdom is very much not trivial, where to draw the line between them needs to be determined by consensus. Thryduulf (talk) 00:59, 6 February 2021 (UTC)
    Subjects like "Tallest President of country", "Fattest Prime Minister of country", "Oldest Stock Car racer", "Youngest 100 meter dasher", would be trivial topics for suc-boxes. GoodDay (talk) 02:18, 6 February 2021 (UTC)
    The first two undoubtedly would be trivial, the latter two maybe - it would depend if there was any significance given to this in reliable sources. However a short list of topics (which a cursory search suggests are not in use) that you consider trivial do not go any way towards addressing the issue in my comment. Thryduulf (talk) 18:20, 6 February 2021 (UTC)
    I don't know what your complaint is. Perhaps if you would put down examples of suc-box topics that you believe should & shouldn't be deleted, would help. GoodDay (talk) 18:26, 6 February 2021 (UTC)
    My point is that they need to be discussed individually or in small, closely related groups (e.g. perhaps succession boxes related to British Prime Ministers). No matter how many examples are listed here you cannot get consensus for anything not listed here, and the more examples you list here the greater the liklihood of a trainwreck. Thryduulf (talk) 00:10, 7 February 2021 (UTC)
    RFC is already in full swing. We'll see how it ends up. GoodDay (talk) 00:47, 7 February 2021 (UTC)
    Consensus that some but not all succession boxes should be removed, but no consensus for the removal of any one in particular - that will need further discussion. It's pretty much the only way it can end. Thryduulf (talk) 02:20, 7 February 2021 (UTC)
    Besides, I find Wiki-Projects tend to garner less attention. Was considering moving another RFC to Village Pump, for the same reason. GoodDay (talk) 23:55, 5 February 2021 (UTC)
    Your subjective opinion that something is "Too time consuming" does not grant you the right to ignore WP:CONSENSUS. If you propose a course of action on a WikiProject and advertise the discussion to the relevant talk pages but nobody opines after a reasonable time (~week) then you can go ahead and remove the succession boxes listed in the discussion. Thryduulf (talk) 00:59, 6 February 2021 (UTC)
    If you want to advertise this RFC on the related WikiProjects? then by all means, do so. GoodDay (talk) 02:18, 6 February 2021 (UTC)
    If this discussion was actually about specific succession boxes that would be appropriate, but as the discussion is actually a vaugie and unfocused attempt to get rid of an unspecified list of succession boxes you (or presumably any other editor) personally dislikes then it is impossible to know which projects and articles are relevant. On the other hand, if you did deign to list those boxes you deem trivia, then it would I suspect rapidly become a trainwreck due to the large number of disparate boxes editors will have different opinions about. Thryduulf (talk) 11:55, 6 February 2021 (UTC)
    Since my concerns grew out of the discussion at James Callaghan, one would link to Political WikiProjects. GoodDay (talk) 18:41, 6 February 2021 (UTC)
All should be delete as links spam due to duplication of links and undue because of overwhelming size. Never understood why we have giant boxes with very few links in them overwhelming the sections. It's definitely a point of contention for content editor that these undue boxes are spamed automatically without consideration of over linking or unwarranted linking.--Moxy 🍁 00:04, 6 February 2021 (UTC)
Very simply because many (not all) of the succession boxes are very useful for readers. Thryduulf (talk) 00:59, 6 February 2021 (UTC)
Not sure how duplication of lnks and overwhelm sections is good for readers. We have protocols for these 2 points....just ignored by template spammers.— Preceding unsigned comment added by Moxy (talk • contribs) 01:19, 6 February 2021 (UTC)
See my reply in the section above for why duplication is not a problem, and I disagree that the presentation is overwhelming. That some succession boxes are trivia does not mean every succession box is spam. Thryduulf (talk) 01:41, 6 February 2021 (UTC)
We will simply have to disagree. By placement practice alone indicates there very low value to the community. See also links dumped at the bottom of articles because they duplicate existing links and the format is not responsible anywhere else in the articles. It's horrible that these boxes are more prominent than the actual topic-specific navigation boxes. Odd they were not omitted from mobile view as load junk.--Moxy 🍁 02:01, 6 February 2021 (UTC)
How does placement indicate they are low value? Of course the format is not appropriate anywhere else in the article - see also links and links in succession boxes have a completely different purpose to links in the prose. You need to explain why the duplication is problematic. Thryduulf (talk) 11:55, 6 February 2021 (UTC)
It's why we have a guideline on this..... distracts readers from the links that are actually important Wikipedia:Overlink crisis. They are so overwhelming that editors hide them in collapsible templates Abraham Lincoln#External links. In many other cases the amount of them is simply overwhelming...mass link spam John A. Macdonald#External links.--Moxy 🍁 17:59, 6 February 2021 (UTC)
You've explained why you think having too many boxes is an issue, and reiterated your opinion that some boxes are low value (which basically nobody is disagreeing with). However you have not explained why having any boxes is problematic or why their position in the article indicates this. Thryduulf (talk) 20:24, 7 March 2021 (UTC)
As I said in my oppose above, who ever closes this is going to find themselves in an impossible situation. There is no uniformity in any of the "Yes" comments. Additionally what does "certain succession box content" even mean?—who decides which ones are being discussed? Aza24 (talk) 23:08, 24 March 2021 (UTC)
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.

Union between IP address and account

Before joining Wikipedia I changed with the IP address. I would like "merge" the contributions of the IP address to my account. Dr Salvus 13:04, 31 March 2021 (UTC)

Shooters

I'd like to propose that Wikipedia stop publishing the names of mass shooters. They do it for notoriety. They want to be remembered as a martyr for violence. Don't give it to them. It also stigmatizes their family members that had nothing to do with their vile acts. Publish where they're from, age, gender, race, background, but not their name. Don't give them the satisfaction of continuing to torture people. — Preceding unsigned comment added by Turtle595 (talk • contribs) 21:00, 30 March 2021 (UTC)

  • While I am sympathetic to your cause, Wikipedia is not censored. We do avoid using the names of minors and take other steps to protect the victims, it is our job as an encyclopedia to document notable events in a neutral manner. If we avoid using the names of guilty parties, it is unlikely it would make a difference in the amount of violence in the world. Dennis Brown - 2¢ 21:37, 30 March 2021 (UTC)
    That's not even true that we 'avoid using the names of minors'. Take Columbine, for example. They were minors (at least one of them was), and we print their names. As well as the names of the victims that were minors, and the bystanders that were minors, we print their names too. Notability and reliable sources are what determine what we print, and we don't censor the names of minors whose names are published in reliable sources. To some extent, I agree with the OP, in cases especially where the shooters name does not become notable. But...it is what it is.. Firejuggler86 (talk) 22:19, 2 April 2021 (UTC)
  • I'd also like to add that we almost always follow the reliable sources (in this case the media) on naming the accused. In basically all shootings we've covered, the shooter's name is already public knowledge. I think Turtle595's desire to deny recognition to mass murderers is admirable, but this really isn't something we can do as an encyclopedia. Spirit of Eagle (talk) 23:56, 31 March 2021 (UTC)
    • We're actually not required to. WP:BLPCRIME cautions us from including names of non-notable, non-public figures simply accused of a crime. Now, arguably, waaay down the road, if a shooter is caught, they will likely be tried and found guilty, at which point the name will obviously be appropriate to include, and the act of hiding the name before that point may seem pointless. My personal preference would be to omit until conviction, but obviously that's difficult to enforce, but I'd like to see more distinction made on including names of shooters or suspects where they were caught at the scene or nearby and where there is little doubt the person was reponsible for the action, compared to people that are arrested some significant time later and their connection is unclear. Eg in considering the D.C. sniper attacks, it took time for the authorities to identify the shooters, and while they were named shortly after arrest, it wasn't necessary clear they were necessarily the guilty parties, so between the time of arrest and the moment of conviction, we aught to not include their names. --Masem (t) 22:30, 2 April 2021 (UTC)

notifications of indef blocked users

This is something that just kind of bothers me and I'm not sure I have a good solution to it but thought a discussion might be productive. Sometimes, very long-term users end up indef blocked, and over time many things they created are nominated for deletion. Notifying someone who has been blocked for years seems unproductive and kind fo like kicking them when they are down. I'm not by any means suggesting these nominations or notifications are done in bad faith, in many cases the notifications are done by automated tools anyway. And that might be where a tweak could be made. I use a script that automatically puts a line at the top of any user page or talk page telling me how long a user has been registered, what user rights they have, and will also inform me if they are blocked. For example, right now on my own user page it displays as A checkuser, oversighter, and administrator, 13 years 7 months old, with 96,136 edits. Last edited 27 minutes ago. If that functionality is compatible with Twinkle or other such tools, they could pop up and ask if the user is sure they want to notify, something like <USER> is blocked and their last edit was 342 days ago, do you wish to proceed?. Does that make sense and/or seem reasonable to anyone else or is it just me? Beeblebrox (talk) 20:11, 9 March 2021 (UTC)

I've been bothered by the same thing, and I think it's a reasonable suggestion. There are also people who've formally left the project, so it should account for people who haven't been blocked but are just plain gone. Acroterion (talk) 20:16, 9 March 2021 (UTC)
(edit conflict) Seems reasonable to me. I prefer to nominate pages for deletion manually rather than using Twinkle, and skip notifying indefinitely blocked users, or users who have been inactive for a long time (I'm not consistent about how long). Although, I once got personally attacked on Meta for not notifying an indefinitely blocked user ... * Pppery * it has begun... 20:19, 9 March 2021 (UTC)
  • Leaving the same courtesy notifications that you would on any unblocked user's talk page is not WP:GRAVEDANCING, not kicking them when they're down. And it's a mistake to assume that those notifications serve only that user. There have been numerous occasions when notices on an indef blocked user's talk page helped me find an old deletion discussion, or discern a pattern in their behavior. Such patterns have led to further cleanup and to the unmasking of sockpuppets. Perhaps such breadcrumbs aren't as important to admins, who I assume can see deleted pages and revisions. As a non-admin, I hope no one stops leaving notices on the talk pages of blocked users. --Worldbruce (talk) 23:13, 9 March 2021 (UTC)
  • I agree with what Worldbruce said above. Also a surprising number of highly productive editors have been indef-blocked, and they have often created significant pages, templates, images, etc., where a wider notification pool may be good. Furthermore, an indef-block is not always forever, and they might return one day to address any issues, or catch up, even if they miss the relevant discussion at the time. And if a page is bothering you, you can always unwatch it. However I also agree with Beeblebrox that people should have the information in a convenient place to opt out of notifying users. Ideally people should be taking the extra few seconds to look at contribs anyway, before choosing the relevant tickbox in Twinkle, but it is what it is. I would guess that it would be relatively easy to implement in Twinkle if it isn't already - you would want to speak to the Twinkle developers. -- zzuuzz (talk) 23:56, 9 March 2021 (UTC)
  • How many of these scripts respect {{nobots}} and might that be something indef'd editors can be made aware of? I get the reasons above about the benefits of allowing these notifications, but it strikes me as similar to don't template the regulars: it's not wrong or forbidden, but just kinda tone-deaf. We should be up-front about the option, and let current editors make their own decisions on whether to template indef'd editors. I'd be fine preventing it by default. — Wug·a·po·des​ 01:36, 10 March 2021 (UTC)
  • The problem here is that productive users have been blocked. For example, I was just reviewing the history of a couple of articles and noticed that Hullaballoo Wolfowitz had made some useful contributions. But they are currently blocked for a period of six months – a remarkably draconian and unproductive punishment. In such cases of obvious injustice, I will typically put that user's talk page on my watchlist so that I may observe any such notifications and take appropropriate action. HW's talk page has over 300 watchers and the notifications are for them as well as the primary user. So far, in that case, we have had one of Gerda's Precious anniversaries which serves to remind us that this block is disruptive. So, the appropriate action in this case is to remove the block – the OP should please oblige. Andrew🐉(talk) 11:47, 10 March 2021 (UTC)
    • See the ANI discussion which led to the block and especially note the discussion following it where the length was explained and endorsed. Andrew you might want to read up on WP:ADMINSHOPping. — Wug·a·po·des​ 20:38, 10 March 2021 (UTC)
      • An overly harsh block for pretty insignificant abuse. The effect of the block is worse than what it was addressing. Anyway for a 6 month block, notifications are still worthwhile to get on the topic of this discussion. Graeme Bartlett (talk) 00:06, 11 March 2021 (UTC)
        • An ... block for ... abuse. fixed that for you Graeme. You might want to try reading the discussion I linked, especially the part where I said even people defending HW pointed out a pattern of incivility, they simply try to excuse it through various means. If you're interested in more than just taking cheap shots at me and want to challenge the close, you know where AN is. — Wug·a·po·des​ 00:53, 16 March 2021 (UTC)
  • This is one I have struggled with, I don’t like the perception of grave dancing, but when nominating an article for discussion I have sometimes left a message for blocked users wondering if (hoping) one of their former collaborators might maintain a watch on their TP and have an interest in or knowledge of subject matter. Cavalryman (talk) 22:02, 10 March 2021 (UTC).
  • This is an interesting discussion. I'm not so concerned about any perceived awkwardness or impoliteness in leaving such a notice on a blocked user's talkpage, as I am in the productiveness of it. As people are saying, it is better to leave such a message rather than none at all, because then the message is at least seen, but if the user has few or no talkpage watchers, or if the user is not blocked, but simply inactive, then notifying just the first editor may not be productive at all. And even if the first editor is still active, they may not be the person who is most interested in the article. Some first editors make just the initial edit or two, and then leave the article, and it may get built up by other editors. I think it may be useful to have an added functionality in the automated tool to notify the first editor AND the most productive editor (perhaps with some added clause such as that the most productive editor should be unblocked, and have made an edit on Wikipedia in the previous month). SilkTork (talk) 09:21, 12 March 2021 (UTC)
  • What Silktork said. There are articles where one creates, but another fleshes it out and has more of a vested interest in the article, so expanding notifications to those people is worthwhile. As for notifying someone who is indef blocked, I certainly don't see it as gravedancing, it is simply treating them like anyone else here, which is technically what we are supposed to do unless they are actually banned. It may be less than ideal in some ways, but it is the lesser of the two available evils. Even if indef blocked, by being notified, they can at least know it up for deletion, and ask someone else to look into it (which isn't the same as proxy editing), or a talk page watcher can look into it, putting more eyes on it. Not every solution is perfect, but I think the current system is the least un-perfect. Dennis Brown - 2¢ 10:13, 12 March 2021 (UTC)
  • Just to be clear, the only thing I was even thinking of proposing was to ask for Twinkle or other tools to just have the option to double check if you want to proceed if the user has been blocked and inactive for say, six months or longer. I don't think we need a rule or anything. An example is User talk:Richard Arthur Norton (1958- ). This user checks in once or twice year, clears like 20 deletion notices off their page, and goes quiet again. Again, I don't think anyone is doing this maliciously, it just seems rather pointless. Beeblebrox (talk) 06:17, 13 March 2021 (UTC)
    • Why not revisit a lot of those possibly unjust, indefinite blocks? These users might be thinking, "Now, I'll get over to Wikipedia now. Am I unblocked? Nope. Do I have the strength to request unblock? No, it'll just be declined. Is my talk page huge? Yes. Full of deletion notices, and I can't even give a rationale for keeping them. I have so many ideas for restarting, but the administrators act like I'm a fly they swatted. Makes me think I should get away from Wikipedia now. See you... never!" 🐔 Chicdat  Bawk to me! 11:22, 20 March 2021 (UTC)
Alfred Dreyfus's talk page, 1895
  • This also bothers me when I see it. Especially since an indeffed user can't actually participate in the deletion process, it just seems unnecessarily cruel: "Hey asshole, that article you spent a bunch of time on is getting nuked, thought it might be funny for you to watch people debate about it without being able to respond in any way". Not nice! jp×g 18:43, 16 March 2021 (UTC)
  • The premise here is well-meaning, which we could always use more of, but I feel like this has maybe been over-thought. First off, if you're indef-blocked, why are you still logging in here? Do people do that, just so they can keep trying to edit? That is, does the audience even see the messages you're worried they'll see? Second, we're talking about people who were such fine folks that they got themselves indef-blocked and such fine articles that they're up for deletion. I guess I'm just being crusty, but I'm having a hard time kindling a lot of sympathy. I'd much rather expend time/effort/resources on the people who aren't dicks. Finally, the deletion is gonna happen or not regardless of the notification; isn't it just as likely - and perhaps more so - that the "nice" thing to do is to let people know what's happening rather than leaving them in the dark? We see a lot of questions on the help desk from people wondering where the hell the such-and-such article went. Matt Deres (talk) 20:13, 26 March 2021 (UTC)
  • Oppose per Worldbruce, Zzuzz, et al. If someone is long-term blocked or simply deciding not to be an editor any longer, they are free to change their site preferences to stop receiving e-mailed notficiations about posts on their talk pages, etc., if they are even receiving any at all. Editors do not own their talk pages, and their talk pages do not exist only for those individuals, but for the entire community. It's quite correct that the XfD and other notices on a troublesome user's talk page are often of direct and immediate use to other editors.  — SMcCandlish ☏ ¢ 😼  05:56, 3 April 2021 (UTC)

Edit conflict mitigation: early-warning tool

I'm proposing an idea for a tool for reducing the number of Edit conflicts, and mitigating the annoyance and other ill effects of them when they are unavoidable, including the number of inadvertent errors resulting from them (or abandoned edits due to not being able to deal with them), by providing a tool that gives early-warning of an impending edit conflict, plus some hints or links about what to do to avoid or minimize the effects.

Let's create a colored, rectangular badge that appears in Preview mode, initially green background, which means, "nobody else has changed this section" (or whatever is inside the Preview window). As soon as its recognized that something has changed (I'm thinking of the Watchlist notice, "View new changes since Timestamp" message that appears at the top of my Watchlist), then the badge background goes amber, and the message inside it changes appropriately (t.b.d. later), along with maybe 2 or three bulleted links or radio buttons or something, for possible actions to be taken. If the section I'm editing disappears entirely (as just happened yesterday, when a bot archived a Talk discussion, while I was replying to it), then the badge goes red.

That would be for changes on disk; but we can go further. Let's have a checkbox in the badge, that says, "Let others know I'm working on this section (or page)" (Maybe also a second checkbox: "and let them know my identity".) Then, if they edit that section as well, their box will immediately go orange, letting them know somebody is working on the same section (and optionally, who it is, if I've allowed that). This is inspired by Pending changes review, which gives you the option to let others know that you are working on a particular change, presumably to avoid conflicts. If you tick the box, then if others also select that same change to work on, they get a little orange message that someone is working on it (maybe even their identity; I don't recall). Enhancement: a Preferences option, "Share my identity by default in the Preview badge when I'm editing a section."

I see all sorts of possible advantages to this, and I have more ideas about what text to place in the badge, and what options might be possible, but this is getting longish for a proposal so I'll stop here for now, and open it to the floor. Mathglot (talk) 21:55, 23 March 2021 (UTC)

  • Support That would be useful. ~ HAL333 21:59, 24 March 2021 (UTC)
  • Support It would be great to be warned of a conflict when I hit "preview" instead of when I hit "publish". Not sure about the second part of letting people know an edit is in progress, perhaps implement it in two steps with first being the preview warning and the next step being enhancements. RudolfRed (talk) 22:56, 24 March 2021 (UTC)
  • Comment doesn't Paragraph-based edit conflict in beta features of preferences kind of address this? Aza24 (talk) 23:04, 24 March 2021 (UTC)
  • @Mathglot: I literally starting working on a script for the first part of this a few weeks ago. My long-term plan is to somehow highlight the words in the edit window that cause the conflict; I haven't even started on that part, yet. If anyone wants I can publish my (horribly ugly and buggy) work-in-progress. Suffusion of Yellow (talk) 23:13, 24 March 2021 (UTC)
    But I'd like to clear up a misconception. The automatic merging when you don't get an edit conflict is based on lines, not sections. Last I checked, it's just passing the three revisions off to diff3 (which was meant for merging code, not English text). What I want to attempt is something based on words, so there should be fewer conflicts. Suffusion of Yellow (talk) 23:17, 24 March 2021 (UTC)
  • If possible, Support. DMT biscuit (talk) 16:54, 1 April 2021 (UTC)
  • Support if feasible. However, I think this would need to be implemented at the MediaWiki level, so it will not be implemented unless it goes through the annual "wish list" process. I think those who care most about instituting this are going to have to figure out that process and make sure this gets listed in the next round of such voting.  — SMcCandlish ☏ ¢ 😼  05:43, 3 April 2021 (UTC)
  • If this is something you can accomplish with javascript, then no need to go through VPR right now, just get to it! Make a userscript and start testing, if it is robust we can make it an opt-in testing gadget, then an opt-in gadget. We'd come back here if you wanted to make it a default gadget. Things like 'share identity' would require mw changes (since it would need to be stored server-side) so will be a much bigger hurdle. — xaosflux Talk 11:07, 4 April 2021 (UTC)
    Yep, this has been a big WP:SQUIRREL for me. I've actually been thinking about this for years, just never got around to writing anything until a few weeks ago. About an hour ago, I got live as-I-type word-level conflict highlighting in the edit window to work for the first time! No need to even click "preview". Suffusion of Yellow (talk) 20:52, 5 April 2021 (UTC)

Wikipedia:Video linksmight have some shortfalls, but it is ready for edits and review to become a guideline. Talk page notified. 2601:601:CE7F:E270:5456:2939:9AB9:38F1 (talk) 07:08, 6 April 2021 (UTC)

Email edit notice update

Given some of the, ...let's say discussions, at various places lately, I wondered if this idea was worth floating. (if this should be at a different VP section like technical, or something else, I have no objections to it being moved)

As it stands now there is the last line in the 'email this user' edit notice:

  • Wikipedia makes no guarantee of confidentiality for messages sent by this system. Do not send information by email that you would not want published on the internet.

and I wondered if perhaps we should bold that to stand out a bit more...

  • Wikipedia makes no guarantee of confidentiality for messages sent by this system. Do not send information by email that you would not want published on the internet.

thoughts? — Ched (talk) 21:55, 4 April 2021 (UTC)

Without trying to commenting on any particular situations... Sure, Wikipedia can't guarantee that an editor won't send a message to another editor. But this is true of any site, anywhere. Facebook can't guarantee that the receiver of a "private message (PM)" won't show the message to someone else, Signal (software) can't guarantee a message sent in its E2E encrypted "private chats" won't be republished by a participant, and for all Snapchat gives an alert when people screenshot an expiring snap/image, it can't actually stop anyone screenshotting it. All this is to say, I don't really see the point of this disclaimer. It doesn't really relate to what good etiquette is (and IMO, it's bad etiquette to repost messages sent via that system), and a move towards possibly implying that this is anything but bad etiquette is a bad idea imo. Not even sure I like the existing text that's there, maybe it should be worded in a more nuanced way (but I suspect I'm the minority on this opinion). ProcrastinatingReader (talk) 00:24, 5 April 2021 (UTC)
While I'm commenting here, what might be interesting is to see if there's now consensus for some sort of email guideline. Wikipedia:Harassment#Private correspondence indicates previous discussions were no consensus. Some other incidents makes me feel this can lead to bad situations (for example this situation). ProcrastinatingReader (talk) 00:36, 5 April 2021 (UTC)
information Administrator note the entire message is stored in MediaWiki:emailpagetext. — xaosflux Talk 00:51, 5 April 2021 (UTC)
The line in question was added by AGK with this edit in 2014. I assume this change didn't come out of nowhere but I haven't immediately found any discussion about it. Two days later they added a similar message at User:Arbitration Committee. Thryduulf (talk) 02:20, 5 April 2021 (UTC)
Was that around the time that there were all those arbcom leaks posted on an external site perhaps? — Ched (talk) 02:26, 5 April 2021 (UTC)
A quick search suggests that the major leak was in mid 2011 Signpost story, with a smaller one in late 2012 Signpost story. That tallies with my memory of leaks not being mentioned significantly in the 2014 elections where I was a candidate. Thryduulf (talk) 02:47, 5 April 2021 (UTC)
  • It's 2021, and people know what email is and how the internet works. It's not our job to educate them on those things in the editnotice Xaosflux linked. Worse, when the editnotice becomes 20 pages long with every other line bolded,[hyperbole] the main actually-important point—that your email address will be disclosed—gets lost because no one reads the notice. This suffers from the same issue that has made so much of instruction on Wikipedia terrible: the way to improve it is to make it shorter so that people actually read it, not to make it longer and longer until it becomes a manual covering every possible eventuality. There are several lines from the current notice that should be removed, including the reiteration; that's where I would start. {{u|Sdkb}} talk 16:11, 5 April 2021 (UTC)
  • If I want to e-mail a user, I go to their user page and use the Email this user option in the sidebar menu. The entire text that I am given in the form is then:
    You can use the form below to send an email message to this user. The email address you entered in your user preferences will appear as the "From" address of the email, so the recipient will be able to reply directly to you..
    Nothing more. For me, this seems to be enough. When would I see the text being discussed above? — GhostInTheMachine talk to me 19:27, 5 April 2021 (UTC)
@GhostInTheMachine: You probably have your interface language set to British English. I see the same thing at [22]. I'm guessing maybe MediaWiki:Emailpagetext/en-GB should be moved to MediaWiki:Emailpagetext/en-gb. Suffusion of Yellow (talk) 21:27, 5 April 2021 (UTC)
Being British and speaking only English -- that would make sense. My preferences do say that my interface language is en-GB, not en-gb — GhostInTheMachine talk to me 19:11, 6 April 2021 (UTC)
@GhostInTheMachine: this should be "fixed" for you now, but please note: there is almost no maintenance of English language variants (e.g. en-gb, en-ca, en-au, etc.) performed on any of the WMF projects and due to oddities with the language fall back chains (see phab:T229992 for more on that) users that pick one of those variants will likely miss out on localized messages often, I strongly suggest you change it to the base English. — xaosflux Talk 10:46, 7 April 2021 (UTC)
Xaosflux Thanks. Sort of – I have downgraded myself from being British to just being an English speaker — GhostInTheMachine talk to me 19:09, 7 April 2021 (UTC)
@GhostInTheMachine: feel free to speak however you like, hopefully this is just a bodge! — xaosflux Talk 19:13, 7 April 2021 (UTC)
  • Sure, but I don't think it makes much difference. The message is more of a disclaimer than a purposeful educational message to users: we've had email for 30+ years, if you don't know how it works by now (in particular how insecure it is) then a bold message on an email form probably isn't going to help. Personally I have a message on my user talk that advises users of my own personal policy with respect to email privacy, which again is more for my own benefit, I really don't expect anyone who emails me to have read it (and generally assume that they have not) but act accordingly anyway. I don't expect the same courtesy from others, and why should I? To that end I'd like to be able to make my own editnotice for the mail form when a user tries to email me, but that's probably dev work and I won't hold my breath. Ivanvector's squirrel (trees/nuts) 13:24, 7 April 2021 (UTC)
    You can do that, see Wikipedia:Emailnotice for simple instructions. Thryduulf (talk) 18:45, 7 April 2021 (UTC)
    Thryduulf, Cool, or in wiki-speak: Thank you for this information, it is valuable to me and much appreciated. Thanks. — Ched (talk) 19:31, 7 April 2021 (UTC)
    About three and a half seconds after I hit save I thought, "someone's going to reply telling me how to do exactly that", and there you have it. Thanks Thryduulf! Ivanvector's squirrel (trees/nuts) 00:39, 8 April 2021 (UTC)

Many articles now have broken references to web based sources that no longer exist or have moved to some other link. Please suggest or require all users and editors to screenshot the info from a web based source and place the reference in caption. — Preceding unsigned comment added by 108.174.40.162 (talk) 19:16, 8 April 2021 (UTC)

a) That's a fair-use nightmare and probably wouldn't be acceptable under our fair-use policy (and wouldn't work at all on other wikis which don't permit fair-use). b) Sounds like a major accessibility issue. c) According to WP:PLRT (can't vouch for whether that's up-to-date), most links added to Wikipedia trigger an archiving of that page in the Internet Archive - and for bonus points, User:InternetArchiveBot can scan for dead links and replace them with archive links. SubjectiveNotability a GN franchise (talk to the boss) 19:25, 8 April 2021 (UTC)
In addition to SubjectiveNotability's excellent points, where would you suggest that editors put the screenshots? Around half the editors seem to use mobile 'phones these days and the other half are probably behind firewalls. Martin of Sheffield (talk) 19:37, 8 April 2021 (UTC)
What they could do is submit the page to archive.is, which will take and save a snapshot. It would be better to have a Bot carry out this task though. Hawkeye7 (discuss) 22:57, 8 April 2021 (UTC)
the Internet Archive automatically scrapes links that are posted to Wikipedia and archives them, if I remember correctly. Elli (talk | contribs) 19:43, 9 April 2021 (UTC)
Our referencing policy doesn't require that sources be available at the time of viewing, only that the citation identifies the source of the information cited at the time of the edit. InternetArchiveBot flags dead links and I think can also replace them with links to [archive.org], and there's either another bot or a semiauto tool which automatically replaces weblinked references with an archive link regardless of their status. Recording screenshots of the source is a bad idea for the fair-use reasons mentioned, but also what's to stop someone from modifying a screenshot to include false information and then citing it as a reference? Ivanvector's squirrel (trees/nuts) 15:34, 9 April 2021 (UTC)
I would add to the excellent points made above that an ephemeral, unarchived, web-based source is very likely not to be a reliable source. I would add that I know of people who have manipulated screenshots in the way described by Ivanvector's squirrel - not for Wikipedia purposes, but it could be done here just as easily. Phil Bridger (talk) 15:52, 9 April 2021 (UTC)

WP:LINKROT has additional information about archiving on enwiki.. -- GreenC 20:09, 9 April 2021 (UTC)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_177&oldid=1142560800"