Wikipedia:Village pump (all)

This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.

Click here to purge the server cache of this page (to see recent changes on Village pump subpages)


Village pump sections

Edit-find-replace.svg
Policy
post, watch, search
Discuss existing and proposed policies

Preferences-system.svg
Technical
post, watch, search
Discuss technical issues about Wikipedia

Dialog-information on.svg
Proposals
post, watch, search
Discuss new proposals that are not policy-related

Tools-hammer.svg
Idea lab
post, watch, search
Incubate new ideas before formally proposing them

Wikimedia-logo black.svg
WMF
post, watch, search
Discuss issues involving the Wikimedia Foundation

Help-browser.svg
Miscellaneous
post, watch, search
Post messages that do not fit into any other category

View all village pump sections at once

Hyperlink-internet-search.svg
Other help and discussion locations
I want... Where to go
...help using or editing Wikipedia Help desk
...to find my way around Wikipedia Department directory
...specific facts (e.g. Who was the first pope?) Reference desk
...constructive criticism from others for a specific article Peer review
...help resolving a specific article edit dispute Requests for comment
...to comment on a specific article Article's talk page
...to view other Wikimedia projects Wikimedia Meta-Wiki
...to learn about citing Wikipedia in a bibliography Citing Wikipedia
...to report sites that copy Wikipedia content Mirrors and forks
...to ask questions or make comments Questions


Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).

Policy

Notability and stand-alone lists of sports accomplishments

I stumbled across a notability issue recently in stand-alone lists of sports accomplishments, specifically cricket statistics. See, for example, Wikipedia:Articles for deletion/List of international cricket five-wicket hauls by Lance Gibbs. There has apparently been a great deal of debate recently at Wikipedia talk:WikiProject Cricket which does not appear to have resulted in a consensus. Rather, to the contrary, it appears to have generated enough dissension and hard feelings to provoke editing restrictions and for editors to leave editing that project or retire completely. I hope that by bringing this to the wider community, some clarity may be achieved. Time will tell if that hope is justified or not, I suppose.

Relevant standard

All appear to agree that the relevant standard is WP:NLIST:

Notability guidelines also apply to the creation of stand-alone lists and tables. Notability of lists (whether titled as "List of Xs" or "Xs") is based on the group. One accepted reason why a list topic is considered notable is if it has been discussed as a group or set by independent reliable sources, per the above guidelines; notable list topics are appropriate for a stand-alone list.

The issue appears to be in how to interpret this standard in the light of the available coverage for cricket centuries and five-wicket "hauls". An apparent WP:LOCALCONSENSUS that 25 centuries or some indeterminate number of hauls by one player is justification for a stand-alone list has been mentioned multiple times in recent AfD discussions but multiple discussions at WP Cricket do not seem to have pointed to any place where such a consensus was first formed (e.g.:Wikipedia_talk:WikiProject_Cricket/Archive_84#Steve_Smith_stats Wikipedia_talk:WikiProject_Cricket/Archive_85#Unanswered_question_since_2015 Wikipedia_talk:WikiProject_Cricket/Archive_85#What_to_list_and_not_list Wikipedia_talk:WikiProject_Cricket/Archive_88#Lists_of_International_Centuries Wikipedia_talk:WikiProject_Cricket/Archive_86#Discussion_on_List_of_fifers/centuries_by_ground:_keep,_delete_or_merge_by_country?. The closest appears to be this discussion which resulted in a consensus that a list of either of these accomplishments for a particular venue requires ten or more entries but is not the same question.

Notability in practice

The actual application of the relevant standard in terms of demonstrable outcomes at AfD is extremely variable. AfD discussions of "List of international cricket [five-wicket hauls/centuries] [by/at] [X]" articles that were closed between Sep 1, 2020 and now shows the following distribution:

  • Keep: 2
  • Delete: 62 (including 2 large multi-AfD's)
  • Merge:9
  • Redirect: 7
  • Draft:0
  • No consensus: 0

There are currently fourteen such AfD discussions open, all started by Störm. This may be an attempt to establish an consensus through WP:OUTCOMES that has so far eluded the Wikiproject. When the Multi-AfD's are included, then deletion is the overwhelmingly most common outcome (87%). When only single-article AfD's are considered, this shows that recent practice is appx 41% in favor of merging such articles and 32% to redirecting. The disparity in these results argues in favor of a discussion forming an explicit consensus.

Proposal

A clear standard for this type of list article is apparently lacking. Either the Cricket Wikiproject or a Notability Guideline should include something similar to the following:

"List of" articles for cricket sports accomplishments such as centuries or fifers home runs are only considered notable if there are independent, reliable sources that significantly discuss the accomplishment in question for an individual or a venue as a group or set. Such sources should be more than mere statistical listings and the data should be put in context with referenced explanations, if necessary.

This text is an attempt to create one such clear standard for this type of article that complies with the Core Content Policies, the General Notability Guideline, and other relevant standards. Please state a preference for the proposed standard for "List of five-wicket hauls/centuries" type articles or propose an alternative. While this particular proposal is occasioned by a cricket-specific issue, there may also be reason to think that such a guidance that applies more widely in sports may be advisable. Thank you for your time and attention. Eggishorn (talk) (contrib) 20:49, 5 February 2021 (UTC)

Modified per below. Eggishorn (talk) (contrib) 00:10, 6 February 2021 (UTC)

Notability discussion

  • I appreciate the idea here, because these controversial cricket AfDs are becoming a problem, but your proposal is cricket-specific. Most editors don't care about cricket, and if you make a solely cricket-related proposal at a general noticeboard, most of the participants are going to be the same editors that are grinding against each other already. It may be that we can come up with an actual proposal to cover sports statistics better, but it feels like this is just another attempt to litigate the same cricket notability standards that nobody seems to actually agree upon. We already have a notability criterion for standalone lists, and to be honest I think that mostly covers these cricket stat lists in most of the way you're proposing - have reliable sources discussed "Johnny Cricketplayer's five-wicket hauls" as a group or set? If not, probably not a good standalone list. ~ mazca talk 23:24, 5 February 2021 (UTC)
@Mazca:, I brought it to this board specifically because the previous participants appear to have been unwilling or unable to come to some agreement on the issue. I acknowledge your point about broader applicability, though, and mentioned it above. I've made a slight adjustment to make that clearer. Thanks for the feedback. Eggishorn (talk) (contrib) 00:13, 6 February 2021 (UTC)
@Eggishorn: I think that minor adjustment is a significant improvement, yeah, as I think the emphasis of any attempt to gain general consensus here needs to remain general to avoid being bogged down in per-sport exceptions. I don't think there's a good argument for arbitrary run thresholds, etc, in cricket granting notability beyond that general principle of "being discussed as a group or set by reliable sources". I absolutely agree with the idea of deciding global thresholds for sport statistics - we just need to make sure it's not some specific solution for cricket. ~ mazca talk 02:44, 6 February 2021 (UTC)
  • Considering at a broader level beyond cricket, I think these types of records at the individual player level may be far too much, per WP:NOT#STATS - even if there is good coverage of this from sources. While certainly the five-wicket haul seems like a notable achievement that is documented and thus a list like List of cricketers by number of international five-wicket hauls, documenting down to the specific player/each individual point of achievement seems far too much. I would say the same for an article like List of milestone home runs by Barry Bonds (while obviously List of Major League Baseball career home run leaders is a fair list to keep). --Masem (t) 23:31, 5 February 2021 (UTC)
  • I have been involved of several of the AFDs surrounding cricket. There seems to be a lot of anger amongst those who to delete, and those who want to keep. The main bone with deletists is that list of stats are WP:NOSTATS, that these lists are not not encyclopedic and Wikipedia should not have statistics that can be found elsewhere, or that these lists are not encyclopedic as there is not enough prose and to much stat. The keeps are saying this is a vendetta after a failed RFC change to WP:NCRIC. My own personal view has been to merge these into the main article, and I have voted as such on 9 that I have seen, which all ended in the 9 merge, and I have posted to others that have been raised that this was the case. The lists are not exhaustive lists, they are for international 5 wicket hauls or centuries only, which are important milestones in cricketers careers and are revered by fans alike. Just look at the coverage surrounding Joe Root in Sri Lanka and India. This is why delete is wrong. My rational is that who is going to search for a List of International Five Wicket Hauls? I wouldn't, I would just go to the Wikipedia page for that player. My other rational is that it's not a ball by ball record for their whole career, just what is regarded as being the highest accolade in cricket. That's my viewpoint on the subject.

My beef is the wording "Notability guidelines also apply to the creation of stand-alone lists and tables. Notability of lists (whether titled as "List of Xs" or "Xs") is based on the group. One accepted reason why a list topic is considered notable is if it has been discussed as a group". The group is the issue. We have Editors who believe they are the only people who have the right to decide what is notable for Wikipedia, they forget the second part "or set by independent reliable sources, per the above guidelines; notable list topics are appropriate for a stand-alone list." They also believe that they should set out what should go on a list. So for example, a nation wide company is not allowed in a list or national retailers because they don't have a page on Wikipedia. Sorry for the rant.

Anyway, the problem I see is that if we have a separate subject specific list for cricket, where will this lead us? It will go mad and every editor with bones to pick will be requesting there own list requirements for each subject Area! Keep it as it is. — Preceding unsigned comment added by Davidstewartharvey (talkcontribs) 00:10, February 6, 2021 (UTC)
@Davidstewartharvey:, I think I have miscommunicated and I need to clarify some things in response.
  1. As I said, I stumbled across this because I troll through AfD's that are not closed occasionally and I haven't been involved previously. I think that it is because of the animosity that you mention that this needs to be handled outside the Wikiproject.
  2. Although this is proposed because of what I found through the cricket AfD's it is not about cricket articles. It is about list articles for stats in any sports. That's why I titled the section "Notability and stand-alone lists of sports accomplishments" and not ..."cricket accomplishments"
  3. Thanks again to Mazca for prompting a clarification to the actual proposal to make the above point clearer.
  4. The wording you object to is not my wording. It is a direct quote from the long-standing notability standard that should already have been followed in all AfD discussions of these list articles. The fact that it has not been followed in such discussions is the reason I am trying to propose a clarification.
I hope that clarifies some things. Eggishorn (talk) (contrib) 16:00, 6 February 2021 (UTC)

POVFORK? Deletion of these types of lists can happen in sports (Wikipedia:Articles for deletion/List of 40-plus point games by Michael Jordan). The main issue, generically and not sports-specifc, is a grouping that seems to meet WP:LISTN, as it's currently written, when most of the items themselves are not notable. In sports, it's often a list for a player of all games where they met a single-game threshold. However, the games themselves are generally not notable. This is different than when we have a list of players that met a milestone, where most of the entires are players who are notable. IMO, these types of lists of non-notable entries are WP:POVFORKs. It's not notable enough to warrant the bloat in the bio, so a standalone of the stats listing is created instead. Lists of non-notable entries is not unique to sports. There's plenty of lists like List of killings by law enforcement officers in the United States, January 2020, a grouping of individually non-notable entries.—Bagumba (talk) 16:22, 6 February 2021 (UTC)

  • Something else to consider... a sports statistics list may not be notable enough for a stand alone article, but may well be appropriate to include as part of a related article. For example, a list of the top cricket players by number of centuries might well be appropriate in the article on Century (cricket). And it might be appropriate for the Michael Jordan article to include a list of his highest scoring games. Blueboar (talk) 17:05, 6 February 2021 (UTC)
    For NBA bios, an FA would typically mention the top games in prose with proper context, and not repeat them with an embedded stats list.—Bagumba (talk) 01:55, 7 February 2021 (UTC)
So, this seems a part of the standard "Expand->split->merge" cycle that we get all the time:
  • An article grows to where it is too big, so it needs to be split up by topic. This is standard practice.
  • The split off article gets someone who complains that it should never have been split in the first place, and it gets deleted.
  • The information has to go somewhere, so it gets put back in the main article.
  • Rinse and repeat
Either the information belongs at Wikipedia, and if so it shouldn't really matter where it goes as long as it doesn't make articles too big or too small, OR it fails WP:V or WP:UNDUE and as such shouldn't be at Wikipedia at all. Without saying whether or not the information does belong, if it actually does, and it's too much to put in the parent article, I see no problem with a split-off list article. If it doesn't belong at Wikipedia at all, the point is moot. --Jayron32 18:51, 10 February 2021 (UTC)
Exactly. I typically think AFD is a poor place to resolve these because that forum is biased towards binary keep/delete results, and encourages judging articles in isolation when obviously these are part of a larger whole, notwithstanding the formatting into a separate page. Resolving whether a split should be maintained requires understanding of all of the interrelated content and pages, and depends on some familiarity with the subject matter to determine what is relevant and what level of detail is valuable to a reader on different subtopics. And there's also WP:ATD. postdlf (talk) 19:29, 10 February 2021 (UTC)
@Postdlf:, unfortunately, it appears that AfD is exactly where this issue is being "resolved" because the relevant Wikiproject reached a stalemate. Do you agree that the proposal should be made an explanatory supplement or something similar? Thanks. Eggishorn (talk) (contrib) 15:45, 12 February 2021 (UTC)
No, it seems like a subject-matter specific legislation of LISTN, which is already far too often misread as necessary rather than merely sufficient. If there's a "stalemate" then apparently there's no consensus in that Wikiproject against such lists. I also don't see why it's worth wasting anyone's time trying to get rid of them. postdlf (talk) 21:17, 12 February 2021 (UTC)
For Jordan, it would be monotonous to enumerate every one of his 40-point games in his bio. Per WP:ONUS: Consensus may determine that certain information does not improve an article, and that it should be omitted ... The AfD there said not to have a standlone list either.—Bagumba (talk) 15:59, 20 February 2021 (UTC)

The role of ArbCom relative to sourcing content in articles

In September 2019, the Arbitration Committee in good faith made the following decision:

5) The sourcing expectations applied to the article Collaboration in German-occupied Poland are expanded and adapted to cover all articles on the topic of Polish history during World War II (1933-45), including the Holocaust in Poland. Only high quality sources may be used, specifically peer-reviewed scholarly journals, academically focused books by reputable publishers, and/or articles published by reputable institutions. English-language sources are preferred over non-English ones when available and of equal quality and relevance. Editors repeatedly failing to meet this standard may be topic-banned as an arbitration enforcement action.

While ArbCom's intentions are honorable regarding that particular topic, and it was clearly an effort to stop disruption in that topic area, I'm of the mind that the remedy is an overreach of ArbCom's scope, and is noncompliant with policy for the arbitration process, specifically that the Committee does not rule on content. With that in mind, see WP:CONTEXTMATTERS which states: The reliability of a source depends on context. Also keep in mind that AE/DS authorizes individual admins to take unilateral action at their sole discretion against an editor, and as some active editors who edit in controversial topic areas will attest, the complexity of DS can quickly turn into a nightmare. An AE/DS action by an admin cannot be overturned by another admin. That opens the door to WP:POV creep because a single admin is making the determination as to whether or not the context of cited sources are reliable for inclusion of content in an article, and no matter how we spin it, that is unequivocally a content issue, not a behavioral issue on behalf of the editor; therefore, the ArbCom ruling is noncompliant per the following:

The arbitration process is not a vehicle for creating new policy by fiat. The Committee's decisions may interpret existing policy and guidelines, recognise and call attention to standards of user conduct, or create procedures through which policy and guidelines may be enforced. The Committee does not rule on content, but may propose means by which community resolution of a content dispute can be facilitated.

This decision directly effects content on so many levels that the remedy creates an even bigger problem then it resolves as it fails to take into account the critically important aspects of sourcing that unequivocally makes it a content issue, not a conduct issue. It also doesn't factor-in the associated problems resulting from political biases in RS, or the fact that a single admin who may be biased, unknowingly or otherwise, is making the decision as to what content can be included based on their sole discretion/interpretation of the cited source(s). Any editor who might be citing sources in proper context that disagree with a particular POV, may inadvertently become the target of a indef t-ban or block under this AE remedy. WP's ideological bias is no secret so in an effort to preserve WP's reputation as a neutral encyclopedia, we probably should at least try to keep ArbCom within its scope. As to my overall position and concerns, see this BLP comment and the quote directly below it.

In the survey below, either Agree that the above mentioned decision is out of ArbCom's scope and noncompliant with policy for the reasons stated above, or Disagree. Atsme 💬 📧 16:07, 9 February 2021 (UTC)

Survey (Arbcom and sourcing)

  • There is no clear distinction between creating policy and interpreting policy. Sometimes it help to take uncodified and unwritten expectations and put them into formal writing, But for many of the perennial issues at WP, the unwritten guidelines are too flexible to be effectively reduced to simple sentences. So when we do, it still leaves the same problems, except that we now call them interpretations. The most obvious analogy to me is the American Constitution and especially its Bill of Rights, and how key phrases in it have never been changed, but have been reinterpreted repeatedly to fit the prevailing ideology. DGG ( talk ) 20:15, 9 February 2021 (UTC)
  • Apologies, DGG but is your comment to agree or disagree? Atsme 💬 📧 12:01, 10 February 2021 (UTC)
as I try to explain a little later, agree or disagree doess not do justice to the actual complexities. DGG ( talk ) 06:11, 18 February 2021 (UTC)
  • Not a productive use of anyone's time See below for explanation. Eggishorn (talk) (contrib) 20:17, 9 February 2021 (UTC)
  • Seems fine to me. There was a behavior that needed addressing, and the quoted ArbCom decision addresses that behavior and does not address content; they are not making any statements about what the articles should or should not say, merely addressing the problem of people misusing source material and devising a reasonable method of stopping that problem. --Jayron32 18:44, 10 February 2021 (UTC)
  • I'm opposed to the camel's nose under the tent expansion of ArbCom remit into editorial issues until such time as the community assesses whether we have to drop our opposition to a centralized editorial board, and if so, think through whether a centralized editorial board ought to be a new group comprised of editorial experts or dumped into ArbCom's lap. (I elaborated on this in a post in the discussion section.)--S Philbrick(Talk) 19:31, 10 February 2021 (UTC)
  • I'm with Jayron32 on this: this isn't a content decision. The policy on disruptive editing includes citing unencyclopedic sources as a form of disruptive editing, and warns that this may be enforced with blocks. ArbCom isn't dictating what an article can or can't say; they're delegating their banning authority to help better enforce the community's policies about content. Vahurzpu (talk) 05:12, 13 February 2021 (UTC)
  • While I don't think this specific restriction has worked as well as intended, it was within arbcom's remit to make it. Thryduulf (talk) 12:23, 18 February 2021 (UTC)

Discussion (Arbcom and sourcing)

See, I always thought that a lot of the Ideological bias on Wikipedia and complaints about it is actually the base rate fallacy - because of our sourcing requirements we are automatically biased in favour of topics with reliable sources as opposed to, say, hearsay and libel. And that's a desirable thing, really. Jo-Jo Eumerus (talk) 16:20, 9 February 2021 (UTC)

Jo-Jo, it would definitely be desirable if that were truly the case, but it isn't. Even Jimbo acknowledged that we have a problem. The sources at our disposal today are not quite like the neutral sources of yesteryear, as Ted Koppell explained in numerous interviews. It's clearly a POV issue but that aside, we don't have any type of qualifiers in place for admins who focus on AE and who will be judging the quality of sources. We already know that qualifiers will never happen because of anonymity, although something along the line of MEDRS would be nice, but again, topics involving POV politics are not easy to qualify. Atsme 💬 📧 16:36, 9 February 2021 (UTC)
"Even Jimbo acknowledged" doesn't mean that Jimbo is correct. WhatamIdoing (talk) 18:25, 10 February 2021 (UTC)
  • The "ArbCom does not rule on content" meme is one that should be definitively retired as having outlived its purpose. To the extent that there ever was a clear line between content and behavior, an iffy division at its very best, that line has been thoroughly obliterated in the last 5-7 years. If an editor advocated for or uses a poor source to slant an article, is that a behavior issue within ArbCom's purview or a content issue outside the realm of cases ArbCom is authorized to handle? The plain truth is: it is both. This case offers an excellent demonstration of that evolution, in fact. At a time when Holocaust minimization and denialism has reached epidemic proportions that include governmentally-organized revisionism, it is ludicrous to contemplate any ruling on such a case that did not address sourcing concerns. ArbCom's ruling here does not require a 16-months-delayed attempted review. This thread appears to do little more than express, well, I'm not quite sure what it is supposed to express: Frustration? Disappointment? Disapproval? It is unclear what practical result this would accomplish. Does the OP wish to overturn ArbCom's decision? Get ArbCom to modify their decision? Wag their finger at ArbCom? If it is the former two possibilities then this is the wrong place for this thread and that goal needs to be much more clearly stated. If it is the latter possibility then there is no point to this. Eggishorn (talk) (contrib) 20:17, 9 February 2021 (UTC)
    Eggishorn, I see it differently. New editors are often surprised to learn that there is no central editorial board. This is deliberate. In fact, I think it's fair to say that in the early days of Wikipedia we eschewed having either a central editorial board or a central "behavioral" board. The hope and expectation was that all such issues could be addressed without the need for centralized authority. I think Jimbo reluctantly came to the conclusion that behavioral issues needed a centralized board and that's why he created Arbcom (while taking care to make sure the creation of it did not mean it reported to him, he started the ball rolling and let the community decide how to organize the group). While the community reluctantly accepted the need for a behavioral board, it still strongly opposed a centralized editorial board which is why ArbCom is supposed to be limited to behavioral issues not content issues.
    However, while some editors are making and can make strong arguments for the need for a centralized editorial board, it isn't at all obvious to me that we should simply broaden the remit of ArbCom. I think the community should revisit the decision to have no centralized editorial committee, but if the conclusion is that we should have an editorial committee, it is far from obvious that we should simply expand the role of ArbCom, if no other reasons than that the skill set to assess editorial issues and the skill set to assess behavioral issues are not identical. Someone will argue that it's overly bureaucratic to create yet another group, but if we decide to have centralized editorial control we've crossed that bridge and we ought to work out the details of whether the centralized editorial committee obviously ought to be ArbCom, or group of people selected for the editorial expertise. S Philbrick(Talk) 19:28, 10 February 2021 (UTC)
@Sphilbrick:, actually, I don't think we're saying things that are really all that different. I'm aware of the history of ArbCom's creation and I've always felt that the content/behavior dichotomy is a false one. The earliest ArbCom case i was able to find from the time period soon after Jimbo passed some of his authority to it was a clear case of interpersonal conflict and a whole heapin' helpin' of behavior issues but they all stemmed from content issues. From the very beginning the two areas have blended together in varying proportions depending on the particulars of each ArbCom case. I'm not arguing for an increase of ArbCom's remit; I'm saying that this discussion was premised on a clear discrimination between two realms that exist along a spectrum and the limitation that ArbCom supposedly stepped over never really existed. I hope that helps clarify. Eggishorn (talk) (contrib) 19:47, 10 February 2021 (UTC)
  • The simplest change in the general scope of arb com, which is closer to reality, is to say that arb com does not rule directly on content. That's what actually happens, and we might as well say so. What I think the op might realistically hope for is that the decision say High quality sources are strongly preferred, particularly peer-reviewed scholarly journals, academically focused books by reputable publishers, and/or articles published by reputable institutions I do not think it unrealistic for this to be suggested as an amendment. Any statement here about sourcing using absolute words like "only" is incompatible with the variety of the real world. DGG ( talk ) 00:06, 10 February 2021 (UTC)
    @DGG: that just reiterates WP:BESTSOURCES and is not a remedy (more like a principle). "Should", "strongly preferred" and similar wordings which are not "must", do not help the problem. The issue is people who are so compelled by their POV they bludgeon people and disrupt talk pages by pushing crappy sourcing. Your amendment does not fix that issue, but the current ArbCom decision does. As such, I'm in favour of sourcing restrictions, having seen the damage and sheer waste of productive editor time SPAs and POV pushers cause on some controversial articles. I agree that with Eggishorn and yourself that the line between conduct and content is blurry, but I think violations of our existing polices, or the intentions behind them, is a behavioural issue. ProcrastinatingReader (talk) 20:49, 17 February 2021 (UTC)
one can equally disrupt talk pages -- and articles -- by contrived or biased objections to what is adequate sourcing. I think the history of AP this past year makes it evident that disputing sourcing has become the primary way of disputing content, and that this can be done in a helpful or in a unhelpful way. In another light, everything is a behavioral issue in a sense, because the act of making an edit is human behavior, so if one tries hard enough, one can get anything under that umbrella. Whether something is in fact a violation of our existing content guidelines is not necessarily a question for arb com. It can be a factual question of the verifiability of information. And, come to think of it, one can use aggressive and even NPA behavior to try to make what are in fact constructive edits. And this very situation is what causes dilemmas for arb com; my service there has shown be the great difficulty of deciding how to handle such issues, and has taught me that not everything I had thought obvious and clear about our practices really was all that simple. DGG ( talk ) 06:09, 18 February 2021 (UTC)
  • I was the only arb who voted against that remedy, precisely because I thought it went too far towards ruling on content. And I still think that sourcing restrictions imposed by ArbCom, AE, ANI, or anything except a content guideline with broad consensus (e.g. WP:MEDRS) are a bad idea. That said, I don't agree that it was in breach of WP:ARBPOL. The committee has the latitude to propose means by which community resolution of a content dispute can be facilitated and ultimately, the interpretation of ARBPOL and whether a specific remedy is within its scope is up to ArbCom itself. That is an important principle without which the committee cannot fulfil its core purpose as a final binding decision-maker. No discussion here can tell ArbCom how to interpret ARBPOL or retrospectively overturn a remedy. If we want to clarify that sourcing restrictions are not within its scope going forward, there needs to be a formal amendment to ARBPOL. – Joe (talk) 13:48, 18 February 2021 (UTC)
  • Anyone who has worked on content & came into conflict over reliable sources could have predicted that the ArbCom would find its way into content disputes. The short version of why is this: on Wikipedia almost any relevant source can be criticized for not be reliable, while almost any relevant source can be defended as reliable. Unless it is one of those apparently rare cases where everyone involved is willing to work together, this leads to deadlock. This deadlock can be resolved one of two ways: (1) finding an informed third party to make a decision that all parties will agree to; or (2) work the rules so that the other side either gives up or gets sanctioned. Either choice means ArbCom is likely to get involved. By this decision, ArbCom has just cut out a few of the steps for cases like this to be submitted to them. -- llywrch (talk) 00:17, 26 February 2021 (UTC)

Knockout brackets in sports events

In tennis, snooker, and other events commonly decided in a knockout format, it is common on wikipedia for people to enter the flag of the country of the winner before the winner is known. For example, here you can see a Czech flag entered in round 4, event though the 3rd round match between Karolina Pliskova and Karolina Muchova hasn't taken place yet (as I write this). I've tried explaining that it's confusing, it looks unprofessional, no reputable sports publication does it, it makes about as much sense as entering "Karolina" in the next round, it takes no account of possible double disqualifications, or both players being sick or withdrawing or otherwise unable to play etc... but still people do it, and revert it whenever I raise these points, sometimes using "other stuff exists" type arguments. (It's often IP's who do this). Usually the issue is resolved within a few days when the match actually takes place, meantime the article looks like crap.

Maybe the MOS needs a section on how to report knockout results from sports events? Maybe I'm like a grammar pedant who reacts with horror to "different than", but those anticipatory flags irk me. MaxBrowne2 (talk) 09:15, 12 February 2021 (UTC)

I agree that that example is not good. To be honest, it looks almost like a loading error, where the name has not populated for some reason. If this is indeed not just a one-off, I'd support deprecating that kind of thing. Matt Deres (talk) 20:38, 12 February 2021 (UTC)
Look at that article's history and you can see what happens if you raise the issue, they just revert without even putting up an argument or even an edit summary. No BRD, nothing. I'm tempted to add "Karolina" to the player's name for round 4 but that would be just a little too WP:POINTy. MaxBrowne2 (talk) 00:13, 13 February 2021 (UTC)
I don't know whether it's written down but adding known flags is the accepted practice for tennis. It must be exceptionally rare that nobody advances from a scheduled match. I followed tennis for many years and don't recall it ever happening. There were a few tournaments where the final was never played due to rain delays but that is irrelevant here. I support adding the flag but definitely not a partial name, and I have never seen it done. Most publications don't use flags or write nationalities in draws so the issue is not relevant for them. PrimeHunter (talk) 00:59, 13 February 2021 (UTC)
Sounds like Appeal to tradition to me, a fancier name for "other stuff exists". MaxBrowne2 (talk) 01:04, 13 February 2021 (UTC)
If the "other stuff" is not selected examples but a well-established practice then it's how Wikipedia works, and often the basis for making it an official guideline. PrimeHunter (talk) 01:10, 13 February 2021 (UTC)
Obviously it would be ridiculous to enter "Karolina" before the result is known. That's the point. By the way Karolina won. I think she's from the Czech Republic. MaxBrowne2 (talk) 02:40, 13 February 2021 (UTC)
I don't think it needs a MOS section specific to this issue. WP:CRYSTAL is sufficient reason to exclude the flag. - Ryk72 talk 02:43, 13 February 2021 (UTC)
I agree with the OP that we shouldn't be pre-populating flags in this type of situation. If people generally do this, they should stop. power~enwiki (π, ν) 02:49, 13 February 2021 (UTC)

The television coverage tends to pre-populate the flags when showing the draws as well. Regardless, it's not a big issue. It's never more than a few days between matches. Sportsfan77777 (talk) 02:57, 13 February 2021 (UTC)

  • I also agree flags shouldn't be pre-populated, we don't need to add it to MOS because it's already specified in CRYSTAL, and if it's been done in the past it should stop. Levivich harass/hound 04:37, 13 February 2021 (UTC)
    WP:CRYSTAL includes: "Individual scheduled or expected future events should be included only if the event is notable and almost certain to take place". It is almost certain that if two players are set to meet then one of them will advance. We don't need a published reliable source to make that "prediction". It's not certain the advancing player actually plays the next match but if they withdraw with injury before that match then their name and flag will remain in the draw for the match. PrimeHunter (talk) 09:32, 13 February 2021 (UTC)
    CRYSTAL then goes on to say "Avoid predicted sports team line-ups, which are inherently unverifiable and speculative." Levivich harass/hound 17:40, 14 February 2021 (UTC)
    A predicted sports team line-up is not a prediction about which teams will play but about which players will be selected for a match by a team. Such speculation is hardly comparable to predicting that one of the two players will advance from a tennis match and not change nationality before the next round. PrimeHunter (talk) 22:26, 17 February 2021 (UTC)
I'd argue this also has some crossover with WP:LIVESCORES which is also against consensus, but a difficult thing to actually get the community to fulfil. Best Wishes, Lee Vilenski (talkcontribs) 17:46, 14 February 2021 (UTC)

I personally think that results should be presented for a complete match, and not a partial result. Filling in the country before the match is done is a partial result. Additionally, it doesn't provide any info that readers can't infer for themselves. isaacl (talk) 23:10, 17 February 2021 (UTC)

  • I think this is much ado about nothing. Would I populate the flag early.... no. Would I put in the scores before that match is complete...no. But the news does both and it's really really difficult to police that sort of thing when an hour later it will fix itself. Fyunck(click) (talk) 20:05, 18 February 2021 (UTC)
    An hour later is not really a big deal (although it still shouldn't be done). Sometimes though matches can be days or even weeks later - that is a big deal and should be reverted if done. We are an encyclopaedia not a newspaper, television broadcaster or other sports reporter. Thryduulf (talk) 21:33, 19 February 2021 (UTC)

Disambiguation cross-references

In the disambiguation page Pitt-Rivers, there is a list of people who happen to be from one family. Some names recur (EG George). I recently edited it to change "* Michael his son" into "Michael George's son". Is there a preferred way of identifying WHICH George in such a page? -- SGBailey (talk) 09:35, 16 February 2021 (UTC)

Maybe append the (birth-death) dates to the name? — GhostInTheMachine talk to me 12:13, 16 February 2021 (UTC)
I've done that at Pitt-Rivers. What do you think? -- SGBailey (talk) 12:49, 17 February 2021 (UTC)
That helps with the confusion, but I would not use the sub tags — GhostInTheMachine talk to me 22:59, 17 February 2021 (UTC)

Clarification to Template:POV

At this article talk I and Julian Brandon came to conflict over wording of Template:POV#When_to_remove. I think it would be appropriate to change this wording from

This template is not meant to be a permanent resident on any article. You may remove this template whenever any one of the following is true:

  • There is consensus on the talkpage or the NPOV Noticeboard that the issue has been resolved.
  • It is not clear what the neutrality issue is, and no satisfactory explanation has been given.
  • In the absence of any discussion, or if the discussion has become dormant.

To this:

This template is not meant to be a permanent resident on any article. You may remove this template whenever any one of the following is true:

  • There is consensus on the talkpage or the NPOV Noticeboard that the issue has been resolved.
  • It is not clear what the neutrality issue is, and either none or only an unsatisfactory explanation has been given.
  • In the absence of any discussion, or if the discussion has become dormant.

The template should not be removed if there is an active ongoing discussion in which "the issues are resolved" consensus has not been reached.

Please confirm and if you think it is an OK change then please implement it in the template page. --Gryllida (talk) 22:40, 17 February 2021 (UTC)

What problem would be solved by this change? Arguing with an SPA about an article on the president of an authoritarian regime is never going to be easy and I do not see how an adjustment to the description of the POV tag would help. Re the proposal, the original looks good to me—it is simple and clear. I don't know how to handle an SPA with unlimited time but forcing a tag on the article is not the solution. Johnuniq (talk) 23:00, 17 February 2021 (UTC)
At what stage would it be appropriate to force a tag onto the article? It currently is of rather poor quality. Gryllida (talk) 23:14, 17 February 2021 (UTC)
I don't think it is ever appropriate to force a tag into an article. Bear in mind that while it might be desirable to have rule that a good editor can force a tag when arguing with an SPA, such rules won't fly and there cannot be a situation where an SPA can force a tag by persistence. Asking for help at noticeboards is all we can do. Johnuniq (talk) 23:20, 17 February 2021 (UTC)
Okay, good to know. Thanks for the response. Gryllida (talk) 23:29, 17 February 2021 (UTC)
Bad idea. Would just be a means of permanently tagging an article that a POV pusher doesn't like. Hawkeye7 (discuss) 23:22, 17 February 2021 (UTC)
Hi Hawkeye7. Thank you for your reply. Good correction to my initial interpretation. I didn't do this before and just picked it up in the helpme queue, would rather get to the finish of it somehow. With the tag off to be fair it might require a bit more editing. Again, appreciate the tip. Gryllida (talk) 23:46, 17 February 2021 (UTC)
Isn't a lack of an explanation also an unsatisfactory explanation? --Izno (talk) 01:24, 18 February 2021 (UTC)
Hi Izno. In this case, the other contributor argued that satisfactory explanation was given, but they also instantly resolved all issues listed in this explanation. This is adorable and brilliant. Their fix, however, lacked some depth; some issues remained; and I can't afford to reply to them instantly to detail. That leaves the article in a bad state, without a tag, for however long it takes someone to either re-articulate or fix the remaining issues. For a BLP I find this a bit disturbing and my first thought, initially, was that the tag got to stay. (For this particular incident, I've made a draft version in my sandbox, which has some of these issues fixed at the cost of breaking the article flow, and is not publishable; then I invited the other contributor to finish it up; so far, no response.) Gryllida (talk) 02:56, 18 February 2021 (UTC)
Remove the second condition altogether.
  • if no clear reason exists, people are going to hash it out on the talk page. The tag should remain up until people figure out it was a drive-by tag. Then, the first condition becomes true (consensus exists that the article meets NPOV), and someone should remove the tag.
  • if neither a clear reason nor a discussion exists (very few interested parties), the last condition is true, and someone should remove the tag.
If the tag exists to notify readers of an active discussion about an article's neutrality, the first and last bullet points suffice, and the middle unneeded. Rotideypoc41352 (talk · contribs) 05:55, 18 February 2021 (UTC)

WP:VANISH, WP:CLEANSTART, and privacy concerns

I am in a public-facing field where harassment and doxing is common, and have witnessed it happening to many of my colleagues in the past several years. As such, I've tried to do basic identity hygiene, closing old accounts, attempting to get taken off people search, and otherwise removing any information that can be linked to my identity. (I realize this sounds paranoid, and I'm sorry I can't be more specific.)

Unfortunately Wikipedia presents a problem in this regard. I made my original account in late high school/early college, when I was not in such a public-facing field. I know for a fact that the username, though not my name, is traceable to my real-world identity and, with some work, vice versa, and given that the account has somewhere in the tens of thousands of edits, I'm sure there are plenty of breadcrumbs there to other past usernames, communities, and identifiable information in the wrong hands. In an ideal world for me, the account would be nuked from orbit or at least renamed to something unique to Wikipedia.

Nevertheless, if I am reading them right, WP:VANISH and WP:CLEANSTART seem to be mutually exclusive. I don't recall being involved in any vandalism, blocks, major conflicts, or anything that would contribute to a negative reputation, and to my knowledge was in good standing. (The "I don't recall" and "to my knowledge" isn't me trying to evade anything, just that I don't remember everything that happened ~15 years ago as a high school junior.) I have no intention of using the old account, as that'd defeat the entire purpose, and as my username implies I am mostly interested in behind-the-scenes improvement, rather than any kind of subject matter-specific editing. (Which is also less traceable to my identity.) But nevertheless the options seem to be leave Wikipedia altogether, or live with the fact that my old info is just going to sit there indefinitely like a ticking time bomb.

So, I was wondering if the mutually-exclusive part of the policy could be revisited, at least for people whose clean start is for privacy, not reputational issues. It seems relevant that Wikipedia is over 15 years old at this point, the policy was created towards the beginning, and the average person's life circumstances change a lot more in 15 years than in 5 or so. It also seems relevant that online harassment is quite a different beast in 2021 than it was in 2007 and has grown to an extent that few people predicted at the time. Gnomingstuff (talk) 10:37, 18 February 2021 (UTC)

Wikipedia:Clean start does appear to apply for privacy concerns. You do not have to have a problematic record to use it. Graeme Bartlett (talk) 12:03, 18 February 2021 (UTC)
Clean start can be used for any reason other than evading scrutiny. The reasons listed in the lead section are just examples of the most common situations not a prescriptive list. Thryduulf (talk) 12:20, 18 February 2021 (UTC)
I did get that part (considering, well, the fact that I'm doing it and all); this is more in reference to the WP:VANISH note "Vanishing is not a way to start over with a fresh account. When you request a courtesy vanishing, it is understood that you will not be returning. If you want to start over, please follow the directions at Clean start instead of (not in addition to) this page. If you make a request to vanish, and then start over with a new account, and are then discovered, the vanishing procedure may be reversed, and your old and new accounts may be linked." Gnomingstuff (talk) 16:37, 18 February 2021 (UTC)
A 2¢ that I do think there should be an alternative to the two current options, for cases like this or for people who are undergoing active online harassment. —Wingedserif (talk) 23:24, 18 February 2021 (UTC)
Gnomingstuff What you're getting at has been discussed extensively, and I suggest you read some of the early discussions, especially c2:WikiMindWipeDiscussion, meatball:RightToVanish, and meatball:RightToLeave which are external discussions that influenced our early drafts of VANISH and CLEANSTART. Allowing something like vanishing for editors who want to disavow or hide their previous contributions can actually be counterproductive. For example, the problem with allowing c2:WikiMindWipes is that they have a Streisand effect. An account and its edits used many years ago isn't going to be noticed or easy to find. What will make it easy to find is flooding the recent logs with reverts, renames, and redactions. I say this having been in a similar situation (see questions 8 and 9 in my RFA) and with sympathy. In an ideal world for me, the account would be nuked from orbit or at least renamed to something unique to Wikipedia. Accounts in good standing can request a rename to just about anything they want, so if you simply wish to have the old name changed you can make a request by following the steps at WP:RENAME; Vanishing just uses a particular pattern to indicate that the user has decided to leave us forever and never return. In general though, even vanishing won't resolve the issue of breadcrumbs. Your talk page signatures will still be there. The rename log will still be there. The content of the edits will still be there. Modifying them will just bring hundreds of pages to the top of recent changes and admin action logs all singling out your information. It seems counterintuitive, but abandoning an old account is one of the best ways to ensure it doesn't get found. We have over a billion edits to millions of pages; finding things is hard, even when you know what you're looking for. Wug·a·po·des 23:04, 18 February 2021 (UTC)
  • Apologies, I'd checked the talk pages for both projects and didn't notice anything recent. Some clarifications: When I say tens of thousands of edits, it's with the caveat that the majority of them were cleanup, wikifying, that sort of thing. I doubt anyone here would even remember me at this point; I wasn't super memorable. I'm also not that concerned about somebody finding me from Wikipedia (which, as you mention, is highly unlikely, though probably possible if someone knows enough about me) but the other way around, finding my profile here from my username (which would be easy). Of course it'd take some effort to dig through those tens of thousands of edits, but the kinds of people who harass people online unfortunately overlap with the kind of people who'd do that (or just grep it). Gnomingstuff (talk) 01:11, 19 February 2021 (UTC)
@SlimVirgin: you might also be interested in this conversation. You brought the VANISH draft over from meta in 2007, and I remember you participating in a related discussion at AN a few months ago. No pressure though if you don't have much to say. Wug·a·po·des 23:06, 18 February 2021 (UTC)
  • I’m likely going to advertise this on the functionaries list since we literally just had a discussion about this topic. My general sense is that it’s better just to abandon an account because if you’re an established user vanishing just brings more attention to it. That’s what I did when I abandoned my account I created as a teenager to create this one. TonyBallioni (talk) 23:09, 18 February 2021 (UTC)
  • The gist of the recent functionary discussions Tony mentioned is that vanishing is inconsistently performed and misunderstood by many users. Personally, I would like to see it deprecated entirely. One common misunderstanding is that if you have disclosed personal information with your account, vanishing will make it private again. It won't. It obscures your former username to a limited extent, but anyone familiar with Wikipedia can find it and link it to all your previous contributions in less than 10 seconds.
We're probably overdue a conversation about how we can help people keep personal information private in this day and age, but we have to remember that Wikipedia is not a social media site, it's a publisher of free content. Retiring a Wikipedia account isn't like asking Facebook to delete your profile and all the information it has about you. It's more like writing a novel, then asking the publisher to remove your name from the cover after it's in shops. They're going to say "sorry no can do, but next time you can use a pen name". That's the space Wikipedia has to work in too. We can probably do better at warning people about the consequences of disclosing personal information under a CC BY-SA License, but we can't unring the bell if they do. – Joe (talk) 08:57, 19 February 2021 (UTC)
"but we can't unring the bell if they do." Wikipedia (ENWP) and by extension the WMF can unring that bell if they want to. It chooses not to. Material released under a CC BY-SA license may be kept against the wishes of the person who posted it but there is no legal obligation that requires it to be (except those rare cases related to attribution). ENWP cites the CC license as a reason for not deleting personal information, but its a matter of policy and process. And policy and process can be changed. Only in death does duty end (talk) 09:30, 19 February 2021 (UTC)
No, it can't. Even if it were practical to expunge say, a talk page signature with someone's real name from the history of thousands of pages (it's not), it's impossible for enwp or the WMF to do anything about the hundreds of mirrors, archives, database dumps etc. that have replicated that signature across the web. Copyleft licenses by definition relinquish control over information the moment it is released. – Joe (talk) 09:54, 19 February 2021 (UTC)
Again yes it can. It chooses not to (in the first case). Its technically trivial for a qualified database engineer to replace that sort of information. The main problem the WMF has is that its technical staff couldnt code their way out of a paper bag. And in the second, that argument is essentially 'other people will keep it, so we might as well too'. Again that is process issue, not a legal requirement. That a license relinquishes control over material does not then dictacte how that material *must* be used. Or even kept. "It would be difficult and we couldnt make other people do it" is not a valid rebuttal to the suggestion that we dont do it. People are generally not going to care if crappy little mirror with maybe 1000 views a month has the potential that their personal info might be seen, when ENWP with its millions of views will guarantee it will be. Only in death does duty end (talk) 10:02, 19 February 2021 (UTC)
That's a lot of assumptions. Let's take a common story: I'm worried that someone, let's call them my nemesis, could use my Wikipedia contributions, associated with my real name, against me. I vanish this account and persuade someone at the WMF to run a query to remove my name from millions of page versions and log entries replicated across god knows how many database instances (invalidating the attribution chain and edit history of tens of thousands of pages on the way). After that, my nemesis googles "Joe Roe + Wikipedia" and finds, in the first page of results, a mirror like this. Ah, they think, I did have a Wikipedia account. They go to https://en.wikidark.org/wiki/Special:Contributions/Joe_Roe and find a red link, but no problem, put https://web.archive.org/ in front of that address and you get a permanent archive of all my contributions. So all that work to bend the third pillar and make me disappear was undone in about thirty seconds.
Or another common story. I don't have a specific nemesis, but I regret associating my contributions with my real-life identity and do the same vanishing and transparency-breaking database procedure. Someone sees a talk page comment signed User:Renamed user XYZ and gets curious about who it is. In the first few pages of XYZ's contributions, they see that they're an archaeologist interested in the Near East and statistical computing, who lives in Denmark. Those four diffs alone narrow it down to maybe 2-3 people in the world and again a quick google search will establish it's probably me. Is it "trivial" for a database engineer to identify those sorts of incidentally-disclosed clues to someone's identity? Bearing in mind that two of those diffs are to articles, not talk pages? And one isn't mine, it's another user (appropriately) alluding to personal information I've disclosed elsewhere?
I'm not denying that we can do things (vanishing, oversight) to make it slightly harder to find personal information on Wikipedia, but presenting these kludges as solutions to privacy concerns is dishonest and potentially dangerously misleading. What we need to do is make it crystal clear to people, from the beginning, that everything they do on Wikipedia is in the public sphere. And that in an emergency, they need to take steps to protect themselves beyond what we or the WMF is capable of. – Joe (talk) 11:01, 19 February 2021 (UTC)
What is dishonest is your continued insistance that it cant be done while relying on 'well it would be kept elsewhere so we might as well not'. It exaggerates the edge cases. Firstly absolutely no talk or user page contribution on ENWP is necessary to be kept at all. And while yes archive sites *may* archive some material, this is not universal. You also appear to have a basic misunderstanding of Attribution. Attribution is required on ENWP for material kept on ENWP. It is not necessary, or in fact required in any form, for ENWP to keep an attribution record chains simply for the purpose of third parties who may use material copied from ENWP, when that material has been removed/deleted from ENWP. The onus on the third party to attribute correctly. If it breaks for them, that is not our problem. The point of removing personal information is not to make it completely impossible to identify someone, it is to make it significantly more difficult to do so and to eliminate the casual dissemination of personal info. The attitude of 'well since a significantly dedicated person with lots of time on their hands could jump through 15 hoops to get it means its pointless' is both lazy thinking, irresponsible, and violates any number of data protection principles in various parts of the world. What we need to do is change the attitude that other peoples personal information is fair game forever just because it was decided in the past that was what ENWP should do. Only in death does duty end (talk) 12:30, 19 February 2021 (UTC)
I think the focus on attribution misses the point. As brought up in c2:WikiMindWipeDiscussion, while anyone is free to remove content, anyone is free to add content as well. If someone goes around removing their signatures, they will quickly get reverted by the community. We have two options then: convince everyone to not do that or convince admins to start blocking people who revert modifications to talk page archives. Both of those are uphill battles, to say the least, and if there is any controversy we risk bringing the personal info squarely into the spotlight at AN, completely negating the privacy benefit of a mindwipe. Going beyond that, we cannot guarantee privacy once the information has been posted, and pretending to do so is irresponsible if not unethical. Even if we were to allow revision deletion of edits by vanished users, we risk increasing the potential visibility and harm. There are people and robots which watch our deletions. An easy way to get their attention is to have a nicely organized, compact section of log entries that correlates page redactions with a rename. We could have those log entries redacted too, but redacted log entries are even more conspicuous than revision deletions. Even if we did agree to allow this, such operations take time and are error-prone. If anything is missed, the whole process could have been pointless, and even if we are perfect, the time it takes from start to finish is more than enough time for mirrors to preserve the information beyond our control. Now, at this point, we've succeeded in eradicating the editor's personal info from our servers, sure, but we've also painted a huge target on their back as every deletion log watcher begins to wonder why hundreds of log entries were redacted without explanation. They then go to mirrors and find all the info they need and then go post about it on Wikipediocracy for some bad faith actor to find later. Have we succeeded in helping the editor? Did all our work protect anyone from harm? Is this a situation we should encourage anyone worried about their privacy to put themselves into? No on all counts. Let's go one step further and try to fix the fundamental issue: logs. That's the domain of the MediaWiki project, not EnWiki, and getting devs to change the software to eliminate any kind of logging will likely be even harder. The software is built around transparency, and we would need substantial buy-in from that community to have them change their primary principles. Are these edge cases? Maybe, but vanishing is an edge case in the first place. Security systems which ignore edge cases are not secure, because exploiting edge cases is exactly how you defeat security systems. Wug·a·po·des 22:48, 19 February 2021 (UTC)
This is kind of where my "it's now been 15 years" remark comes into play; that's a very long time both in terms of developments regarding Internet privacy and in terms of life stages. Editing in high school/college is one; another very plausible situation is that someone might take a job requiring extensive background/security checks, or a job with risk of being fired for off-work activities like grade-school teaching, that was not on their radar over a decade ago. "Everything you do is in the public sphere" is all well and good in hindsight. The concern about edits being conspicuous is valid and something I don't have a good answer to. The only thing that immediately comes to mind is a system that automatically anonymizes usernames after X period of inactivity (which, of course, could be undone should the editor decide to come back), but that doesn't solve the log issue above so much as drown it in noise, and I imagine people might have other objections to it. But at the very least, the current policy ("leave it or leave," essentially) has room to be loosened. Gnomingstuff (talk) 02:41, 20 February 2021 (UTC)
  • Re Gnomingstuff's problem, I recommend abandoning the account without any drama (no further edits, no "retired" tag or other farewell message). After a delay, start a new account with no mention of the old account. Or, if your particular situation would be helped by vanishing (renaming) the current account, do that per VANISH. However, the advice above is correct, namely that vanishing is a very flimsy mechanism that is easily undone. Ignore the instructions about connecting your new account to the old. Instead, send an email to Arbcom (see User:Arbitration Committee) briefly explaining the situation and telling them you have created the new account (which you would reveal) without linking it to the old account in order to avoid harassment. Johnuniq (talk) 00:59, 20 February 2021 (UTC)
  • @Gnomingstuff: Just to be clear, "courtesy vanishing" is just a rename to some random nonsense, userspace deletion, and possibly the deletion of irrelevant meta discussions about the user themselves, which most people don't have to begin with anyway. It doesn't do anything beyond that. Your signatures will still be there and they will still link to your renamed account. You can still rename your account to some random user name, delete your userspace, blank your talk page, and then do a clean start. You'd be achieving the exact same thing, the only difference is that your rename would have to be "carefully chosen" rather than random characters caused by slamming your hands on the keyboard. ~Swarm~ {sting} 01:43, 20 February 2021 (UTC)
  • We should have a hygiene-vanish process where an old account gets renamed and a bot searches-and-replaces signatures from the old name to the new name. Some trusted authority who've signed NDAs like arbcom or maybe OS or CU (or T&S) can administer and keep a record for any copyright or other legal-related needs. This won't be 100% deletion because the old name will still be in old revisions and that's unavoidable, but at least it'll make it so searching for the old name won't bring up any results. And that option should be open to any editor in good standing. Levivich harass/hound 08:08, 20 February 2021 (UTC)
    • Umm, no. First, wide-scale editing is disruptive, particularly in archives where "this hasn't been touched" is a good indication of the archive's integrity. More importantly, such changes would draw massive attention with the certain result that dozens of people would notice that User:X was renamed User:Y, and a non-trivial number of those would be sufficiently curious to investigate the background. Finally, if someone ever wonders why they can't find the editor they planned to harass, they can simply look in the bot's contributions for a permalog of all vanished users. Wikipediocracy and other troll sites would quickly set up a system to translate the bot's contributions into a handy table: X was renamed Y on such-and-such date, with a comments section for any gossip they can find. Johnuniq (talk) 09:35, 20 February 2021 (UTC)
      • The bot can delete its own edits. Heck it doesn't even have to be a bot, this can be done "server-side" and not be logged at all. We can think outside the box. We can prioritize privacy over watchlist disruption. Levivich harass/hound 15:03, 20 February 2021 (UTC)
        If it was done without logging then someone would just write a bot or script that compared the public dumps to pick out the changes to signatures. Consider also comments like the one above that begins Re Gnomingstuff's problem. No signature changing process will remove that and many breadcrumbs would be left. While you could go through and change all instances of "Gnomingstuff" to "Vanished user XYZ1234" with very few false positives, you definitely could not do that with usernames like "Swarm" or "Joe", nor for user's whose names get abbreviated - not all instances of SV relate to user:SlimVirgin, my username is sometimes shortened in discussions to "Thryd", "Thry", "Thr" or even just "T" when that is unambiguous, plus there are many different misspellings of it. There is literally no way to put the genie back in the bottle and any attempt you make to do so will just draw attention to whatever it is you are trying to hide. The Streisand effect is real and inescapable. Thryduulf (talk) 16:24, 20 February 2021 (UTC)
        • On the other hand, if somebody malicious were to google "Thryduulf" looking for dirt, it would be much harder to find it if the only references to you were "Thryd". (Or even virtually impossible; googling site:wikidark.org "thryd" -thryduulf turns up nothing identifiable.) This is where I think we're talking past each other. Some people in this discussion seem mostly concerned about people involved in Wikipedia discovering a real-world identity. My concern is people outside Wikipedia identifying a Wikipedia profile, given a username. Gnomingstuff (talk) 06:16, 21 February 2021 (UTC)
          Where we're talking past each other is that your concern isn't clear. Above, you raise the concern about extensive background/security checks, but now you're raising concerns about cursory google searches. These are different problems, but the common problem being ignored is mirrors. If you google "wugapodes" the first page of results returns this mirror of my userpage and this mirror of my talk page which contains my signature and the signatures of many other people. It even contains this Wikipediocracy thread where people discuss my Wikipedia contributions including my previous username. If I delete my userpage, rename myself, mind wipe all my signatures, change the database, and so on and so forth, we cannot take down those pages. The mirrors are legally entitled to continue displaying that content for all time, and I gave them that right when I hit publish. The Wikipediocracy thread isn't even a mirror, yet it contains far more personal information in a localized space than all my Wikipedia contributions. Those people watch our deletion and redaction logs constantly and there are multiple threads on Wikipediocracy discussing deletions and redactions, including links to unredacted archives. We could delete the entire encyclopedia to protect my privacy, and it will have absolutely no effect on any of that. We can build whatever convoluted system for post hoc anonymization we want, and you will still not be protected from the most basic of google searches, let alone an extensive investigation. It is irresponsible to pretend otherwise.
          We can consider how to better protect anonymity going forward, but the reason you have not gained much traction so far is that you are not grasping the uncomfortable reality that a lot of the information you want hidden is on servers we do not control. Unless you have an idea on how to force other people to give up their legal rights to republish our content, you will not be able to scrub your history from the internet. That is sad, and as Joe said above we can do a much better job of making that fact clear to contributors, but we cannot change the past with wishful thinking. I appreciate Levivich's suggestion, and even the WMF is working to better anonymize IP addresses, but it boils down to security theatre. Neither of those efforts would stop a mirror from hosting the usernames or revision content, and so we would be rewriting our own history and creating large amounts of work for volunteers in order to give the illusion of security with no actual security improvement. That is irresponsible, and I will not advocate lying to contributors about our ability to protect anonymity. I am on record advocating for strong rights to vanish, and I care deeply about online privacy. But we cannot improve our privacy practices if we cannot acknowledge the reality that nothing is ever truly gone on the internet especially when you irrevocably allow others to republish it as much as they want. Wug·a·po·des 22:42, 22 February 2021 (UTC)
          This is all true but "truly gone" isn't the relevant standard. Imagine if Twitter said, "We won't allow you to delete your Twitter account because even if you deleted it, it would still be available on mirrors and archives, and the deletion would draw more attention to the account than just abandoning it and starting a new one." I mean, you'd think they'd let the user make that decision! I think there are some aspects being overlooked. First, the plain truth that Wikipedia is a database and it can be changed without creating any kind of public log entry. (Volunteers won't be the ones doing that, it'd have to be a WMF employee or contractor, so it wouldn't take up volunteer time.) And while it's true that even such a change won't eliminate all traces of the removed name, and will be noticeable by anyone who takes the time to thoroughly investigate, and may even be discussed at WO, all of that pales in comparison to having something on Wikipedia.org, which is a top-10 website. "Wugapodes" is a poor example of this, because it's a unique word. Try Googling "John Smith". The first couple results are Wikipedia.org, and then there are many, many pages of results before you see a Wikipedia mirror, much less Wikipediocracy.com. So removing "John Smith" from Wikipedia.org is a HUGE benefit if you're trying to hide "John Smith" from the internet, even if "John Smith" remains on mirrors, and even if they talk about him on some obscure web forum. And it should up to John Smith to decide whether he'd rather have Wikipedia.org be the #1 search result, or have some internet sleuths deduce that "John Smith" was removed from Wikipedia by, e.g., comparing database dumps or log entries, and talk about it on WO. We ought to have some process to wipe, even if the process isn't perfect, and we should let the user decide about Streisanding risks rather than deciding for them. $100 million a year is enough to pay for the development and execution of a privacy protection policy that allows people to remove things from Wikipedia. I think the much more difficult question to answer is what that policy would look like, and what the safeguards would be to prevent misuse. Levivich harass/hound 07:09, 23 February 2021 (UTC)
          Firstly, we can argue about what is and isn't a good example, but my understanding is the concern was about an attacker knowing a username, not a legal name. I would argue that on a scale of "uniqueness" most usernames on EnWiki fall closer to "Wugapodes" than they do "John Smith". Leaving that aside, the method of security demonstrated by your "John Smith" example is the exact method we already use: rename the account and let it get lost in the noise of more recent edits, see meatball:PracticalObscurity. That said, I don't think arguing about examples and counter examples here will actually get us anywhere productive. I want to focus on what you say here: "truly gone" isn't the relevant standard. Then what is the relevant standard? I don't mean that rhetorically, I'm curious what we're trying to prevent because we need to know what we're trying to protect if we want to build an effective protection system.
          My understanding is that we're considering an attack where bad-hat actor Bob knows Alice uses the handle xXxAlicexXx and is trying to use that fact to find out more information about Alice. We have sensitive data which Alice posted here under that handle, and we want to prevent Bob from (1) finding out that Alice edited here and (2) finding the sensitive data Alice published here. For (1) a standard rename is just as effective as "deleting" the account, especially if the rename log entry is redacted. For (2) our oversight policy allows pretty liberal use of the tool for hiding personally identifiable information--and the logs are hidden from all but the most trusted users. Given that, what's left to hide? What other standard are we going for other than "truly gone"? I brought up that standard because that seemed to be what was left, but it wouldn't be the first time I overlooked something.
          Lastly, there are a lot of differences between Wikipedia and Twitter, but ignoring most of them, tweets are atomic. You can delete a tweet without having to disentangle it from any other tweet. With a list of tweets (i.e., a profile), you can delete them all programmatically (by bot or script) without materially altering any other tweet in the database. This is not necessarily true of edits or contributions pages, and anyone who has used the "undo" button on an old edit knows this problem. Consider: Alice adds the text "I like puppies" and Chuck later comes by to change it to "We like puppies" and then Daisy changes that to "We like kittens and puppies". Now Alice wants all her contributions deleted and scrubbed...how? The fundamental content Alice added is still there, and even some of the original words. If we just removed the commonalities we would be left with "We kittens and" so we need something more robust than reverting whatever text Alice added that's still on the page. Will we have a human review and resolve every single conflict? Do we also revert Chuck and Daisy despite their changes being good and helpful to building an encyclopedia? Do we just delete Alice's username but leave the content up causing licensing problems later on? These are hard problems that twitter will never have to face when deleting a profile. Now consider a talk page thread: Alice makes a comment and Ethan replied directly to her. Will Ethan's comment just be a reply to nothing? What if Ethan quoted Alice or mentioned her by name (i.e., pinged her)? Will we modify Ethan's comment, or even delete it outright? What if Ethan doesn't like the decision and adds Alice's comment back under CC By-SA so that his comment retains its context? Will we edit war with Ethan? Block him for trying to make sure his comment is seen in proper context? We're not Twitter, and deleting content is not trivial, especially old content. We can come up with answers to these questions, but other people may have wildly different opinions on what is correct (I imagine this is what you meant by I think the much more difficult question to answer is what that policy would look like so I say this for the sake of others).
          Developing a consensus answer acceptable to the community will be hard, especially when the practical benefit is limited. I agreed with Joe above that we should focus on prevention not because I think it is the ideal solution, but because it is the most effective solution that we can build consensus around. For example, in edit-a-thons I advise new Wikipedians to not use their real name, especially women, because of the potential for harassment and difficulty of retraction should they regret the choice later on. Our essays at Wikipedia:Personal security practices and Wikipedia:Guidance for younger editors do a really good job of describing risks and prevention strategies users can take; making those more visible to logged out and new editors would help prevent contributors from publishing information they may later want to retract which is a more effective harm reduction strategy in the long run. We already link to Wikipedia:On privacy, confidentiality and discretion at Special:CreateAccount, but adding reminders in the edit window or in welcome messages can also help. How volunteers spend their time is up to them, but I think focusing on intermediate steps we can take now is a better return on investment. It might even help people be safer on websites other than our own. Wug·a·po·des 09:29, 23 February 2021 (UTC)
          Then what is the relevant standard? "Off the top page of google results" is one possible standard. "Less visible" is another possible standard. It's hard to argue with "an ounce of prevention is worth a pound of cure", and I agree with you that that's the place to focus, but I also think we should do what is being asked in the OP, which is to allow WP:VANISH for users who want to WP:CLEANSTART (as opposed to only for users who do not want to return). Levivich harass/hound 21:31, 23 February 2021 (UTC)

You're welcome to rename your account the traditional way, and then CLEANSTART afterwards. Beyond that, I agree with the sentiment above: anything more is either technically impossible, or is likely to draw more attention to you and your edits. power~enwiki (π, ν) 23:13, 22 February 2021 (UTC)

Even this discussion may already have drawn attention of the kind you wish to prevent. · · · Peter Southwood (talk): 06:46, 23 February 2021 (UTC)

Evaluating WP:NEXIST

There is a discussion over at Wikipedia talk:Notability#WP:NEXIST that might be of interest. Thank you CapnZapp (talk) 15:34, 20 February 2021 (UTC)

Concerns about the usage of draftspace

I'd like to raise some policy concerns regarding the current usage of draftspace, specifically the practice of moving new or relatively new articles to draftspace (presumably as a part of WP:NPP). The WP:DRAFTIFY section of Wikipedia:Drafts policy explicitly says regarding this practice that "It is not intended as a backdoor route to deletion." Moreover, it also further says that any editor has the right to object to an article having been moved to draftspace, and that if such an objection is raised, the article must be moved back: "Other editors (including the author of the page) have a right to object to moving the page. If an editor raises an objection, move the page back to mainspace and if it is not notable list at AfD."

The problem is that, as a practical matter, few users, particularly among the new users, have any idea that this right to challenge a move to draftspace even exists. When a page is nominated for deletion, the page's creator is notified of that fact and is informed, via a template, how to participate in the deletion discussion. The same thing happens with a CSD tagging. However, something completely different occurs when an article gets moved to draftspace. The creator does get a notification message but this message says nothing about the right to contest the move or how to exercise that right. Instead the page usually gets tagged right away with one of the Draft/AfC templates, such as Template:Draft article or Template:AfC submission/draft. The notification message about the move to draft space only says that when the draft is sufficiently improved, it may be submitted for the AfC review. There is never any mention that the AfC process is optional for autoconfirmed users either.

These moves to draftspace are often performed by fairly inexperience users, with limited understanding of deletion and notability policies and with no discussion. In effect such moves do function as deletion from mainspace decisions, but they are subject to almost no oversight. Even in those cases where such moves are performed by experienced users, the current practices are highly problematic. They give a single user, performing the move, too much power that is not subject to meaningful challenge. The current practices for user talk page notifications about moves to draftspace are, IMO, actively misleading.

I feel that we need a stronger policy framework governing this process. Thus, IMO, whenever a page is moved to draftspace as a part of NPP, the notification message (either manual or via a template) to the creator's user talk page must explicitly mention that the creator has the right to contest the move and explain how to exercise that right. I think this requirement needs to be included in WP:Drafts. Nsk92 (talk) 18:27, 20 February 2021 (UTC)

I wholeheartedly agree. This whole "moving to draft space is not a backdoor route to deletion" idea must be one of the biggest lies on Wikipedia. Many articles that are moved to draft space do not then get edited and are speedily deleted after 6 months with no further consideration of whether the subject is suitable for a Wikipedia article. Phil Bridger (talk) 18:40, 20 February 2021 (UTC)
I agree with both of you. I'm sure we had a discussion recently about moving to draftspace leading to deletion, but I can't remember where it was. My vague recollection is that it resulted in broad agreement that things needed to improve but the vocal objections from a few who see throwing babies out with bathwater when defending against spam resulted in nothing happening. Thryduulf (talk) 19:18, 20 February 2021 (UTC)
I've found a couple of discussions - Wikipedia talk:Criteria for speedy deletion/Archive 78#Roundabout G13 deletion of mainspace articles (July 2020) and Wikipedia talk:Criteria for speedy deletion/Archive 77#G13 and articles moved to draftspace (May 2020) but neither was the one I was thinking of! Thryduulf (talk) 19:29, 20 February 2021 (UTC)
Interesting, thanks. I haven't thought about it until now, but in effect the moves to draftspace do function as a kind of a soft form of speedy deletion. I see quite a few threads at Teahouse from new and not so new (but already autoconfirmed) editors whose articles have been moved to draft and who don't understand what hit them. Probably in a substantial majority of cases such moves are justified and the editors are also well advised to utilize the AfC. But I also feel that we need to be more honest with them and explain more clearly to such editors what's happening and what their options are. E.g. a user talk page notification message informing about a move to draft space and the right to contest it should probably also explicitly say that in that case an article may be listed for an AfD. With the current system I suspect that we are losing not only articles but editors too. Nsk92 (talk) 19:50, 20 February 2021 (UTC)
If an editor creates an article and has any thought about after it is published, then they will note the move to draft space and improve if the article can be improved. Moving to draft may well be a backdoor deletion method, but for content that merits deletion as presented. BD2412 T 20:11, 20 February 2021 (UTC)
If the content merits deletion then that's what PROD and AfD are for. Nsk92's comment shows that there are people who do have a care about what happens to the content after they've published it who are not being served by current practice - and chances are there are editors in a similar position who don't find their way to the Teahouse. Remember not to assume that everybody knows how Wikipedia works already. Thryduulf (talk) 20:28, 20 February 2021 (UTC)
If "moving to draft may well be a backdoor deletion method" then we should be honest about the process and not claim that it is not. The current process means that any editor, including ones that would never remotely be considered for adminship, can in effect delete articles. We need to remember that article creations are not the personal property of their creators but potentially valid encyclopedia articles that belong to everyone. Why shouldn't we use the procedures that we have, such as AfD, which, if successful, won't leave a page languishing for six months without a hope of ever becoming an enyclopedia article? Phil Bridger (talk) 20:39, 20 February 2021 (UTC)
I must add something that I heard a short time ago on the radio - I'm afraid that I was busy cooking dinner at the time so didn't catch the name of the speaker or the programme, but know that it was on BBC Radio 4 - on the lines of "procrastination doesn't lead to fewer decisions that must be made but more, one to put off the decision and one to make it". We are simply pushing decisions into the future, when they have to be made anyway, by the current use of draft space. Phil Bridger (talk) 20:52, 20 February 2021 (UTC)
In a substantial percentage of cases the moves to draftspace affects articles that do not merit removal from mainspace "as presented". These moves are often performed by relatively inexperienced users engaged in NPP. I am not even sure that having a 'New Page Reviewer' userright is actually needed to configure Twinkle to perform such moves (and they can always be performed manually). In any case, if this process really functions as "a backdoor deletion method" then, as Thryduulf and Phil Bridger noted, we should be honest and treat it as such. For deletion we have AfDs and DRV, plus the CSD tags are reviewed by an admin and the article's creator can contest them. With a move to draftspace, none of these safeguards currently exist. In fact the current process is quite obscure to the point of being misleading. The editors whose articles get moved to draftspace get a notification telling them that when a draft is sufficiently improved they can submit it for review to AfC. They'd have to click on WP:DRAFTS, read it most of the way through, find the passage that talks about the right to contest the move and figure out what to do with it. That reminds me of a passage from The Hitchhiker's Guide to the Galaxy with a quote by Vogons regarding the demolition of Earth: "All the planning charts and demolition orders have been on display at your local planning department in Alpha Centauri for 50 of your Earth years, so you’ve had plenty of time to lodge any formal complaint." I would, in fact, be much happier with a system where NPP moves to draftspace were officially treated as a special form of speedy deletion and required a special kind of a CSD tag. A tag could be placed by any user on a new unreviewed article, but would have to be reviewed by an admin, and the reviewing admin would have to perform the actual move to draftspace. This way the article's creator would have a chance to react before the article is yanked out, and perhaps even to improve it so that a move to draftspace becomes unnecessary. Nsk92 (talk) 21:57, 20 February 2021 (UTC)
As much as I believe that WP:AfC is a really useful process that all new editors should be encouraged to follow to learn about article creation, if users have a right to contest any draftification, they should be explicitly informed of this. It would help if there were an easier way of doing this too. I've seen many editors perform cut and paste moves when contesting a draftification, which creates problems itself. Spiderone(Talk to Spider) 14:14, 28 February 2021 (UTC)
  • There is another option here... Userfication.... the original creator (or any other editor) can REQUEST that the material be copied over to their USER sandbox space (not DRAFTSPACE), where they can improve it at leasure. Blueboar (talk) 23:00, 20 February 2021 (UTC)
    Only if they know that is an option and know where and how to ask for it. This is unlikely the case for new users given the current information given to them. Thryduulf (talk) 02:53, 21 February 2021 (UTC)
I agree that this is a problem and something like the OP's suggestion is desirable. Ping me if it gets to RfC. · · · Peter Southwood (talk): 07:08, 23 February 2021 (UTC)
This recently happened to an article that I translated, and I agree that it was a confusing process. It was completely unclear from the notice why the page was draftified instead of just tagged with refimprove. I only found the note about being able to contest after searching myself through policy pages. In the end, it was easier to just add some sources to fix the problem; it seemed like having to litigate would have been more complicated than it was worth. —Wingedserif (talk) 16:57, 28 February 2021 (UTC)
  • I certainly agree that there is a problem with how draftification is often used. What needs to happen for this to move forward? Ingratis (talk) 18:20, 28 February 2021 (UTC)
  • So what’s the proposal here? Celestina007 (talk) 18:42, 28 February 2021 (UTC)
    The proposal made is, as clearly stated by the editor who proposed it, that editors creating articles that are moved to draft space should get a message that clarifies that, per WP:Drafts#Requirements for page movers, they have a right to get an article moved back to main space by the person who performed the move, where those articles may be subject to our normal deletion procedures. This is no change to any rights that anyone has, but merely a proposal to make sure that editors know about those rights. Personally I would go further and say that draft space should be done away with as a failed experiment, but that is not the proposal being made here. Phil Bridger (talk) 19:02, 28 February 2021 (UTC)
    Any views on obliging article creators to comply with the requirement to provide multiple RIS for their articles? Or is everyone fine with them sitting in mainspace with tags? Mccapra (talk) 20:33, 28 February 2021 (UTC)
    That's a completely different issue. Nothing proposed here would stop anyone nominating an article for deletion. Phil Bridger (talk) 20:41, 28 February 2021 (UTC)
    That’s exactly the issue. There are many new articles that may be notable (with so many being about topics in countries where I don’t speak the language it can be hard to determine). For one reason or another the creator provides no sources, or inadequate sources. Let’s say I can guess it’s likely to be notable. What I would do now is draftify it if there is no response to tagging for notability/more sources. If the creator can just oblige me to move it back to mainspace you’re saying that’s fine and it should just sit there with its tags till someone else comes along some time to put it right. If the consensus is that this is fine I kind of think everyone at NPP is wasting their time really and mainspace will rapidly fill with many more unsourced or poorly sourced articles. Mccapra (talk) 20:51, 28 February 2021 (UTC)
    What you describe is the current consensus per WP:Drafts#Requirements for page movers. If you want to change that then you should propose doing so, but his proposal is simply to tell article creators what the current consensus is rather than hide it from them. For most of the time that Wikipedia has existed we operated as a wiki and had articles edited in main space, with them being deleted if they met the criteria. Draft space is a recent innovation. Phil Bridger (talk) 21:13, 28 February 2021 (UTC)
    Yes and it’s a good innovation because 1. It supports our continuing drive to ensure that all mainspace articles are properly sourced and 2. There are many articles created that are possibly notable but where notability has not been demonstrated. I think the story that it is “backdoor deletion” is unproven at best and in fact pretty spurious. Mccapra (talk) 21:19, 28 February 2021 (UTC)
    Your opinion is noted, but whether draftification is or is not a backdoor route to deletion is irrelevant to this proposal. Currently, if an editor objects to their page being moved to draft space (for any reason or no reason, whether or not the move was correct according to policies, guidelines, custom or practice) they have the right to ask that the move be reverted and the page returned to mainspace. If a page is moved back to mainspace then anyone who thinks it should not be in mainspace is entitled to nominate it for deletion in the same way as if it had not been moved in the first place. Literally the only thing this proposal would change is that editors would be informed that they have the right that they currently have. Nothing else. Thryduulf (talk) 21:53, 28 February 2021 (UTC)
    they have a right to get an article moved back to main space by the person who performed the move this is problematic because editors take responsibility for content they add. So if I accept a pending changes edit, or an AfC draft, to some degree I'm taking responsibility for that edit. Requiring editors to move highly problematic drafts back into mainspace is problematic, thus. And it's also unenforceable. What, are we going to start blocking editors for refusing to move a problem draft into mainspace now? I'm okay with making it more clear of a user's ability to move their draft back into mainspace and their right to have it subject to a deletion discussion. ProcrastinatingReader (talk) 22:17, 28 February 2021 (UTC)
Note that WP:DRAFTIFY already requiries that an article, whose draftification has been challenged, be moved back to mainspace, even if the quality of the draft is obviously poor. If an editor raises an objection, move the page back to mainspace and if it is not notable list at AfD. The current wording is not explicit on who shoulfd perform the move back, but I think the wording suggests that it should be the editor who originally draftified the article (the bit "and if it is not notable list at AfD" doesn't make sense otherwise). IMO, it is reasonable to require the editor who performed the original draftification to perform the move, if the author of the article specifically requests it (and requests that it be the editor who draftified the article move it back). There are situations where the creator of the article can't perform the move, e.g. if that editor is not yet autoconfirmed and the article was created via AfC. There will be other situations where the creator of the article is a relatively new editor who is autoconfirmed but is unfamiliar with the pagemove process across namespaces and doesn't feel confident enough in doing it themselves. Draftification is performed by a single editor with no discussion and no prior notice . No, it is not too much of an imposition to require them to move the page pack if requested, even if the page is in very poor shape. They should be free (and sometimes encouraged) to immediately list the page for AfD after that. Moving a page back to mainspace should be viewed as similar to a WP:REFUND restoration of a previously deleted article that had been PRODded. The admin who REFUNDed the article performed a procedural due process action and does not assume responsibility for the restored content. Nsk92 (talk) 00:15, 1 March 2021 (UTC)
@Nsk92, it’s not a bad idea that the editor is aware of their rights, it’s only fair I guess, but one of the reasons for draftifying an article is for addressing undeclared COI, so wouldn’t this be encouraging COI editing, in the sense that they are able and feel empowered to disregard disclosing their COI & unilaterally move the articles back to mainspace without proffering an explanation as to what their COI is, or are we okay with articles on mainspace with tags on them that would most likely never be addressed? sometimes AFD'ing an article wouldn’t always be the viable nor plausible option such as, when the article created by the COI editor is actually on a notable subject. Celestina007 (talk) 07:52, 1 March 2021 (UTC)
Certainly agreed that we lose a lot of worthwhile articles to G13 due to draftifications. Some time back I created User:SDZeroBot/Draftify Watch to keep a track of these pages but unfortunately I've had little time to actually look at them and revert the problematic ones. ALso it's worth noting that a couple of users doing draftifications are quick to revert back if you revert them. – SD0001 (talk) 11:51, 1 March 2021 (UTC)
I just want to be clear that while anyone can engage in looking at new articles, actual NPP, which is referred to multiple times in this discussion, comes with an associated user right, NPR. I agree that draftifications against the guideline prevent good information from being in mainspace. I do think the answer for this is to talk to people doing a poor job rather than adding an additional layer of bureaucracy into an already heavily regulated area (even if the actual deliver of this would be done by script for most). Best, Barkeep49 (talk) 21:33, 1 March 2021 (UTC)
Agree with Barkeep49, I also can't really see from the above discussion anyone actually providing any evidence that there is a genuine issue here with NPP draftification. Polyamorph (talk) 13:04, 2 March 2021 (UTC)

Wikipedia:Requests for comment/Desysop Policy (2021)

I have opened an RfC at Wikipedia:Requests for comment/Desysop Policy (2021) to discuss establishing a community based desysop policy. All are invited to comment. TonyBallioni (talk) 20:46, 20 February 2021 (UTC)

Edit summaries

I was reminded in a discussion today that Help:Edit summary is neither a policy nor a guideline, but just an information page. I had been kind of aware of this fact, but did not think that it mattered until now. I had understood that the use of edit summaries was a widely accepted norm anyway and so it didn't matter that the page had no policy guideline/status. However, in a discussion with another user (in fact an admin) that user expressed the opinion that edit summaries are optional and that he views them as only helpful in some cases while in others they dusrupt his workflow. There may be a sizable what I presume to be minority of users who hold similar views. There are also quite a few users who do believe that edit summaries are useful and necessary but whose own usage of edit summaries is intermittent.

Therefore I believe it would be useful to upgrade the status of Help:Edit summary to that of an editing guideline, and perhaps insert some stronger language there. To be clear, I am not talking about any technical changes such as forcing the wiki software to always display a warning box if an edit summary is not provided. But I do think that the basic principle that every edit needs to be accompanied by a meaningful edit summary needs to be elevated to the status of an editing guideline. Nsk92 (talk) 15:37, 22 February 2021 (UTC)

As the correspondent in the discussion described above, I note that it is a fair and neutral description of the discussion, and look forward to rational and evidence based debate on the matter. · · · Peter Southwood (talk): 05:07, 23 February 2021 (UTC)
  • This should be moved to WP:Village pump (proposals). Primergrey (talk) 05:40, 23 February 2021 (UTC)
    I think it's fine here; this is the place for policy proposals. {{u|Sdkb}}talk 07:14, 23 February 2021 (UTC)
    Just going from the message at the top stating, If you want to propose something new that is not a policy or guideline, use Village pump (proposals). I wouldn't normally mention it, but this proposal has potentially huge implications and should probably be where it would be most expected. Primergrey (talk) 07:24, 23 February 2021 (UTC)
Primergrey, you are correct, but I am propositing a policy change: Upgrading the status of Help:Edit summary to that of a guideline. That's why I started this thread here rather than at WP:Village pump (proposals). Nsk92 (talk) 11:21, 23 February 2021 (UTC)
  • I'm hesitant to provide ammunition to anyone who might be inclined to bite a newcomer or make an attack along the lines of "hey, you didn't use an edit summary, therefore you messed up and are in the *wrong*". On the other hand, there is a significant subset of experienced editors who habitually refuse to use edit summaries, and are not moved by regular complaints on their talk page that it wastes others' time by prompting unnecessary scrutiny; I wish that we could apply a bit more pressure to these editors beyond just {{Summary2}}, and guideline status might help with that. I haven't given the page a close read lately, but if promoted, I'd want to see its language refined carefully to strike a balance between these things. {{u|Sdkb}}talk 07:13, 23 February 2021 (UTC)
There is a relevant talk page thread at Peter Southwood's talk page that he mentions above, see User talk:Pbsouthwood#Edit summaries, where pros and cons of edit summaries are discussed. (I'll try to just continue most of that discussion here.) Regarding new editors, they routinely break all sorts of other policies and guidelines and we extend a greater degree of tolerance to them for a while because they are newbies. I think some specific language in an eventual guideline can be used to ameliorate this concern as well as others. E.g. I don't think that refusing to use edit summaries (as opposed to deliberately using them misleadingly) should ever be considered disruptive behavior and lead to a block. Regarding editors who don't use or don't consistently use edit summaries, it appears that they fall into a several categories. Some do it because they are careless/lazy although they do, in principle, recognize the importance of providing edit summaries. Some do it deliberatetely to avoid scruitiny for their edits. (I suspect that this group is rather small.) There are some editors who have principled objections to relying on edit summaries and think that they are needed only in some specific types of cases. Peter Southwood is one of such editors. I believe that this subset of editors is also relatively small, but it does exist. I don't think that simply inserting stronger language in Help:Edit summary will be sufficient here, without changing the status of the page. Again, see the discussion at Peter Southwood's talk page to see why. Nsk92 (talk) 11:46, 23 February 2021 (UTC)
  • Many editors, even experienced ones, also do not use edit summaries, especially on talk pages. They're usually useless on talk pages anyway, and often cookie-cutter ones like "c". I think it makes sense to have them as a guideline in mainspaces, but probably not in talk ones. FWIW, here's what ArbCom has to say about edit summaries. ProcrastinatingReader (talk) 11:53, 23 February 2021 (UTC)
I basically agree, on both points. I think that edit summaries in projectspace, particularly at user talk pages, are much less important. However, for mainspace edits I do consider edit summaries important. The guideline language can make that distinction explicit. Nsk92 (talk) 12:06, 23 February 2021 (UTC)
On implementation, I think Help:Edit summary is too much of a "help" (like a how-to) page to be promoted to a guideline, and aspects would need cleanup anyway. I would prefer to see some wordsmithing done to what ArbCom wrote, and then adding that sentence into an appropriate guideline page (I don't really know which one that would be? Wikipedia:Etiquette seems close in name, but not really in content). ProcrastinatingReader (talk) 12:21, 23 February 2021 (UTC)
It's an interesting thought, athough as the destination, the behavioral guideline Wikipedia:Etiquette seems like the wrong place for this item. However, your suggestion made me realize something. There already is a mention of edit summaries in the main editing policy, Wikipedia:Editing policy, in section, WP:UNRESPONSIVE. It says there: "Be helpful: explain your changes. ... Try to use an appropriate edit summary. For larger or more significant changes, the edit summary may not give you enough space to fully explain the edit; in this case, you may leave a note on the article's talk page as well." (Pinging Pbsouthwood since this point is relevant to our discussion at his talk page.) Perhaps we should clarify the language in this section to make it a bit stronger and more explicit ('Try to' sounds too noncommital.) I think a link to WP:UNRESPONSIVE also needs to be added at Help:Edit summary. Nsk92 (talk) 12:53, 23 February 2021 (UTC)
I have added a hatnote pointing to Wikipedia:Editing policy#Be helpful: explain at Help:Edit summary. Nsk92 (talk) 13:03, 23 February 2021 (UTC)
  • Providing an edit summary is often helpful, but it is not required. I see no reason to change that. Blueboar (talk) 13:35, 23 February 2021 (UTC)
As you happens you are incorrect on the not required part. The requirement is already a part of the Wikipedia:Editing policy#Be helpful: explain section although the language there can be improved. Nsk92 (talk) 13:49, 23 February 2021 (UTC)
Try to is not equivalent to is required. It is, then, not a matter of "clarifying the language", it is a proposal to radically change the way many editors do their work here. Primergrey (talk) 20:47, 23 February 2021 (UTC)
Perhaps 'required' was the wrong word to use here, I am not sure. But "Try to use an appropriate edit summary" is certainly much more than a suggestion, particularly since the language occurs in a policy. I'd actully want to drop "try to" in this sentence and replace it with "Use an appropriate edit summary." Nsk92 (talk) 21:14, 23 February 2021 (UTC)
I'm rather surprised about how weakly worded our current policies and guidelines are about edit summaries and I would support requiring one for every edit accompanied by something along the lines of (but not exactly) "try to make your edit summary clear enough so someone reading the page history can determine the nature of your edit, this is particularly important on reader-facing pages." Thryduulf (talk) 22:31, 23 February 2021 (UTC)
I would oppose making this a guideline in general, but it could possibly be one for article space, which, as many people seem to forget, is the whole reason for this site's existence. I always try to provide an edit summary when editing an article, but usually don't provide one when editing a discussion page, which includes article talk pages and most Wikipedia space pages, because my edit itself is its own summary. If I could capture the essense of a comment in any shorter form that the edit itself then I would truncate that edit. I have a particular dislike for edit summaries to deletion discussions that say "keep" or "delete". Any contribution worth its salt cannot be summarised in such a way. Phil Bridger (talk) 23:16, 23 February 2021 (UTC)
I'd like to see the language of Wikipedia:Editing policy#Be helpful: explain strengthened along the lines you suggest, and maybe somewhat stronger. E.g. have it say there that an edit summary is required for mainspace edits and is recommended for projectspace edits, but that editors should use their discretion and best judgement there. Personally, I actually appreciate "keep"/"delete" edit summaries for AfD edits. I must confess that for an AfD where I participated, if I see an edit with an edit summary indicating a !vote that agreed with mine, I usually don't look up the edit. But in the opposite case I do. Nsk92 (talk) 23:56, 23 February 2021 (UTC)
If edit summaries are to become compulsory for all mainspace (or other space) edits, then making it impossible to save without an edit summary would technically enforce the requirement, making it impossible to forget or accidentally publish without a required component of the edit. However, this does not enforce a useful or accurate edit summary, which is not a simple matter to define, and is probably largely a matter of opinion. For some edits, like content re-use, it is relatively straightforward to specify what is necessary to provide attribution, but in other cases where a number of changes with different purposes are done in the same edit, it can become difficult to keep track, and may require considerable effort and quite a lot of text to describe both correctly and usefully. The edit summary could become unwieldy or too large to fit, and in some cases be larger and require more work than the actual edit. I do not see this helping to recruit new editors or retain existing editors. Also, as edit summaries are effectively not changeable, there is the question of what to do if there is an error in the edit summary, or if one saves before finishing the summary. What will the appropriate response be to edit summaries that do not comply with the requirements, and who decides whether a summary meets the requirements? This could be seen as creeping bureaucracy, and a barrier to contribution. Will it lead to biting the newbies, harassment and hounding, be used as an excuse to revert edits people don't like? Other unforeseen consequences? Time is a zero sum commodity. When used for one thing it becomes unavailable for others. As volunteers we decide for ourselves what we want to do with our time. · · · Peter Southwood (talk): 02:40, 24 February 2021 (UTC)
I don't really see how the community as individuals could ever enforce mandatory edit summaries. The drama boards would be filled with gotcha moments plus the oft-mentioned BITE. I could see supporting mandatory edit summaries as a community or admin sanction for a particularly troublesome editor, though that would create other risks like useless or disruptive edit summaries. Slywriter (talk) 03:13, 24 February 2021 (UTC)

Edit summaries are not required, but are expected, particularly of experienced editors; I have and will oppose RFAs based on a lack of use of edit summaries. I don't see it beneficial to WP:BITE newbies for not using edit summaries in their first 1000 edits. I haven't investigated enough to determine whether this would support making Help:Edit summary policy or not. power~enwiki (π, ν) 02:43, 24 February 2021 (UTC)

As I understand it, the purpose of this discussion is to consider whether edit summaries should be required, with the possibility of opening a RfC on a proposal to make then compulsory. The possible consequences should be considered. · · · Peter Southwood (talk): 03:26, 24 February 2021 (UTC)

If you require edit summaries, you're just going to wind up with a bunch of edit summaries like this: hfgkyuopk[] --Khajidha (talk) 14:03, 24 February 2021 (UTC)

  • Some responses to the comments above: I don't propose making it impossible to save an edit without an edit summary. But if there is a broad community consensus that edit summaries in mainspace are helpful and that editors should provide them, our main editing policy, Wikipedia:Editing policy should explicitly say just that, in reasonably strong form. If it does, it will be easier to approach experienced editors who neglect to include edit summaries in their mainspace edits and remind them that they should do so. Newbies routinely break all sorts of rules and norms, and they are routinely extended an extra level of tolerance per WP:NEWBIES; it will be/is the same with edit summaries. Regarding people providing nonsensical edit summaries, like hfgkyuopk[], I really don't see that happening. Experienced editors certainly won't do that, even if they personally find the edit summary requirement annoying. Newcomers are much more likely to just leave the edit summary field blank. Nsk92 (talk) 14:27, 24 February 2021 (UTC)
For convenience and context, I include here the full current text of Wikipedia:Editing policy#Be helpful: explain. Nsk92 (talk) 14:37, 24 February 2021 (UTC)
Be helpful: explain your changes. When you edit an article, the more radical or controversial the change, the greater the need to explain it. Be sure to leave a comment about why you made the change. Try to use an appropriate edit summary. For larger or more significant changes, the edit summary may not give you enough space to fully explain the edit; in this case, you may leave a note on the article's talk page as well. Remember too that notes on the talk page are more visible, make misunderstandings less likely and encourage discussion rather than edit warring.
  • I'm going to have to agree with Blueboar and Peter Southwood. I see no merit in requiring edit summaries for every article-space edit. It's certainly helpful in many cases, such as to note a significant development in the article, or particularly where the edit changes something for reasons that might be unclear or controversial. And I've called out people before for not using an edit summary when nominating a page for deletion because that seems contrary to giving good faith notice to interested editors. But many edits are perfectly self-explanatory, or truly minor as to not be worth elaborating on. Abandoning judgment calls in this area would just seem to create extra work for editors that will ultimately discourage many edits from being made. And it begs the question of what "requirement" means here, I can't see any way of "enforcing" this that would actually be desirable or constructive. postdlf (talk) 18:31, 24 February 2021 (UTC)
IMO, there is no such thing as a "self-explanatory" edit. An edit may only become self-explanatory, after someone have looked up the diff and analyzed the edit. By then it is too late. The time and effort of the editor looking up the diff has been expended. Let's say an edit shows up on my watchlist for an article that I am interested in, with no edit summary. The edit has added 751 bytes of data. That's all I know from seeing this edit in the watchlist. What happened there? Was somebody cleaning up some references? Or a table? Added a maintenence tag? Or perhaps added a few sentences regarding the subject's of the the article childhood? Or political career? The point is, without an edit summary, I and all the other editors who see this edit in their watchlists have absolutely no idea about the substance of the edit. Quite a number of them will feel that they have no choice but to look it up to see what the edit was about. If the edit summary just said "reformatting a table" or something similar, most people probably wouldn't feel the need to check it. Nsk92 (talk) 19:59, 24 February 2021 (UTC)
Self-explanatory meaning it's obvious what was done and why when you see what was changed. Edit summaries are not a substitute for actually looking at the edit. If you don't know or trust the editor making the change enough to go without confirming its validity, I don't see how you're going to trust that their summary was accurate or complete either without confirming. I think the focus on disruption raised by Masem below is helpful. All else is precatory. postdlf (talk) 20:29, 24 February 2021 (UTC)
I think that edit summaries should be a substitute for actually looking at the edit. An edit summary of "fix typo" saves me the time of looking at the edit; that's one of the great benefits of edit summaries, IMO. One editor spends a little more time to save time for many other editors, now and in the future. Similarly, on talk pages, putting the comment (if it's short) into the edit summary saves page watchers the time of having to look at the page to read the comment (and, IMO, is more useful than "cmt" or "re"). Levivich harass/hound 01:23, 26 February 2021 (UTC)
They can be a substitute for looking at the diff if the editor is one you trust, but if you trust the editor then why would you want to read the edit summary? One reason would be that you may be interested in the actual edit, and in those cases a summary can help you decide whether it is likely to be worth the time. Other valid reasons may exist but I think they should be stated rather than assuming that they are obvious to everyone. · · · Peter Southwood (talk): 07:00, 26 February 2021 (UTC)
  • Let's also not forget summaries like "RV nonsense" and the many variations thereof. Not uncivil enough to warrant any action, but worse than no summary at all. Mandatory edit summaries will also surely increase the use of back and forth summaries (and reverts) in lieu of talk page discussions. Primergrey (talk) 18:35, 24 February 2021 (UTC)
  • I would agree with Blueboar's statement and what Nsk92 puts above. Edit summaries should be seen as a means to minimize disruption; an editor that is known to work without creating disruption in the first place in their usual mainspace work shouldn't be expected to use edit summaries, but an editor that may have been established as a disruptive editor or a new editor should be strongly encouraged to use them to regain community trust - to what degree they need to, we shouldn't be sticklers for but if failure or misuse of edit summaries does create more disruption, that's a problem. --Masem (t) 18:48, 24 February 2021 (UTC)
    Totally agree. Our policy against disruption fairly eliminates the need for the multitude of specifics that would otherwise exist. The community sees a conspicuous lack of edit summaries accompanying substantial edits...it gets addressed, with no need for a violation of a bright-line rule. To whatever degree this is perceived to not already work is simply an indication of the priorities of the community, not the system in which it operates. Primergrey (talk) 19:07, 24 February 2021 (UTC)
I have never thought about edit summaries as being mainly a means for minimizing disruption but rather, as the quoted text of the editing policy above says, as the means of being helpful to other editors. That's what edit summaries do: they provide help to other editors by letting them know the substance of the edit. I believe that most editors, myself included, use edit summaries to decide whether to look up a diff for an edit they see on their watchlist (and, similarly, when they look up an article history log). I usually AGF the edit summaries and I find that on the whole they save me a great deal of time and work. That's why I believe that everyone should use them. Nsk92 (talk) 19:39, 24 February 2021 (UTC)
I don't mean that edit summaries are a means for minimizing disruption. Rather, I mean that if a lack of edit summaries from a particular user is seen as disruptive, there is already a well-established way to deal with that. As to your other point, I don't think I fully grasp how someone who assumes good faith about the content of an edit summary wouldn't also assume good faith regarding the content of an edit. In other words, if an article on my watchlist shows a significant change in size, I'm going to check it out regardless of what the summary says or doesn't say. That's not a lack of good faith. While, it seems to me, that automatically reverting any edit that does not have an edit summary is, to a large degree. (Not suggesting that that is your MO, but it's certainly an option availed by some.) Primergrey (talk) 20:32, 24 February 2021 (UTC)
When I decide to look up an edit it is primarily not with the reason to revert it but to understand it. That is, for an article that I am interested in, if a substantial edit adding/changing meaningful content comes from an experienced and totally reliable editor, I would likely still want to look it up, just because I am interested in the subject. Even for a shorter edit that adds a short piece of useful info, I may want to look it up because I am interested in that info. For an edit reformatting a table or adding a maintenence tag, I'll likely skip it. But when I see an edit without an edit summary in my watchlist, I can't tell the difference between these types of situations. Nsk92 (talk) 20:54, 24 February 2021 (UTC)
Another thing to consider is that watchlists are not the only reason for edit summaries. Indeed for my work, their appearance in page histories is far more significant as I'm often looking at why a particular term was added or removed from an article, or why content was reorganised (not something that can be done any other way). They help understand how the article was developing across time, how active it is in terms of content development/vs maintenance. When disputes arise, edit summaries are an invaluable aid to determining what is happening and why, and for filtering out edits that are not part of the dispute but happen to be made at the same time. They also enable me to see whether a gnoming change made to the article was reverted because someone disagreed with it or because they didn't spot it when making content changes. On talk pages, summaries like "reply to Nsk92" are helpful because you can distinguish them from very different edits like "The early life section biased". For all these reasons and more, not leaving and edit summary makes things harder for other editors, sometimes years down the line, in exchange for a tiny investment of time for you. There is no reason for any experienced editor to be routinely not leaving edit summaries. Thryduulf (talk) 21:47, 24 February 2021 (UTC)
Peter Southwood made several earlier. Primergrey (talk) 21:51, 24 February 2021 (UTC)
I should have said "no good reason" as those expressed by Peter Southwood are either fallacious, a failure to summarise or an example of where an edit summary pointing to a fuller explanation on the talk page should be used. Indeed in the 15 years I've been editing Wikipedia there have only been a small handful of occasions where I've not been able to adequately explain my edit in an edit summary and on each of those occasions I've posted on the talk page. I am aware of exactly zero occasions when leaving no edit summary would have been better than leaving one. Thryduulf (talk) 23:49, 24 February 2021 (UTC)
Misleading or abusive edit summaries? However I assume you mean useful edit summaries,which makes it a bit of a tautology. · · · Peter Southwood (talk): 09:19, 25 February 2021 (UTC)
Thryduulf, What work do you do that relies so much on edit summaries? · · · Peter Southwood (talk): 09:27, 25 February 2021 (UTC)
RfD and dispute resolution are the most frequent times I rely on edit summaries, but there are other times too. Misleading or abusive edit summaries are a red herring - any feature can be abused and yet the vast majority of people don't (it's how the entirety of Wikipedia works). If someone is misusing something intentionally that's a behavioural issue that needs addressing (and it normally happens alongside other behaviour issues as well), if they're doing it unintentionally that's an education issue. Thryduulf (talk) 13:11, 25 February 2021 (UTC)
Exactly zero appears a bit hyperbolic, but not a big issue.
Thryduulf, I would like to understand just how the presence of edit summaries is so critically important to your work, so I can develop an informed opinion on how seriously I should take your claims. I can be persuaded by evidence and logical reasoning, not so much by rhetoric, and can generally tell the difference. Cheers, · · · Peter Southwood (talk): 06:46, 26 February 2021 (UTC)
It isn't critically important in the sense that I can't do it without it, but edit summaries make it so much easier to find the key edits in the page history and especially to understand why they were made. A large part of RfD is understanding why a term redirects where it does and why the term or related information was added to or removed from the article or moved elsewhere. Looking through a page history the edit summaries should tell the story of how the article changed, it means I don't have to read every edit to find what I'm looking for, I don't have to guess at the reason a change was made years after it was made. I'm frequently dealing with subject I know very little about, so things that are obvious to involved editors at the time can be opaque to others later. If a term is removed from an article without explanation it makes it much harder to know whether this was a good change or a bad change. Understanding why a term is or isn't in a particular article is often important to working out what should happen with a redirect so that we can best help readers.
For dispute resolution purposes, a good edit summary can make it immediately clear what someone's motivation for an edit is, they can make it clear which users are disputing what and why. They can make it clear that intervening edits are or are not part of the dispute, or whether someone is trying to diffuse it, e.g. by trying compromise wording. Again edit summaries should be telling the story of the article.
When I say "I am aware of exactly zero occasions when leaving no edit summary would have been better than leaving one." I mean exactly that, it's not hyperbole. There may be a few occasions where adding an edit summary adds nothing over no edit summary (I'm struggling to think of such situations, but I'm prepared to believe they might exist) but an edit summary is truly never worse than no edit summary. Thryduulf (talk) 13:55, 26 February 2021 (UTC)
Thryduulf, if I take your statement at face value, I find myself wanting to ask you to explain how an abusive or disruptive edit summary can be not worse than no edit summary.
I can see that for your work on redirects that some edit summaries can sometimes make the work easier. Do you have an estimate for what percentage of all edit summaries this might be valid?
I agree that edit summaries are desirable whenever it appears reasonably likely that the edit may be contended. · · · Peter Southwood (talk): 06:43, 2 March 2021 (UTC)
@Pbsouthwood: Edits with misleading summaries are such a tiny percentage of all edits that they're essentially irrelevant to the discussion (and frequently subsequent edits correct them, explicitly or implicitly anyway). As for what percentage of edit summaries are potentially helpful? 100% - including misleading ones as a misleading edit summary is a good indicator that the edit was made in bad faith. They don't all help in the same way, but given there are so many different reasons people can be looking at the summaries every single edit summary has the potential to be helpful to someone at some point, even just "this is not the edit I'm looking for" is helpful - an edit without a summary gives you no clue as to it's purpose, relevance or indeed anything else. What percentage of edit summaries are actually helpful to me personally is irrelevant. Thryduulf (talk) 09:57, 2 March 2021 (UTC)
  • Bit like leaving explanatory notes in code, not doing it is not helpful.Selfstudier (talk) 23:01, 24 February 2021 (UTC)
  • I have to say that having to explain why you deleted one letter due to typo will make a lot of editors very unhappy! Davidstewartharvey (talk) 17:32, 25 February 2021 (UTC)
I guess m ought to cover things like that? Typo is pretty well understood, too. And Sp. But maybe I assume too much.Selfstudier (talk) 19:26, 25 February 2021 (UTC)
  • I agree with Thryduulf on the potential value of edit summaries when reviewing an article's history, but I think that's more useful, and a more reasonable expectation, when the edits are substantial or substantive, such as "added section on personal life" or "complete rewrite of education". My disagreement is with the position that "every" edit should be "required" to have one. I think checking an edit as minor obviates the need in many or most circumstances, for example, and I personally don't want anyone to waste their time typing in "corrected typo" as an explanation for why they changed "Washingtno" to Washington" (nor do I want to read that summary). Nor should it ever be required for adding talk page comments. Adding to the transaction cost of every edit means fewer edits. No one has really addressed the "enforcement" question either, as far as what people think "required" would mean in practice, however narrow or broad the circumstances it might be "required". postdlf (talk) 18:16, 25 February 2021 (UTC)
    Thinking about the "transaction cost" aspect that you point out leads me to abandon my former position that this may possibly be a useful guideline for main space. We already have rules against disruptive editing, which can include not using edit summaries when they should be used, such as making a potentially controversial edit or nominating an article for deletion. There's no need to badger people for some percentage produced by a tool. If someone is making good edits then it's better that they make those edits rather do the ideal thing and provide an edit summary. Let's not let the best be the enemy of the good. Phil Bridger (talk) 18:44, 25 February 2021 (UTC)
I believe that the actual transaction cost in terms of decreasing the number of article edits would be either minimal or non-existent. When an editor wants to make an edit, they don't start with worrying about the edit summary. They prepare an edit and hit preview. Only then, when it comes to saving the edit, do they start thinking about the edit summary. Even for editors who may be somewhat annoyed by a requirement to provide an edit summary, they would be unlikely to scrap and abandon the edit. There may be some editors who may be so annoyed that they would just start editing less but I doubt that it'd be a large number. Providing an edit summary for every edit (or every article space edit) easily becomes a habit, like waring a face covering now when you go outside. After a while it just becomes automatic and you don't really think about it. I am sure it would be the same with edit summaries if we were serious about requiring them. Nsk92 (talk) 19:39, 25 February 2021 (UTC)
Nsk92, Is there any reliable data available as evidence to support that belief? Minimal is theoretically possible as an average value, provided there is some agreement on what constitutes minimal. Non-existent is at face value improbable, as in my experience some edit summaries are non-trivial to compose, and those include the ones I consider critically important, like the ones required for attribution, and which I try to both do when necessary, and do adequately informatively. For those cases the transaction cost is not a problem, as it is clear that they are an essential part of the edit. · · · Peter Southwood (talk): 06:46, 26 February 2021 (UTC)
I was speaking colloquially. Of course nobody, as far as I know, actually tried to conduct precise experiments on the topic or to assign a quantifyable measure to the transaction cost of making an edit summary. My point is that, IMO, making edit in article space summaries mandatory is unlikely to significantly reduce the number of edits because of how an editing process works. You prepare an edit first and only then think about an edit summary. Plus providing edit summaries becomes a habit fairly quickly. Nsk92 (talk) 07:47, 26 February 2021 (UTC)
Plus, of course, for those who are worried about the potential transaction cost of requiring edit sumaries being a significant impediment that would somehow significantly reduce the number of overall edits and ever drive some editors away, there is no reliable data as evidence to support that belief either. At this stage we are trying to make arguments at the level of common sense. Nsk92 (talk) 07:54, 26 February 2021 (UTC)
If it takes time to do, then it necessarily can't be a "nonexistent" cost. And if it takes more time to do something, all else being equal fewer people will do that thing. That honestly seems axiomatic. Particularly since everyone is a volunteer so there's no increased benefit presented to balance that cost out. I know I'd be less likely to correct the spelling of a word in an article I'm reading on my phone if I'm required to also type in "corrected spelling". And it may be just because my toddler is suddenly getting into the cupboards again before I can finish, the red light has changed to green, or I just decide the extra time this "requirement" takes is not worth my time. Again, whatever "required" means here, which is yet to be explained. Unless the "or else" is really laid out I don't know what we're talking about in practice. postdlf (talk) 18:59, 26 February 2021 (UTC)
I hope users choose not to edit while in a car waiting for a light to turn green. isaacl (talk) 21:14, 26 February 2021 (UTC)
There is some value in there being a transaction cost. Our aim should be to increase the quality of edits, not just the quantity. Writing the edit summary first can also be valuable — if you do not know why you are making the edit, then perhaps it is not a worthwhile edit? — GhostInTheMachine talk to me 12:38, 2 March 2021 (UTC)
I don't think edit summaries should be required, but they should be encouraged. They're not used enough. I've seen well timed edit summaries stop edit wars in their tracks. An explicit edit summary lets other editors know exactly what you added. That might not seem necessary when it's an editor that you trust, but when you're looking at an edit history page where some damage has occurred amongst a dozen or so edits, it's better to have explicit edit summaries from everyone. If I correct a typo, I'm likely to not just write "correcting typo" but also "Washingtno -> Washington". That informs people of what exactly went on, without having to open the page. I'm also apt to write the more generic "copy editing", which some might find completely useless, but getting in the habit of doing that prompts me to be more explicit when I think it's warranted, e.g. "copy editing, employing British spelling, esp. 'labor' to 'labour' ". But instead of trying to impose my fussiness on others, which would be impossible, my suggestion would be for the system to provide diffs as edit summaries, or to summarize those diffs where there's not enough space to include them all, as many bots are now doing. Dhtwiki (talk) 22:43, 25 February 2021 (UTC)
  • I'm not sure that promoting the help page to a guideline is the best way to skin this cat, but I agree with the general principle, and I think a better approach is perhaps to revise what it says in the editing policy. Though they shouldn't be required, I think editors should be encouraged to use edit summaries for most if not all mainspace edits. They can also be helpful in other namespaces. Most importantly, editors should be taught why to use edit summaries, and what to write in them: why "rv nonsense" is bad (it's not descriptive) and "fix typo" is good (saves having to look at the edit). This is what the help page already does, and it's already linked in the policy page. So I think the status and relationship of the two pages is fine, but perhaps the wording of the policy page could be revised. Levivich harass/hound 01:28, 26 February 2021 (UTC)
  • Perhaps this is due to the fact that I watch several articles that are prone to vandalism, but... edit summaries are not always helpful. In fact, when editors are not acting in good faith, an edit summary can actually be harmful, intentionally used to deceive. I have often seen significant (POV vandalism) edits hidden behind innocuous summaries such as “fixed typo” or “correcting spelling”. Blueboar (talk) 13:26, 26 February 2021 (UTC)
    Editors abusing edit summaries is not evidence against the usefulness of edit summaries, it is evidence of a problem with the users doing the abusing in the same way that editors deliberately applying incorrect citations is not evidence that citations are a bad thing. Thryduulf (talk) 14:00, 26 February 2021 (UTC)
I don’t disagree... my point was simply that edit summaries are not always helpful. We still have to check the edit to see whether what is said in the summary matches the actual edit. Blueboar (talk) 14:23, 26 February 2021 (UTC)
When I made the original suggestion at the top of this thread regarding Help:Edit summary, I didn't realize that the section Wikipedia:Editing policy#Be helpful: explain dealing with edit summaries existed. At this point I agree that changing the status of Help:Edit summary is not the way to go. But I would like to strengthen the language of Wikipedia:Editing policy#Be helpful: explain, assuming consesus to do so can be achieved. Nsk92 (talk) 01:53, 26 February 2021 (UTC)
  • Objectively speaking & semantics aside, I believe, using edit summaries be made the onus of every and all editors. I believe without an iota of doubt that it is only proper. I also do not have any reservations if it be made a policy, there’s also concern of editors using edit summaries in a disruptive manner in such scenarios I believe the editor(s) be warned for disruptive editing & sanctioned by the community if need be. Celestina007 (talk) 08:08, 1 March 2021 (UTC)
    Celestina007 Beliefs/opinions aside, what would you consider appropriate consequences for (a) not providing an edit summary, or (b) for providing an edit summary that any given reader does not find sufficiently useful? I am looking for reasonably practicable suggestions here. Disruptive edit summaries are already covered by general policy. · · · Peter Southwood (talk): 06:10, 2 March 2021 (UTC)
    Occasional accidental omission of an edit summary deserves no consequences (especially if followed by a whitespace or similar edit to correct), perfection is not required. Repeated intentional omission of an edit summary should be treated as a form of disruptive editing. Intentionally leaving edit summaries that are actively unhelpful is no different to leaving a misleading edit summary. In other situations, discussion and advice is appropriate. If that advice is not heeded then progress as we would for people disregarding advice in other ways. More specific than that depends on circumstances. Thryduulf (talk) 10:03, 2 March 2021 (UTC)
  • An edit summary is intended to be helpful to other editors and failing to add a suitable summary is choosing not to be helpful — GhostInTheMachine talk to me 12:29, 2 March 2021 (UTC)

RfC on editnotice policy

There is an RfC at Wikipedia talk:General sanctions/Coronavirus disease 2019 #RfC on use of COVID-19 editnotice to answer the question "Should admins have the ability to place the General sanctions/Coronavirus disease 2019 editnotice template on pages in scope that do not have page-specific sanctions?" --RexxS (talk) 21:55, 23 February 2021 (UTC)

Announcement: (essay) WP:SOLDIER deprecated

Any regular of AfDs will surely have encountered this when discussing military figures. Per a recent RfC at the WikiProject Military History discussion page; it's been found to be inappropriate and there was consensus to deprecate it. Just letting you know in case you end up upon it still being cited in relevant discussions.

For WikiProject Military history,

RandomCanadian (talk / contribs) 00:50, 25 February 2021 (UTC)

Caitlyn Jenner

Discussion about the pronouns used at the Caitlyn Jenner article belongs at, and is happening at, Talk:Caitlyn Jenner. Discussion of the general case belongs at Wikipedia talk:Manual of Style but there is no appetite here for change. Thryduulf (talk) 10:10, 2 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.

There seems to be a concerted effort to keep male pronouns from Caitlyn Jenner, even when they refer to Jenner pre-transition. I cannot find any instances of the pronoun "he" in the section referring to his olympic career, including in cases where omission of the pronoun would be grammatically incorrect, such as "Jenner watched teammate Fred Dixon get injured in the 110 meter hurdles, so took a cautious approach to the hurdles and discus." There is no pronoun between the bolded words when there should be. Jenner was indisputably male before 2015, so he should be referred to as such when concerning his Olympic career. The current situation also possibly counts as WP:CENSORSHIP as there may have been a deliberate purge of male pronouns. Gender changes are not retroactive. 053pvr (talk) 05:24, 28 February 2021 (UTC)

Without making any judgement on the whole of the above (other than that this may not be the best place to discuss it), i will point out that the quote objected to is perfectly proper English and, indeed, has evidently been thought through carefully in order to remain good usage and yet not use the potentially objectionable pronoun; happy days, LindsayHello 07:15, 28 February 2021 (UTC) Adding ping, which i missed; happy days, LindsayHello 07:16, 28 February 2021 (UTC)
One place to start is Wikipedia:Gender identity#Retroactivity. There have been several conversations about this over the years. The current consensus may not be agreeable to everyone but it is not censorship. MarnetteD|Talk 07:23, 28 February 2021 (UTC)
@053pvr: There appears to be an active discussion going on at Talk:Caitlyn Jenner which you started, so you should be quite aware of. That discussion has not yet played out, indeed you made this post here 14 minutes after you started the prior discussion. This looks like WP:FORUMSHOP. The existing guidance is at MOS:GENDERID, which states "Any person whose gender might be questioned should be referred to by the pronouns, possessive adjectives, and gendered nouns (for example "man/woman", "waiter/waitress", "chairman/chairwoman") that reflect that person's latest expressed gender self-identification. This applies in references to any phase of that person's life, unless the subject has indicated a preference otherwise." If you wish to see it changed in general for all articles about transgender people, I suppose you could start that discussion, but I would not see it happening. The existing guidance was arrived at through many months of discussions from a wide swath of the Wikipedia community, and while consensus can change, and you're entirely free to start a discussion to change the existing guidelines, I wouldn't recommend it as you are unlikely to see any consensus to change it. --Jayron32 17:39, 1 March 2021 (UTC)
Part of the advice that's developed in dealing with transitioned people that were notable before transitioning like Jenner is that if pronouns can be avoided, they should be, as that eliminates the confusion and debate over what gender terms to use, even in a case like Jenner where at that point Jenner was running an official male event as a male. The wording given seems like a perfect way to remove a pronoun without confusing the actors in that sentence, for example, and thus a clean way of handling that. --Masem (t) 18:07, 1 March 2021 (UTC)
Without starting into policy, the idea that we must adjust pronouns depending on the time period being referenced is bizarre and, to me, reads like an excuse to use the incorrect pronouns. A person, as they exist in the present, has a personhood that encompasses the entirety of their personal history. If they currently go by one pronoun, that pronoun should be used in the past, because it is still referring to the person as they exist in the present. We might say "she had an athletic career" because we are talking about a person who exists now, who uses she/her pronouns. Given this, I particularly don't appreciate he/him being used by the editor above in their message. I also dispute that anybody can be said to be "indisputably" male or female based on assumption, especially if they later went on to come out. BlackholeWA (talk) 23:30, 1 March 2021 (UTC)
BlackholeWA, I one hundred percent agree with you, every word. Jorm (talk) 23:41, 1 March 2021 (UTC)
These poor abused horses... EvergreenFir (talk) 00:08, 2 March 2021 (UTC)
Meh... the horses are dead, they don’t feel the beatings. Blueboar (talk) 00:35, 2 March 2021 (UTC)
  • Confirmation bias aside, is this going to be a multi-forum event? - Floydian τ ¢ 00:42, 2 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.

Are we really "Not Vote"ing, or is that just a nice fiction?

I'm not exactly an experienced editor, but I like to hang out on the website, read policy, and contribute to processes, because the hivemind of Wikipedia fascinates me. Most of my active participation has been in RfCs and XfD discussions.

Obviously, I know that the convention is that polling in processes is WP:NOTAVOTE, and that they should be regarded as a solicitation of views from editors which should be considered on merit. However, I find that, in practice, these discussions essentially do just function as straight majority polls. In fact, the entire concept of consensus as realized in Wikipedia seems to be rooted in taking the course of action that is supported by the majority of editors.

I realize that the idea here is that people should be expressing their views when they make their !vote, and that by stating these views, they influence the editors who !vote afterwards until an overall consensus has been formed. This is nice in theory, but it has a number of failure modes. Firstly, many people, especially in long RfCs, will not read all the discussion that has taken place beforehand, instead skipping the block of text and appending their opinion unchanged. Secondly, if the idea that a consensus is the result of people being persuaded by previous arguments, this ignores the fact that groups of editors might want the same outcome for different reasons. In situations where 40% of participants oppose an action, but the other 60% are split evenly in their rationale for wanting the action, then arguably there has been no "consensus" the rationale for the decision, and so the process defaults to simply being a blind vote.

The other option, of course, is that the closer could unilaterally decide to uphold a minority view because they are more persuaded by its argument or adherence to policy, but in practice I think this rarely happens and would be met with outrage and immediate challenge, because the expectation is still that these processes are conducted essentially as votes.

This isn't about any particular discussion or issue, nor could I suggest a better way of doing things particularly. I just wanted to ask for other opinions; is the convention of "Not a vote" essentially just a nice thought? Or its primary function not to be applied in a strictly literal sense, but to remind editors to always state their opinions such that discussions are generally more opinion-orientated rather than a series of contextless supports or opposes? Or do you think that Wikipedia generally does manage to hold itself to "not voting" in relevant discussions? BlackholeWA (talk) 12:01, 1 March 2021 (UTC)

  • WP:NOTVOTE is more than an aspiration, but the way it works is probably more obvious when you close discussions rather than when you participate in them. For one, what we aim for is a rough consensus, not a unanimous one; agreement amongst a majority of participants can carry the day even if a significant minority disagrees. That is why it's rare (but not at all unheard of) to see closes in favour of a minority position and why the outcome is often similar to that of a poll. But closers still do a lot more than count heads. Your hypothetical discussion in which a majority of participants agree on an outcome but for different reasons is an example of the process working as intended – consensus emerges from the common ground that most agree on. To make it concrete, let's say we have an AfD where 3 people !vote keep, 3 delete, 2 merge, and 2 redirect, all with equally valid rationales. Seen as a poll, no outcome "wins". But there is obviously a rough consensus (7–3) that the article shouldn't be kept in its current form even if there is no agreement on what to do with it. A good closer would recognise this and, guided by the general principle that we err on the side of keeping content, close it as merge.
Your second example sounds like a supervote. The "quality of arguments" part of WP:CONSENSUS means that in assessing it we discard opinions that are obviously baseless, refuted, or contradict established policy. It's not about what the closer personally finds persuasive. – Joe (talk) 12:49, 1 March 2021 (UTC)
  • I've closed several RfCs/RMs/TfDs in favour of the minority view (example). Usually such closes require giving a longer explanation to make ones thinking clear. Some get appealed to DRV etc but none have been overturned yet. I think it's totally valid to close in favour of a minority in some cases, but it is still uncommon. In my view, most discussions are mostly a vote, and consensus is not about being 'right' but rather it's about stability. To the extent that WP:NOTAVOTE matters it's mostly a corrolary of WP:CONLEVEL (i.e. votes that go against a wider consensus are not weighted very highly, and also votes that are internally logically inconsistent or otherwise severely problematic get discarded). In some discussions, particularly ones where some special interests (ie a local consensus, WikiProjects claiming territory, etc) are at work, it's also worth being careful not to discount broader opinions of editors and recognise if stonewalling/bludgeoning is occurring. Also have to be wary of SPAs/socks/canvassing. After that, it's mostly looking for whether there are outcomes/points editors seem to generally agree on.
    If there's a clear consensus against a current title but no consensus on a better title, then it can be common to move to an interim stable solution which has the most support (example: 2021 storming of the United States Capitol). Some special cases also apply to different types of discussions. In current events RfCs, for example, seeing a wall of supports/opposes later on can be a strong indicator of consensus becoming apparent due to external changes (eg media coverage). Also if there's mixed discussion, and then a refutation of a major point happens, and that seems to result in a notable swing in the votes that's also a useful indicator. In such cases the overall number of votes on each side seems to matter less than the trend the RfC is going in (but in some cases it's not clear enough and a 'no consensus' outcome is the only valid result). One useful approach, which I took from Primefac, is to skim the discussion and get an idea of the various views/arguments, and then make a closer read to see which seem to have consensus. This tends to be a good approach for messier RfCs (so, actually, I guess many discussions aren't really a vote?). ProcrastinatingReader (talk) 17:22, 1 March 2021 (UTC)
  • You do know that, sometimes, the side of a debate with a numerical advantage does actually have the better, more policy-based argument? I know, right? Weird. In my experience, cries of "WP:NOTAVOTE IS NOT BEING OBEYED" come from people who didn't have a sound policy-based argument in the first place. I have, on occasion, closed discussions which went against the majority, but it should be noted that a large proportion of discussions do see that the same side of the debate that has the most votes also has the best rationales. Which is not to say that the OP doesn't have a case to be made for whatever specific case caused them to make this long post. Without reference to a specific case, we can't tell what specific problem we need to assess, and yes, sometimes discussions are closed the wrong way. Whether or not any one of them the OP is thinking of needs to be reviewed I cannot possible know without looking at it. --Jayron32 17:31, 1 March 2021 (UTC)
    • I'm not talking about or having issue with a specific case. Believe me or not, I'm not trying to be tendentious wrt a particular discussion, but just wanted to get opinions on the policy in general, as it's been something I've been thinking about recently - there are some interesting perspectives here, which I appreciate. BlackholeWA (talk) 20:41, 1 March 2021 (UTC)
  • Certain discussions are more likely to have "NOTAVOTE" utilised than others. For example, AfDs are very policy-based, and by far the type of discussion where you're most likely to see the minority side (by absolute numbers) "win", though obviously still uncommon! Naming discussions are also common cases for this. RfCs are all over the place - it can be a bit hard to judge here, since often they're creating policy because there isn't currently any. As such, making a policy-backed case is hard, so it's more on weight of reason, and weight of viewpoints. RfAs act like a vote unless they get to the CRATCHAT sphere, at which point, they default back to NOTAVOTE. Nosebagbear (talk) 20:36, 1 March 2021 (UTC)
  • Basically what everyone else said, but especially Joe's point about it being more obvious when you're a closer than a participant. I'd encourage you to look through the discussions and archives at WP:Discussions for discussion if you want a more explicit idea of how contentious discussions get closed. the entire concept of consensus as realized in Wikipedia seems to be rooted in taking the course of action that is supported by the majority of editors while it may seem that way, it's not; as others have pointed out closing against a numerical majority is not uncommon. This is especially likely if the numerical majority looks like it won't be able to actually enforce its opinion. That is the root of consensus: unity of action. It's not that everyone (or X% of everyone) agrees "let's do X", but rather everyone agrees "we won't stop others from doing X if they keep Y and Z in mind". Our policies describe what people already do, not necessarily what must be done; we have no firm rules, so no matter the outcome of a "vote" it can only be implemented if the minority agrees to not stop its implementation (see meatball:CommunityDoesNotAgree). If 40% of editors vehemently oppose a change to the Manual of Style, they will revert any attempts to enforce it. The majority is then faced with a problem: either block 40% of our editor-base or compromise with the minority. That functional conflict is the basis of consensus: how do we avoid blocking 40% of editors every time we need to make a complex decision? We determine what the community agrees to allow rather than forcing one faction to do what another faction wants. Of course, that's not always ideal---sometimes we do want to force people to act in particular ways (e.g. WP:BLP, WP:NLT, WP:NPA, and WP:GS). In that situation voting is very effective because it demonstrates a mandate for forcing actions. But voting, like consensus, is a tool and not every tool is useful in all situations (for when it is useful, I largely agree with SunirShah's point of view at meatball:VotingIsEvil). For all the bytes people spend pointing out the problems in our consensus-based governance model, we rarely engage with the legitimate problems and failure modes of polling. Per Arrow's Theorem all non-binary voting systems will be sub-optimal along some metric of "fairness", so turning everything into a vote won't magically solve our problems. In fact, outside of binary choices, it is necessarily sub-optimal. We rarely have binary choices, and we rarely need to demonstrate a mandate to strictly enforce rules with blocks. That's the spirit behind NOTAVOTE: voting is a tool that is rarely useful for making decisions on Wikipedia. While many discussions look like votes (because straw polls are useful for organizing opinions by general sentiment), they don't function like them except in specific contexts or obvious cases. Wug·a·po·des 00:05, 2 March 2021 (UTC)

Technical

Pending Changes again

After this archived thread was resolved, I am once again unable to set pending changes on articles. @Xaosflux:. -- Jezebel's Ponyobons mots 17:00, 19 February 2021 (UTC)

phab:T273317 may be still a problem, could you see if you can add/remove users from the new page patroller and autopatrolled groups? You can test with Special:UserRights/Xaosflux_ep (just set it to expire in a day). — xaosflux Talk 17:16, 19 February 2021 (UTC)
Done. No problem there.-- Jezebel's Ponyobons mots 17:44, 19 February 2021 (UTC)
Added to phab:T275017. — xaosflux Talk 19:20, 19 February 2021 (UTC)
hi @Ponyo, thanks for the report and @Xaosflux thanks for putting it on Phabricator
As a possible workaround, can you try to add yourself to "pending changes reviewers" group to see if that helps you to workaround the issue? Martin Urbanec (talk) 02:09, 20 February 2021 (UTC)
(I know it can sound unrelated, but when debugging the previous occurance of the same issue, it sometimes worked with reviewer, but not without for some weird reason, so that's why I'm suggesting it) Martin Urbanec (talk) 02:10, 20 February 2021 (UTC)
For information, the same happened with my last edits. --Delfield (talk) 15:18, 20 February 2021 (UTC)

Pending changes auto-accept error again

In this this thread last month, several users (including myself) mentioned an error where our edits are not being auto-accepted on semi-protected articles. This techincal issue was eventually resolved. Now I'm having the same issue again, as seen here (same article as last time). Can this technical issue be fixed again? Thanks. Maestro2016 (talk) 02:13, 20 February 2021 (UTC)

Suspect this is same problem as Wikipedia:Village_pump_(technical)#Pending_Changes_again above. — xaosflux Talk 02:19, 20 February 2021 (UTC)
I'm still having the same issue, as you can see from recent edits to the same article. I'm still getting the "pending changes" thing again. Maestro2016 (talk) 19:15, 21 February 2021 (UTC)
I also just experienced this issue on Scratch_(programming_language) [1] - the diff shows the version as current, but the Scratch page shows 1 pending revision, mine. Might it be because I undid an accepted revision? Dialectric (talk) 03:07, 25 February 2021 (UTC)

Hello, I don't know where to put this, but my edits to pending changes pages have recently not been accepted automatically. This is weird because I've been able to make many edits to pending changes pages without any problem earlier this month. My account is almost a year old and I have over 500 edits, I've been able to edit extend-confirmed and semi-protected pages without any issues. Clear Looking Glass (talk) 05:47, 25 February 2021 (UTC)

Just experienced the same problem. Please see others' complaints at Wikipedia talk:Pending changes#Why I am being caught up in this?. --DB1729 (talk) 01:53, 26 February 2021 (UTC)

I'm getting the same problem. Link to Teahouse discussion (https://en.wikidark.org/wiki/Wikipedia:Teahouse#Pending_Changes_problems) and Phabricator. DiamondIIIXX (talk) 08:01, 1 March 2021 (UTC)

Pending review edits

There's this recent problem of mine that when I edit pending changes protected pages it says that my edits need to be reviewed first and not "automatically accepted". The first time that this happened to me was at Dire wolf, where I reverted an edit and didn't automatically accept it. Two edits of mine at Carnosauria [2] [3] also weren't automatically accepted, and there were no previous edits pending review. I've been extended confirmed here for a long time already (almost 8,000 edits and 1 and a half years), so why do my edits at pending changes protected pages need to be reviewed? Can someone please explain what's happening and how can this be fixed? JurassicClassic767 (talk | contribs) 06:28, 28 February 2021 (UTC)

@JurassicClassic767: Pending-changes protection is different from extended-confirmed protection. To accept pending changes you need the pending-changes reviewer userright. ƒirefly ( t · c ) 12:43, 28 February 2021 (UTC)
No, I know I'm not a pending changes reviewer, what I'm saying is that my edits at pending changes protected pages don't appear as "automatically reviewed". And what I meant was "autoconfirmed" (which is what you need for your edits to become "automatically accepted"), and I've been an autoconfirmed user a long time ago. JurassicClassic767 (talk | contribs) 13:48, 28 February 2021 (UTC)
@JurassicClassic767: Ah I see what you mean now, apologies. Edits from logged-in users to pending-changes protected pages are automatically accepted if and only if there are no prior edits pending review. If there are prior edits pending review, then the edits will go into the queue to be reviewed. ƒirefly ( t · c ) 13:57, 28 February 2021 (UTC)
But that's not what's happening though, in my examples above (Furileusauria and Carnosauria), there were no previous edits pending review, and when I edited, my own edit needed to be reviewed, that's the strange thing. JurassicClassic767 (talk | contribs) 14:12, 28 February 2021 (UTC)
Hmmm... yes that does seem odd. This edit was accepted on 31 Jan, and then your edit was made on 27 Feb. I'll see if I can dig anything up. ƒirefly ( t · c ) 14:23, 28 February 2021 (UTC)
#Pending Changes again? PC has been on the fritz lately. --Izno (talk) 18:44, 28 February 2021 (UTC)
Yes, there’s a phab ticket about it (for JurassicClassic767’s info) - phab:T275322 ƒirefly ( t · c ) 20:20, 1 March 2021 (UTC)
Huh, so it seems that there are several other users with the exact same problem as me, but is there really something that could be done to fix it? JurassicClassic767 (talk | contribs) 20:55, 1 March 2021 (UTC)
The developers are aware and I’m sure they’ll figure out a fix soon. ƒirefly ( t · c ) 22:29, 1 March 2021 (UTC)
Seems unlikely. FlaggedRevs (i.e. pending changes) is abandoned. Few/no devs want to touch the codebase. Although, it seems like there is a patch for review for that particular regression. ProcrastinatingReader (talk) 22:36, 1 March 2021 (UTC)
Ugh. Yet another part of MediaWiki that's mostly abandoned. Apologies, I didn't know FlaggedRevs had fallen down that particular hole. ƒirefly ( t · c ) 09:35, 2 March 2021 (UTC)
There's also the issue of when a page is both semi-protected and pending changes protected, and yet some edits are still not accepted. Ex. [4]... This will need some further bug fixing... Cheers, RandomCanadian (talk / contribs) 00:02, 2 March 2021 (UTC)
Einmal wieder... This is the second time this bug happens today; on the same page; with the same editor (@Paper Luigi: I don't think you have a clue either as to what might be causing this, just FYI)... RandomCanadian (talk / contribs) 01:32, 2 March 2021 (UTC)
I did notice that my edits were not automatically accepted and instead required approval. Consider me clueless. — Paper Luigi TC 01:36, 2 March 2021 (UTC)
I'm getting the same problem... DiamondIIIXX (talk) 03:42, 2 March 2021 (UTC)

Range block

My ignorance of technical matters is complete. My IP address is currently subject to a range block. (1) The instructions given to IPs are confusing and misleading, and I think they ought to be changed. Is this the right place to raise this issue? (2) Up until today, this has not been a problem for me, since I can simply log in to my account. Today, the system kept telling me that I was not allowed to edit Wikipedia because my account had been blocked – it was logging me out in the middle of a simple edit. Sweet6970 (talk) 12:40, 21 February 2021 (UTC)

If this is not the correct place to raise my query, I would be grateful if someone would tell me where I should do so. Sweet6970 (talk) 10:42, 22 February 2021 (UTC)

Depends on whether it’s a global block on Meta or a local one on English Wikipedia. Can you share part of the message you receive, Sweet6970? (No need to divulge the IP address if you’re not comfortable with that.) — Pelagicmessages ) – (08:15 Fri 26, AEDT) 21:15, 25 February 2021 (UTC)
@Pelagic: Thank you for your reply.

It’s a local one on English Wikipedia. [5] [6] https://en.wikidark.org/wiki/Special:Contributions/2A02:C7D:0:0:0:0:0:0/33

The wording I receive as an IP is """""""""""""""""""""""""""

View source for Melvyn Bragg ← Melvyn Bragg Jump to navigationJump to search You do not have permission to edit this page, for the following reason:

 Your account has been blocked from editing Wikipedia.

This does not affect your ability to read Wikipedia pages.

Editing from ‪2A02:C7D:0:0:0:0:0:0/33‬ has been blocked (disabled) by ‪Drmies‬ for the following reason(s): Persistent addition of unsourced content: Persistent addition of incorrect content: change to site-wide This block has been set to expire: 13:15, 29 June 2021. Even when blocked, you will usually still be able to edit your user talk page and email other editors and administrators. For information on how to proceed, first see the FAQ for blocked users and the guideline on block appeals. The guide to appealing blocks may also be helpful. Other useful links: Blocking policy · Help:I have been blocked """""""""""""""""""""""""

This wording is incorrect for me, since my account is not blocked, it is my IP address which is blocked. More importantly, it is incorrect for the IPs, because there is no point in appealing, they have to create an account if they want to edit.

I am no longer having trouble being logged out, but I am still concerned about the wording, which does not make it clear to IPs that if they want to edit, they have to create an account. You can see that 8 people have created a Talk page in order to appeal, which is not what the intention is. I have checked some of the IP addresses, and found various parts of London, Middlesbrough, and Glasgow, and I am wondering if everyone in Britain who uses my ISP is blocked from editing as an IP, and not being told that they have to create an account if they want to edit.

Sweet6970 (talk) 11:42, 26 February 2021 (UTC)

Generally IP blocks extend to accounts created using that IP or the IPs cannot create new accounts. Otherwise they would be too easy to avoid, and telling the users how to circumvent a ban wouldn't be a good idea either even if it would be possible. Things can cascade from there, see Wikipedia:Autoblock. --mfb (talk) 12:18, 26 February 2021 (UTC)
@Mfb: In this case, the intention is that any IP affected should create an account. See [7] The range of this block is absolutely enormous, and as I said, it looks like the range block covers anyone in Britain who uses the same ISP as I do. But the problem is that the instructions received by the IPs do not tell them that they should create an account. Sweet6970 (talk) 12:32, 26 February 2021 (UTC)
@Sweet6970: Typically, any significant range block should use the {{rangeblock}} or {{anonblock}} (or {{schoolblock}} or similar) templates, which I believe are relatively clear. Most admins are quite good about doing this. I don't enjoy taking over such large range blocks, which is what would happen if I were to change the message; what we can do is ping the blocking admin User:Drmies, or you can head over to his talk page, and ask him simply and nicely to please add a template. -- zzuuzz (talk) 12:45, 26 February 2021 (UTC)
@Zzuuzz: Thank you for your comment. It looks like the {{anonblock}} would be the most suitable, but it still does not actually say ‘You are allowed to create an account, and this is what you should do’. (Under this particular block, there is no need to make a special request to create an account.) I did raise the question of this range block with Drmies in January. [8] The reply I received [9] felt like a brush-off, and I felt that it implied that I was on the side of vandals. I expect that if I raise this matter again I will be told that this is none of my business, so there is no point. Sweet6970 (talk) 13:41, 26 February 2021 (UTC)
I believe your previous note to Drmies didn't clearly identify the problem, or the solution (which you probably weren't to know about). But no worries, hopefully my ping from here will clarify the issue and result in a positive outcome. If not, ping me again, and I'll begrudgingly take over Drmies' block with a suitable message. Generally, the anonblock template is tried and tested, and I think it should be good enough, but suggestions to improve the wording are always welcome. -- zzuuzz (talk) 13:50, 26 February 2021 (UTC)
I have to admit I don't quite get the problem. If it's that the block notice isn't inclusive enough, sure, someone higher up on the technical food chain can fix that, I suppose. But still, Sweet6970's note on my talk page was odd: "It looked like it would have been possible for me to create an account (I didn’t go through with it)"--well, they already had an account. The template's second sentence is "you are still able to edit if you sign in with an account", and that links Wikipedia:Why create an account?, where as-yet unregistered users can create an account. Many if not all as-yet unexperienced editors are able to "work this out", to use Sweet6970's phrasing, so why not here? And "If the idea is that anyone who is affected by the block should create an account, then the instructions need to be improved to give a clear route to this option"--well, the instruction is right there, and it's clickable. So no, I'm not saying this is none of their business, and I appreciate advocacy, and if someone thinks the template should be improved, go for it. Drmies (talk) 15:59, 26 February 2021 (UTC)
@Drmies: (1) Regarding my note being ‘odd’: Yes, of course I have an account. Now. But I am looking at this from the point of view of someone who does not have an account, and remembering the bafflement, frustration, and annoyance which I felt when I was subject to a range block before I created my account.
(2) I don’t understand what you mean when you say The template's second sentence is "you are still able to edit if you sign in with an account". That’s not what I get when I go to edit logged out. I have already copied the wording in my previous post above:

“””””””””””””””””””””””””””””””””””””””””””””””””””””””” Jump to navigationJump to search You do not have permission to edit this page, for the following reason:

 Your account has been blocked from editing Wikipedia.

This does not affect your ability to read Wikipedia pages.

Editing from ‪2A02:C7D:0:0:0:0:0:0/33‬ has been blocked (disabled) by ‪Drmies‬ for the following reason(s): Persistent addition of unsourced content: Persistent addition of incorrect content: change to site-wide This block has been set to expire: 13:15, 29 June 2021. Even when blocked, you will usually still be able to edit your user talk page and email other editors and administrators. For information on how to proceed, first see the FAQ for blocked users and the guideline on block appeals. The guide to appealing blocks may also be helpful. Other useful links: Blocking policy · Help:I have been blocked “””””””””””””””””””

There is nothing here about creating an account. The instructions lead you to appeal the block (as several IPs have done) which is pointless.
(3) Your block prevents people from all over Britain from editing as IPs, and does not notify them that they have the option to create an account. Sweet6970 (talk) 16:44, 26 February 2021 (UTC)
Sorry, I was pointing at the block notice that Zzuuzz linked. Let's change that then, if we can (I can't). Drmies (talk) 17:37, 26 February 2021 (UTC)
Would it not be possible to cancel the existing block and immediately replace it with a block using the anonblock template? Alternatively, the template which is currently in place includes your own wording for the reason for the block. Presumably, you could add something here like ‘If you wish to make constructive edits to Wikipedia, please create an account in order to do so’? This would be clearer for IPs subject to the block. Is it possible to cancel the existing block, and immediately replace it with another block with the same template, but with the additional wording? Sweet6970 (talk) 18:33, 26 February 2021 (UTC)
  • Hi, just trying to reconcile eveything above. Is the technical problem that we are trying to resolve mostly: Logged in users that are using an IP address range that is hard blocked are getting the wrong text from MediaWiki:Blockedtext's headline. ? — xaosflux Talk 19:20, 26 February 2021 (UTC)
Sorry, no. The problem is that IPs who are blocked under a very large range block are not getting the message that they should create an account if they want to edit. (I know very little about these things, but I think this is what is called a 'soft block', because my IP address is covered by the block, but I usually have no problem editing if I log in.) Sweet6970 (talk) 20:01, 26 February 2021 (UTC)
Indeed. The issue is that the default (interface) block message is not helpful, compared to having the {{anonblock}} template in the block (log) message. This is why we have the block log templates. The range is actually soft blocked with AC enabled. All we need is for someone to copy-paste {{anonblock}} into the current block reason. -- zzuuzz (talk) 20:05, 26 February 2021 (UTC)
@Zzuuzz: MediaWiki:Blockedtext should be showing a different message if a non-logged in user is blocked, along the lines of: You are currently unable to edit Wikipedia due to a block affecting your IP address.... If there are improvements to that message suggested, anyone can place an edit request at MediaWiki talk:Blockedtext. — xaosflux Talk 20:24, 26 February 2021 (UTC)
Indeed it should, and that I can't readily explain. On another IPv4 range, I've only been able to confirm that MediaWiki:Blockedtext-composite is working correctly, but I'm not in a position to check this situation. However, I think my point remains, this block - any block of this size - needs a block log template. -- zzuuzz (talk) 20:49, 26 February 2021 (UTC)
@Zzuuzz: You first mentioned the {{rangeblock}} and {{anonblock}} templates in your post of 12:45, 26 February 2021 (UTC). If I block a range of IPs (something I've never done, but recently I have had cause to), where should these templates be placed? I normally put templates like {{subst:uw-vblock}} on the user talk page - but an IP range may have hundreds (if not thousands) of talk pages. Am I expected to put the template on all of them? --Redrose64 🌹 (talk) 21:31, 26 February 2021 (UTC)
Any template placed in the block reason is transcluded to the user. So, if you pick one of the templates in the dropdown list (the bottom half of this list), the full template will be displayed when the blocked user tries to edit. Every IP in the range will see the transcluded template when they try to edit. You can also just place the template in the 'custom reason' field, or mix it up as I recently did here. That user will get the full username block template, plus the custom message I added. -- zzuuzz (talk) 21:46, 26 February 2021 (UTC)
@Zzuuzz: I’m sorry to trouble you. The message I get when I go to edit logged-out is still the same. You have said that all we need is for someone to copy-paste anonblock into the current block reason. Presumably only an admin could do this. Could you fix this, please? Sweet6970 (talk) 16:45, 1 March 2021 (UTC)
@Sweet6970: Done. If there's still issues, or you want to let me know how you're getting on with the message, drop a note on my talk page. -- zzuuzz (talk) 17:13, 1 March 2021 (UTC)
@Zzuuzz: Thank you very much for your help with this matter. Sweet6970 (talk) 17:37, 1 March 2021 (UTC)

Global user page

As I understand it, it is possible to configure one's preferences at meta to create a global user page that will be transcluded from meta to all wikis, MediaWiki:Help:Extension:GlobalUserPage. When a user does that, a user page is no longer editable on en-wiki and its history log is not viewable here either. Most of the time this is fine, but I can see some potential problems, e.g. if somebody starts putting some inapprorpriate material (spam, using the userpage as a webhost, personal attacks etc) on their global user page, and we are not able to address the issue here. Another situation concerns users who are banned or blocked (e.g. for sockpuppetry) on en-wiki. Often in such cases we tag their userpages accordingly but it would seem that for a user with a globally transcluded user page we don't have this capability. Or do we? I saw a user who got indef blocked at ANI yesterday and they seemed to have implemented a global user page option via meta today. Is there anything that can be done in such situations? Nsk92 (talk) 13:36, 21 February 2021 (UTC)

The easiest way is to create a user page locally. All local user pages override global ones. Note that meta has also policies against inappropriate material like spam, webhosting, attacking others, so for some pages requesting deletion there is an option too. Majavah (talk!) 13:43, 21 February 2021 (UTC)
If there is blatant inappropriate material on a meta-wiki user page, you may tag it for speedy deletion on Meta, if you aren't sure you can ask at meta:Meta:Requests for help from a sysop or bureaucrat. You should not put project-local scarlet letters on someone else's meta-wiki page though. — xaosflux Talk 15:41, 21 February 2021 (UTC)
Nsk92: the local user page can still be created if there is a transcluded meta page. Try it on your example. If someone is using their meta global page for abuse, a global lock is probably in order also. –xenotalk 13:46, 21 February 2021 (UTC)
The blocked user in question, User:Tisquesusa, did have a local user page before. Then it suddenly disappeared and got replaced by a global user page transcluded from meta. The globally transcluded page does not contain any abusive or improper material at the moment (there was a G11 user subpage that I CSD tagged today and it got deleted). But the situation still somewhat concerns me. In fact I don't understand how I can try to create/edit a local user page for this user now (assuming I wanted to do that). I can't create a red link. I can't access the history log for the user page. The global user page just sits there. Nsk92 (talk) 13:59, 21 February 2021 (UTC)
The user page was deleted as WP:CSD#U5 by Deb today. I don't see how it qualifies as U5, mind you. An admin can recreate it if necessary. Jo-Jo Eumerus (talk) 14:18, 21 February 2021 (UTC)
I can restore it if you think it's worth the effort - it looks pretty awful, mind you. Let me know. Deb (talk) 14:26, 21 February 2021 (UTC)
The page that was deleted (as both G11 and U5) was a subpage User:Tisquesusa/Más Muisca, not the parent user page. I don't remember what the user page itself contained, but the subpage was an advertisement page for a guided tour/adventure operation run by the user. That's U5 in my book. Nsk92 (talk) 14:30, 21 February 2021 (UTC)
@Deb and Nsk92: U5 only applies when the owner has made few or no edits outside of user pages. Tisquesusa has made lots of non-userspace edits, so the criterion cannot possible apply. * Pppery * it has begun... 15:03, 21 February 2021 (UTC)
Ah, yes, I see you are right. I should have only tagged it as G11. Nsk92 (talk) 15:11, 21 February 2021 (UTC)
Nsk92: what do you mean "I can’t create a red link"? Unless there was a change I didn’t hear a about, any user can create another user’s user page. –xenotalk 14:34, 21 February 2021 (UTC)
Only if it doesn't exist already. When I type 'User:Tisquesusa' in the search window and press 'Go', I am taken to the global user page, User:Tisquesusa. If I press 'Search' instead, I get a line 'There is a page named "User:Tisquesusa" on Wikipedia.' Nsk92 (talk) 14:43, 21 February 2021 (UTC)
When visited locally, it can be edited locally, despite the global presence. Generally if there is abusive content it would simply be turned into a redirect to the user talk page. –xenotalk 14:46, 21 February 2021 (UTC)
But how, exactly? How can it be turned into a redirect or edited locally, if necessary? I can't access the local history log for this user page now. And the edit button for it is not available either. Nsk92 (talk) 14:49, 21 February 2021 (UTC)
Hmm, try clicking here. Maybe it is limited to administrators? –xenotalk 14:57, 21 February 2021 (UTC)
Works for me, even though I'm not an admin. * Pppery * it has begun... 15:03, 21 February 2021 (UTC)
Your link works, and it allows me to create a local user page (it does look like it has been deleted or displaced somehow, presumably by the global user page being activated). But I have no idea how you created this link. Did you just manually type an entire http address? Interesting and strange ... Nsk92 (talk) 15:08, 21 February 2021 (UTC)
I’m using the desktop monobook responsive view; I have some custom scripts but I don’t think they are what’s adding the edit button for me. –xenotalk 15:09, 21 February 2021 (UTC)
Weird. I am also using the desktop monobook view, but I don't have an edit button for that page. Nsk92 (talk) 15:17, 21 February 2021 (UTC)
Nsk92, the link you are probably looking for is "Add local description" which takes you to the edit page. It is confusingly named, but I think it is because it uses the same system as images on commons use (i.e. random file File:Rueda de prensa sobre la sentencia del tribunal europeo acerca de los desahucios en España (8558751810).jpg when viewed on enwiki has the "Add local description" link instead of "Edit"). The "Add local description" link makes more sense for images, as you are adding a local description of the image. However, it doesn't make as much sense for global userpages. Perhaps this should be renamed for global userpages to something like "Create local userpage"? Dreamy Jazz talk to me | my contributions 15:29, 21 February 2021 (UTC)
(edit conflict) Depending on preferences there may be one or more of the tabs "Add local description", "Create", "Create source", "Edit", "Edit source", or MonoBook variants. Don't you have any of them? PrimeHunter (talk) 15:31, 21 February 2021 (UTC)
You are right, there is an "Add local description" button. I didn't realize that it acts as a local edit button (which would presumably override a global user page?) Nsk92 (talk) 15:55, 21 February 2021 (UTC)
← Yes it would Nsk92. Dreamy Jazz, good suggestion for the interface change. The responsive view was giving me an intuitive pencil but in landscape, it is indeed Add local description. –xenotalk 16:07, 21 February 2021 (UTC)
Xeno, if I'm not wrong, would that be achieved by placing the text needed in MediaWiki:Create-local? I also presume that mediawiki pages can contain parser functions and magic words which will work per page (so that the page knows where it is being used and then can modify the wording based on the namespace). It could, if I assume correctly for those both, use a parser function to check if the namespace number is 2 (i.e. userspace) and then output "Create local userpage" instead. Dreamy Jazz talk to me | my contributions 18:38, 21 February 2021 (UTC)
I've created a sandbox for this and when adding "?uselang=sandbox" to the URL it seems to work as intended. So my assumptions were correct. Dreamy Jazz talk to me | my contributions 18:50, 21 February 2021 (UTC)
I think this change is pretty minor, so I'm inclined to sync the sandbox (what is currently in MediaWiki:Create-local/sandbox) to MediaWiki:Create-local. However, I'll wait for a bit in case there are objections. Interestingly this page had no history until I edited it. That seems to be the same with MediaWiki:Create-local. Dreamy Jazz talk to me | my contributions 19:00, 21 February 2021 (UTC)
There are around 26,000 MediaWiki messages and only around 2,000 pages in the namespace. The rest display a MediaWiki default. PrimeHunter (talk) 18:21, 22 February 2021 (UTC)
I've gone and merged the sandbox to the main page so that it shows for everyone with their language set to en. Dreamy Jazz talk to me | my contributions 13:52, 25 February 2021 (UTC)

Stop Chrome from scrolling the editing box when I press enter

I asked this already at the reference desk but was unable to arrive at a diagnosis or solution. When I am editing Wikipedia, Chrome has some weird annoying feature that is horrendously annoying. Usually, but not always, when I press the enter key, the editing textbox will scroll so that the new line is at the very top of the text box, rather than the text box staying where it is and the new line pushing the text down under it (as is the expected behaviour). This only happens on Wikipedia (although I have not found any sites that use plain multiline text boxes to test... everything is script-based these days), and it happens on every computer I try it on. It happens logged out as well as in incognito mode, so this is the behaviour that IPs would be experiencing unless they use the visual editor.

I've used Chrome for years, but this behaviour has only been happening to my knowledge for the past several months. How do I stop text boxes from scrolling when I press enter? I'm up to date with v88.0.4324.150. - Floydian τ ¢ 17:46, 21 February 2021 (UTC)

This happens to me when I paste in one or more lines of text, but it is not consistent. Subsequent pastes do not always make it happen. Using Chrome on Lubuntu.--Verbarson (talk) 15:20, 22 February 2021 (UTC)
He's already tried mw:safemode, and that didn't help. I'm stumped. Anyone else have any ideas? Whatamidoing (WMF) (talk) 00:34, 23 February 2021 (UTC)
  • Bump to stop bot archival. - Floydian τ ¢ 05:11, 28 February 2021 (UTC)

Reply tool

Just checking in to see if anyone else has information for me about mw:Talk pages project/Replying. I'm talking to the devs about offering this as a default-off Beta Feature here. There are lots of comments at Wikipedia talk:Talk pages project#Experiences from people who've been using it, but we might be biased. ;-) So if you're aware of any problems that make you nervous about having more people try it out, or if you've been secretly cleaning up messes every time I use it and you just never wanted to mention it, please ping me. (Try it out here: https://en.wikidark.org/wiki/Wikipedia:Village_pump_(technical)?dtenable=1 and look for the [reply] buttons. If you switch to the visual mode, it'll make it really easy to @-mention editors. As long as nobody breaks the page with, say, an unescaped half of a parser code, an unclosed div tag, or a broken wikitext table, then it should work even on a page as big as this one.) Whatamidoing (WMF) (talk) 00:45, 23 February 2021 (UTC)

So, silence means no obvious problems? ;-) Whatamidoing (WMF) (talk) 17:26, 26 February 2021 (UTC)

Watchlist parameter

Hi all,

my question is when I enable the HIDE->bots parameter - in order to reduce the size of my watchlist - the problem is the hidden articles may contain as well non-bot new edits before the latest/recent bot edit, that have been made earlier (but was not present in my earlier listing, since those edits did not have been made then, but between my two listings). With other words, in case the last=(recent) edit has been made by a bot, then that article will not displayed on the actual listing of the watchlist, and it will remain until a non-bot edit will be performed, however, if again a bot edit would follow (and meanhile I would not make a fresh listing by any purpose), again it would be/remain hidden, and I would not know anything about any intermediary non-bot edits, like that. This is the problem. I would like just to hide those articles in my actual listing, which had just and only both edits from a given time, but not the non-bot edits have been done after the given time, but before the recent/latest bot edit. I hope I formulated my problem in a way to be correctly understood. Thank You.(KIENGIR (talk) 22:34, 24 February 2021 (UTC))

@KIENGIR: this is known issue phab:T11790, not something we can fix directly here on the English Wikipedia. You can follow that ticket for more details. — xaosflux Talk 00:40, 25 February 2021 (UTC)
Thank, I looked through the thread, but as I see the outcome tended the opposite direction I wish to achieve...or I would be wrong?(KIENGIR (talk) 00:55, 25 February 2021 (UTC))
That problem is still "open" meaning that no one has implemented a fix for it, yet. — xaosflux Talk 01:11, 25 February 2021 (UTC)
I have not tried this but elsewhere, others have suggested this:
Trappist the monk (talk) 01:41, 25 February 2021 (UTC)
@Trappist the monk:,
thank you, I am very afraid to make tryout changes, since in the past a village pump discussion was needed to fix another issue with the watchlist, and I had luck with the tweak that was proposed, however, the whole system did not work as should be, so my current result is a test&tweak alltogether, far from perfect (not listing back to the set days, in a way number of diffs limited, etc.). Explanding watchlist to show all changes - even with after hiding bot edits - is out of qustion, since I wish to reduce, it would dramatically enlarge it (I assumed the directive you put as a sequential step and not separate). The group changes I don't understand what would exactly means, can someone explain it?(KIENGIR (talk) 22:47, 25 February 2021 (UTC))
No need to be afraid; if you don't like the results of this, uncheck those options. You want to see all edits except bot edits. Until T11790 is fixed, this is the only way I know of to accomplish that. 'Group changes by page' groups the changes into collapsed lists so that grouped entries on your watchlist watchlist look something like this (except a lot of it will be wikilinked):
►       22:47 	Wikipedia:Village pump (technical)‎‎ 24 changes history  +8,012‎  [TheDJ‎; Suffusion of Yellow‎; Roxy the dog‎; PrimeHunter‎; Pelagic‎; ONUnicorn‎; KIENGIR‎; Dreamy Jazz‎; 0mtwb9gd5wx‎; Slywriter‎ (3×); Xaosflux‎ (4×); The Anome‎ (8×)]
When you click on the ►, it changes to ▼ and shows the changes for the page sort of like this:
▼       22:47 	Wikipedia:Village pump (technical)‎‎ 24 changes history  +8,012‎  [TheDJ‎; Suffusion of Yellow‎; Roxy the dog‎; PrimeHunter‎; Pelagic‎; ONUnicorn‎; KIENGIR‎; Dreamy Jazz‎; 0mtwb9gd5wx‎; Slywriter‎ (3×); Xaosflux‎ (4×); The Anome‎ (8×)]
  		22:47 (cur | prev)..(+828‎)..KIENGIR (talk contribs) (→‎Watchlist parameter rollback)
   		22:08 (cur | prev)..(+1)‎..Slywriter (talk contribs) (→‎Edit filter to prevent http: //%5B(and cousins) making good links bad: Indent (Tags: Mobile edit Mobile web edit)
   		22:08 (cur | prev)..(+793)..Slywriter (talk contribs) (→‎Edit filter to prevent http: //%5B(and cousins) making good links bad: Thanks PrimeHunter and question on long term Maintenance (Tags: Mobile edit Mobile web edit)
   		etc
Click ▼ to collapse the list. Line wrapping in the real watchlist is prettier. Try it. If you don't like, undo it.
Trappist the monk (talk) 23:44, 25 February 2021 (UTC)
Thank you very much for the demonstration...well maybe once I will try, but as I see I have to really wait for the fix...(KIENGIR (talk) 19:32, 27 February 2021 (UTC))
As far as I know, "Group changes by page in recent changes and watchlist" is irrelevant in this equation. Older edits to pages whose latest edits are hidden show up as long as "Expand watchlist to show all changes, not just the most recent" is checked. Nardog (talk) 15:20, 28 February 2021 (UTC)

Edit filter to prevent http: //%5B(and cousins) making good links bad

So while playing on toolforge and running a search on %.%[10](which terrified me that I would blow up a server), I stumbled onto the fact that potentially hundreds of links/refs are broken because http://%5b (as well as %5b%20 , %5E and a few others) are appended to the beginning of the url.

Working my way through cleaning up what I can but wondering if an edit filter would be viable to that warns an editor adding a double http:// in an edit summary (I say warn because possible their are valid reasons - Interner archive comes to mind) Slywriter (talk) 02:31, 25 February 2021 (UTC)

Here is an example one added. No apparent cause. 10 years ago. Unclear why it's happening. %5B = open square-bracket. Old MediaWiki bug? -- GreenC 02:53, 25 February 2021 (UTC)
Wow, sorry, totally forgot to add examples. I've already cleaned up a bunch but let me go back through them and see if there is any similarity in when the edits were added. Slywriter (talk) 03:05, 25 February 2021 (UTC)
2012 Special:Diff/472050129
2018 Special:Diff/822925977
For it to be a bug, it would be a long standing one. Not seeing any commonality in tags either (web, mobile, iOS, visual)Slywriter (talk) 03:26, 25 February 2021 (UTC)
Yeah hard to say. BTW notice some of the URLs have trailing %5D that also should be removed. It may be pretty difficult to automate a fix given how many forms it takes. -- GreenC 04:18, 25 February 2021 (UTC)
Like this URL http://%5Bhttp://www.drukgyelhss.edu.bt/%20Drukgyel%20school%20%5D%20 in Drugyel higher secondary school should be [http://www.drukgyelhss.edu.bt/ Drukgyel school]
5B & 5D there. Cut and Paste of a wiki link gone wrong?
Tested what happens when you manually type/cut and paste [http://example.com] into the edit screen(&visual editor manual cite wizard) as [http://[example.com]] but that didn't trigger a change to unicode, the brackets remained.
Doubt I'll have much luck figuring out the how they do it but the brackets showing up give me the idea to search against other special wiki characters (<>{}~) unicode equivalents. Might be some other unicode characters that will cause obvious problems at beginning or end of a url.
If the double html remains constant, may be able to at least automate the generation of a list that can be manually checked. Slywriter (talk) 05:31, 25 February 2021 (UTC)

With some sleep and a new look at the data, assuming I am correct in my assumption that my search string is returning an alphanumeric sorted list of ALL websites links found in article space, then the problem is less than a 100 links. Only reason I question my assumption is the surprisingly low number of IP only web addresses that are used for links. Slywriter (talk) 14:49, 25 February 2021 (UTC)

It can happen if you try to use the toolbar link feature on code which already has external link syntax. An article may say [http://www.drukgyelhss.edu.bt/ Drukgyel school]. Click the chain icon in the toolbar and paste the code in the top field. You get a warning and cannot save. If you select "To an external web page" then you can save but it becomes [http://%5Bhttp://www.drukgyelhss.edu.bt/%20Drukgyel%20school%5D [http://www.drukgyelhss.edu.bt/ Drukgyel school<nowiki>]</nowiki>]. I don't know whether nowiki was always added. PrimeHunter (talk) 21:45, 25 February 2021 (UTC)
Thanks for that explanation. The sequence also explains why it's mostly, though not exclusively, low quality pages that its occurring. Situations where it seems the editor was determined to get the link in.
I've found a few other bad link styles like web addresses starting with a period http://.example.com . ::For now, I'll work on cleaning up through toolforge but once I have a good list of the errors is here the best place to see if someone with better backend knowledge can setup a query that I can run on my own or updates a page to show likely bad URLs? Would be better for long term maintenance and I suspect lower overhead than me running constant toolforge searches. Slywriter (talk) 22:08, 25 February 2021 (UTC)

How do we disable magic links?

This 2017 en.WP RFC determined that once bots and scripts have replaced magic links (ISBN et al.), magic links should be disabled. As far as I know, bots and scripts have done this work (except for new untemplated and nowiki-wrapped ISBNs that are added continually by manual editing and buggy VE copy-paste editing), and the ability to disable magic linking locally has been provided.

This MW page appears to explain how to disable magic linking on a per-wiki basis. It is past time to do it here, if we have this local control and if there are no show-stopping feature requests that depend on magic links. There are a bunch of magic-link-related bugs and feature requests linked at T145589, but I am unable to determine whether any of them will be affected if we disable magic linking locally.

Is there anyone here with the sysadmin-level knowledge to figure out whether we can finally disable magic linking here at en.WP? – Jonesey95 (talk) 03:18, 25 February 2021 (UTC)

I don't disagree that these should be disabled at some point, but there are more than 11,000 ISBN magic links in use and a few thousand of the rest combined. If the magic links are disabled how will they be replaced? Perhaps we could start with an edit filter that does not allow any more magic links to be added, and then hopefully the fixer bot can get rid of those remaining? RudolfRed (talk) 00:57, 26 February 2021 (UTC)
I'm pretty sure the bots don't mess with User-space or Talk-space pages, for good reason, and there is no need to "fix" old AFD or other discussion pages. There should be no problem disabling magic links in those spaces.
That leaves only about 1,000 article-space pages with ISBN magic links, down from an initial population of about 500,000 in 2017, and with many tens or hundreds of thousands of pages fixed up by bots over the years. That's 99.8+% done, which is good enough. Those stragglers presumably exist only because the bots are taking care not to mess with edge cases like this one or this one. I'm fine with keeping the maintenance categories or WPCleaner reports around if we think they are useful, but the RFC said we should disable these magic links. It's time. – Jonesey95 (talk) 04:57, 26 February 2021 (UTC)
I say go for it. The effects of T162291 are the same (I assume they will stop doing that once the change goes through), T179769 is stalled because it has not been requested to disable magic links yet and T145589 is just about autolinking new magic links in a new way. It is possible to make an specific tool to make VE link those links the new way, once T179769 is fixed, see mw:VisualEditor/Gadgets. At the most, just warn VE users that adding magic links the new way is not going to work until T179769 gets fixed. Tidy was repaced with linter errors outside of mainspace still remaining, so that should be fine (seemingly not on enwiki, but elsewhere, see phab:T192821).--Snaevar (talk) 14:29, 26 February 2021 (UTC)
Also support disabling these. It's long overdue, and we can easily clean up anything that breaks. ƒirefly ( t · c ) 15:21, 26 February 2021 (UTC)

servers crashing

An error occurred while attempting to preview your changes. The server did not respond within the expected time.

11 times...... 0mtwb9gd5wx (talk) 08:56, 25 February 2021 (UTC)

Latest version of Firefox appears to break Wikimedia single sign-on

Firefox 86.0 comes with "total cookie protection" (see https://blog.mozilla.org/security/2021/02/23/total-cookie-protection/ ) that sandboxes cookie storage to prevent cross-site tracking by third party cookies. Unfortunately, it also seems to break the Wikimedia single-sign-on mechanism. See https://hacks.mozilla.org/2021/02/introducing-state-partitioning/ for a description of how it works.

This clearly either needs WMF liason with Mozilla to whitelist the single sign on mechansim, or to use the Storage Access API to request it be permitted on a site-by-site basis. Where is the best place to report this? -- The Anome (talk) 09:18, 25 February 2021 (UTC)

The Anome, welcome to the club. My Safari ticket is here phab:T226797TheDJ (talkcontribs) 09:42, 25 February 2021 (UTC)
This clearly needs to be fixed ASAP -- how do we get the WMF's attention on this? -- The Anome (talk) 10:03, 25 February 2021 (UTC)
But does it need to be fixed if it isn't broken? Using firefox as always, version 86, has continued to give great service, and hasn't broken yet. just an observation. -Roxy the grumpy dog. wooF 11:03, 25 February 2021 (UTC)
@The Anome: to be clear, simply having FF v86 doesn't appear to be breaking logon, does it? Is this an opt-in feature that users have to select? (I think the option is labeled All third party cookies (may cause websites to break)). — xaosflux Talk 12:06, 25 February 2021 (UTC)
Logon is fine, cross-site logon between sites ending in "wikidark.org" is also fine. What doesn't work is SSO between top-level domains, such as Commons or Wikidata, if you log in from a wikidark.org site. -- The Anome (talk) 12:13, 25 February 2021 (UTC)
@The Anome: is this only in "strict mode" ? — xaosflux Talk 12:23, 25 February 2021 (UTC)
I believe so. But the system sould support strict mode, as this is what any privacy-conscious user should be using already. -- The Anome (talk) 13:46, 25 February 2021 (UTC)
In the mean time, can anyone verify if someone enables this strict mode (that warns it may be breaking) if they can still exempt site-by-site as talked about in this article? — xaosflux Talk 14:06, 25 February 2021 (UTC)
The mozilla blog says Total Cookie Protection makes a limited exception for cross-site cookies when they are needed for non-tracking purposes, such as those used by popular third-party login providers.SD0001 (talk) 07:47, 26 February 2021 (UTC)

Ugly workaround

I threw together a hacky little user script at meta:User:Suffusion of Yellow/central.js. Works for me with FF86/Linux with all third party cookies blocked. Install in your global.js, then click "Central login" under "tools" on any site you are currently logged in to, and follow the directions. You will be logged in to all the other wikis, too. Suffusion of Yellow (talk) 21:26, 25 February 2021 (UTC)

Technical help needed on the helpdesk.

Technical minded people may want to take a look at Wikipedia:Help_desk#Series_of_failed_pings. I can't figure out what's going wrong with this person's pings. ~ ONUnicorn(Talk|Contribs)problem solving 20:19, 25 February 2021 (UTC)

User:Dotcodegh

This user has only a single edit, made one hour after registering the account, which created an article, George Takyi. How could an account which is not autoconfirmed create an article? Cullen328 Let's discuss it 22:55, 27 February 2021 (UTC)

@Cullen328: The page was created in Draftspace and then moved by User:Kinvidia into mainspace. ƒirefly ( t · c ) 23:12, 27 February 2021 (UTC)
Thank you, Firefly. Cullen328 Let's discuss it 23:19, 27 February 2021 (UTC)
No problem! :) ƒirefly ( t · c ) 12:40, 28 February 2021 (UTC)

Search history on Wikipedia app on iPhone

I am using the Wikipedia app to browse through Wikipedia. It really annoys me that it saves your search history. I know how to clear my search history in the app, but I would like to how to prevent the app from storing my search history so I don’t have to keep clearing it. Same goes with the article viewing history. Thanks, Interstellarity (talk) 00:06, 28 February 2021 (UTC)

Optional Class Parameter

Someone recently pointed out to me that the class parameter for a Wikiproject banner is better left blank for Drafts and Redirects because those articles are likely to change in the future and the class is auto-populated simply by virtue of the article being in Draft or Redirect space. I was curious what the standard conventions for WikiProject banners in general, but I'm specifically interested in whether it would be better to have a shortened WikiProject banner for Categories and Files because they are unlikely to change, but would be auto-populated. Would a short banner without a class parameter be best or should the class be included? Or if it doesn't matter, what would you suggest? I would assume that it's best to keep a standard convention across a large number of articles so if I'm making sure it's one specific way for an entire WikiProject what would be ideal?

I've never used the Village Pump so let me know if this is the wrong place. I figured it was a technical question because I want if there is a benefit to adding optional parameters. TipsyElephant (talk) 02:18, 28 February 2021 (UTC)

I think most WikiProjects also auto-assess class on categories and files. So I think the answer to Would a short banner without a class parameter be best? is yes? @Redrose64: --Izno (talk) 18:45, 28 February 2021 (UTC)
Not just categories and files - rather than listing the namespaces explicitly, it's easier to say "all talk namespaces except for Talk: itself". More specifically, if the |class= parameter is omitted or left blank, all WikiProject banners that have class ratings (with the exception of {{WikiProject Military history}}) will automatically set the class if either (i) the subject page is a redirect; or (ii) the subject page is not in main (article) space - if both apply, it's classified as a redirect. In the case of {{WikiProject Military history}}, which doesn't autodetect redirects, it will automatically set the class if the subject page is not in main (article) space. So, generally speaking, the |class= parameter should only be filled in if the subject page is an article or disambiguation page. Remember that pages in Draft: space are not articles (although they may become articles when developed sufficiently) so WikiProject banners in Draft talk: space should not have the |class= filled in. --Redrose64 🌹 (talk) 00:18, 1 March 2021 (UTC)

Two-dimensional schematic diagram

I would like to do a two-dimensional schematic diagram to represent a streetcar network of 3 north/south lines and one interconnecting east/west line. I would like to use Template:Routemap but I would want the east/west line to be a horizontal line instead of twisting it into a vertical line. Thus, the schematic would resemble the city street grid. However, I suspect I would have problems indicating and labelling east/west stops. Is there any existing examples of doing this?

My second choice would be to acquire some inexpensive, easy-to-use diagram software to produce a diagram similar in style to this svg example or this gif example. Could someone recommend software to do this? Thanks. TheTrolleyPole (talk) 22:04, 28 February 2021 (UTC)

TheTrolleyPole, You'll probably find better answers at Wikipedia:Graphics Lab. -- RoySmith (talk) 16:49, 1 March 2021 (UTC)

'Publish changes' should ask for confirmation but doesn't

When finished editing a Wikipedia article and clicking 'Publish changes', your changes go live, immediately and irrevocably. That is arguably reckless and wrong.

When editing, I will click 'Show preview' incrementally, many times, to make sure each change I make is correct. But it is very easy to click the adjacent 'Publish changes' button by mistake. Especially because 'Publish changes' is hi-lited in blue but 'Show preview' is white, visually tempting you in a moment of inattention to click the former when you didn't mean it.

Allowing all comers to commit, with a single click, a permanent write action on a Web site used by untold millions egregiously fails to err on the side of caution. A good user interface, let alone publishing to a world-wide audience, demands that on clicking 'Publish changes', you put up a box asking 'Are you sure you want your changes to go live? Yes / No,' with 'No' the default, hi-lited in blue.

It should obtain for all editing on Wikipedia—articles, Talk pages, this Village Pump page, all contexts.

I, for one, desperately want a safeguard against my own inattention.

Jimlue (talk) 03:53, 1 March 2021 (UTC)

@Jimlue: An extra step sounds annoying but I searched Wikipedia:User scripts/List and found "SafetyEdit for all pages" at Wikipedia:User scripts/List#Previewing and summary: "adds a check box for all pages during editing, which must be clicked before saving is enabled." PrimeHunter (talk) 10:24, 1 March 2021 (UTC)
Some thoughts:
  1. This is unlikely ever to occur for the 2010 wikitext editor. There are simply too many people who want to be able to edit now, and most of them are the power editors who care.
  2. Allowing all comers to commit, with a single click, a permanent write action on a Web site used by untold millions egregiously fails to err on the side of caution. is overblown. Bad actions are readily reversed. Good actions - well, why are you complaining? :)
  3. You should generally review WP:Be bold.
  4. Good news perhaps for you. The current 2017 wikitext editor requires you to go through preview at this time. Have a try.
--Izno (talk) 17:25, 1 March 2021 (UTC)
The power users probably wouldn't bring out the torches if it was an opt-out feature. PrimeHunter (talk) 20:35, 1 March 2021 (UTC)

Space at start of external link

I've been noticing lately that this works fine, but if I [ https://wikidark.org mistakenly put a space in before the URL], the link breaks. Is there a reason for allowing the space there? Possibly (talk) 04:54, 1 March 2021 (UTC)

@Possibly: it isn't "allowed there" it is just ignored - when you put in whitespace you don't trigger the link generator - the only reason you are then seeing the link is that a separate link generator is formatting your bare link. — xaosflux Talk 10:47, 1 March 2021 (UTC)

finding a MW page in search

I thought of looking for a phrase "Proton will be proxied" in this page https://www.mediawiki.org/wiki/Proton in order to find it on Search. although the page does not seem to be appearing..please advise..Gfigs (talk) 06:36, 1 March 2021 (UTC)

as per "Chromium" ,and suspected "Puppeteer"..Gfigs (talk) 06:58, 1 March 2021 (UTC)
@Gfigs: Selecting "MediaWiki" in searches means the MediaWiki namespace in the English Wikipedia. https://www.mediawiki.org/wiki/Proton is not a page in the MediaWiki namespace but a mainspace page at the MediaWiki wiki. You have to make searches at https://www.mediawiki.org to find pages there. PrimeHunter (talk) 10:10, 1 March 2021 (UTC)
@PrimeHunter:, ah, ok..thank you Gfigs (talk) 11:20, 1 March 2021 (UTC)

Gadget request

Would it be a good idea for commons:User:Jack who built the house/Convenient Discussions to become a gadget? The script is very useful and would help a lot of newcomers. Steve M (talk) 17:52, 1 March 2021 (UTC)

Pinging @Jack who built the house
Please see also the Wikipedia:Talk pages project and User:Enterprisey/reply-link. Whatamidoing (WMF) (talk) 05:17, 2 March 2021 (UTC)

Tech News: 2021-09


19:06, 1 March 2021 (UTC)

Page changes

I have a list of ~80,000 pages that I am fetching daily. Is there a way to find out which pages in my list have been edited in the last day, so that I can fetch only those? Sam at Megaputer (talk) 19:53, 1 March 2021 (UTC)

@Sam at Megaputer: how/why are you fetching these? There’s a way to do that with database queries - e.g. on Toolforge or Quarry. ƒirefly ( t · c ) 20:50, 1 March 2021 (UTC)
@Firefly:: I'm fetching the pages through the API so that they can be evaluated for promotional content as part of an anti-promo tool I've built. Right now the major limitation I am facing is the computing resources, so the more efficient I can make this thing the more pages we can defend. Can you link me to the documentation on those database queries? Sam at Megaputer (talk) 21:02, 1 March 2021 (UTC)
@Sam at Megaputer: so as a quick example this query pulls in all pages that have been touched in the past 24h (touched means edited, had protection level changed, had included templates changed, etc.). I’ve limited it to return only 1000 results for now, but obviously you could tweak it for your own use. Some documentation here about querying the replicas on Toolforge if it helps. ƒirefly ( t · c ) 21:25, 1 March 2021 (UTC)
Thanks! This should solve the problem. Sam at Megaputer (talk) 21:35, 1 March 2021 (UTC)
No worries - happy to help. ƒirefly ( t · c ) 21:38, 1 March 2021 (UTC)

Bordered image

Is it possible for an image to have a coloured border around it?--Launchballer 11:03, 2 March 2021 (UTC)

I'm assuming you mean purely when displayed somewhere, as opposed to being part of the image itself? Where is this needed & why? Thanks! ƒirefly ( t · c ) 11:40, 2 March 2021 (UTC)
 
I don't know whether image syntax can do it but you can display an image without a border and surround it with a border made in other ways. PrimeHunter (talk) 12:06, 2 March 2021 (UTC)
I'm trying to get Fantendo's Template:MenuSprite to have an optional border round it, which it now does; I was missing the word 'solid'. Using div forces the sprites on to several lines, so I've used span instead. However this does mean the boxes are running on to each other, but I can play around from here.--Launchballer 12:21, 2 March 2021 (UTC)
Wikipedia is not affiliated with Fandom. Please say when your post is about another wiki. Your code [13] has mismatched <span>...</div>. PrimeHunter (talk) 12:48, 2 March 2021 (UTC)

Proposals

RfC: What to do with category links to Commons?

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)

  • I'm not sure why this was bot-archived while still running, I've manually unarchived it. Thanks. Mike Peel (talk) 13:04, 31 December 2020 (UTC)
    belated @Mike Peel: It was archived at 02:40, 30 December 2020 (UTC) because there had been no posts since 18:17, 20 December 2020 (UTC), and the archiving settings (that's the {{User:MiszaBot/config}} at the top of this page) include the parameter |algo=old(9d), which means that any thread which has had no new posts for at least nine days is eligible for archiving. Archiving bots cannot tell if a discussion is running or not - they simply look at the most recent timestamp. --Redrose64 🌹 (talk) 20:11, 17 January 2021 (UTC)
  • Just to note that I've requested a closure for this at Wikipedia:Administrators' noticeboard/Requests for closure. Thanks. Mike Peel (talk) 12:59, 22 January 2021 (UTC)
    • Still pending someone to close this... Thanks. Mike Peel (talk) 11:34, 2 February 2021 (UTC)

Survey (Commons category links)

  • 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)[14] 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 (talkcontribs) 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
    • Weekly Oppose A1 indeed the links to the other wikimedia projects are from my point of view not visible enough for wikipedia readers in order to lead them to click on this link in the side menu.Robby (talk) 21:50, 19 December 2020 (UTC)
    • Strongly support A2 from my point of view this is at this moment the best solution. Robby (talk) 21:53, 19 December 2020 (UTC)
    • Strongly Oppose A3 indeed this will result in an endless workk by both bots and manual che3ck for categories deleted respectively moved on Commons.Robby (talk) 22:33, 19 December 2020 (UTC)
  • 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)
    • I've followed up on this comment at [15]. To be clear, claims of authority and admin access are irrelevant here. Thanks. Mike Peel (talk) 20:54, 10 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)

Convert all English variant notices to editnotices

This proposal arises from an ongoing discussion at the idea lab about how to reduce the clutter of excessive talk page banners, a phenomenon that leads to banner blindness, overwhelming and confusing new editors and reducing the visibility of the more important notices.

One idea I put out that seems to have gotten particular traction is that there is no need to have English variant notices (e.g. {{British English}}) appear on the talk page, rather than just as an editnotice that appears in the edit window while one is editing the article. The primary rationale is that no one is policing the English variety used on talk pages, so the only place this is needed is the editnotice. I'm therefore proposing here that we convert all existing English variant notices on talk pages to editnotices on the corresponding page. This would be done via a bot task, and once completed Module:English variant notice would be configured so that it produces an error notice if placed on an article talk page. {{u|Sdkb}}talk 14:34, 10 January 2021 (UTC)

Survey (English varieties)

  • Support as nominator. To address two potential concerns: (1) In the rare instance that there's a talk page discussion about changing the variant, it's easy for the proposer to provide the context. I can't think of any other situation in which people on the talk page need to pay attention to the variant. (2) Modifying editnotices currently requires advanced permissions; my understanding is that this is for technical reasons rather than because of any editorial consensus. This is an issue that ought to be addressed on its own at some point, but I don't think it's an insurmountable impediment here, as most pages developed enough to be tagged with a variant notice are monitored by editors able to modify it, and if not, they will be prompted to create an edit request, which is quite straightforward. {{u|Sdkb}}talk 14:34, 10 January 2021 (UTC)
  • Support This is a good idea and should be implemented, provided any technical issues are addressed eventually (new permission?). GenQuest "scribble" 15:34, 10 January 2021 (UTC)
  • Support there's a dual benefit as it simultaneously improves both the talk page (by reducing clutter) and the edit screen (by displaying relevant info), a win-win. --Paultalk❭ 16:55, 10 January 2021 (UTC)
  • Oppose The proposal seems half-baked because it doesn't address the use of templates like {{Use British English}} which are what I see most often. For talk pages, we could use something like an infobox which would contain key pieces of information about the article such as its size and quality rating. The dialect would fit best in such a summary of the article's properties. Andrew🐉(talk) 17:26, 10 January 2021 (UTC)
    Regarding the "use" templates, this wouldn't affect them one way or another; they'll continue being available for when it's desirable to designate a variant but there's not enough erroneous editing for there to be a need for a notice. We could discuss down the line how often to have something visible vs. invisible, but for now I think getting all the visible notices into editnotice format is the best first step.
    Regarding your idea for a hypothetical talk page infobox, I'd suggest proposing that at the broader idea lab discussion. I could support it if it's implemented well, but it's beyond the scope of the more narrow change I'm trying to achieve here. {{u|Sdkb}}talk 19:12, 10 January 2021 (UTC)
  • Excellent idea. I suspect if editnotices had existed when these templates started this problem would not have arisen. ϢereSpielChequers 18:50, 10 January 2021 (UTC)
  • Strong support if implemented, this would be huge for reducing talk page clutter, and actually making the english variety notices effective. As I said at the idea lab, the people who are disregarding or ignoring an established English variety aren't going to be on the talk page and see it there. As such, I'm convinced that the current position on the talk page is basically worthless. Aza24 (talk) 21:03, 10 January 2021 (UTC)
  • Support this seems like a way to make the information more effective and reduce talk-page clutter at the same time. Thryduulf (talk) 22:06, 10 January 2021 (UTC)
  • Support we do this for a few Canadian articles already...like Template:Editnotices/Page/Canada....still not seen in mobile view :-( --Moxy 🍁 01:06, 11 January 2021 (UTC)
  • Support great idea. One added benefit is that it reduces ownership of articles by preventing new users from posting useless engvar tags. Since only admins, template editors, and page movers can add these if we make them edit notices, it also gives template editors and page movers something to do. Wug·a·po·des 02:54, 11 January 2021 (UTC)
    • I also like the idea of removing them altogether. Wug·a·po·des 21:45, 13 January 2021 (UTC)
    • Template editors and page movers may not want something else to do. It seems simple enough to write a bot with the necessary permissions to do this. ChromaNebula (talk) 23:20, 26 January 2021 (UTC)
  • Support for all of this genre of notices (engvar, date formats etc.), but -- perhaps heretically -- I would support all top-of-the-page cleanup notices going into editnotices as well, so people who just want to consult an article for information aren't bothered with them. Beyond My Ken (talk) 03:17, 11 January 2021 (UTC)
    Beyond My Ken, by top-of-the-page cleanup notices are you referring to things like {{NPOV}} or {{Original research}}? I think those notices are pretty necessary from a reader perspective, since readers deserve to know when an article has significant problems so that they can read it with due caution and skepticism (yes, people should always be doing that, but they trust us enough they de facto often don't). That's more true for some notices than others, though; I could see a case for many of the yellow style ones like {{Cleanup bare URLs}} to be converted to be shown to editors only. The question at that point becomes whether we're wasting an opportunity to convert readers to editors by offering them an easy task. All this is tangential to the current discussion, so maybe take it elsewhere if you want to develop it further, but I hope my comment is food for thought. {{u|Sdkb}}talk 11:05, 11 January 2021 (UTC)
    No, you are correct, I was referring to the "yellow style" ones which primarily concern editors only. Beyond My Ken (talk) 21:26, 11 January 2021 (UTC)
    I would argue that a fair number of the yellow banners are useful to readers (eg Template:Overcoloured letting colourblind users know that they may not interpret something on the page correctly, or Template:Essay-like). Further, as I've been editing even the ones which non-editor readers may not find useful now inform how I read. For example, seeing Template:Debate wouldn't have changed how I read something in the past, but now it suggests to me that people may have POV forked, there may not be great usage of reviews/meta-analyses (in the case of scientific articles), or its editing may have been a series of unconnected additions. They're also useful for the purpose of editing - I will detour from doing other tasks to correct an article if I notice some kinds of banners, including when I wasn't intending to edit it. --Xurizuri (talk) 10:55, 12 January 2021 (UTC)
  • Support Great idea, this banner contributes to creep and I hope that this reduces needless conflict, as many well intentioned edits from new and IP editors are related to ENGVAR. --Tom (LT) (talk) 03:20, 11 January 2021 (UTC)
  • Support not useful on talk pages, useful when editing which shows on editnotice. No need for new permission, nor should editing editnotices be available to all, PMR & TPE can do this. If the TPER queue becomes too long, we can get a bot with TPE to carry over additions from the talk page into the editnotice. ProcrastinatingReader (talk) 09:21, 11 January 2021 (UTC)
    Striking in favour of using hidden templates such as {{Use British English}} on the article prose, as said by Whatamidoing, and removing all the editnotices and talk page banners and converting them into hidden templates such as {{Use British English}}. Alternatively, a {{article standards}} template, as described in the thread by Levivich. Arguments by Levivich & L235 are compelling imo. ProcrastinatingReader (talk) 15:15, 5 February 2021 (UTC)
  • Support per proposal ~ ToBeFree (talk) 11:09, 11 January 2021 (UTC)
  • Support – reducing talk page template bloat and helping new editors understand Engvar at the same time sounds like a clear win-win to me. AngryHarpytalk 12:47, 11 January 2021 (UTC)
  • I think I oppose for sympathetic reasons. 2 reasons: 1) I do not think this is technically feasible. It asks to make an edit notice for essentially 6 million pages. That's an awful lot of infrastructure. (Someone tell me I'm wrong.) 2) I do think the correct remedy is removing these in their entirety from talk pages. We do not need them present in both their canonical place as article tags as well as talk pages. (Replace as needed on the article proper.) --Izno (talk) 14:41, 11 January 2021 (UTC)
    • @Izno: I think it would be at most creating 41,000 edit notices with current use of the eng var module. --Paultalk❭ 18:36, 11 January 2021 (UTC)
      • Just a casual 41k. Eyeroll. --Izno (talk) 18:44, 11 January 2021 (UTC)
        • Trivial for a bot. Thryduulf (talk) 19:57, 11 January 2021 (UTC)
        • Trivial or not, a very different figure to 6 mil. --Paultalk❭ 21:14, 11 January 2021 (UTC)
          • Creation is "trivial for a bot". Maintenance and filtering through the noise in the template namespace looking for anything but edit notices? Yeah, not so much. --Izno (talk) 01:39, 12 January 2021 (UTC)
  • Support This seems like a good idea worth pursuing. --Jayron32 18:16, 11 January 2021 (UTC)
  • Support Reducing talk page clutter is a good idea. Remagoxer (talk) 20:51, 11 January 2021 (UTC)
  • Support. It'd be more useful as an edit notice - I know I never check first, and it's a pain to have to open the talk page in a new tab (especially as I have ADHD and sometimes forget the variant as soon as I close said tab). Ideally, similar notices about the style of writing in a given article would also be great to have as edit notices. However, a concern would be that by reducing talk page clutter, we need to not just relocate the clutter (sweeping it under the carpet, so to speak). --Xurizuri (talk) 10:55, 12 January 2021 (UTC)
  • Support, but what about protected pages? There might be an increase of (incorrect) ENVAR edit request, I guess you would also add a en-varent message on the talk page too? (please ping) DarthFlappy 18:53, 12 January 2021 (UTC)
    @DarthFlappy: I would expect that the vast majority of edit requests come from people trying to edit a protected page (that they don't meet the requirements of), clicking the button to request an edit and filling in the form. You might have noticed many are blank—this is because people don't read what's on their screen and just click the big blue "Submit" (maybe thinking that they're requesting permission for them to be given edit access). But anyway, I wouldn't think the talk page banner would really make a difference on edit request content. — Bilorv (talk) 23:49, 14 January 2021 (UTC)
  • Oppose Will only worsen banner blindness. CaptainEek Edits Ho Cap'n! 20:41, 12 January 2021 (UTC)
  • Support but not at scale, and only as a pilot. As I understand this could affect millions of articles, so please try it first as a pilot for 100s of articles. Big changes like this are best done with test cases, time passing, multiple requests for comment, and documentation. This already has my general support and also I anticipate supporting again in the future, but the proposal as it is has no limits. The scale and pace of the changes matters to me. I am only expecting volunteer-level documentation and not the best and most complete, and I encourage the pilot. I recognize the existence of the problem and feel that it will only grow. There are various possible solutions, and perhaps we have to use several solutions at once to address this issue. Please develop this one solution first. Blue Rasberry (talk) 20:51, 12 January 2021 (UTC)
  • Oppose editnotice banners are far more annoying than talk page notices. They slow down editing. Graeme Bartlett (talk) 22:18, 12 January 2021 (UTC)
  • Oppose — Enwiki has got to be the only publication in the world that writes a single work using multiple varieties of English. Engvar isn't important enough to have talk page banners for, I agree, but the solution is to remove them altogether. Moving them to the edit notice will create edit notice blindness instead of talk page banner blindness, and that's even worse, because in theory, edit notices have the really important stuff, even moreso than talk page headers. Creating thousands or millions of edit notices is a huge overhead and maintenance increase. Edit notices are annoying and largely ignored anyway. They don't show at all for mobile users. In all, I think this moves the problem to a worse place rather than alleviating it. Levivich harass/hound 04:53, 13 January 2021 (UTC)
    This is a fair point. I was thinking the notice should be trimmed down, literally into a bullet point like: “* This article uses British English.”. Alternatively, we can have a single “Article conventions” talk page template which is highly trimmed down and signifies standards like the variety of English used — this assumes that there are other types of standards other than English and date variety that could possibly apply. A bit like {{article standards|lang=British|dates=dmy}}. ProcrastinatingReader (talk) 09:16, 13 January 2021 (UTC)
    An article conventions template sounds like a very good idea. There are probably others besides engvar and usedmy, but those two are good examples. I would find iconography to be the most efficient way of communicating these sorts of things, but I'm not sure if everyone would be on board for that. So like a little British flag somewhere if it was use BrEng, a US flag for AmEng, something like that. Levivich harass/hound 17:27, 13 January 2021 (UTC)
    I agree that the notices should be kept unobtrusive and concise. Regarding the "just remove them entirely" point, we already have the e.g. {{Use British English}} family of templates, which set the standard without displaying anything, just as you describe. I'm undecided about whether/when we should use that compared to {{British English}}, but I think that, in circumstances where it is important enough to warrant a banner, that banner should be proximate to the place it actually applies, which means putting it in the edit notice next to the article rather than the talk banners next to the talk. {{u|Sdkb}}talk 00:06, 14 January 2021 (UTC)
  • Oppose We should save banners for the truly important stuff like BLP, rather than spelling. (t · c) buidhe 18:35, 13 January 2021 (UTC)
  • Oppose per Graeme Bartlett and CaptainEek. ~ HAL333 22:19, 13 January 2021 (UTC)
  • Support: seems like a no-brainer. Banner blindness on a talk page is already a massive issue, and ENGVAR isn't relevant to reading the talk page, it's relevant to editing the page, so it should be where it's relevant. Sceptre (talk) 23:33, 14 January 2021 (UTC)
  • Oppose: it's absolutely a reasonable proposal, but I'd prefer removal of these banners from the talk page instead. I just don't buy that language variant is important enough to warrant this kind of attention, and instead it will just cause reader blindness wherever it appears. I understand that it's very frustrating to be reverting the same good-faith spelling changes over and over again (I've lost count of the number of times I've had to revert "installment" back to "instalment" on the BritEng Black Mirror series of articles), but I've found that most unregistered editors will not see an editnotice, a wikicode template or a hidden comment in the middle of a word that keeps being changed (I don't know why the last doesn't work, but it doesn't), or possibly just willfully ignore them all. So I believe that this proposal, though it seems like the common sense logical position to move the template to, would just create blindness and have little-to-no effect on averting editing redundancies. — Bilorv (talk) 23:40, 14 January 2021 (UTC)
    @Bilorv: Your point about having to correct the same word over and over gives me a thought: what if we had an edit filter so that e.g. anyone trying to introduce "installment" to an article tagged with British English would get a big caution notice when they try to publish? {{u|Sdkb}}talk 01:58, 15 January 2021 (UTC)
    I think it is unreasonable for new/IP users to have no way of knowing this info before editing. Yes, they most likely won't read the notice, but "there's a notice that you ignored" is much better than "there's a policy hidden in our arcane (to new users) WP namespace that you don't even know about". And given that the varieties of English are largely identical, it's sometimes difficult to tell what variant the article is in; the notice is a nice reminder. - Novov T C 07:57, 15 January 2021 (UTC)
    To Sdkb, that's possibly something I could support, but I really don't like edit filters targeted at newbies because it's one more barrier to entry. If there was a way to say "literally the only changes in this edit are a bad spelling changes" then that would be ideal. I know that's asking a lot. To Mir Novov, many good faith edits I see by new/IP users that I have to revert are something I couldn't reasonably expect them to understand. There's been a discussion on the talk page? The lead doesn't mention this because of due weight? This source is unreliable even though it's a newspaper one million people read per day? It's wrong to call a section "Controversy" even though you've seen 1000 other articles with that bad heading? If anything it seems to me that "this article uses Australian English because it's about an Australian show" is so much easier to explain than most common mistakes made. — Bilorv (talk) 09:37, 15 January 2021 (UTC)
    Bilorv, in my idealized 2030 version of Wikipedia, the way that filter would work is that someone would go in and try to make a bad switch to another variant within an otherwise fine edit, and when they click publish, a notice would pop up saying "Hey, you switched 'instalment' to 'installment', which appears to go against the British English used for this article. Would you like to (a) publish, but keep British English? [works in one click], or (b) publish anyways?"
    Even with that, though, I agree with Novov that, for pages where switches are common (which is the group we're discussing here), it's better not to make someone do all the work before giving them the alert. And it's not just newcomers—I didn't know that "installment" was one of the words that differed until you mentioned it above, so I could easily see myself making that error. Whereas if there's an editnotice that (again, thinking futuristically) automatically detects that "instalment" is used a lot on that page and therefore includes it in the examples, that'll let me know not to touch anything. {{u|Sdkb}}talk 13:05, 15 January 2021 (UTC)
  • Support - This information is most useful for actually editing pages, not discussions. Logically, it should belong there, and such a relocation would be useful to the IP editors that have "corrected" spelling . Yes, some other info is on the talk page that should be read, but a lot of people don't read that, and wishful thinking won't make that fact go away. - Novov T C 07:57, 15 January 2021 (UTC)
  • Oppose. Instruction creep, overly intrusive and will just lead to more edit notice blindness. Neutralitytalk 19:43, 15 January 2021 (UTC)
  • Oppose per Neutrality. Personally, I dislike edit notices and more edit notices that would intrude on the editing interface is something that I would not want. Perhaps something similar to the Template:Use mdy dates template would be better. A whole host of edit notices on the national varities of English (sometimes where editnotices are already in place) would be worse than talk page banner blindness for content creators hoow would have to scroll past the edit notice every time they edit. Plus, the national varities of English really isn't that important and as such, this is why we should keep them on talk pages. P,TO 19104 (talk) (contribs) 23:08, 15 January 2021 (UTC)
  • Oppose per Graeme Bartlett and CaptainEek. Cavalryman (talk) 03:14, 16 January 2021 (UTC).
  • Oppose. Varieties of English are not important enough to warrant placement as an editnotice. Just try and notice what variety the article is using and emulate that; if you get it wrong, someone will help you fix it. In my view, the talk page banner exists only to attempt to avert edit wars over this stuff, with one side being able to point to the banner. The rest of the time it's not useful, whether on the talk page or as an editnotice. KevinL (aka L235 · t · c) 20:07, 18 January 2021 (UTC)
    • Further to this, there are some truly important editnotices (e.g. DS notices that create blockable offenses), and the more editnotices we add the more banner blindness we get. Talk page notices are already ignored; let's not consign editnotices to the same fate. KevinL (aka L235 · t · c) 20:09, 18 January 2021 (UTC)
    Whilst I see your argument, to be fair, the editnotice format already exists right now and is placed arbitrarily; admins/TE/PMRs will place it themselves or on request for other editors, also in line with the current documentation for these templates. The pages that only have a talk notice are usually arbitrary. ProcrastinatingReader (talk) 20:12, 18 January 2021 (UTC)
    • There's an editnotice already? That's awful. Let's delete it. KevinL (aka L235 · t · c) 20:22, 18 January 2021 (UTC)
      • Yeah, see doc of {{British English}}. It’s done using a parameter, but the idea is (I think) to use both. To clarify, my point isn’t that we should enshrine a pattern that may not make sense, but if we don’t want language editnotices we should remove them entirely rather than the arbitrary system currently.
        Personally I think either trim it down to literally a bullet point not a hefty notice, or create a {{article standards}} for talk pages. Each option has a different purposes of course: the former is intended to alert editors writing to tailor their language, the latter to help copyeditors ‘fix’ errors. Personally, I don’t know other varieties of English so I make my ‘errors’ and let someone else copyedit their fixes if they care, so possibly the latter is smarter. ProcrastinatingReader (talk) 20:26, 18 January 2021 (UTC)
        • The current editnotice should be terminated with prejudice. KevinL (aka L235 · t · c) 20:52, 18 January 2021 (UTC)
          • I think I have used that edit notice. But the idea is to only insert the notice if it really needs to be noticed, ie there is a chronic problem with numerous edits on the page. So in general it should not be added in my opinion. Graeme Bartlett (talk) 23:59, 18 January 2021 (UTC)
  • Oppose - editnotices should be reserved for important article- and page-specific instructions, and should be used as minimally as we can manage. Opening editnotices to general advisories about article styles will lead to clutter and significantly diminish the usefulness of editnotices for those article- and page-specific notices. See also this discussion from a couple years back about this exact thing which led to consensus that style notices shouldn't be used this way without evidence of disruption. In the same discussion, several users smarter than me also suggested that doing this would pollute the database with a few hundred thousand new pages and increase the loading time of articles, for no particularly important reason. Ivanvector's squirrel (trees/nuts) 01:04, 20 January 2021 (UTC)
    Furthermore, we still haven't solved the issue that editnotices aren't visible to mobile editors, so they're not well suited to editorial advisories anyway. Ivanvector's squirrel (trees/nuts) 01:06, 20 January 2021 (UTC)
  • Oppose as this proposal appears to ignore the fact that editnotices don’t show on mobile. SK2242 (talk) 06:41, 20 January 2021 (UTC)
    Neither do talk notices. Or, well, they're well hidden. ProcrastinatingReader (talk) 23:00, 21 January 2021 (UTC)
  • Weak oppose; how many times have you read on AN or ANI a reminder along the lines of, "Dear OP, did you miss the violently orange notice when you posted here?" If they miss that, do we really think that an editnotice will prevent page watchers from having to revert to the correct EngVar? Personally, i think that editnotices should be kept for the very most important things ~ things that if you cross or miss might end up with your privileges restricted. happy days, LindsayHello 14:10, 22 January 2021 (UTC)
  • Support but only if there's an option for logged-in editors to turn off the notifications. Lugnuts Fire Walk with Me 17:23, 22 January 2021 (UTC)
  • Oppose having more edit notices. In the visual editor and the 2017 wikitext editor, you have to click to get past the edit notices every single time you open that page to edit. Also, just as Ivanvector's squirrel says, you stop reading them when they're common. WT:MED has an edit notice that I've clicked past most days for the last several years, and I no longer know what it says. When we need to have notes about the language variant to use, please make them all "invisible" templates that carry the necessary information in the title, such as {{Use British English}}. WhatamIdoing (talk) 19:58, 22 January 2021 (UTC)
  • Support. As many others have said, very few editors will actually notice talk page banners, especially IPs and newbies. And failure to heed ENGVAR instructions has often led to disruptive, pointless edit wars. Of course, we need to be mindful of not accumulating so many edit notices that people will stop paying attention, but that's a separate discussion of how to condense the edit notices. ChromaNebula (talk) 23:20, 26 January 2021 (UTC)
  • Support: Even if people ignore the notice, it won't be worse than it is now. This is a great way to stop people from changing between English varieties unnecessarily. And, also, since more people are seeing the fact that "you can tag articles for types of English?", there'll be more people tagging, which, in turn, leads to more standardisation and organization. Opal|zukor(discuss) 22:10, 29 January 2021 (UTC)
  • Support, ideally with the notice stripped down to its bare essentials. Perhaps just   This article is written in American English, and this should not be changed without consensus. Learn more. I see using editnotices as an improvement in multiple ways. Talk pages become less cluttered. Newbies who don't know about our approach to English varieties are more likely to learn about it and avoid making unwanted changes. And more experienced users editing articles without strong national ties can quickly see how they should write without having to either check the talk page or scan the article for clues as to the preferred variety. the wub "?!" 23:35, 30 January 2021 (UTC)
  • Support - this seems like a good idea. Rollo August (talk) 17:32, 3 February 2021 (UTC)
  • Oppose per Levivich and L235. AVSmalnad77 talk 04:04, 5 February 2021 (UTC)
  • Oppose. Edit notices make it harder to edit. They should be reserved for important matters. Espresso Addict (talk) 07:54, 11 February 2021 (UTC)
  • Strongly oppose.: Instead, eliminate the editnotice versions. We do not need to browbeat editors, especially new ones, about style trivia every single time they edit the page. If someone gets it wrong, some gnome will fix it later, as with all other style quibbles. MoS is a guideline, not a policy, for a reason. No editor is required to follow it when adding new content; they're not permitted to disruptively and stubbornly change material to be noncompliant after they've been asked to stop doing it. Trying to effectively make following an MoS line-item mandatory to edit the page at all is an end-run around WP:EDITING policy, is WP:BITEy, is WP:CREEP of the highest order, and is also an end-run around nearly two decades of consensus that no style matters aside from some key points about article titling rise to policy level. While we're at it, also just get rid of the talk page banners for this. The "silent" templates like {{Use British English}} at the top of the actual article is entirely sufficient.  — SMcCandlish ¢ 😼  18:01, 13 February 2021 (UTC)
  • Weak support, this is one option to reduce current clutter. These templates already exist as edit-notices, so whether or not they should be needs to be a different discussion. Either way, as a talkpage tag or edit notice, they should be sharply reduced in prominence/space in line with similar comments above, first of all by removing flags/other images per the spirit of WP:FLAGCRUFT. Frankly these notices could be reduced to two words (eg. "British English", "American English") left somewhere consistent on the talkpage/edit notice. CMD (talk) 17:46, 14 February 2021 (UTC)
  • Oppose per SMcCandlish. Editnotices should be reserved for important instrctions/information only. --NSH001 (talk) 10:04, 20 February 2021 (UTC)
  • Oppose clutters the editnotice space with hundreds of thousands of pointless editnotices, while making sure editnotices need to be even flashier for users to read them. Ideally, we'd have a standardized location in the editor displaying the English variety - and editnotices are a hacky - and bad - way to somewhat emulate this. Elliot321 (talk | contribs) 01:45, 28 February 2021 (UTC)

Discussion

  • If this is adopted, how would it be implemented relative to existing editnotices that already incorporate English variety? That is, see Wikipedia:Featured articles/Editnotice templates for a list of all medical featured article editnotices, that already include English variety, incorporating a custom list of words from the article. (Not a techie, please spell this out in Dummy 101 detail.) SandyGeorgia (Talk) 16:46, 10 January 2021 (UTC)
    • In the cases where it's already in the edit notice, I think we'd just leave it there and only remove it from the talk page. --Paultalk❭ 17:07, 10 January 2021 (UTC)
      Yeah, for pages like Template:Editnotices/Page/Rotavirus, it already includes {{British English|form=editnotice}}, so the bot would just remove the talk page notice and not add a duplicate. For the rare page that has a custom language editnotice, like Template:Editnotices/Page/COVID-19 pandemic, that'd be a little trickier, but still doable; the bot could just skipping adding anything for editnotices that link to a page in Category:English dialects. {{u|Sdkb}}talk 19:55, 10 January 2021 (UTC)
  • Shifting banners from talk to the edit notice helps talk but makes it even more unlikely that people will read the edit notice. I would want to see a draft of exactly how this proposal would be implemented (create a million new edit notices? create one central edit notice with magic code to show the language variety?), and exactly how it would appear. Try editing Donald Trump to see what an edit notice can look like. Johnuniq (talk) 22:59, 10 January 2021 (UTC)
    • You're emphasis of how big of a change this will be is certainly valid, though I don't know if I agree that moving to an edit notice makes it even more unlikely that people will read the edit notice – even just the flag of the UK or US in the edit notice would do more than right now. The only alternative I can see to the current situation or the proposed solution above is to completely remove the english variety, which is a more or less impossible scenario. Aza24 (talk) 00:10, 11 January 2021 (UTC)
    • We make the editnotice form smaller? ProcrastinatingReader (talk) 09:25, 11 January 2021 (UTC)
      • I'm not sure how feasible this is in a technical sense, but if an editnotice template is about the formatting (eg date order), language variant, etc, then could those be smaller and all placed together right above the editor? It'd make it less obtrusive, while still being easy to locate all the relevant little pieces of information re writing conventions. Those could alternatively be in an expandable bar, like some of the category lists at the end of articles are. --Xurizuri (talk) 10:22, 12 January 2021 (UTC)
    @Johnuniq, I believe that this will involve creating tens of thousands of edit notices. WhatamIdoing (talk) 20:01, 22 January 2021 (UTC)
  • Many old time editors, most newer editors, and virtually all IPs never make it a habit to look at the talk page before editing an article page. English version notices on the talk page are worthless. GenQuest "scribble" 23:30, 10 January 2021 (UTC)
    • Completely agreed, and this proposal should address that appropriately I believe. The current placement of English variety templates are virtually invisible to the intended audience. Aza24 (talk) 00:10, 11 January 2021 (UTC)
      • As a newer editor, I have never intentionally checked before editing so that's at least some anecdotal evidence for your point. However, I'm not sure if this is a function of the notice on the talk page, but on the visual editor on some articles there's a little prompt right under the title (eg Education in Australia). I'm a big fan of those little prompts. --Xurizuri (talk) 10:22, 12 January 2021 (UTC)
  • The need for an administrator to intervene will force an non-administrator-editor who notices a a change to the English variety is clearly warranted to spend two edit sessions on the page. The first session would be to place a protected edit request. The second would be to actually change the variety. Jc3s5h (talk) 01:02, 11 January 2021 (UTC)
    • Given how infrequently a page's variety of English should be changed this sounds like a benefit to this proposal - ensuring that it only happens when there is a good reason to do so. Thryduulf (talk) 11:12, 11 January 2021 (UTC)
      • I would agree with this. Requiring two edits isn't unreasonable for something that defines how the entire article is written. --Xurizuri (talk) 10:22, 12 January 2021 (UTC)
  • I expect that the opposers on the basis of "we shouldn't have them in the first place" will actually do something about that and propose that we remove them all together (were this proposal not to pass) . Otherwise, you're wasting everyone's time. Aza24 (talk) 06:08, 13 January 2021 (UTC)
    Opposing a change from the second-best solution (talk page banners) to the third-best solution (edit notices) is not a waste of time, even if one doesn't propose the best solution (no banners). Making a proposal that doesn't have a reasonable chance of success is a waste of time. Oftentimes, "second-best" is status quo because it's the compromise. Levivich harass/hound 06:16, 13 January 2021 (UTC)
    You are mistaken if you believe this discussion cannot generate the consensus to remove these from talk pages without replacement. RFCs are not votes.
    Secondly, we are not wasting time regardless. We should prefer the best solution, however we get to it. It is a logical fallacy to argue that we also must do things consistent with our position, especially as this is a volunteer mission. (I have no problem being called a hypocrite if you like. :)
    Thirdly, this is maybe the least concerning thing on the wiki today. We don't need the polarism on your part. --Izno (talk) 22:09, 13 January 2021 (UTC)
    Izno, literally no where did I say anything like this discussion cannot generate the consensus to remove these from talk pages without replacement, and I certainly wasn't intentionally trying to generate "polarism"; the misrepresentations are not appreciated. I think I was pretty clear about what would be "wasting time" – a situation where people who oppose on the basis of "we shouldn't have them in the first place", the proposal fails, yet these opposers don't start some proposal to remove English variety banners. Because in a situation where a problem is brought up, consequently unresolved by the introduction of a bigger problem and neither end up being addressed is a waste of time. Aza24 (talk) 22:39, 13 January 2021 (UTC)
  • Obviously, the best solution would be a bot that automatically (and quietly) corrected spelling and usage to whatever variant was designated (assuming that a variant has been designated)... with an edit summary explaining what was done and why. Then editors could simply write, and not worry about whether they were writing in the designated variant. Blueboar (talk) 14:00, 15 January 2021 (UTC)
    @Blueboar: editors that are writing any new content shouldn't be overly concerned with this already - it is really about avoiding refactoring the existing text over and over again. — xaosflux Talk 11:45, 16 January 2021 (UTC)
  • At the very least, the banners should be reduced and have the flags or other images removed. English varieties don't always neatly follow political boundaries, and at any rate we have WP:FLAGCRUFT for such situations in articles and yet flags are spammed across talk pages. Removing them also helps reduce space and prominence for a template that is probably mostly seen when explicitly being looked for. CMD (talk) 16:47, 17 January 2021 (UTC)
    I agree that the banners should be trimmed down, but I think the flags are actually quite helpful as a visual shorthand, so they're an element I think we should keep. {{u|Sdkb}}talk 21:15, 14 February 2021 (UTC)
  • My main concern here is that editnotices only can be edited by page movers, template editors and admins. I get that a bot can do the initial move but how will we go about additions of these in the future? I don't mind if the consequence is that these notices become rarer, but in that case it should be a deliberate choice and not just an oversight. I also don't think it's a good use of time to significantly increase the number of trivial WP:TPERs with changes to engvar notices. --Trialpears (talk) 21:46, 11 February 2021 (UTC)
    Trialpears, as I mentioned a bit in my !vote, I see this as an underlying problem—there are lots of situations in which anyone autoconfirmed ought to be able to edit a page's editnotice but can't (not because of any editorial consensus, but just because of something about the back-end technical structure of editnotices). That's a problem that we should solve (and if this goes through, it might nudge us toward doing so), but I don't think we should handicap ourselves here and reject this because of it. To do that would both obscure the level of need to resolve the issue and give ourselves more work down the road once it is resolved. {{u|Sdkb}}talk 00:12, 13 February 2021 (UTC)
    I feel like that would in general be a good idea, but I still see some reasons for the protection. Vandalism at editnotices would likely not be detected most of the time and even if it was detected most editors would probably not be familiar how to solve it. Putting misinformation in them could be significantly worse. I would definitely support enabling it for extended confirmed users though. With regards to implementation the restriction is governed by MediaWiki:Titleblacklist which can easily switch it to requiring autoconfirmed. It should also be possible to use a editfilter instead which could implement an extended confirmed restriction instead. --Trialpears (talk) 21:26, 16 February 2021 (UTC)

Pending-changes protection of Today's featured article

The idea of automatically applying WP:Semiprotection to WP:Today's featured article (TFA) has been thrashed to death; see WP:PERENNIAL#Protecting Today's Featured Article on the Main Page. I think the most recent discussion was in July 2020, at WT:Today's featured article/Archive 14#Question about protection. The key argument (for me at any rate) is that the last thing we want to do is discourage new editors.

Nevertheless, any time an article with a hint of controversy is TFA, it turns up at WP:ANI. For some recent examples, see Wikipedia:Administrators' noticeboard/IncidentArchive1057#The Holocaust in Slovakia—TFA subject to ongoing vandalism (27 January 2021), Wikipedia:Administrators' noticeboard/IncidentArchive1057#Guadeloupe amazon—Today's TFA subject to ongoing vandalism (28 January 2021), Wikipedia:Administrators' noticeboard/IncidentArchive1057#Pyramid of Nyuserre —Today's TFA subject to persistent vandalism (30 January 2021) and WP:ANI#Hitler's prophecy—TFA undergoing ongoing vandalism (30 January 2021). They may also get posted at WP:AIV, which is less easy to search. I haven't seen reports of problems with WP:DYK articles.

During that last discussion, I suggested that TFA might be WP:Pending changes-protected for only so long as it is on the Main Page; and this idea seems to be new. IPs and unconfirmed editors would be able to post, even if their contributions didn't display immediately; and vandalism could be speedily dispatched where it belongs. A TFA's godaprents could be encouraged to help the regular pending changes patrollers. It would also solve the problem of working out when the vandalism occurred and who did it (a perennial problem with the small amount of vandalism I deal with - mostly involving links to DAB pages - which can be buried behind several recent good edits and require copy&paste from the last good version). It shouldn't be technically difficult to implement; it could be part of the script which adds articles to and removes them from the Main Page. Some other editors seem to like the idea, and it was suggested that I open a discussion here. (For the record - I'm in favour.) Narky Blert (talk) 10:36, 2 February 2021 (UTC)

I'll note that one of the primary reasons for rejections of auto semi on TFA in the past is giving the impression that Wikipedia isn't so free to edit by having our most visible page be uneditable to the majority of the audience of TFA. Pending changes protection avoids this by still allowing users to make the edit, even if there is a slight delay in publishing it live, so it would be a decent compromise between unfettered access and maximum accessibility for our most visible page, and avoiding wasting of the community's time and potential risk of bad content being put up for all to see. Regards, User:TheDragonFire300. (Contact me | Contributions). 11:01, 2 February 2021 (UTC)
As a further thought - the protection template text should be tailormade for TFA, and welcoming. Narky Blert (talk) 13:35, 2 February 2021 (UTC)
And another - WP:ANI#Pacific swift - Today's TFA receive high level of IP Vandalism (4 February 2021). Narky Blert (talk) 08:59, 5 February 2021 (UTC)
Another one, for which protection was declined - WP:ANI#Cheadle Hulme - Today's TFA receive high level of IP Vandalism (5 February 2021). Narky Blert (talk) 11:42, 7 February 2021 (UTC)
This is every edit made to Cheadle Hulme during its day at TFA. I see a grand total of two IP vandals, one of whom made two edits and one of whom made one, while every other IP edit is constructive. If any admin had protected it under those circumstances, then unless there's something I've missed they'd have been instantly hauled off to Arbcom for admin abuse. ‑ Iridescent 12:37, 7 February 2021 (UTC)
I am not an admin, and have no comment on whether any particular page should or should not have been protected. Nevertheless, I have felt it right to post here every relevant ANI post since I opened this discussion, no matter whether they help or harm my proposal. All evidence is important towards reaching a consensus. (I have not monitored WP:AIV or WP:RFPP, which would be much more difficult.) Narky Blert (talk) 20:10, 19 February 2021 (UTC)
Another one - WP:ANI#Apollo 14 - Today's TFA receive high level of IP vandalism and unsourced content (8 February 2021). Narky Blert (talk) 12:53, 9 February 2021 (UTC)
And another - WP:ANI#Bernard A. Maguire - Today's TFA suffered persistent vandalism (11 February 2021). Narky Blert (talk) 00:23, 12 February 2021 (UTC)
WP:ANI#Vandalism on TFA Grant Memorial coinage (12 February 2021). Narky Blert (talk) 05:42, 13 February 2021 (UTC)
Another - WP:ANI#Vandalism on Saturn (magazine) (14 February 2021). Narky Blert (talk) 07:30, 14 February 2021 (UTC)
Today's installment - WP:ANI#Vandalism on Silesian Wars (15 February 2021). When this one got reported to ANI, it had only a couple of hours left on the main page. Cluebot and something like six registered editors had already dealt with edits to it; add in the protecting admin, and that's a lot of work.
I spotted something I hadn't noticed before - User:TFA Protector Bot had stuck {{pp-move}} on the article on 26 January, with automatic expiry at midnight 15 February. Narky Blert (talk) 17:34, 16 February 2021 (UTC)
@Narky Blert: For several years now, it has been normal for all upcoming TFAs (which don't already have move protection) to be given a short-term move prot, set to expire the moment the article stops being TFA. Until November 2013 it was a manual process; since then it has been tasked to TFA Protector Bot, see the BRFA. This prot is usually applied some time in advance (I believe soon after the calendar slot has been approved), see the bot's log; and the use of {{pp-move}} is supplementary to that. --Redrose64 🌹 (talk) 22:33, 16 February 2021 (UTC)
I didn't know of that procedure (which was why I mentioned it), but it strikes me as an excellent one. Even a good-faith move of a reviewed and queued article would be disruptive, in the greater scheme of things. We don't want redirects on the main page.
Also - WP:ANI#Vandalism on Meteorological history of Hurricane Dorian (19 February 2021). Narky Blert (talk) 20:00, 19 February 2021 (UTC)
And another two - WP:ANI#Vandalism on SS Mauna Loa (19 February 2021) and WP:ANI#Multiple IPs adding porn or offensive image in supposedly TFA article (20 February 2021). On the second one, I count (among other reversions) seven WP:REVDELs while the article was on the main page. Narky Blert (talk) 00:53, 21 February 2021 (UTC)
Another - WP:ANI#Vandalism on Margaret (singer) (23 February 2021; also mentioned by Levivich, below), which illustrates a problem. An admin WP:SILVERLOCKed the page for 3 days (which IMO is too much in both duration and level); a non-admin closer thought that the problem should have been posted at WP:RFPP not ANI. Narky Blert (talk) 21:49, 24 February 2021 (UTC)
@Narky Blert: It was I who closed that thread; in that case, there was already a duplicate at WP:RFPP, so having an ANI thread seemed redundant. Regards, User:TheDragonFire300. (Contact me | Contributions). 04:57, 2 March 2021 (UTC)
PC is widely agreed not to work/be practical on highly edited pages. That's why no one suggests it, probably. --Izno (talk) 15:44, 2 February 2021 (UTC)
This is something that was proven during the PC backdoor attempt, by the Barack Obama and George W. Bush articles. The volume of edits was so high that the queue on those articles were perennially backlogged, and so it was and still is agreed that PC is not suitable for pages that would see high volumes of edits, something which would happen with TFA as a matter of course. —A little blue Bori v^_^v Takes a strong man to deny... 16:43, 2 February 2021 (UTC)
At least the TFAs as considered in this discussion. I have seen some fairly quiet TFAs of late. --Izno (talk) 17:17, 2 February 2021 (UTC)
Unfortunately I suspect the set of TFAs that would be suitably quiet for PC to work is almost identical to the set of TFAs where PC is not needed. Thryduulf (talk) 01:30, 3 February 2021 (UTC)
As a supporter of the proposal, and an active PCR, I don't think this would be insurmountable for most TFAs. I note that the two given examples are highly political topics, one of whom was at the time President of the United States and the other of whom had been less than a full term ago. Vaticidalprophet (talk) 06:04, 3 February 2021 (UTC)
I'm against preemptive protection of any kind, especially pending changes which makes more work for volunteers and is rarely useful. Wug·a·po·des 01:53, 3 February 2021 (UTC)
  • Support some sort of protection it's unacceptable to have editors (very predictably!) vandalizing articles like The Holocaust in Slovakia while they're on the main page. This diminishes our reputation much more than any protection would do. (t · c) buidhe 04:16, 3 February 2021 (UTC)
  • I should note that "highly active" is a fairly low boundary - PCR starts having real issues well before, say, editors would be frequently edit-conflicting. I'm also not sure how accurate a prediction of a TFA's likely edit rate we can do. Obviously we can predict the "very active" and "not likely to be edited much" buckets, but there'd be a large middle category that is tough to order. As such, I continue to believe PCR remains distinctly problematic for any TFA use that would actually warrant PCR. Nosebagbear (talk) 07:35, 3 February 2021 (UTC)
  • To be honest, I'm not totally against this. The utility of pending changes is different from semi-protection: the goal is not to reduce the workload for administrators and recent change patrollers (as others have correctly pointed out above, pending changes effectively does the opposite), but rather, to prevent the vandalism from being seen by readers and thus possibly bringing the project into disrepute. As a matter of fact, if my memory serves me right, for a brief period a few years ago, we actually did start preemptively putting PC protection on the TFA after an WP:AN discussion because of a particularly nasty LTA that would replace images on TFAs with extremely shocking ones. The traditional problems with PC on highly edited pages don't seem to be a big concern here because the protection would only last for one day, and most TFAs don't seem to be edited so frequently that large backlogs might become a problem. At the very least, I would probably support a trial period for this idea. Mz7 (talk) 07:53, 3 February 2021 (UTC)
    Thinking about this a little further, I think the relevant question would be how frequently vandalism remains undetected for longer than, say, a minute while on the TFA. Pending changes works best on articles where vandalism has a hard time getting reverted quickly, and now that I think about it, because the TFA already has a lot of eyes on it in general, it may be the case that most vandalism is already reverted within seconds, rendering the need for pending changes moot. Mz7 (talk) 08:02, 3 February 2021 (UTC)
So far as I can tell, TFA vandalism is rarely if ever reverted within seconds. I've heard averages around 10-15 minutes, which is enough to be problematic for those articles, especially with heavy or grotesque vandalism. Vaticidalprophet (talk) 11:39, 3 February 2021 (UTC)
Looking at the edit histories of the articles I mentioned in the opening paragraph (a very small statistical sample): if ClueBot spots it, within seconds; if a human, 1-40 minutes (median 8). Narky Blert (talk) 14:24, 3 February 2021 (UTC)
I think the relevant question would be how frequently vandalism remains undetected for longer than, say, a minute while on the TFA This is the crucial question for me. If our goal is to prevent disruption to the reader, we need to know how much vandalism is currently disrupting readers. I don't think a trial would change our ability to look at that, we just need someone to crunch the numbers from the page history. It could also be crossed with the day's page hits to estimate the number of readers who actually saw the vandalism, e.g., this vandalism was up for 5 minutes, so with a total of 60 thousand page views that day---5 thousand people probably saw this instead of the article. In my experience it's as you describe with the added eyes bringing faster reversions, but knowing the average and other statistics would be useful and quite possibly change my mind. If PC protection really is a substantial benefit, I'd be willing to support its use on TFA. It at least allows users without accounts to edit, and if we craft a nice message as Narky suggests, it could minimize the potential newbie biting. So my main concern in this case is usefulness because I've rarely seen PC solve more problems than it caused. Wug·a·po·des 20:13, 3 February 2021 (UTC)
(I guess the maths in your example isn't meant to be taken literally but 5 mins of 60,000 pageviews is about 209 views—5000 would be 60,000 per hour. A limitation of this approach is that vandalism lasts longer the less-viewed the page is, and the pageviews vary based on time zones in areas where most of our readers are from. But I think some API somewhere can give you hourly pageviews.) — Bilorv (talk) 20:43, 4 February 2021 (UTC)
  • Support pending changes protection as a trial: TFA is different from other highly-viewed pages in that there is very likely a highly active editor who is passionate about the article (the one who just promoted it to FA), and activity is limited to 24 hours (maybe the next few days as well, while it's still linked on the main page). I can't really speak for all such editors (I've only been that person once) but perhaps some would be able to look through all the changes at the very least after the dust has settled, and collect any of the changes which are productive. A counterargument is that TFAs are, well, featured articles, and so much less likely to have issues that new and unregistered users will be able to solve. But there are likely still small prose improvements that one might expect to be made in the TFA period. An alternative is maybe pre-emptively semi-protecting only some TFAs based on topic. — Bilorv (talk) 20:43, 4 February 2021 (UTC)
  • Support Few useful changes are made, vandalism is a serious problem not for the number of vandals but for the black eye we get for allowing it on the front page. Volume of changes we are talking about is not great. So this is an excellent use of PC. Hawkeye7 (discuss) 04:33, 5 February 2021 (UTC)
  • Support test, in my view, this is the ideal balance between preserving both the integrity of our "anyone can edit" mantra, and quality of our featured articles. I tend to agree with Hawkeye that "few useful changes are made"—to the point where the amount of vandalism or unhelpful edits vastly outnumbers the occasional random spelling fix (and any major edits/errors would better be discussed on the talk page anyways). But either way, this protection could address both the vandalism and occasionally helpful edits. Aza24 (talk) 09:07, 5 February 2021 (UTC)
    • Would just like to reaffirm my support; when my Portrait of a Musician went to TFA a couple of days ago, there's was a lot of vandalism, almost all of which could have been prevented by PC; the other proses fixes and edits were by users who would not have beee restricted by PC. A test is certainly worth it. Aza24 (talk) 23:37, 1 March 2021 (UTC)
  • (nom) I agree that any change should be on a trial basis.
My idea for the template text is along the lines of: "Welcome to Today's featured article. It is an unfortunate fact that these articles attract vandals. Therefore, changes by new editors are reviewed by experienced editors before they show up for everyone to see. This usually takes only a few minutes. If you are here to be part of the community whose goal is to improve Wikipedia - Thank you, and happy editing! You might find Help:Editing a useful beginners' guide. If you are here only to disrupt - Be off with you!" Narky Blert (talk) 18:04, 5 February 2021 (UTC)
  • Support Would prevent instant publication of toxic or copyrighted material on such highly visited articles. ~ HAL333 02:58, 6 February 2021 (UTC)
  • Upon notice I haven't explicitly said it here yet, support as one of the parties in the original conversation. Vaticidalprophet (talk) 13:53, 6 February 2021 (UTC)
  • Oppose. PC protection generates significant amount of work for minimal benefit, and doesn't work on pages with a high volume of editing; those pages which attract enough vandalism to make protection worthwhile, are also going to be those pages on which PC won't work. PC also comes with significant additional drawbacks in addition to the maintenance backlog it generates; there's no way to add a summary when rejecting an edit, so when disapproving a good-faith but inappropriate edit one can't explain why in the edit summary; for BLP issues PC has little impact since it doesn't affect what Google scrapes (they pick up the most recent revision even if it's been unapproved); to approve/disapprove changes to an article at FA level often requires specialist knowledge of the topic, which the handful of people who work the Special:PendingChanges queue are unlikely to have; the whole proposal appears to be predicated on the idea that every, or at least most, FAs are going to be on peoples' watchlists, which just isn't the case. ‑ Iridescent 08:00, 7 February 2021 (UTC)
(Interesting to see you here -- I was literally just wondering what you would think of the proposition.) For what it's worth, "there's no way to add a summary when rejecting an edit, so when disapproving a good-faith but inappropriate edit one can't explain why in the edit summary" is incorrect -- the edit summary box is...huh, PC queue is empty as we speak, so my plan to take a screenshot for "right here" will have to wait, but it's prominently placed complete with giant "ADD AN EDIT SUMMARY IF WHAT YOU'RE REVERTING ISN'T BLATANT VANDALISM" bold text. Vaticidalprophet (talk) 06:37, 8 February 2021 (UTC)
In lieu of screenshotting the edit summary box itself, here's a screenshot from my recent PCR contributions showing them. Vaticidalprophet (talk) 06:42, 8 February 2021 (UTC)
It's alarming as a standalone thing to learn that Google is scraping the most recent revision on PCP pages—albeit I understood it to have a bit of a delay for general vandalism reasons (possibly it's just that it takes a few minutes for Google to scrape the article again). However, this is Google's problem, not ours. I don't want them having a single say in any of our decisions in any way. They need to change to suit us, not the other way around. Other search engines are available. — Bilorv (talk) 00:56, 13 February 2021 (UTC)
In around 2014, I was told that Google scraped a well-known social website every 20 minutes. Our goal as volunteer moderators was to take down heavy commercial spam within that time. IDK if that's a typical number, but our leader tried and failed to get them to increase it to 30. Narky Blert (talk) 06:05, 13 February 2021 (UTC)
  • Support The only backlog this would generate in terms of PC is one page which would need to be checked regularly for the duration (and, well, PC isn't that large of a backlog, compared to some other places). And, well, while it might not stop everything, at least any vandalistic edit (which would need to be reverted anyway, PC or not) won't be prominently displayed to every person who gets there... RandomCanadian (talk / contribs) 01:21, 12 February 2021 (UTC)
  • Support as a pending-changes reviewer, I think the added workload would be minimal compared to the benefits. With the number of eyes on the page, good changes will be accepted quickly, while bad ones won't be prominently linked from the main page. Elliot321 (talk | contribs) 05:57, 14 February 2021 (UTC)
  • Support - This strikes me as a reasonable compromise that both allows IPs to edit TFAs and combats vandalism. Put another way, it's the least restrictive means of effectively protecting our most prominent articles. (Protecting one article a day certainly won't overwhelm PC, and the article will be widely watchlisted anyway.) Let's at least give this scheme a try: I think it would be effective. Extraordinary Writ (talk) 07:18, 14 February 2021 (UTC)
  • (nom) To repeat a point I made earlier, in case it might get lost. This idea has both carrot and stick. It would provide a means to speedily welcome new editors and to point them in the right directions. Experienced editors know where to look or to ask for help; newbies, by definition, don't. Narky Blert (talk) 07:50, 14 February 2021 (UTC)
  • Support. This is about balancing Wikipedia's positive reputation as the encyclopedia 'anyone can edit', agains the potential negative reputation for vandalism and inaccuracies being introduced and not being caught. I think pending-changes protection is an excellent compromise, allowing people to edit, but preventing stupid nonsense from showing up on our most prominent article of the day. ƒirefly ( t · c ) 14:02, 14 February 2021 (UTC)
    • Changing to strong oppose after learning that FlaggedRevs (i.e. the module behind pending changes) is effectively abandoned, with nobody on the MediaWiki dev team having responsibility for it, and that it has various odd bugs (phab:T275322, phab:T275017) that seemingly aren't getting resolved. The last thing we want is weird MediaWiki bugs on display on TFA. ƒirefly ( t · c ) 09:42, 2 March 2021 (UTC)
  • Support as trial. I agree with RandomCanadian, a short period of time having pending changes protection isn't going to create much of a backlog and with so many eyes on TFA already.
    I've been wondering though (which is also why I'm voting here, for the first time at Village Pump), where would one go to suggest an entirely-new protection type? Because what if, instead of putting pending changes on TFA, there was instead a "delayed changes" protection? It would basically be pending changes, but with automatic approval after some set amount of time. Set the time to something a bit longer than the average length it's taken for vandalism to be reverted, and I'd bet it would drastically reduce the workload on heavy-vandalism days without contributing to a pending changes backlog. This would be protection for just TFA (a case of a page with high visibility/traffic for a short period of time). But since this would need to be created and isn't a matter of assigning an existing protection, it's more of a future-implementation kind of suggestion. --Pinchme123 (talk) 01:27, 18 February 2021 (UTC)
    @Pinchme123: Feature requests should be submitted at Phabricator. --Redrose64 🌹 (talk) 14:26, 18 February 2021 (UTC)
@Redrose64: Thank you for pointing me to Phabricator, as I did not know about it beforehand. But my question isn't about "submitting" for a feature request, but suggesting one, to be discussed before requesting it. I see little point in requesting a brand-spankin' new feature without having a discussion about its merits, especially when feature requests appear to be made outside of WP (since Phabulator is merely an affiliated Wikimedia entity, and I had to create a new account just to see the feature request creation page). So where might I go to suggest the feature, for discussion? --Pinchme123 (talk) 16:16, 18 February 2021 (UTC)
  • Oppose, per Iridescent, and also because of the general principle of using TFA to highlight the "anyone can edit" principle. Editing with a delay is not the same thing as editing with an immediate impact, and using PC on such a prominent page would harm recruitment. --Yair rand (talk) 06:25, 18 February 2021 (UTC)
  • Comment. I'm in the knee-jerk oppose camp per Iridescent & Yair rand, but I can see the problem of adapting our processes as we evolve from "the encyclopedia that anyone can edit" to "the encyclopedia that anyone can edit". If we want to use the TFA for recruitment then the edit must be visible (almost) immediately; more than 30s would, I think, take away that little burst of joy that addicted me to editing here. I believe one of the major problems that Wikipedia faces as it matures is erosion of the editor base as it becomes harder and harder to get a foot in the door as a new editor. Is there any evidence that newbies take up editing via the TFA? I've seen multiple new editors converted via ITN, but rarely other sections of the main page. My DYKs have occasionally had substantive or typo-fixing edits by redlinks or IPs who are clearly interested in the topic, and I've even very occasionally had comments of thanks or opprobrium from IPs. Personally I hate pending changes and hardly ever accept significant revisions because it puts the onus on me to put my weight behind them, and I know others have the same problem. Is there some bot-mediated mechanism that could immediately auto-accept anything that looked good faith and not obviously problematic? Could Cluebot be set to run on every TFA edit immediately? Espresso Addict (talk) 12:19, 18 February 2021 (UTC)
  • Strongly support trying something after seeing today's TFA, Margaret (singer), be ceaselessly vandalized, spawning yet another ANI thread. I think the work combatting vandalism at TFAs is greater than the work involved in protecting the article, and the detriment from vandalism at TFAs is greater than the detriment of not allowing everyone to instantly edit it. I'm not sure if it's PC or semi or something else, but Something Must Be Done™. I'd support a trial of this or any type of protection. Or even a trial of both PC and semi, like an A/B test. What I strongly oppose is resigning ourselves to "well that's just how it is" and trying nothing. Strongly oppose trying nothing. Levivich harass/hound 22:44, 23 February 2021 (UTC)
  • Support As it's a featured article, the cost-benefit calculation here is very different than most. Newcomers vandalize many articles but also make good edits to make up for that. For featured articles, the likelihood of a newcomer making a good, constructive edit is greatly reduced (based on low potential for improvement of the article as a featured one), while the fact that it is on the front page means that the amount of vandalism increases substantially. Personally, I support pending changes protection on all featured articles because of the diminished benefit a newcomer editing them can bring. Plenty of featured articles have significantly declined in quality over time as for a pretty much completed article it is much more likely for any edit by newcomers to be unhelpful. I think people are overestimating that satisfaction people get to see their change immediately; as long as they are aware of the pending changes situation, what matters most is the fact that your work is published at all, not the exact time. Zoozaz1 talk 22:00, 24 February 2021 (UTC)
  • Support Most recent TFAs follow a pattern similar to Oryzomys gorgasi, the TFA on 26 February. There were 62 edits on that day. Of those, 27 (roughly 44%) were from IP addresses. With one exception that I saw, all were vandalism. The ‘legitimate’ edits were almost all from established users, and most of those edits involved repairing the damage caused by vandals. The 'anyone-can-edit' principle is, at least from my perspective, the means and should be subordinate to the end of creating an encyclopedia by drawing upon collective knowledge.Venicescapes (talk) 08:07, 28 February 2021 (UTC)
  • Support; generally works fine on dewiki on highly-viewed pages. All articles are PC-protected on dewiki, leading to a long backlog,(7500 pending changes) but this doesn't seem to be a concern when the protection is limited to 24 hours and done selectively on pages that are very likely to be reviewed. ~ ToBeFree (talk) 19:52, 1 March 2021 (UTC)
  • Support per proposal; yes anyone should be able to edit, which they will be in this proposal, but Wikipedia should not once again fall victim to being called the website with inaccuracies anyone can add. waddie96 ★ (talk) 20:44, 1 March 2021 (UTC)
  • Support I seem to remember suggesting this a few years ago in one of the periodic conversations about semi-protecting TFA. It would prevent vandalism from being shown live while still allowing IP editing. It can get complicated with many edits, but it's worth a trial at any rate. ~ ONUnicorn(Talk|Contribs)problem solving 20:57, 1 March 2021 (UTC)
  • I don't like protection much, and I loathe pending changes. But perhaps it is time to move away from TFA as our poster child for "anyone can edit" and look for other ways to draw new editors in (TFA really isn't the best place for editing tests). I'd prefer semi to PC, but I won't oppose the proposal. —Kusma (t·c) 21:25, 1 March 2021 (UTC)
  • Support. Prefer semi over PC. My first concern is with the reader, THEN the editor. Dennis Brown - 22:26, 1 March 2021 (UTC)
  • Support because it will best serve readers. TFA gets a lot of traffic, and it's a disservice to readers if they encounter the article while vandalism is visible. Schazjmd (talk) 22:34, 1 March 2021 (UTC)
  • Begrudging support I think PC is bad, broken, and not hardly useful. I think semi is superior in effectively all cases. However, since we have decided against semi protection for FA's for years, I will settle with PC. I think it is ludicrous that we don't want to use semi on FA's. We have become stuck in a rules trap. It is written that protection should only be used after disruption is happening, so we wait until we see disruption. But we now hew to the letter of the law, not the spirit! The spirit is to prevent disruption. Sure, for most articles, we can't know when disruption will occur. But featured articles get vandalized like clockwork. Suddenly showing a page to 10 million extra people a day (including our LTAs!) makes it almost certain to get vandalized. A little dash of WP:IAR would save a great deal of time and frustration. TLDR: semi-protection would be superior, but I will settle for PC. CaptainEek Edits Ho Cap'n! 22:55, 1 March 2021 (UTC)
  • Comment and Oppose. The ability to instant create edits lies at the heart of this project. And I think many editor's very first foray into Wikipedia is through attempts at a main edit. It's our welcome mat. Seeing your change live instantly provides a thrill and confirms to newcomers instantly that their suspicions of how things work ("anybody can edit") were valid. Yes, this includes lots of immature vandal edits. But those tends to be stupid things like profanity inserted very visibly. But even this helps prompt good new edits to try to fix that. In other words, the "wild west" nature of the front page is an important way to engage new users which we need. And even some of the vandals turn into good editors as they mature. Using PC makes your first edits boring and people tend not to stick around for boring things. Jason Quinn (talk) 02:22, 2 March 2021 (UTC)
  • Oppose using PC for TFA, but support just about any other form of protection (semi, extended confirmed, etc). IMO, Pending Changes is an abomination that shouldn't be used at all, on any article, ever. It increases the amount of work needlessly and makes editors responsible for someone else' edits. It is also extremely confusing and difficult to understand as a feature, which for prospective TFA use makes it unacceptable. TFA will be viewed and edited by many inexperienced editors. We should not confuse the hell out of them with a monstrosity like Pending Changes. Just semi-protect TFA instead. Nsk92 (talk) 02:47, 2 March 2021 (UTC)
  • Oppose. It looks as if the wind is blowing strongly in one direction on this one, but my take is that this seems like an overkill solution in search of a problem--which proposed problem I think is substantially minimal by the very nature of the context. If TFAs somewhat gain additional traffice from IPs and neophyte editors, they are also gain increased scrutiny from a broad chunk of the community over the same 24 hour period that they are up on the main page. Additionally, these articles tend to be slightly more robust and reflective of engaged editing than the average article. In short, I can't see that adding pending changes will make all that substantial a difference to protecting the article against erroneous, bad-faith, or otherwise problematic edits over the course of its day of featured status. Meanwhile, it seems absolutely certain to have an impact on what has traditionally been one of the Featured Article's perceived benefits: editor recruitment.
In fact, I would argue that having this process by which new editors are corralled into a different article each day (which article represents decent editorial standards) and that space becoming the first place in which they can appreciate the pleasure of contributing to the encyclopedia and enjoying the immediate feeling of seeing those changes go live, while simultaneously focusing community oversight on that article space in an organic fashion all sounds like precisely the balance we want to establish and why this is a "it's not broke, don't fix it" type of situation. Additionally, TFAs frequently benefit from the super-crowd-sourcing feature of the attention they get: the vast majority of even IP edits are beneficial, not deleterious, so why gum up the works by having a queue of (potentially overlapping) pending edits. And those queues don't always get addressed with alacrity: I'm a pending changes reviewer myself and have logged a fair amount of work in the area over recent years, and I can tell you that the queue being addressed is quite a variable thing with regard to both the subject matter of the article and the time of day. Lastly, this is just not the typical scenario (a n inherently problematic article) in which this form of protection is typically seen as most justified.
In short, and with respect to the proposers and supporters above, the cost-benefit analysis runs strongly counter to the proposal, as I see it. Snow let's rap 04:28, 2 March 2021 (UTC)
It's equally likely that a new editor attempting to edit a well established article (the TFA) will mess something up and get a notice or worse a stern scary looking warning on the their talk page. This also ignores that PC still allows the new editors to edit the article, while conveniently removing the incentive for at least some vandalism/LTAs. Ex. (had to dig for it a bit): TFA from May last year - the revdel'd edits are a well known LTA vandal (the same as for most of the articles on Wikipedia:Today's featured article/May 2020... - I know, this discussion is not a new idea); after the PC protection the LTA stopped, while still allowing other non-AC edits (a fair bit were common vandalism, some were good faith but misguided; but anyway PC does not create the same issues as semi-protecting would). While PC might not be effective on some articles, or maybe even on most, on the TFA it would probably be the best of both worlds: not showing vandalism to our readers, while still allowing new editors to intervene. Cheers, RandomCanadian (talk / contribs) 05:06, 2 March 2021 (UTC)

RFC: Should certain succession box content, be deleted

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)
    • All superlatives? What about tallest buildings and longest bridges? Those seem extremely useful succession boxes to me. Thryduulf (talk) 18:24, 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)

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 (talkcontribs) 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)

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)

  • No. --Izno (talk) 22:19, 9 February 2021 (UTC)
    • @Izno: care to elaborate? —El Millo (talk) 22:21, 9 February 2021 (UTC)
      • Consider the abuse possible with arbitrary titles. --Izno (talk) 22:23, 9 February 2021 (UTC)
      • Never mind abuse, consider how hard it would be to identify the correct title so you could do things like basic linking of the page. Yeah, no. --Izno (talk) 22:36, 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)
  • No basically per all the issues Izno already raised. — xaosflux Talk 00:10, 10 February 2021 (UTC)
  • I never knew C# isn’t at the correct title. That’s weird. If this proposal is approved, would this currently technically possible with a config change or something, or would code need to be written up? Anyway, it seems to me that ideally # should be supported as a character in normal titles, not using a display title hack. ProcrastinatingReader (talk) 00:16, 10 February 2021 (UTC)
    @ProcrastinatingReader: Well, to enable # as a legitimate page title without DISPLAYTITLE hacks, you would still have to treat it as a special case because # has a special meaning in URLs. davidwr/(talk)/(contribs) 00:27, 10 February 2021 (UTC)
    Yep. If a # was a supported character in titles, should Foo#Bar take you to the article "Foo#Bar" or the section "Bar" in article "Foo"? – SD0001 (talk) 14:04, 10 February 2021 (UTC)
    How do articles handle it? eg HC Zemgale/LUA? Or is / (ie subpages) not valid in article space? ProcrastinatingReader (talk) 18:48, 12 February 2021 (UTC)
    Subpaging is turned off in main space (see example Fate/stay night). --Izno (talk) 19:02, 12 February 2021 (UTC)
    This is technically possible as a config change (setting $wgRestrictDisplayTitle to false) * Pppery * it has begun... 00:37, 10 February 2021 (UTC)
  • Not arbitrary changes carte blanc, but I am open to allowing it on a case-by-case basis after a discussion similar to that of a controversial page-move discussion. I'm also open to allowing whole new classes of "DISPLAYTITLE" to be allowed e.g. "allow #", again, after an RfC for similar discussion for each proposed exception. This could be implemented by allowing DISPLAYTITLE when there is a 1-1 mapping from page titles to DISPLAYTITLE arguments in a "whitelist file" maintained by administrators. Of course, we are talking about a code change, and developer time isn't unlimited. I don't see this as a priority, but if developer- and tester-time is available, I'd favor it. davidwr/(talk)/(contribs) 00:24, 10 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)
  • Oppose It's too annoying and error-prone if the displayed name cannot be copy-pasted to a wikilink or the search box. It can also be confusing if you click a link in search results or somewhere else and come to a page with a different title. PrimeHunter (talk) 15:38, 10 February 2021 (UTC)
  • Oppose. When I worked for a music tech startup, one of our pains in the butt was artists like Ke$ha and NIИ. We were constantly special-casing things like this so people could find them in searches. Yes, it is annoying that typing "C#" into a wiki-search box gets you to C, so you have to hatnote you way over to C-sharp where you finally get to click on C# (programming language) which takes you to C Sharp (programming language) (actually, I think that last step might be a violation of MOS:DABPIPE). But, I think the alternative would be worse. -- RoySmith (talk) 15:50, 10 February 2021 (UTC)
  • oppose The characters that are allowed in the title are limited for good reasons as far as I can tell. Specifically, # already has a meaning in URLs and so would be a real problem for wiki links. — GhostInTheMachine talk to me 18:08, 10 February 2021 (UTC)
    This is not about allowing # in wikilinks, but allowing custom DISPLAYTITLE. Aasim (talk) 21:51, 10 February 2021 (UTC)
    I get that, but imagine the fun people will have trying to type a wiki link to a page that has a # character in the displayed title. Is a wiki link of A#B to a page called A#B or to a link called B in page A? Is the link to a page called A-something-else, but displayed as A#B? If the page title is displayed as A#B, what should the link be? — GhostInTheMachine talk to me 22:53, 10 February 2021 (UTC)
  • The issue with this is that we don't want title-spoofing abuse. Perhaps, in certain cases, we could have a system for displaying the "technical title" in a less prominent alongside the "display title"? --Yair rand (talk) 06:19, 18 February 2021 (UTC)
    We could take an approach like Wiktionary, and have an "Unsupported titles" page where we can have all the unsupported titles listed. Then the technical hatnote would be unnecessary and the links would become clearer. Aasim (talk) 02:49, 21 February 2021 (UTC)
    Please provide a link to that Wiktionary page. --Redrose64 🌹 (talk) 08:28, 21 February 2021 (UTC)
    What I mean is "unsupported titles" prefixpage and have subpages of it be unsupported titles. See wiktionary:Unsupported_titles/Number_sign for an example. For the page C#, we could have it be located at Unsupported titles/C-sharp and then have JavaScript change the title displayed to C#. Aasim (talk) 08:40, 21 February 2021 (UTC)
    There appears to be some JavaScript going on: on visiting the page, the title showed as "Unsupported titles/Number sign" briefly, which was then replaced by a single "#" character. --Redrose64 🌹 (talk) 09:00, 21 February 2021 (UTC)
    Yeah, it's wikt:MediaWiki:UnsupportedTitles.js, which has a central list of titles. Problem is, trying to link directly to the displayed titles will not work. --Yair rand (talk) 11:54, 2 March 2021 (UTC)
  • Support as there are many titles that should have square brackets [] but can't. # is also a problem. But perhaps this could be done with a mechanism to DISPLAYTITLE that enabled checking for abuse. An edit filter could check for mistakes if a standard is set for mapping to the name. Note that there other unicode characters that are similar in appearance to the forbidden ones. Graeme Bartlett (talk) 22:47, 24 February 2021 (UTC)
  • No per all the points raised by IznoSea Ane (talk) 21:46, 26 February 2021 (UTC).
  • Oppose unless the actual page title is also displayed prominently. —Kusma (t·c) 11:39, 2 March 2021 (UTC)

RFC: Citation Style 1 parameter naming convention

Should non-hyphenated parameters be fully removed from the CS1/2 family of templates? Primefac (talk) 02:14, 10 February 2021 (UTC)

Background (CS1)

In 2014 an RFC determined that all parameter names in Citation Style 1 templates should have an alias which is in lowercase that has separations with hyphens between English words, between (not within) acronyms, or between English words and acronyms. The documentation is to show this lowercase, hyphenated version as the one for "normal use". This meant, for example, that |access-date= would be shown as the preferred parameter while |accessdate= was shown as acceptable but discouraged from use. In the following years there have been various trends and discussions formally deprecating many of the non-hyphenated parameters, from a small handful (2019 example) to the current list which contains over 70 entries. Many of these are the non-hyphenated variants of the preferred/hyphenated versions, which are being removed to decrease the maintenance burden and increase the uniformity between templates (i.e. "ease of use"). Other changes have included having RefToolbar give the hyphenated params and setting AWB's genfixes to replace some parameters.

In October 2020, all non-hyphenated parameters were added to the "current list" linked above. In November 2020, a bot request was submitted ("Monkbot 18") to remove or replace these deprecated parameters so that they could be removed from the base module and simplify the template code further. While acknowledging that this task was largely cosmetic in nature, BAG and other venues (primarily templates for discussion) have historically sided with the idea of a "maintenance burden" as a valid reason for edits such as these; see for example Monkbot 17, which replaced (cosmetically) one parameter for a better-named value for ease of use.

The issue for Monkbot 18 arises from the number of edits it is/was required to make; a conservative estimate would put the number of edits it has made for this task over a two month period (Nov 2020-Jan 2021) at around 1 million edits; as discussed on the task's talk page, this has essentially removed all but five of the non-hyphenated parameters, but another 2-3 million edits taking up to four additional months will still be required to fully "clear out" these parameters. Additionally, those opposed to the bot also expressed concern that the relatively small-scale discussions to deprecate these parameters had not reached a wide enough audience to merit what they felt were sweeping changes.

Proposal (CS1)

There are three main options with regard to the CS1/2 family of templates, and by extension Monkbot 18's task.

  • Option A: Non-hyphenated parameters should be deprecated and removed; the bot is free to continue its work.
  • Option B ("status quo"): Non-hyphenated parameters are formally deprecated, but should not be immediately removed. Deprecation can be bundled into genfixes or performed along with other non-cosmetic changes, but (ignoring a possible Cosmetic Bot Day) should not be done on its own by a bot.
  • Option C: Non-hyphenated parameters should not be deprecated; deprecation should not be continued and bot approval should be revoked. This will also mean that the deprecated parameter list will need to be updated to remove the non-hyphenated parameters.

Please note that this discussion is primarily about the CS1/2 template parameters and whether two full sets of parameters should be kept/maintained. It is not the place to re-litigate the various discussions about Monkbot 18's task; Option B is provided for those who feel the task should not proceed.

Survey (CS1)

  • First choice A, second choice B. I'd be happy to see AWB's genfixes take on some of this burden, and I'd be happy to see this happen a little more slowly, but it should happen, even though it's occasionally inconvenient for me. Also, when any individual parameter reaches a sufficiently small state (e.g., potentially still thousands of uses, but not hundreds of thousands of articles), the template should be updated to disallow that particular parameter (not merely advise against it in the documentation), so that they won't keep creeping back in, because, hey, it still works, so why should I bother? WhatamIdoing (talk) 19:12, 10 February 2021 (UTC)
    @WhatamIdoing: AWB's genfixes already handles this through WP:AWB/RTP, so manual edits and other bots can help whittle down the list while making other (non-cosmetic) edits. GoingBatty (talk) 04:12, 11 February 2021 (UTC)
    GoingBatty, are you sure that |accessdate= will be replaced by |access-date= by editors using the current version of WP:AWB/RTP? I think it was removed. – Jonesey95 (talk) 04:33, 11 February 2021 (UTC)
    @Jonesey95: You're right! While the functionality exists (and other parameters are still replaced), editors have removed some hyphenation replacement rules. GoingBatty (talk) 04:59, 11 February 2021 (UTC)
  • Option A. I support completing the nearly finished move away from unhyphenated multi-word parameters. See below for more details about this process, which is being questioned now by a very few editors after seven years of work, and when it is more than 90% complete. With any other template, it would have been the work of a few days to standardize on one style of parameter name and convert all of the transclusions. The only reason that the process for CS1/CS2 templates is different is that there are millions of transclusions instead of hundreds. – Jonesey95 (talk) 04:33, 11 February 2021 (UTC)
  • Option C. This is pointless make work; see extended comment in discussion section. Espresso Addict (talk) 07:08, 11 February 2021 (UTC)
  • B going to C If it was only confined to a few thousand pages, it wouldn't be a big deal. But when it's upwards of 3 million pages, maybe it should be the other way round - IE no hyphen. Lots of pointless bot cloggage in going through millions of pages for a trivial change. Lugnuts Fire Walk with Me 08:20, 11 February 2021 (UTC)
  • B if not C As per comments above; many editors are clearly quite happy with the unhyphenated forms, so why not allow both? Changing is pointless. Lots of other templates allow aliases as parameter names. I fail to see the problem. But we are where we are, so I favour B rather than C. Peter coxhead (talk) 09:04, 11 February 2021 (UTC)
  • Option A (second choice B), per Jonesey95. Let's just get everything simplified, as it should be. Get on and finish the job. --NSH001 (talk) 10:18, 11 February 2021 (UTC)
  • Option C. It is a totally pointless exercise. The unhyphenated ones are better in my eyes as they do not wrap in the edit window and can be underlined as a typo so are clearly visible in the edit window. Keith D (talk) 13:01, 11 February 2021 (UTC)
  • C (first choice) or B (second choice). I've read many of the discussions about this issue and I've never yet seen anything the convinces me that deprecation actually benefits the encyclopaedia in any way. Even if we assume for the same of argument that it somehow does, the real and evident disruption caused by the bot so far and the extent of the changes the bot operator notes will be required to complete the task, very clearly and very significantly outweigh that benefit. Thryduulf (talk) 15:20, 11 February 2021 (UTC)
  • Option A this change is a bit painful, but better for editing in the long-run. It's better to make this change than to not make it. The best time would've been fifteen years ago - but the second-best is now. Allow the bot to continue its operation, get rid of all the parameters, and once all are removed, start generating cite errors. Elliot321 (talk | contribs) 17:09, 11 February 2021 (UTC)
  • Option A. Unfortunately, the visual editor exists... but isn't useful for large editing projects and thus many people still use wikitext editing - condensing to one form (specifically the hyphenated one as it is easier to read for editors) will help ensure consistency between articles at least in the CS1 templates. Obviously this won't make every article easier to edit as there are articles with non CS1 style citations, but it'll help the millions that do use CS1 look the same to editors instead of having a hodge-podge of hyphenated names. I further agree with the bot continuing to run now, and then running maybe once per week or so after this initial run to fix any CS1 non-hyphenated parameter names. -bɜ:ʳkənhɪmez (User/say hi!) 17:13, 11 February 2021 (UTC)
  • Option C. The point of templates and bots is that they should work to make editors' lives easier, not that editors should change the way they do things to make template and bot creators' lives easier. This bot has it completely topsy-turvy, and if the bot-approvals group has approved this then that is a problem with that group, not with a few unhyphenated parameters. I can't help feeling that that group is looking at the interests of a few bot operators rather than of the many more editors and still many more readers. There's no great complexity in having a few synonyms for template parameters, and there's no problem at all with exporting data - if the synonymic parameters point to the same place in code then they can be exported in the same format with no extra effort. I can't believe that forty years after I went into IT we still expect users to be slaves to the systems that are supposed to help them. Phil Bridger (talk) 18:21, 11 February 2021 (UTC)
    The point of templates and bots is that they should work to make editors' lives easier. Exactly so. That's what this bot is for. It makes the parameter names easier to read (taking them as a whole, not just access-date on its own), reduces the size of the template documentation, makes the parameter names all consistent. All these combine to make learning how to use the cite templates easier. It also makes maintaining the templates easier. a win-win situation. The only reason we're having this discussion is that Mediawiki's watchlist software is so bad at handling bot edits. Otherwise it would be a no-brainer. Some people here seem to be under the mistaken apprehension that this is just to advance the interests of "a few bot operators". Well, I'm quite sure Trappist (the operator of this bot) could do without the stress of planning, writing and running this bot. He does a bloody fantastic job, and deserves a huge amount of credit and appreciation for his work. I can't believe that forty years after I went into IT we still expect users to be slaves to the systems that are supposed to help them. The whole reason for this bot is to make users' life easier. FWIW, I also have experience of IT work more than 40 years ago (seconded for 2 years to work on a (very successful) project - mathematical programming on big data for a life insurance company) and frequently had to liaise with IT people since then. I'm well aware of the problems that can arise when you just allow systems to get more and more complex, so I appreciate Trappist's (and many other people's) efforts to simplify matters. --NSH001 (talk) 23:37, 11 February 2021 (UTC)
    Clarifying: Re-reading this again this morning, it might appear to readers who don't read carefully that I'm agreeing with Phil Bridger. Nothing could be further from the truth, I still support Option A. Option C makes no sense, for all the reasons set out by SMcCandlish. --NSH001 (talk) 08:35, 12 February 2021 (UTC)
    And Phil Bridger's hyperbole stance is fallacious. Option B imposes nothing on anyone. "I don't like option A" does not equate to "only option C can work". Option B is the status quo, and it has broken nothing. I'm rather shocked at how stark obvious this is, yet at least 10 editors don't seem to have noticed. I know that we have a lot of populism running around in the world – a lot of "I would feel very strongly about this, if it were true, and it feels good to pretend its true, so I'm going to pretend it's true" behavior. But that stuff needs to be left at the door.  — SMcCandlish ¢ 😼  04:21, 12 February 2021 (UTC)
    No, my stance is not hyperbole or due to populism. The reason I reject option B is the word "immediately". It still leaves current consensus that unhyphenated versions of parameters will be removed, just not immediately, and it is that consensus that should change, however many years it has been stable for. I am happy with simplifying the documentation, but not with removal of the option. Phil Bridger (talk) 09:19, 12 February 2021 (UTC)
    As noted above: Deprecation is not synonymous with disabling. You're confusing replacement of the parameters as written in a template transcluded in a page, with removal of the runtogether parameter variant's ability to function in the template. Only option A would do the latter. We have many, many templates that support variant-spelling parameters but do not "advertise" them in the documentation, and it breaks nothing whatsoever to bot-replace them with the canonical version, just as the same bot will replaces calls to a redirect name for the template with the actual page name of the template. I.e., you're having a strong negative reaction to an argument that option B is not actually making.  — SMcCandlish ¢ 😼  17:50, 13 February 2021 (UTC)
    Option B very clearly says "but should not be immediately removed". Either the word "immediately" has some meaning, and this option would lead to removal, but just not immediately, or it has no meaning and has no business being there. Phil Bridger (talk) 18:10, 13 February 2021 (UTC)
    SMcCandlish, this was explained in the previous discussion at CS1: ""Deprecation", by the definition used in the context of CS1/CS2, means that if the parameter is used, a red maintenance message will be shown and it will appear in a tracking category. It is a phase before removal of support for a parameter (in which case only an "unsupported parameter" message and optionally a hint on the new parameter will be shown). It is possible to stay in this state for extended periods of time, but the idea is that eventually the functionality will go". So the intention is to error and then remove the functionality of these parameters, not simply not advertise them in the documentation. If you want to propose a variant of option C that removes the parameters from the documentation but still allows them to function, go ahead, but option B is not that. Nikkimaria (talk) 20:09, 13 February 2021 (UTC)
    What I want to propose is a variant of Option B that removes the parameters from the documentation before letting some bot go around changing the articles on my watchlist as if the parameters are somehow bad. If the params are really bad, and if there's a consensus to that effect, then Step One is to take them out of the documentation (either by dragging them away in the dark of night, silently, like ninjas, or by transparently mentioning them as being deprecated, so everybody knows what's going on). The first phase of real deprecation is telling people to stop using something. Then you can start throwing up red messages and it's not so damned rude or surprising. — JohnFromPinckney (talk) 21:40, 13 February 2021 (UTC)
    Sure, I would support that variant, too. Or a variant that kept mention of those versions of the parameters but deprecated them. Whatever gets us closer to having consistency in the actual deployed templates being used in citations.  — SMcCandlish ¢ 😼  04:15, 14 February 2021 (UTC)
    This stuff should be in a tracking category, if that's what bots and other tools are going to work with. If we don't like the error messages, then we can disable them. This is just template and module code, it's not etched forver into a mountain face like Mt. Rushmore.  — SMcCandlish ¢ 😼  04:15, 14 February 2021 (UTC)
  • Option C I agree strongly with Phil Bridger here. In other words, I fail to see what exactly is accomplished by making millions of cosmetic edits and then deliberately breaking things that would otherwise have worked. * Pppery * it has begun... 20:21, 11 February 2021 (UTC)
    Option B breaks nothing. You, et al., are providing an argument against option A, not an actual argument for C, and just ignoring B. Also, a !vote for C is an !vote for overturning a status quo that has been stable for years, in favor of chaos, yet without an actual rationale to do so. The closer should take that into account, per WP:NOTAVOTE. In the event of a "no consensus" result we still end up with the status quo. Things like this are why I keep telling people they need to write RfCs better. "Anything that can be misinterpreted will be."  — SMcCandlish ¢ 😼  04:21, 12 February 2021 (UTC)
    SMcCandlish, option B supports disabling of the non-hyphenated parameters - that is a breaking change. The difference between A and B is speed, not outcome. Your !vote below suggests you want the non-hyphenated variants to remain supported, but of the options provided only option C accomplishes that. Nikkimaria (talk) 16:18, 13 February 2021 (UTC)
    Nope. See my response to same claim by Phil Bridger, above.  — SMcCandlish ¢ 😼  17:50, 13 February 2021 (UTC)
    Yep - see above. You can also look at what has happened with previously deprecated CS1 parameters such as |authorfirst= - they don't work. Nikkimaria (talk) 20:09, 13 February 2021 (UTC)
    Which is perfectly fine, given enough time that people stop actually using them. Thus remove them from the template documentation and replace them in deployed template translcusions. Eventually the "monkey see, monkey do" effect of being exposed to deprecated parameter variants goes away, through decreased and eventually zero exposure. I'm mean, come on, that's what the point of deprecation is. It seems to me that you [plural] are coming from a "give me C or give me death" perspective, artificially conflating A and B because you just will not tolerate the idea of any parameter name variants ever going away for any reason. If I'm wrong about that perception, then please explain.  — SMcCandlish ¢ 😼  04:18, 14 February 2021 (UTC)
  • Option C per Phil Bridger. Ealdgyth (talk) 21:28, 11 February 2021 (UTC)
  • Option C - Commenting here probably falls under my doctors' lists of "things HF shouldn't do while he has a concussion", but I don't want to miss this discussion. While I understand that maintaining the citation templates is not a particularly easy job, in the end, rigidness in the citation template is not desirable. The citation templates should be easy to use, and having a couple aliases for the most common parameters makes it easier to use. And a trout to the bot guild for approving a bot task that was designed to deprecate template parameters with no consensus for that deprecation. Hog Farm Talk 22:15, 11 February 2021 (UTC)
  • First choice A, second choice B. Wikipedia source text is becoming increasingly complex and difficult to manage making it less accessible, except for the type of experienced editors participating here. Anything we can do to reduce complexity is a win, fewer options the better when plainly redundant. -- GreenC 22:41, 11 February 2021 (UTC)
  • Option C per Phil Bridger, personally I prefer non-hyphenated parameters, and I find deprecating them to be an absolutely pointless exercise that breaks things for absolutely no reason other than to satisfy the cosmetic preferences of a few editors. Devonian Wombat (talk) 00:14, 12 February 2021 (UTC)
  • Option C. Largely per Hog Farm. Keeping extremely commonly used aliases is helpful for editors using these templates. Nikkimaria (talk) 01:17, 12 February 2021 (UTC)
  • Support option C, neutral on option B, strongly oppose option A. My fingers are used to typing many of these parameter names without hyphens. Deprecating them and the accompanying gnomework of replacing them with the un-deprecated versions is already causing me significant hassle, both in trying to remember that really now they should be hyphenated, and in trying to pick out the important changes on my watchlist among all the pointless gnomery. Removing the unhyphenated forms altogether would be worse. —David Eppstein (talk) 01:41, 12 February 2021 (UTC)
  • Option C. I'm with Phil Bridger and Hog Farm. I don't know if this is bike shedding or yak shaving, but it's just not productive and a bad look. Alternatives exist because it's simpler than remembering which of two common possibilities are acceptable, rather than forcing one or the other (as the other options do). Discussing efficiency because of a off-row character on the other hand (oh, so we're making this choice based on everyone using QWERTY?) is the kind of ignore-practical-facts reasoning that yield platypus-shaped end results. -- Mikeblas (talk) 01:52, 12 February 2021 (UTC)
  • A is better in the long run, but B for now, and have the conversion covered by AWB genfixes and similar. Headbomb {t · c · p · b} 02:29, 12 February 2021 (UTC)
  • Option C per Phil Bridger. SarahSV (talk) 02:51, 12 February 2021 (UTC)
  • Option C. This "everything must be hyphenated" approach doesn't work well with the text editor. For some common parameters like |accessdate=, it is simply better being unhyphenated because the source text is quicker and easier for a human to parse because the parameter doesn't word wrap in the editor's textbox. Jason Quinn (talk) 03:09, 12 February 2021 (UTC)
  • Option B. We should stop listing the nonhyphenated ones in the documentation at very least, so that between editorial shift and AWB/bot genfixes cleanup, we get more consistent over time. It's too soon for option A, if ever, because the templates serve us, we don't serve the templates. It's perfectly fine for templates to quietly support non-hyphenated variants so they don't just break if people try them. But we should not continue listing those variants in the docs. It's antithetical to the purpose of templating, for us to perpetuate inconsistency (without good reason, like an ENGVAR color vs. colour distinction). And it pointlessly makes the documentation longer and more complex for no gain at all; no one looking for how to specify the Archive.org URL needs to know anything but |archive-date=, and telling them |archivedate= also works is just stuffing pointless trivia into their head. Yes, do continue converting to hyphenated versions in genfixes and other automated edits (when doing something more substantive at the same time). Finally, option C is rather pointless. We've regularly been (gradually) deprecating various old parameter names, and it has worked just fine. Option B will not break anything, and will have (already is having) positive results.  — SMcCandlish ¢ 😼  04:21, 12 February 2021 (UTC)
  • Option B Option C. These are all valid aliases, as there is zero confusion between say |access-date= and |accessdate=. The status quo works fine: hyphenated is preferred because it's easier to read, but unhyphenated is acceptable because there is no ambiguity and evidently plenty of people type it that way. Cosmetic changes should adhere to policy. – Finnusertop (talkcontribs) 05:53, 12 February 2021 (UTC) Changed from B to C as I am opposed to the implications of the "formally deprecated" part of these valid aliases. – Finnusertop (talkcontribs) 09:26, 12 February 2021 (UTC)
  • Option C first choice (B second). Editors should be allowed to use either hyphenated or non-hyphenated versions. Consistency is not better than flexibility here: the only people reading the parameter are editors, so let the editors decide whether or not they want to use a hyphen in their template parameters. I share the general concern about the disconnect between code writers and content writers, and the frustration with some template and bot maintainers imposing decisions on everyone without consensus. Fait accompli editing across millions of edits or transclusions is kind of a big deal. Levivich harass/hound 07:20, 12 February 2021 (UTC)
  • I Like C: I especially echo Levivich, Thryduulf|, and Phil Bridger's comments regarding these perennial, periodic, new surprises where editing articles is concerned. That is disruptive and we should just stop it. C, therefore, will bring the sanity back. GenQuest "scribble" 07:42, 12 February 2021 (UTC)
  • Option C. These are templates for use by editors, they have no impact on readers, and it's a complete waste of time making rules and regulations about them and then writing bots to enforce those pointless rules. Not to mention that when AWB goes through "fixing" all these in an article, it can drown out the genuine edits and make it harder for people to track what's going on. Get rid of this ridiculous rule, delete it from AWB, and then maybe we can get on with actually building an encyclopedia.  — Amakuru (talk) 09:13, 12 February 2021 (UTC)
  • Option C (which is the status quo ante). I just don't see what problem people are trying to fix, so follow WP:NBDF. The hyphenated parameters are useful and improve wikitext legibility, I personally prefer them, but allowing both forms makes things easier for editors. Deprecating them appears pointless, and removing them entirely seems actively harmful. It's created millions of pointless busywork edits clogging up watchlists for no good reason. We don't have a problem with template aliases, so why the concern about parameter aliases? None has been convincingly articulated. Modest Genius talk 12:10, 12 February 2021 (UTC)
  • Since I have been pinged, neutral all round. I'm have nostalgia for the status quo for some reasons already presented (muscle memory, line breaks), but I recognize that once we pass through the valley of the shadow and emerge into the bright uplands yonder of a cleaner implementation, we'll have forgotten the pain. Mind you, I'll probably be 90 years old and beyond caring. But I have some implementation concerns in the Discussion. David Brooks (talk) 16:54, 12 February 2021 (UTC)
  • Option C - Standardization of this sort may be useful to researchers or developers, but not to regular users. Adding citations should be as easy as possible. To that end, I want to minimize the chances that the interface will not know what I'm trying to do, or that I'll get an error because I entered an underscore instead of a hyphen. The rest of the internet is trying to increase flexibility to make user experience easy and intuitive. We do that too in many ways. But here we seem to be doing the opposite: removing flexibility and requiring users to know how we've worded/arranged things.
    I don't care if there's a bot that goes in an standardizes them afterwards or if someone runs AWB behind me. Again, I get the appeal of standardization. We should just be doing everything we can to make the experience intuitive for regular users. — Rhododendrites talk \\ 23:04, 12 February 2021 (UTC)
    • Alternative: Option D - let the bot and/or AWB standardize, but never disable the parameters. Standardization is good; degrading usability is bad. — Rhododendrites talk \\ 23:12, 12 February 2021 (UTC)
      I would certainly support your option D if it was on the table, but cannot support anything that says that this functionality should be removed, as option B (despite the illiterate claims above that it doesn't) clearly mandates. Phil Bridger (talk) 18:10, 13 February 2021 (UTC)
  • Option A with B as my second choice. Maintaining our complex citation templates is not an easy task, and if the people who are putting in the work want to do this to make their jobs easier, I'm in favor of it. Legoktm (talk) 23:48, 12 February 2021 (UTC)
  • Option C with Option B as second choice: Modest Genius makes an excellent comment, as do several others. The community needs to stop wasting its time on this citation formatting nonsense and do the hard labor of introducing citations in articles instead, the place we actually have a front-facing desperate crisis which damages our reputation. I use |accessdate= and I have no intention to stop. I remember very clearly the process I went through of learning citation templates in 2014—they were confusing at first but I never had a single confusion in parsing "accessdate" as the two word phrase "access date", very clearly meaning the date you last accessed a reference. I can see that in theory this would be marginally better for new users, and I can see that in practice some people who don't like the look of "accessdate" are escalating it ("my opinion" becomes "the correct view" becomes "a moral imperative to enforce"), but this just doesn't outweigh the actual genuine pain it will cause editors like me to retrain a years-long developed muscle memory; almost every mainspace edit I make for months will have a disrupted flow (interrupts my thought process, wastes my time re-typing) if this is to change.
    As for the bot that has been wasting several minutes of my time per day, I strongly opposed it in the first place and have had more than enough of it. (No, I can't ignore it, because if I turn bot edits off I will miss acts of vandalism, unconstructive changes or cleanup tagging that are hidden by a subsequent bot edit.) BRFAs need wider advertisement when their scope is so enormous and their violation of WP:COSMETICBOT so overt. I don't accept that option B reflects past consensus in practice in that I can't remember anyone ever approaching me about my use of |accessdate= or changing it to |access-date= manually. Past local consensus among technical groups who don't work in article space, sure. But enwiki community consensus? No. — Bilorv (talk) 01:07, 13 February 2021 (UTC)
    • @Bilorv: if I turn bot edits off I will miss acts of vandalism, unconstructive changes or cleanup tagging that are hidden by a subsequent bot edit -- this always takes me aback. Just curious, but why not enable the "Expand watchlist to show all changes, not just the most recent" + "Group changes by page in recent changes and watchlist" settings? I see no bot edits, and they don't cover anything up. — Rhododendrites talk \\ 02:50, 13 February 2021 (UTC)
      • @Rhododendrites: appreciate the suggestion! It's never occurred to me that combining those would produce that functionality (there are so many complex combinations of Watchlist filters and Preferences options), but I've enabled those two and kept "Latest revision" on and enabled "Human (not bot)" as the Preference option "Hide bot edits from the watchlist" didn't seem to do that and now I think (small sample size in my watchlist atm) I see the latest change only, including if it's a bot, but only if at least one non-bot edit has been made (which is exactly desirable). — Bilorv (talk) 11:34, 13 February 2021 (UTC)
  • Option A with B as my second choice. Maintaining the complex citation templates is not an easy task. AManWithNoPlan (talk) 02:52, 13 February 2021 (UTC)
  • Option A on the basis that standardization is good. I don't actually care whether the hyphens are there or not, but it's better one way or the other rather than having a mix. In general I'd rather see us migrate away from using wikitext for reference information, though, it's like doing your finances in a text document. Thanks. Mike Peel (talk) 18:26, 13 February 2021 (UTC)
  • Option A I have always preferred the hyphenated form personally because it allowed the spell checker to verify that there was no typo, whereas the unhyphenated form is always flagged as a typo, although the preview now informs me of errors. I disagree with the contention that humans can parse |accessdate= more quickly than |access-date=; spaces were invented for this reason. I also know the overhead that permitting multiple parameters that mean the same thing in templates entails. I'm aware that this has been cluttering my watchlist with Monkbot edits, but my !vote is to continue. Hawkeye7 (discuss) 22:12, 13 February 2021 (UTC)
    Note that this is mostly an WP:ILIKEIT rationale and dismisses the views of those who indicate that they can parse "accessdate" without issue as wrong without any evidence. It also dismisses the very real disruption caused to others as necessary to reduce overheads, whereas this overhead, even if it is a significant as some claim (for which no convincing evidence has ever been presented) it's still trivial compared to the disruption caused by Monkbot's edits and by the unnecessary disruption to editors using the templates. Thryduulf (talk) 15:29, 14 February 2021 (UTC)
  • B or C. I've no strong preference between accessdate or access-date, both seem useable, if one is formally preferred then fine. However, the massive ongoing bot spam for something that has literally no effect on readers, and barely any on editors, is unwarranted. In addition to being everywhere on the watchlist, Monkbot makes it much harder to disentangle various series of diffs in the edit history for little benefit. A user making an edit inserting "accessdate" isn't an egregious issue that should cause a bot to come running, and such a bot action then obscures the edit in question from watchlists. CMD (talk) 18:18, 14 February 2021 (UTC)
  • Option C. Removing a common way to type parameters in templates reduces ease of use for the end users. Having a bot going around and "fixing" these has a negative impact on the readability of page history and watchlists . No one in this conversation has demonstrated that the maintenance burden on the template is so significant that it would justify all of these downsides. It also seems that the maintenance burden is not something that would be difficult to track like accidental blue links to primary topic articles when non-primary topic articles were intended, since the template code are on the template pages.---- Patar knight - chat/contributions 18:53, 14 February 2021 (UTC)
  • Option C. The previous discussions linked above (a six-year-old RFC with seven people participating in it, which specifically promised that nothing would be depreciated, followed by a handwavy argument about maintenance burden), are not remotely sufficient to justify such a sweeping change. Yes, maintenance burden is a pain, but it affects a relatively small handful of bot authors; removing the most widely-used version of a template parameter affects a huge swath of editors, who need to be given deference here on account of being a larger group. And obviously there is not a standing consensus that maintenance burden justifies such changes (at least not one on a scale necessary to justify this), or this discussion wouldn't be so clearly split. Therefore, the unhyphenated version should never have been depreciated, which makes the bot's edits pointless clutter at best and an attempt to push through a controversial change without sufficient consensus via fiat accompli at worst. Furthermore, if maintenance burden is the only concern, obviously the solution is to reverse the 2016 RFC (which, again, had only seven people participating it and agreed merely to create the hyphenated versions as alternatives) and remove the hyphenated version, which currently sees little use and would therefore be far easier and less disruptive to discard. --Aquillion (talk) 22:12, 15 February 2021 (UTC)
  • Option B-ish. I think it's reasonable to have the hyphenated forms be the canonical version of the parameter, but I see no reason to make mass-edits to change from one form to another or to change the usual rules about cosmetic bots here. I see no harm in Option C, but implementing Option A will trade current problems for new ones. --AntiCompositeNumber (talk) 02:15, 16 February 2021 (UTC)
  • Strong Support A: standardization for template parameters is important & useful.
Mild Support B: the # of |accessdate= per page is too damn high (much of the time), so much so as to interfere with checking regular WP:GenFixes (i.e. many single-screen diffs become many-screen diffs) — I would Strong Support B IIF Monkbot was allowed to continue & hyphenate at least this parameter.
Strong Oppose C: antithesis of A.
~ Tom.Reding (talkdgaf)  19:23, 16 February 2021 (UTC)
  • To whom is standardization for template parameters important & useful? Phil Bridger (talk) 20:39, 16 February 2021 (UTC)
  • How and why is standardisation more important and useful than editors being able to improve the encyclopaedia without needing to know the exact format of parameter names and deal with watchlists and page histories full of cosmetic edits? Thryduulf (talk) 20:45, 16 February 2021 (UTC)
  • Are y'all suggesting we bring back all deprecated parameters, and adding more so that every user may choose to use the parameter names that are most comfortable/understandable/intuitive to them? I'm ok with soft-deprecation - allowing both but discouraging/converting one, in bulk once via bot, then gradually/passively via WP:GenFixes & other tools, but that is not one of the options.
    Re: "watchlists": may be configured to ignore bots until it's done.
    Re: "histories full of cosmetic edits": the bot only requires 1 edit; hardly "full of"; regardless, there is community consensus for WP:CBD.   ~ Tom.Reding (talkdgaf)  12:16, 17 February 2021 (UTC)
    Yes, I am suggesting that all the two-word parameters should accept hyphenated and non-hyphenated varieties. It's fine for one to be preferred over the other in documentation but both should work and continue to work as this is by far the least disruptive to editors and allows them to spend their time producing/maintaining content rather than worrying about finicky syntax. I don't have massively strong objections to general fixes substituting one for the other when making non-cosmetic changes to the page, but I wouldn't actively encourage it as it will clutter diffs for no benefit. I strongly oppose bulk bot runs and making one option non-functional in the future. Thryduulf (talk) 15:29, 17 February 2021 (UTC)
    Re "Are y'all suggesting we bring back all deprecated parameters" - yep, that's spot on. They should never have been deprecated in the first place. This is a template, which sits in the background, and exists for editor convenience, nothing more. Deprecating parameters reduces that convenience. And it's well-established that bots and editors shouldn't be running through making cosmetic changes to wikitext that do nothing to alter the page, so those need to stop as well.  — Amakuru (talk) 12:48, 18 February 2021 (UTC)
  • Option C, I guess, as I've not been persuaded as to the marginal utility of the hyphenated versions. Without that clarity, we shouldn't be doing these kinds of changes. (And if we had consensus, then B, but with documentation changes as the first step.) — JohnFromPinckney (talk) 01:48, 17 February 2021 (UTC)
  • Option C If it works don't fix it. Andrew🐉(talk) 13:01, 17 February 2021 (UTC)
  • Option A, strongly oppose option C: anybody working regularly on templates or modules will appreciate the value of settling on a single style for issues like parameter names. I don't care what the agreed style is, as long as it's consistent, and the argument about whether it should be hyphenated, underscored, camel-case or run-on has been settled with hyphenated as the preferred style. It is then nonsensical to fail to implement that style, and I'd prefer it was done as soon as possible. This whole debate is reminiscent of the date-linking wars where strong objections were made to unlinking dates, yet within a few months of a binding decision being reached to delink dates, everyone had moved on, and nobody today would even consider linking dates. Once we have standardised on hyphenated parameters, future editors will look back and think how lame and time-wasting this sort of debate is. --RexxS (talk) 19:46, 19 February 2021 (UTC)
  • A or B but not C per Scott, Hawkeye, and RexxS. Usingahyphenismoreuserfriendly, andwhilethereissomeupfrontworkonourparttomaketheswitch, itisbetterinthelongruntohavesomedelimiterbetweenwordsinsteadofrunningthemtogether. Just like we stopped linking dates and no longer SmashWordsTogether, this is worth the temporary inconvenience. Wug·a·po·des 00:46, 20 February 2021 (UTC)
    Notwhen it'sjust twowords :-P Levivich harass/hound 08:10, 20 February 2021 (UTC)
    ...is what your comment would look like if we allowed people to use whichever method worked for them and still made it work. If we turn off those parameters, your comment wouldn't have appeared. If we allow people to use whatever works and use a bot to clean it up afterwards, your comment would look just like everyone else's after some period of time (during which your comment would still be functional, even if pairs of words were sometimes combined). :) — Rhododendrites talk \\ 20:15, 22 February 2021 (UTC)
  • Option A for all the arguments already made at length in the CS1/CS2 talk pages over the years and the good arguments brought forward above. Definitely not Option C. --Matthiaspaul (talk) 02:06, 20 February 2021 (UTC)
  • Option C. Such an absurd waste of time and energy and an enormous source of watchlist spam, all to achieve something that will make editing more difficult. Toohool (talk) 02:26, 22 February 2021 (UTC)
  • Option A as standardizing is better in the long term. Let the bot continue its work. If people have a problem with their watchlist getting spammed, they have the option to filter out bot edits. AVSmalnad77 talk 05:59, 23 February 2021 (UTC)
  • Option C if not B While I love consistency, I'm struggling to see what the actual issue is here. I guess they can be gradually changed by the bot along with other more useful changes, but this is just cosmetic to the code and clutters edit histories. Reywas92Talk 06:21, 24 February 2021 (UTC)
  • Option C. Benefits for bot or template builders don't outweigh the inconvenience for other editors. Fram (talk) 08:13, 24 February 2021 (UTC)
  • C. I don't see the argument for mandating hyphens. Just let people use both, consistency on this does not matter. Fences&Windows 17:00, 24 February 2021 (UTC)
  • Comment - my default is Option D... I refuse to use citation templates, and format my citations by hand. It means that I can ignore all the silly debates about parameters and what not. Blueboar (talk) 17:49, 24 February 2021 (UTC)
    Yeah and we can instantly clear the WP:PHAB backlog by writing articles with paper and pen. We can solve many technological problems by abandoning technology. Levivich harass/hound 00:52, 25 February 2021 (UTC)
  • Option C. Bots do some useful work but their code can be changed as needed. Here I am much more concerned about regular editors who use citation templates when making manual edits. These are live human beings and there are many more of them than bots. Making the template syntax too rigid will make their life much more unpleasant. Extra flexibility is both useful and helpful for regular editors. Nsk92 (talk) 02:26, 25 February 2021 (UTC)
  • Option C. I've been typing accessdate for the last 15 or so years, sometimes while reaching for my drink with my other hand (Qwerty keyboard). Why wreck my muscle memory and deprive me of a sip of tea?-gadfium 04:04, 25 February 2021 (UTC)
  • Option Cper Phil BridgerSea Ane (talk) 21:53, 26 February 2021 (UTC)
  • Option C, stop the craziness hitting watchlists (although most of that damage is already done). SandyGeorgia (Talk) 00:58, 2 March 2021 (UTC)
  • C sounds best, followed by B. Removing parameters that were widely used in the past will break old revisions of articles for very little practical advantage. —Kusma (t·c) 11:44, 2 March 2021 (UTC)
  • Option C. Others have already hit on why – watchlist spam, waste of time and energy for no genuine benefit, unnecessary imposition on editors, etc. I'm increasingly warming to the idea of writing out citations manually (as someone else here mentioned), just to avoid the constant tinkering around that seems to take place with these templates. JG66 (talk) 11:51, 2 March 2021 (UTC)

Discussion (CS1)

Some suggestions regarding the options:

  • Pedantry: "Non-hyphenated parameters" should read "Non-hyphenated multi-word parameters" in all three options. Parameters that contain only a single word or acronym do not need a hyphen.
  • In Option C, there is no point in suggesting that "the deprecated parameter list will need to be updated to remove the non-hyphenated parameters"; there are no instances of those deprecated parameters left in the affected namespaces, so support for them will be removed shortly, just as support has been removed for dozens of unhyphenated multi-word parameters already.

Some history and a status update, for those here on VPP unfamiliar with the long history of updates and changes to the Citation Style 1 templates ({{cite web}} and its siblings): As far as I can tell, there are only six unhyphenated multi-word parameters left – |accessdate=, |airdate=, |archivedate=, |archiveurl=, |authorlink=, and |origyear= – out of an original population of many dozens. So far, through the work of scores of editors and bots over the seven years since we standardized on hyphenation of multi-word parameters, we have deprecated, removed from pages in affected namespaces, and then removed from the CS1 templates themselves (as WhatamIdoing suggests above), many dozens of different unhyphenated multi-word parameters in CS1/CS2 templates. All new multi-word parameters during that time have been introduced using only a hyphenated form. This RFC is essentially asking: should we finish the job, or leave it at over 90% done, in a sort of limbo state, with six parameters as exceptions to the overall pattern, just because those parameters are used in a lot of articles? – Jonesey95 (talk) 04:38, 11 February 2021 (UTC)

  • Problem with "Option B": Option B is not the status quo. If it were, I'd be much happier. Since it's not, I don't know whether to !vote for A or B. The documentation at Cite web, for example, makes no mention of accessdate being deprecated. This means that users will be quite justified in blissfully adding and readding templates with accessdate, even after the bot has come through already and changed accessdate to access-date in 20 places. Each iteration tends to address fewer instances, but each run is a separate entry in my watchlist. Watchlist entries seem to be part of the complaint against this kind of work, so the first step should be turning off the faucet at the source, before spending energy to, um, bail out the boat. — JohnFromPinckney (talk) 06:37, 11 February 2021 (UTC)
    • The first sentence is true; all but six of the unhyphenated multi-word parameters have been formally deprecated and removed. As for "turning off the faucet at the source", that would be Option A, but in the past, when we have made red error messages appear in large numbers of articles as a first step in standardizing the citation templates and noting errors in them, there has been significant pushback. In order to avoid that pushback, the bot was acting to fix 90+% of the non-standard parameters before turning on the error messages, but that work has been stopped as well. Option A will allow that work to be completed. – Jonesey95 (talk) 15:09, 11 February 2021 (UTC)
      • I feel we are not understanding each other. "Deprecation" involves communication as a first step; removal is a second, later step. If we are going to have a bot changing pages (e.g., accessdate to access-date), causing some distress to the populace (and this is the status quo), then we should at least change the documentation to say that accessdate is deprecated, and is not a usable alias. I am strongly against a bot going around to change parameters to the "good" names when we don't ever tell the humans they shouldn't use the "bad" ones. That's just an endless cycle of watchlist-cluttering edits causing great irritation. If you want to avoid pushback, tell the people not to use the unhyphenated versions, then run the bot, then remove support some time later. — JohnFromPinckney (talk) 15:41, 11 February 2021 (UTC)
        • Deprecate in terms of the CS1 templates means to emit a red error message indicating deprecation. When we emit any red error messages for parameters in CS1 that are used often (or lack thereof for parameters that should be used more often), a lot of people get very irate. We do not change the documentation to indicate deprecation until after the module begins telling people inline about deprecation. So yes, you are not understanding each other, but it's a question of terms of art. --Izno (talk) 16:44, 11 February 2021 (UTC)
          • Why do people get irate? Because suddenly millions of readers go from nothing being wrong to seeing a load of red error messages all over hundreds of thousands of articles (and you couldn't seriously expect someone to debug a CS1 error as their first contribution). These citation templates aren't for us. They're for the reader and they need to be functional with low rate of error messaging 24/7 with no exception, because even small amounts of downtime have significant reputational damage. — Bilorv (talk) 02:54, 15 February 2021 (UTC)
      • That "we" (who is that, some class of super-techies whose opinions count for much more than those of us "normal" editors?) get significant pushback when creating error messages is simply a demonstration that the wider community does not agree with what "we" have decided. The answer is to stop doing what you are doing, not to do it more stealthily. Phil Bridger (talk) 18:37, 11 February 2021 (UTC)
        • You are welcome to participate at Help talk:CS1, the same as any other editor. Decisions are made by consensus there, inline with how consensus is practiced everywhere else on wiki. Don't like a decision "we" made? Get involved. --Izno (talk) 18:42, 11 February 2021 (UTC)
          • I saw absolutely no discussion of the removal of the freetext editors field on the talk page. Where did that happen? I don't think it's coincidence that all the editors whose names I know well from content creation/editing are voting B/C and all the editors voting A are those I don't recognise at all. Espresso Addict (talk) 20:08, 11 February 2021 (UTC)
            • The difference is between those people who think this is an encyclopedia and those who think that it's a playground for techies. Phil Bridger (talk) 20:43, 11 February 2021 (UTC)
              • Your ad hominem has no welcome here. Move along if that's the best you can offer to the discussion. --Izno (talk) 20:47, 11 February 2021 (UTC)
                • That is just the kind of reply that people who are here to create an encyclopedia tend to get from the techies. No response to genuine concerns but just an order to "move along". I have no wish to monitor whatever pages are used to ignore end users, but I have a right to expect that any decisions taken will respect the interests of everyone, not just a self-appointed clique of people who "know" what is right. Phil Bridger (talk) 19:53, 15 February 2021 (UTC)
                  • It's the kind of reply to people who needlessly create category A and category B and then line themselves up in one or the other categories. If you (specific/personal) don't want to monitor whatever pages, that's your prerogative. Do know that it is your choice and you are responsible for that choice, and choices have consequences. Changes are always announced ahead of time and consensus is sought for non-obvious changes (and even obvious changes with non-obvious implementations), so you have no excuse not to tune in at least once every couple months when the regular "Shit is Changing" post gets made. Secondarily, the scare quotes are not indicated by this discussion, nor any prior discussion that I can see, whatsoever. I have not seen any such 'clique' nor any of the users who would prospectively be in such a 'clique' claim they "know" what is right. As I said, if you have nothing to contribute but smears and attacks and divisiveness, move on. --Izno (talk) 20:22, 15 February 2021 (UTC)
            • In reverse chronological order: the patch notes indicating removal, the removal discussion, the patch notes indicating deprecation, the deprecation discussion. 4 times mentioned over a period of half a year on that talk page, a pre-existing maintenance category indicating a soft deprecation, and my removal of over 4k instances of the parameter over the year and a half preceding that deprecation discussion. Basically by hand (my hand, as it happens). --Izno (talk) 20:45, 11 February 2021 (UTC)
            • As for I don't think it's coincidence that all the editors whose names I know well from content creation/editing are voting B/C and all the editors voting A are those I don't recognise at all., I invite you the same as I invited Phil Bridger. You may watch and edit Help talk:CS1 at any time, the same as me. "I don't recognize these people" is a trash association to make and is the same kind of ad hominem that I have asked Phil so kindly to stop employing. It is certainly not sufficient cause to say "I don't like this change". --Izno (talk) 20:49, 11 February 2021 (UTC)
              • I think there's a genuine problem here that there's a disconnect between the editors maintaining the citation templates and the editors employing them to write and maintain articles. I didn't make the decision to abandon years of using citation templates (CS2 actually, but the same parameter changes are happening there too, even less announced) lightly. Espresso Addict (talk) 21:35, 11 February 2021 (UTC)
                The disconnect is real and significant. Someone whose skills and interest lie in writing or maintaining article content shouldn't need to care about what happens at pages like Help talk:CS1 (and how on earth is a new editor even meant to know that page exists?), let alone have to pay attention to discussions there. Those who do care about template mechanics should always be acting in ways that actively put readers first, editors second and programmers third. The only time there should ever be breaking changes or a need for cosmetic edits is when after detailed examination there are literally no alternatives available. We've ended up here because that hasn't been happening and a local consensus has ignored the needs of end users. Thryduulf (talk) 01:38, 12 February 2021 (UTC)
                I almost commented last night, and then put that version into a text file and went to bed. Now I have been spurred by a comment above to reply here. The editors using these templates to write and maintain articles are the same as the editors maintaining the citation templates. Get that through your head. If we prioritize different qualities versus this other supposed separate group, it's because we have the experience to do so. If you don't, let me reiterate, get involved. Come and say "I don't like this" or "this is a painful interaction" or X, Y, and Z, and provide a suggested fix. That's how consensus starts forming, like every other page or process on this website. Others will say "I don't want this to work like that suggested fix because A, B, and C". Then you discuss the tradeoffs and make a decision. If you're unwilling to step up and discuss the paper cuts, then we end up having mass RFCs or AN drama or what have you over what would otherwise be small issues or ones that could have been discussed informally with the ordinary "let's figure it out" consensus view of the world. That's a disconnect too, and blaming editors interested in one page versus those apparently disinterested is not the right way to move forward. Want something to be better? Ask. Propose. Cajole. Make the effort to put forth the minorest of social interactions required to start a discussion in the one place where everything about that thing is discussed. We're all volunteers and our heart is in just a right a place as yours, but if we should have disagreements, then we talk to each other and find out how to fix the problem or agree to disagree on the points of interest. Not have constant complaints of "they didn't listen to me". Consensus is not unanimity.
                The only time there should ever be breaking changes or a need for cosmetic edits is when after detailed examination there are literally no alternatives available. This is quite frankly an opinion lacking any community consensus whatsoever. We've recently approved an RFC allowing cosmetic edits on a regular basis and from what I could see in that discussion (and murmurings elsewhere), cosmetic edits might be closer to having consensus than not, it's just inertia that leaves us not performing them regularly. Moreover, hundreds of templates, and certainly all those which go through WP:TFD, have a process applied which causes breaking changes or which results in more-or-less cosmetic edits. Are you claiming that TFD does not have consensus as a process? That templates which are being cleaned up because of a talk page discussion on that template's talk page should be stopped? You want your cake (to not care about how things work) and eat it too (have all of your opinions and claims listened to, when they aren't even articulated in the first place). Get real. --Izno (talk) 20:22, 15 February 2021 (UTC)
                I fear this just demonstrates the truth of what Thryduulf writes. "The editors using these templates to write and maintain articles are the same as the editors maintaining the citation templates. Get that through your head." is self-evidently false, as well as impolite. Speaking only for myself, what I actually want is to be able to get on with writing & improving articles, rather than having long side discussions on matters that aren't directly relevant. Espresso Addict (talk) 00:10, 16 February 2021 (UTC)
                get on with writing & improving articles Then do that. No-one is stopping you from not caring. I am just calling you hypocritical for raising a fuss when you don't and then changes happen elsewhere that affect you. Don't like it? Change your behavior. (I won't reply to you again.) --Izno (talk) 00:34, 16 February 2021 (UTC)
                The editors using these templates to write and maintain articles are the same as the editors maintaining the citation templates. Get that through your head. Both uncivil and not even close to correct. While it is possible that some, maybe even many, of the editors maintaining templates also write and maintain articles there are literally hundreds of editors writing and maintaining articles who have never been near a discussion about the template code, let alone written any code. Writing encyclopaedic prose and writing computer code are very different skills; nobody is or should be required to do both. However given that the purpose of this project is to write an encyclopaedia everything that is not writing an encyclopaedia should be done for the benefit of (first and foremost) readers of the encyclopaedia and (secondly) those who write and maintain the encyclopaedia. The convenience of those dealing with tools is least important. Thryduulf (talk) 00:23, 16 February 2021 (UTC)
                Writing encyclopaedic prose and writing computer code is a false dichotomy and a blatant misrepresentation of what the two paragraphs I had to say. I did not ask you to do both. Nor do I serve you (general) in your supposed role as an article writer. There are no (formal) hierarchies on this encyclopedia, and even considering yourself as supposedly above me or my efforts is the actual uncivil statement. Lastly, I place myself fully in both supposed groups given the thousands of articles where I have bettered their citations. (And as I said to Espresso, I will not reply in this section again.) --Izno (talk) 00:34, 16 February 2021 (UTC)
                My role here is not as an article writer (I do very little of that), I spend the majority of my time on the project trying to ensure that readers can find the content they are looking for and those that do write and improve articles without needing to worry about nonsense like this that will needlessly make their job harder. There might not be a formal hierarchy but their should be: (1) Readers are head-and-shoulders above anyone else. (2) Those who write and maintain the encyclopaedia a short way above (3) Those who support those write and maintain the encyclopaedia are a long way above (4) Those who hinder any of the above. I place myself in the third category alongside many of those who maintain templates. Thryduulf (talk) 21:02, 16 February 2021 (UTC)
  • Comment. What is the merit of citation templates? Let alone the increasing creep to make them more and more rigid and harder and harder to use? The only reason I can see is to make it easier to export and sell data. No-one ever seems to give a thought to those who type citations manually; it is far harder to type "access-date" (which requires two hands and a hand movement) than "accessdate" (one hand, no move). I don't understand what the benefit of this change is at all. In fact, broadening this discussion, I don't understand why the freetext editors field was suddenly withdrawn this January. Personally I've decided to meet the latter change by reverting to writing out references by hand, which is easier, more flexible, and seems to have no downsides. Espresso Addict (talk) 07:04, 11 February 2021 (UTC)
    • Citation templates make standardizing citation style and look much easier. They can, for example, automatically standardize date display. Machine-readability is also a good thing, imo. I suppose access-date is slightly harder to type - but editors editing wikitext manually would probably not mind. Otherwise, tools for inserting these citations exist. Elliot321 (talk | contribs) 17:12, 11 February 2021 (UTC)
      • It's not slightly harder to type, it's a great deal harder to type for a touch typist. And here's an editor editing wikitext manually who does mind, enough to bother responding here. There's no tool I know of that creates citation template code in the form I prefer for ease of wikitext editing afterwards; they all make code soup that takes longer to fix than retype. Espresso Addict (talk) 20:08, 11 February 2021 (UTC)
        A bit slower, yes, but I personally don't find it a great deal harder—touch typists generally have practised it a lot while learning. Nonetheless, I don't think ease of typing by some metric is the primary issue. isaacl (talk) 20:40, 11 February 2021 (UTC)
        Speaking as one of those touch-typists, and as a person who learned to type on an actual typewriter, I don't find the hyphenated version any harder to type, and I do recall my typing teacher saying that it was faster and easier to type words that were split evenly between hands, instead of all in one hand. WhatamIdoing (talk) 22:49, 11 February 2021 (UTC)
        Yeah, personally I imagine it has a greater effect for a hunt-and-peck typist. When I said a bit slower, I was thinking compared with a word of equal length that consisted only of letters. Of course, in this case, the hyphenated name has one more character which would comprise most of the difference for me. isaacl (talk) 23:02, 11 February 2021 (UTC)
        For me, not an issue on a regular keyboard, but a bit of a pain on a tablet. Then again, so much is a bit of a pain on a tablet... · · · Peter Southwood (talk): 05:39, 2 March 2021 (UTC)
      • I use citation templates myself, but I respect the wishes of those who prefer not to use them. It is precisely the fact that I use them that leads me to the opinion that obvious synonyms for parameters should not be removed, as proposed here. What on Earth is the problem with allowing both hyphenated or unhyphenated forms? All it means is a few extra bytes of storage, and no extra code if it is done properly. And the work has already been done, but this proposal is to undo it. Do we still live in the days when I started in IT working for one of the world's leading business information companies whose UK operations were all run from a computer with 1MB of memory and where all online programs were limited to 12KB? I thought we had moved on from there. Phil Bridger (talk) 20:34, 11 February 2021 (UTC)
        I am reminded of a story about a lady, who (decades ago) bought a large supply of personalized stationery and then discovered that the post office was renaming her street. She convinced the local postmaster into letting her continue to use the old address until her stationery was used up. This saved her some money and effort, but it had external costs. For many years to come, every mail carrier had to learn that "123 Main Street" wasn't on Main Street and wasn't number 123, but instead had to be delivered to the other side of town.
        Aliases are often low-cost in storage and computational terms, but they are not actually free. "Not free" can add up to a quite significant cost when it is repeated a million times. WhatamIdoing (talk) 22:56, 11 February 2021 (UTC)
  • Although I sympathize with the desire for all templates to align with one standard (from a user's perspective, I would personally find it easier), I just don't think it's feasible at this point in time. In which case, I sympathize with those who think computers should make our lives easier, and just accept both formats. On the third hand, from an implementer's perspective, I appreciate that it adds a lot of noise to template syntax, if not implemented with a Lua module. Since the CS1-based templates are implemented with Lua, the overhead can be minimized, and so I think both formats should continue to be supported. I don't feel there is much advantage to converting en masse, by any mechanism. isaacl (talk) 20:40, 11 February 2021 (UTC)
  • Pinging some previous participants in related conversations who may not yet be aware of this discussion: @SandyGeorgia, Jason Quinn, Oknazevad, Tom.Reding, Brainulator, DavidBrooks, SMcCandlish, David Eppstein, Matthiaspaul, Headbomb, Gracefool, Ss112, JG66, Mikeblas, Gonzo fan2007, Sariel Xilo, Modest Genius, and SlimVirgin:. Nikkimaria (talk) 01:17, 12 February 2021 (UTC)
    Thanks for the ping, I was indeed unaware of this discussion. Modest Genius talk 12:16, 12 February 2021 (UTC)
  • Does anyone have any evidence that having alias for parameters makes things harder for end users? In my experience as a trainer and long-time user, having multiple ways to achieve the same ends allows editors to spend their time and energy working on content rather than puzzling over making sure that the template parameters are named in exactly the right way. I've never met anybody who was comfortable enough to be dealing with templates in the first place who was not completely comfortable with the idea that "you can write it as either access-date or accessdate, it doesn't make a difference." (or similar). Speaking personally, I don't want to have to learn whether it is "accessdate", "access-date", "access_date" or "access date", I just want them all to be accepted so that whichever I input the template works and I can worry about more important things. Thryduulf (talk) 01:29, 12 February 2021 (UTC)
    The inconsistency across all templates does make things harder. Users have to either remember which templates only support one form and which one, or look it up each time. I appreciate though that there is extra complexity in trying to support lots of aliases, particularly for ones that aren't implemented with a Lua module (either each use is going to become more elaborate and verbose, or the template could delegate the detailed implementation to a helper template, with the top-level one only doing parameter normalization), so personally I wouldn't want to require that every template must support aliasing. Thus I think we're kind of stuck with inconsistency. isaacl (talk) 02:12, 12 February 2021 (UTC)
    This inconsistency should be tolerated. Some, particularly high-use, templates having aliases is important for the great number of people who use these templates. They don't have to remember was it |access-date= or |accessdate=. If it doesn't work on some other template, well fine. But eliminating aliases and simply making the computer say no on all templates makes things a lot harder for the vast majority of users. That inconvenience is far greater than the fact that a few lesser-used templates don't support aliases and you might need to take a look at the documentation sometimes. – Finnusertop (talkcontribs) 06:05, 12 February 2021 (UTC)
    Yes, as I said in another comment, I feel both forms should continue to be supported for the CS1-based templates. I'm pretty sure the vast majority of templates don't support both hyphenated and non-hyphenated parameters—for example, from what I can tell from the code and a quick test, {{Infobox}} doesn't. That's just the way it goes when trying to make as many aspects of Wikipedia markup accessible to as many editors as possible: standardization won't always happen, and often simpler markup will be preferred by more editors than more complex markup, even if it would add more functionality for users. isaacl (talk) 22:22, 12 February 2021 (UTC)

Arbitrary break 1

  • Thanks to Nikkimaria for the ping based on my earlier involvement. I'm appallingly neutral (or torn) on the main topic but I earlier did some analysis that gives me concern about impacts on Template space in particular, if deprecation goes ahead fully. Here I'll use |authorlink= as a proxy for all six, because I personally type it more often. There are three areas that concern me: templates that indirectly invoke CS1, those that transclude CS1-invoking templates, and clones. I'm concerned about where and when red error messages appear, and documentation, in which I include both /doc and TemplateData.
  1. There are many CS1-friendly templates that invoke one of the canonical templates; {{Cite encyclopedia}} is often used for example. Some use parameter rewriting, converting |authorlink= to |author-link= before passing it on.
    1. Does their documentation always give precedence to |author-link=? I think we caught them all during the earlier discussion, but I can't guarantee the quality of the search.
    2. Because the CS1 code never sees the deprecated parameter, should this template emit a red error itself during the substitution? Or maybe just forget about the mapping and have CS1 do it? And how hard is it to find templates with the parameter substitution code?
    3. If |authorlink= ever moves from deprecated to invalid, then all those mappings and documentation need to be trimmed in one fell swoop. Well, I guess the mappings can stay in place although they could trip up inattentive longtime users.
  2. There are templates that simply transclude a pre-filled CS1-style template: for example embedding {{Cite book}} as a citation to a specific volume that is relevant to any use of this template. Have they all been fixed? If not, their user will see a red error message (correct?) that has nothing to do with their own usage.
  3. There may be templates that are modeled on CS1 but roll their own expansion, although I don't know of any such. If they happen to use |authorlink=, should they also be brought in line?
Two final comments: there are more than six, if you consider variants like |author1link= and |authorlink1=. And in principle the arguments above apply to any page outside Template space that gets transcluded by someone, although I know that feature is rarely used. David Brooks (talk) 16:51, 12 February 2021 (UTC)
Shoulda said: the above applies to A and to some extent B but you can probably figure that out. David Brooks (talk) 16:57, 12 February 2021 (UTC)
DavidBrooks: There is a tiny army of editors at the ready to fix these templates. As far as I know, there are no transcludable templates that pass |authorlink=, your example, to any CS1 templates, so using those templates would not generate an error message. |accessdate= and the two or three remaining unhyphenated parameters being passed from template transclusions to CS1 templates were being processed by the bot before the bot was paused to hold this discussion. Once this discussion is closed, the bot will be able to resume that work, with human assistance, if the closure is a reasonable one. – Jonesey95 (talk) 17:13, 21 February 2021 (UTC)
@Jonesey95: I just addressed a related issue in Help talk:Citation Style 1, where by modifying the example given I found 3 templates that use |authorlink= in a CS1-style template that's used to reference a specific source: {{Barmakids family tree}}, {{Citeer web}}, {{Alox2}}. But this less restrictive query shows a few more (ignore the "DYK" archive, I think). Not sure if you meant this type of usage in your comment; I may be missing the context. David Brooks (talk) 05:05, 22 February 2021 (UTC)
@Jonesey95: OK, looks like you fixed {{Alox2}}. {{Barmakids family tree}} and {{Citeer web}} still need to be fixed (I'll do them later today). The documentation of "Cite book (short)" in {{Quicktemplates}} lists the not-incorrect |authorlink=, so that comes under the "prefer the hyphen forms in documentation" rule. I didn't look for |authorlink2= or |author2link= because they are unlikely to appear alone. David Brooks (talk) 19:17, 22 February 2021 (UTC) ...  Y, also {{Bach's compositions (sources)}}, which indeed had |author2link =. David Brooks (talk) 21:42, 22 February 2021 (UTC)
  • I would like to clarify what I meant when I originally wrote the options, since there is some confusion. My intention with "removal" was to refer only to removal of usage of nonhyphenated parameters by transclusions of the template, not removal from the implementation of the template itself (I will call this "disabling the parameter"). This is also distinct from deprecation, which is designating something in documentation and warning messages as discouraged. Remember that the original reason for this RfC is to clarify whether we should have a bot going through the article space removing the parameter usage as its sole action. A, B, and C are respectively continue removing now, remove only as part of other non-cosmetic edits or in a situation where cosmetic-only edits are allowed, or do not remove. In case of A or B, I did not intend for them to make a statement about whether we should disable the parameter when this is done. This is an important question, but orthogonal to whether the parameter usage is removed now or later. — The Earwig alt ⟨talk⟩ 22:11, 13 February 2021 (UTC)
    Thanks for clarifying (except the part where you formulated the options). Unfortunately, it now means I'm missing the option: Non-hyphenated parameters should be deprecated now and removed later. The actual status quo seems to be: Non-hyphenated parameters should be removed now and deprecated later, and the removal can occur by bot which does nothing else on the page (cosmetic only), but will revisit the page as often as necessary to re-remove the non-deprecated params that keep getting added. — JohnFromPinckney (talk) 23:01, 13 February 2021 (UTC)
    For context, this is how I originally phrased it; note B and C are swapped. Isn’t what you’re desiring exactly option B (in the current formulation)? It seems describing B as the "status quo" is confusing. Instead, view A as what the bot was doing before it was stopped, and B as what is currently happening with the bot stopped, but with clear, formal deprecation. — The Earwig alt ⟨talk⟩ 00:19, 14 February 2021 (UTC)
    Mmm, maybe, and in any case I'm very grateful for your link to the pre-RfC coordination at Primefac's Talk. And I can say that your original formulation was clearer than the formulation we're now using for the RfC proper. However:
    1. There appears to be no consensus for the removal of non-hyphenated multiword parameters. The 2014 RfC determined only that the hyphenated version must exist, and the close explicitly allowed for non-hyphenates.
    2. If this RfC is intended to determine whether non-hyphenates should be deprecated, it's poorly formulated to the extent that it mentions the current bot activities.
    3. I can't view Option A as what the bot was doing before it was stopped, because the parameter has not been deprecated. (The statement by Nikkimaria that deprecation "in the context of CS1/CS2" means a red maintenance message will be shown is not something I can accept, as any reasonable software provider knows that advance notice is the first part of deprecation. Unfortunately, I don't usually work "in the context of CS1/CS2", so haven't argued before against this unhappy definition.)
    4. Option B, as written on this page, is a garbled mess, not only because of the "status quo" mention, but also because of the "Deprecation can be bundled into genfixes..." bit. Deprecation, as above, is (first) a documentation task, followed by a (presumably small) step to cause red messages to be generated (I'm not sure what's involved here). I don't see what would need to be "bundled into genfixes". I had the feeling that many !voting here saw "removal" as meaning elimination of usages, but maybe that's due to my own confusion. Your Option C (and your original formulations in general) were much clearer.
    There should never have been any bot activities, because (a) there's no consensus, yet, to deprecate non-hyphenates, (b) the params are not yet deprecated, and (c) the bots' edits have been largely accessdate => access-date only, so violate WP:COSMETICBOT. So I guess I'll be !voting for B, although I'd much rather choose your original Option C. This RfC as written has been too unclear (at least for me). — JohnFromPinckney (talk) 11:20, 14 February 2021 (UTC)
    Re The 2014 RfC determined only that the hyphenated version must exist: As called out in the proposal, it also said The documentation is to show this lowercase, hyphenated version as the one for "normal use". Hence my comment above: some of us recently tweaked the documentation of a few high-use templates to make the hyphenated version the privileged one, but I can't guarantee we got both /doc and TemplateData for every template that indirectly uses CS1/2. If we end up with both hyphen and no-hyphen equally valid (is that C?), then tweaking the documentation will be the only change visible to current editors. SHould there be a more valiant effort to track them all down? David Brooks (talk) 19:45, 14 February 2021 (UTC)
    If the consensus is for Option C, then nobody has to track down anything; we can leave the documentation as it is. BTW, the claim written there, This will also mean that the deprecated parameter list will need to be updated to remove the non-hyphenated parameters is another red herring and would, it seems, not apply at all (as accessdate isn't even listed there yet).
    If we chose Options A or B, then yes, the documentation should be immediately changed. I can't believe it will take too much valor to find the Template:Cite web documentation, as it doesn't seem terrible exotic, but it should be included in the tweaking in those cases. — JohnFromPinckney (talk) 20:07, 14 February 2021 (UTC)
    • The 2014 RFC had a participation of only seven people and was six or seven years ago. It is patiently absurd to update documentation with such a sweeping change based on that alone, and any such changes ought to be reverted pending the outcome of a more clear RFC. Furthermore, the 2014 RFC specifically indicated that nothing would be depreciated, so if you are relying on it as a justification for any changes then obviously no non-hyphenated versions can be depreciated until / unless a new RFC overturns it. --Aquillion (talk) 22:19, 15 February 2021 (UTC)
    Please read the summary at the top of this Discussion section. Here's the summary of that summary: Dozens of unhyphenated multi-word parameters have been deprecated, removed from pages, and then removed from the Citation Style 1 templates over the last seven years. There are only six left. During those seven years, many new, hyphenated multi-word parameters have been introduced, without unhyphenated aliases. At present, the situation is that unhyphenated multi-word parameters are the standard, and there is just a bit more work to do to remove the final six outliers. Unfortunately, it appears that many editors have not enabled the useful settings "Expand watchlist to show all changes, not just the most recent" and "Group changes by page in recent changes and watchlist" so that bot edits can be hidden without losing visibility of bad human edits, so people are complaining about a bot "clogging" their watchlists. – Jonesey95 (talk) 23:59, 15 February 2021 (UTC)
    None of that is however relevant to Aquillion's comment in the slightest. That a flimsy consensus (at best) has been used to justify removing functionality in the past does not mean that that removal was a good thing or that the bot edits (which clog both watchlists and page histories with unnecessary edits, whether they hide other edits or not) should continue. Indeed, I strongly suspect there would be support for re-enabling the parameters already removed. Thryduulf (talk) 00:27, 16 February 2021 (UTC)

Please note, folks, that this bot is a one-off; it may be processing some 2 or 3 million pages, but it's still a one-off, that is (unless reverted) it will only ever appear ONCE in any article history. So the idea that it's "clogging up" page histories is a big red herring. If you're bothered about it "clogging up" your watchlist, then please set the options recommended by Jonesey95 and others. So that objection falls by the wayside too. Please also note that this bot finishes the job. Once it's done, that's it – no more bots making this sort of change. To the charge that this bot is "disruptive" or that it's somehow "removing functionality", I can't do better than copy Rexx's observation above: "Once we have standardised on hyphenated parameters, future editors will look back and think how lame and time-wasting this sort of debate is." --NSH001 (talk) 19:30, 21 February 2021 (UTC)

Except that, no, that's completely inaccurate. Consider List of University of Pennsylvania people. When I look at the last 500 edits just now, I see that Monkbot has been there SEVEN times: here (21:07, 19 October 2020) and here (01:02, 28 December 2020) and here (17:21, 14 January 2021) and here (21:21, 16 January 2021) and here (01:53, 18 January 2021) and here (15:30, 18 January 2021) and here (20:54, 30 January 2021). While that first edit (from October) did nothing with |accessdate=, the others all did, as often as it found new additions to the article. Note that the fifth and sixth edits both occurred on the same day.
I don't ordinarily block bot edits from my watchlist because I want to know what's going on with "my" articles, and the bots generally do useful and interesting work. It's just that the (to me) sudden and unforeseen flurry of multitudinous edits (doing, it appears, nothing which really interests me) was quite irritating. The repetition on List of University of Pennsylvania people really got my blood pressure up, and that's not far off from "disruptive" to me. — JohnFromPinckney (talk) 21:15, 21 February 2021 (UTC)
Hmm... The October edit is Monkbot 17 (not 18), so doesn't fall into the scope of this RfC. The edit on 28 December is the main application of this bot. That leaves 5 (mostly quite small) unexpected additional edits by the bot. They are all caused by editors adding parms that don't conform to the canonical standard. So yes, I should have qualified my statement by allowing for that possibility, sorry for that. Understandable that this should happen in the absence of a clear deprecation (so far) of the unhyphenated form. Perhaps the editors concerned are using some cite-generating tool that doesn't generate the canonical form, in which case the tool should be updated. Whatever, that strengthens the case for deprecating the non-canonical forms ASAP, and for moving forward as fast as possible with the main task. It's late now, and I will be going to bed shortly. Will comment on Phil Bidger's intemperate remark below in the morning. --NSH001 (talk) 00:06, 22 February 2021 (UTC)
Naw, the editor concerned is/was just copying/pasting whatever they found in whatever articles they were looking at. (The user also hasn't learned that refs go after punctuation, or that a named ref copied from another article might not be declared on the target page, or that Wikipedia has a Preview function to allow checking for errors. Not that I'm bitter.) Agreed, without actual deprecation, nobody knows what they're supposed to use or not use, so watchlists get plagued with unnecessary repetition. And I can't point such a user to the deprecation or consensus not to use the non-hyphenated forms, because there aren't any yet. — JohnFromPinckney (talk) 00:21, 22 February 2021 (UTC)
Thanks for that. If it is the case that editors on that page are simply copy-pasting cites from the original wiki bios, then that's good news – the problem will go away if the bot is simply allowed to continue and fix the problem in the source articles. I don't think it's true that there is no consensus for this change: the desired style was settled in an RfC several years ago, and has been 90% implemented in the years since, with no substantial objection. So there is an effective consensus, and it makes no sense not to carry the task through to its logical conclusion. The objections here amount to a dislike of large numbers of bot edits appearing on watchlists, not on the actual merits of the case. --NSH001 (talk) 07:34, 22 February 2021 (UTC)
The RfC in question only had seven supports, and only concerned making sure a hyphenated version existed and was presented first in the documentation. I don't know how that could be read as effective consensus for deprecating a parameter that, prior to the bot run, seems to have been more commonly used than the hyphenated variant - and even if it could, it would be a limited one. The objection to the bot is not just that it edits a lot, but that it "fixes" something that isn't a problem. Nikkimaria (talk) 14:01, 22 February 2021 (UTC)
Exactly this. — JohnFromPinckney (talk) 02:05, 23 February 2021 (UTC)
Nikkimaria, the first fallacy in your argument is that you are assuming the wider community, if it participated in the original RfC, would disagree with its conclusion. That isn't (quite) the case – I'm pretty sure that, out of the various choices available for multi-word parameters (runon, camelCase, under_score, hyphenation, etc), hyphenation would still be chosen, simply because it is the easiest to read in wikitext. Possibly underscore might be better (it won't line-wrap) but most people, apart perhaps from those with a programming background, will be much more comfortable with the hyphen, so that RfC came to a very sensible conclusion. The detail of its implementation is another matter, though. The second fallacy in your argument concerns the reason for the objection to the bot. Firstly, the observable fact is that some editors are now kicking up a huge time-wasting fuss about this bot, but said nothing about the many other bot runs for all the other CS1/2 parameters doing exactly the same thing. Secondly, and I see this repeatedly in other RfCs as well, that editors tend to focus solely on a perceived short-term problem, without taking account of the bigger picture and the wider context. That context has already been well described in the introduction to this RfC, and in the links given there. It's astonishing to me that people don't see that that the whole point of this work is to make the citation templates simpler and easier to use. Part of that process is to make the parameter names more meaningful and consistent. It's ridiculous to leave the mess inherited from the early days of citation templates, with these few remaining parameters sticking out like sore thumbs. --NSH001 (talk) 08:25, 25 February 2021 (UTC)
Please explain how allowing e.g. "accessdate" is less meaningful, is less simple, is harder to use for regular editors. That is the bigger picture, the wider coontext: the benefits are actually only for a small group of people, who have every right to present their case and ask if their life can be made easier, but should not be astonished when it turns out that in some cases, their preferred solution is not supported by the larger group of people who don't do (or not as regularly) the template and bot stuff. Putting error messages on thousands of pages for things which are not an error but something which a few people decided is no longer allowed at all is losing sight of the bigger picture as well. Fram (talk) 09:24, 25 February 2021 (UTC)
you are assuming the wider community, if it participated in the original RfC, would disagree with its conclusion. I don't know that, and neither do you, because the wider community was never consulted. We can be reasonably sure that the discussion would have been far less one-sided, based on subsequent commentary. As to the second half of your point, as Fram notes, it's not at all clear why deprecating widely-used aliases would make the templates easier to use for the average editor. Nikkimaria (talk) 13:33, 25 February 2021 (UTC)
So the solution to a bot editing against consensus is for those who object to stop watching it? You couldn't make this stuff up. Once again, this is a fucking encyclopedia, not a place for techies to dictate to editors. Find a playground elsewhere, or get a real job and you will find out that people can only get paid to write programs if thay do what their users want them to. Phil Bridger (talk) 21:27, 21 February 2021 (UTC)
Phil, your first sentence is false. This bot was approved by consensus, following standard procedures. Indeed its operator went to extraordinary lengths to shout from the rooftops that it is a "cosmetic" bot. I'll ignore your intemperate and baseless personal attack. Finally, on the question of bot edits and watchlists, I refer you to Bilorv's conribution at 11:34, 13 February above, which looks like a good solution (I'll just add the caveat that I haven't tested it yet). --NSH001 (talk) 08:25, 25 February 2021 (UTC)

Reading some of the above comments, I'm sorely tempted to add a new proposal here: every editor who deliberately makes a change which adds an error message to at least 10,000 pages is stripped from their template editor right. Excluding hidden cats of course, these aren't a problem; but no depreciation of any parameter justifies such mainspace disruption for readers. Fram (talk) 08:30, 24 February 2021 (UTC)

Three responses: First of all, the error messages displayed by CS1 templates are displayed by consensus, not by a single editor. Second, the error messages, such as those displayed in articles within Category:CS1 errors: unsupported parameter, are shown not because a single editor changed a template, but because individual editors made errors when they used CS1 templates. Third, the objection to error messages being splashed across article space is why the bot was operating before the deprecation error messages were displayed. People hate the display of hundreds of thousands of minor error messages, so the bot was fixing the articles before the CS1 modules were changed to display deprecated-parameter errors.
Fram's feedback offer give something to think about, however; if the logical options A or B are chosen here so that the last 10% of the hyphenation of multi-word CS1 parameters can be completed, perhaps we should not display deprecated-parameter error messages (except maybe in preview mode) in articles until the vast majority of parameter name replacements are complete. – Jonesey95 (talk) 16:29, 24 February 2021 (UTC)
Thanks, but remember Wikipedia:Administrators' noticeboard/Archive313#Is there a semi-automated tool that could fix these annoying "Cite Web" errors? from 1 1/2 year ago? There also was "consensus" for that change, among a tiny group of editors, but disregarding the wider community. I hoped that that episode would have learned some of the people most active at these templates that, when they propose a change affecting many pages (and certainly when they propose a change adding error messages to many pages), they should get a much wider consensus first. Still, I see in the above discussion people arguing to activate the red error messages for this (most error messages we get now are either on very few pages or for actual errors, e.g. impossible dates), which isn't an error but something some bot operators and template builders don't like. Fram (talk) 17:06, 24 February 2021 (UTC)

New speedy delete criterion (Not for Wikipedia)

This AfD could have been resolved earlier if there was this criterion. It was clearly not for Wikipedia, and it was a WP:SNOW anyway. The text should read as follows:

Ax. Not for Wikipedia.

Pages which qualify under Not for Wikipedia as not for Wikipedia. (templates)

-or something to that effect. This should be numbered A12. Please consider this, as it will help avoid future unnecessary AfDs like that. AnotherEditor144 talk contribs 21:56, 14 February 2021 (UTC)

Just let the process work out. It will be gone within a week. --Malcolmxl5 (talk) 22:18, 14 February 2021 (UTC)
Clearly not for Wikipedia is far too broad and subjective for a speedy deletion criteria. I'm a little more sympathetic to AFD snow as a speedy deletion criteria, except for the issue that sometimes it can be a while before someone comes along and does the legwork to find spources and save an article. ϢereSpielChequers 22:45, 14 February 2021 (UTC)
  • I of course also agree that "not for Wikipedia" is much too broad and subjective for CSD. As for SNOW, it can't be a CSD because then future iterations of the article wouldn't be G4-eligible. Perhaps a better idea would be to create some sort of "requested SNOW closure" category (perhaps populated via a template) to notify administrators that a SNOW close had been requested. Extraordinary Writ (talk) 22:59, 14 February 2021 (UTC)
    Wouldn't that require making WP:SNOW a guideline first? Adam9007 (talk) 23:09, 14 February 2021 (UTC)
    Snowball closes are authorized by WP:XFD, which is a guideline. I thus think that a requested SNOW close category would be valid, although the details would probably still need to be fleshed out. (WP:SNOW probably should be a guideline, for what it's worth, although I don't think it's necessary for our purposes.) Extraordinary Writ (talk) 23:25, 14 February 2021 (UTC)
    Ok. Let's go to Wikipedia talk:Criteria for speedy deletion and sort this out. AnotherEditor144 talk contribs 07:33, 15 February 2021 (UTC)
  • (edit conflict) This is a frequently suggested criterion for speedy deletion, indeed so much that it is point one at WP:NOTCSD. Also, for future reference, the correct location to proposed speedy deletion criteria is Wikipedia talk:Criteria for speedy deletion. Thryduulf (talk) 23:01, 14 February 2021 (UTC)
    Ok. AnotherEditor144 talk contribs 07:28, 15 February 2021 (UTC)
  • So should this maybe be moved to the talk for the CSD page? Foxnpichu (talk) 14:22, 15 February 2021 (UTC)
    • Only if someone has a proposal for something different to what has been suggested and rejected countless times before. Also don't bother unless it meets all four of the criteria at WP:NEWCSD. Thryduulf (talk) 15:14, 15 February 2021 (UTC)
      • I wonder whether what's needed is actually to change CSD's name, from "speedy deletion" – everyone wants bad articles to be removed quickly, so if CSD doesn't have the right criteria to fit the page I want to get rid of, then we should just expand the list some more – to something like "undiscussed deletion". WhatamIdoing (talk) 06:42, 16 February 2021 (UTC)
        • Interesting idea. Ideally a new name would include something to indicate that it is an exception to the standard process for exceptional situations not something that's just for "things one or more editors dislike". Thryduulf (talk) 12:31, 16 February 2021 (UTC)
          • That’s the problem. If an article seriously needs deletion, it is best to delete it immediately. Foxnpichu (talk) 23:05, 16 February 2021 (UTC)
            • Well, then, how about "Article for Immediate Removal" (or Deletion, etc.)? GenQuest "scribble" 17:39, 24 February 2021 (UTC)

RfC: Disable minor edits on English Wikipedia

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)
  • 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)
  • 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 (talkcontribs) 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)

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: [16] [17] [18] [19] [20] [21] [22] [23] [24] [25] [26] [27] [28] [29] [30] [31]. — 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)

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

Notification of an RFC

Users may be interested in the RFC at Wikipedia talk:Page mover/delete-redirect § RFC on granting delete-redirect to page movers. Thanks, -- DannyS712 (talk) 23:29, 18 February 2021 (UTC)

Science Photo Competition 2021 Russia targeting CentralNotice banner

On Marth 1, the «Science Photo Competition 2021» started, traditionally the photo marathon is being held jointly with the Nauka television channel, it will be interesting. We invite everyone who is interested in science and who is able to hold a camera in their hands. The rules of the contest are very simple, prizes have a place to be! Colleagues, to attract external participants, we proposed a banner of the competition through CentralNotice. JukoFF (talk) 11:43, 21 February 2021 (UTC)

CentralNotice proposal for International Women's Day

A proposal has been made to run a CentralNotice banner for both anonymous and logged-in users from March 1-10 for International Women's Day, highlighting gender gap issues. The proposal is at m:CentralNotice/Request/Int. Womens day 2021. --Yair rand (talk) 11:36, 22 February 2021 (UTC)

I'm only a man, but can somebody tell me when International Women's Day is? You know, a date? Neither of those two links tell me when this damned thing is supposed to be. I guess all the women already know it, but if we're all supposed to celebrate it, or it's supposed to mean something, why is it kept such a big secret? — JohnFromPinckney (talk) 02:09, 23 February 2021 (UTC)
International Women's Day is 8 March. --Malcolmxl5 (talk) 02:25, 23 February 2021 (UTC)
Maybe the reason all the women already know when it is, is because they tried clicking the links, or reading the first sentence of International Women's Day. ¯\_(ツ)_/¯ Levivich harass/hound 02:29, 23 February 2021 (UTC)
If you don't fancy Google, then there is this nifty online encyclopaedia that has articles about things like this and much more. It's called Wikipedia, you might even have heard of it? Anyway, you can find their article at International Women's Day, and in the very first sentence it says International Women's Day (IWD) is celebrated on 8 March every year around the world. it's got a citation and everything! Thryduulf (talk) 02:32, 23 February 2021 (UTC)
Yes, friends, thanks for providing the actual date along with the snide remarks. I was 98.3% sure somebody was going say, "but it's right there in big <color> letters!", and I had just completely overlooked it. And yes, I could have googled, or looked directly for a WP article on International Women's Day, but I foolishly followed the provided link to International Women's Day, thinking (sort of on autopilot) that that must be it.
And while it's good and right that International Women's Day (the unlinked one) included the date, I still think two other pages which make a big deal out of "International Women's Day" would at least mention when it is. You know, for us ignorant people who might learn something. I know when Christmas Day and the Fourth of July and New Years Day are, but I haven't learned IWD yet. Or maybe I'll know it now. — JohnFromPinckney (talk) 04:20, 23 February 2021 (UTC)
Second link in the OP, top of the page: One global banner for International Womens day 2021, available for all gender gap activities around the 8th of March. Levivich harass/hound 04:27, 23 February 2021 (UTC)
Ah, now I see it. Still took me a whole minute, even with your directions. Thanks. — JohnFromPinckney (talk) 04:36, 23 February 2021 (UTC)
You're welcome. As a man, I'm proud you even asked for directions. Levivich harass/hound 05:52, 23 February 2021 (UTC)
International Men's Day is 19th of November. Emir of Wikipedia (talk) 21:51, 23 February 2021 (UTC)
Well, shoot, everybody knows that. Minor, finicky detail: I didn't know there even was a International Men's Day. — JohnFromPinckney (talk) 22:47, 23 February 2021 (UTC)
  • Opposed - WP should not engage in advocacy - no matter how noble the cause. Just spend the day improving articles about women. Blueboar (talk) 15:33, 25 February 2021 (UTC)
This is not advocating for a cause, this is a notice bringing to our attention several events aimed at filling in gaps in the encyclopedia. --Malcolmxl5 (talk) 15:35, 25 February 2021 (UTC)
Reiterating support for this central notice. You may disagree with advocacy, but worth noting English Wikipedia in general has done advocacy e.g. Wikipedia:SOPA initiative, and while not community sanctioned, the Wikimedia Foundation sued NSA. This event itself is not advocacy and most concretely is a call to improve content on Wikipedia. Shushugah (talk) 15:49, 25 February 2021 (UTC)
I try to avoid where possible much celebration of such days, because they often serve as excuses to ignore relevant issues for the rest of the year, but if this encourages people to take part in events that aim to improve Wikipedia then I see no reason to oppose it. It is not advocacy, as in telling people what they should think, which I do oppose. Phil Bridger (talk) 16:32, 25 February 2021 (UTC)
  • I believe that the actual proposal for the banner has been made on meta. The original post by Yair rand above contains a link. Probably editors wanting to express support/oppose opinions should do so there, not here. Nsk92 (talk) 18:11, 25 February 2021 (UTC)

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)
  • Sometimes, edits to one's userpage might be helpful. In the case of receiving barn stars, it should surely make one feel affirmed. Rollo August (talk) 19:28, 28 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 - 11:59, 2 March 2021 (UTC)

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)
  • While I think WP:WBE is a good thing in general along with other metrics that give positive feedback to editors efforts I worry that opening it up for low number of total edits is much more likely to encourage Wikipedia:Editcountitis. Since it's already split 1-5000 and 5001-10000 if it was increased I would suggest just 10001-15000 is added not all the way to 20000. KylieTastic (talk) 10:22, 1 March 2021 (UTC)
  • Meh, I'll be more interested in Wikipedia:List of Wikipedians by number of FA nominations. enjoyer|talk 10:30, 1 March 2021 (UTC)
    Enjoyer of World, that exists. I've redirected your redlink to the page. {{u|Sdkb}}talk 07:19, 2 March 2021 (UTC)
    Cool. enjoyer|talk 08:31, 2 March 2021 (UTC)
  • I strongly support ~12,000, support 15,000, weakly oppose 20,000, and strongly oppose anything past 20,000. 🐔 Chicdat  Bawk to me! 11:29, 1 March 2021 (UTC)
  • Double Meh! Edit counts are really pretty much meaningless as a metric. Why bother? GenQuest "scribble" 02:41, 2 March 2021 (UTC)
  • Triple meh! Editcountitis is the most succinct way of describing this; and well as GQ states they're a pretty much meaningless metric. RandomCanadian (talk / contribs) 04:01, 2 March 2021 (UTC)
  • Oppose. I agree with the editcountitis concerns. Additionally, beyond 10,000 (and arguably even beyond 5,000), the rankings are so high that it's not a very meaningful metric. {{u|Sdkb}}talk 07:22, 2 March 2021 (UTC)
  • I would be against that simply because 10k is more than enough as it is. The list as is arguably doesn't do much to improve the encyclopedia, not sure how expanding it would. Dennis Brown - 12:01, 2 March 2021 (UTC)

Cite book display: contributors/contribution should FOLLOW author/title, not precede them

Moved to CS1 talk. Please comment further there. {{u|Sdkb}}talk 07:16, 2 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.

Here I'm editing Carl Marzani#Published by Marzani & Munsell. The entry of concern displays as

  • King, Jr, Martin Luther; Nelson, Truman (1962). Foreword. Negroes with Guns. By Williams, Robert F. New York: Marzani & Munsell. OCLC 340047.

Only on Wikipedia does the citation give top billing to the author of the Foreword. That's not good, please fix it, so that the entry appears like this:

  • Williams, Robert F. (1962). Negroes with Guns. with Foreword by Martin Luther King, Jr; Truman Nelson. New York: Marzani & Munsell. OCLC 340047.

Even better, since the "Foreword" is actually two separate essays by King & one by Nelson, it would be best to have contribution1, contribution2 and contribution3 as parameters. Larry Koenigsberg (talk) 18:38, 1 March 2021 (UTC)

Please raise this at Help talk:Citation Style 1 which is where citation template issues are discussed. Peter coxhead (talk) 19:33, 1 March 2021 (UTC)
Done. Raised at Help talk:Citation Style 1#Cite book display: contributors/contribution should FOLLOW author/title, not precede them. Larry Koenigsberg (talk) 21:50, 1 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: Pronouns placed in signature for new users

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 (talkcontribs) (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)
  • 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 - 11:56, 2 March 2021 (UTC)

Idea lab

Trigger warnings

Trigger warnings should be added at the beginnings of articles or at least somewhere on the page. Avoids people accidentally stumbling across triggering content. Perhaps in the form of one of those template notice thingies that go at the top of the page? -LocalPunk (talk) 11:14, 25 January 2021 (UTC)

It would be nigh-impossible for Wikipedians, who may not share each others' societal or cultural norms, to agree on a comprehensive standard for what constitutes "triggering content". If the principle of least astonishment is properly followed, readers should generally come across offensive material only when it is expected (e.g. readers should anticipate articles on anatomy will contain images of sexual organs) and enhances their understanding of the topic, which would negate the need for warnings. There is also a general content disclaimer which explicitly warns readers that Wikipedia hosts objectionable content. (See also WP:NOTCENSORED). – Teratix 14:01, 25 January 2021 (UTC)
True. Perhaps a card with a link to the content disclaimer could be an idea? -LocalPunk (talk) 15:40, 25 January 2021 (UTC)
The problem is still which articles should have it, which is a highly subjective choice. —  HELLKNOWZ   ▎TALK 16:24, 25 January 2021 (UTC)
There'd probably have to be some sort of free-to-update list or something. -LocalPunk (talk) 19:19, 25 January 2021 (UTC)
@LocalPunk, I think you will want to read Trauma trigger. There might be some practical value in having a NSFW warning, but there is probably no benefit to a trigger warning. WhatamIdoing (talk) 02:35, 26 January 2021 (UTC)
I strongly disagree with the first paragraph of "In higher education". LocalPunk (talk) 11:35, 26 January 2021 (UTC)
The University is not engaged in making ideas safe for students. It is engaged in making students safe for ideas. Thus it permits the freest expression of views before students, trusting to their good sense in passing judgment on these views.

Clark Kerr, 1961[1]

It might be useful to differentiate between trauma trigger and thing that makes some people uncomfortable. For example, if you saw a person stabbed to death, then you might (or might not) develop long-term PTSD as a result. Your trauma trigger, however, is statistically unlikely to be "seeing people stabbed" or "reading about people being murdered". It's likely to be something like the metallic smell of blood, or the odd motion of the murderer's head, or the food that you had eaten just beforehand. Reading about crimes or watching a violent movie might be uncomfortable (or not; some traumatized people seek out horror films[32]), but it is unlikely to be an actual, bona fide trauma trigger.
There has been talk in the past about certain kinds of content filters. Nobody should have to look at a photo of someone gouging out another person's eye or dead bodies just because Special:Random will sometimes take you to pages related to mixed martial arts or war crimes. But actual trauma triggers, rather than things that make people feel uncomfortable, are probably few and far between on wiki, and warnings for true trauma triggers are probably neither possible (how is anyone supposed to know what your personal trigger is?) nor necessarily helpful. WhatamIdoing (talk) 03:35, 30 January 2021 (UTC)
  • Someone should have warned me there'd be a Trigger warning discussion on this page before I visited it, because every time I see someone proposing trigger warnings I just want to cry. EEng 21:34, 29 January 2021 (UTC)
    I think you're missing a ⸮ there, EEng. 4D4850 (talk) 19:43, 15 February 2021 (UTC)
    What, you think I wasn't serious? EEng 06:42, 2 March 2021 (UTC)
What if it's like one of the banners Wikimedia puts up on articles that need to be reviewed. Just a pale yellow warning "Common Trigger Warning" and editors and decide how specific that needs to be. — Preceding unsigned comment added by Totalart44 (talkcontribs) 06:05, 23 February 2021 (UTC)
  • I agree that there should be trigger warnings on things that everyone can agree on is triggering, like the holocaust or KKK. Starman2377 (talk) 16:25, 25 February 2021 (UTC)
  • I don't think this should be dismissed out of hand - such warnings would not impact article content and would go a long way to making the website more accessible to some. As for what topics should be "warned" for, we could decide on that the same way we do anything else - through editor consensus. A standardized banner template with slot-in content warnings seems feasible and reasonable. BlackholeWA (talk) 23:51, 1 March 2021 (UTC)
  • Seriously, how about if someone creates a browser extension that searches a page for key words and phrases, does some kind of image automagic, etc., before unveiling it. Then it would work on everything, not just Wikipedia. And we can get out of the nannying business. EEng 06:42, 2 March 2021 (UTC)

There should be more "in a nutshell" bulleted lists at the top of the page

I like when some articles have summaries at the top, they are really helpful, especially when I just want to get the most important information. Might be cool — Preceding unsigned comment added by TheFirstVicar4 (talkcontribs) 01:40, 27 January 2021 (UTC)

TheFirstVicar4 - sorry, are you suggesting that this should be adopted for main-space articles? Or just that it should be used more widely on essays/guides/etc? --Paultalk❭ 12:48, 27 January 2021 (UTC)

I'm saying for articles, not only wikiguides. I thought that it would be helpful for slow readers like me — Preceding unsigned comment added by TheFirstVicar4 (talkcontribs) 14:32, 27 January 2021 (UTC)

Does an WP:Infobox fulfill this function? --A D Monroe III(talk) 17:09, 27 January 2021 (UTC)
 
Left to right: Article body; lead; infobox; first sentence of lead; summary of first sentence of lead. EEng 21:26, 29 January 2021 (UTC)
  • This sounds like a good idea. The Encyclopedia Brittannica used to have a Micropedia section and a Macropedia section, the former largely consisting of summaries of articles in the latter. If you looked at one of the many articles on famous people in the Macropedia, and then read that person's entry in the Micropedia, you would see that the Micropedia article would read "Abstract of text biography". Wikipedia does not need to have separate Micro-Wikipedia and Macro-Wikipedia versions, but if abstracts of the articles appeared at the top of articles, that would serve this function. Rollo August (talk) 14:28, 16 February 2021 (UTC)
  • Oppose We already have short descriptions for that. 🐔 Chicdat  Bawk to me! 12:26, 25 February 2021 (UTC)

Vacations

Some companies do mandatory vacations for employees to make sure nobody's absolutely required. I wonder if the same concept could be applied here. Or maybe it's general knowledge what the results would be. Enterprisey (talk!) 09:56, 30 January 2021 (UTC)

everything we do here is written down since writing things down is like, the only thing we can do - so I'm not sure how the bus factor could possibly apply. --Paultalk❭ 21:38, 30 January 2021 (UTC)
There are various areas of wiki which would stop functioning properly, or be notably reduced in quality, if one editor left. Of course, the wiki keeps going in any case. ProcrastinatingReader (talk) 21:50, 30 January 2021 (UTC)
Recorded actions don't tell the whole story, in particular why something was done. Enterprisey (talk!) 23:55, 30 January 2021 (UTC)
It is worth noting, however, that I’m not sure this test helps. The only solution to these areas is to recruit more people to take that spot, which are functions of both our general editor recruitment efforts (from non-editors), and our ability to give existing editors permissions needed to elevate their roles. For example, there was a point last year when Primefac took a short break and BRFA grinded to a halt (and TFDH). There’s no solution to that other than more BAG (which, currently, I guess myself and Earwig are quite active), and more competent template editors with general TfD authorisations. Unblock request patrolling tends to be Yamla and another whose username escapes me. Edit filter requests pretty much rest on SoY, as most edit filter managers don’t interact with that venue, and even SoY can only do so much, so that venue is half useless. L235 was responsible for much of the ArbCom clerking I think, and still is somewhat even after election (updating templates and such). Endless list of examples like this, some of these (and others) more effected than others. No real solution to them other than train new editors, but that’s a problem in itself due to general skepticism. Most areas are documented so someone could pick them up with time, but some more obscure areas rely on unwritten conventions (TFDH work for example, and some of TFD in general). ProcrastinatingReader (talk) 00:51, 31 January 2021 (UTC)
Enterprisey, that's an interesting thought! I don't think people would go for it, but I do think there are things we could do better to help make sure Wikipedia doesn't become overly reliant on any one editor.
There are several different realms in which this applies. With regard to maintaining articles/templates/other pages, I wrote the essay Wikipedia:Build content to endure (WP:ENDURE) with my thoughts.
And then there's bots, which I think are by far our weakest link in this area. There are lots of instances where a bot operator retires, and their bot subsequently stops working, oftentimes leading to substantial damage before anyone notices. I've brought this up before and suggested some ideas, but either they aren't workable or no one has bothered to fully implement them. {{u|Sdkb}}talk 17:19, 1 February 2021 (UTC)
So then why not have a backup operator who becomes operator when the operator retires? Then all bots would be in good quality. 🐔 Chicdat  Bawk to me! 12:29, 25 February 2021 (UTC)
  • And yet somehow we lumber forward. Once solution would be that as soon as a given editor manifests themself as high-performing and knowledgeable, we block them. Then we don't become dependent and future surprises are avoided. (Not sure themself is a word but seems to me it should go with "singular they".) EEng 15:32, 2 February 2021 (UTC)
    Or we should just pre-emptively block anyone who tries to edit. If we also deleted all of our articles we would then have a nice tidy encyclopedia. Phil Bridger (talk) 17:18, 26 February 2021 (UTC)
  • Breaks in some of the "big bots" (via their operators) would be the most impactful; we've got a lot of workflows that depend on this client-side work that is one-deep (for example look at this log: Special:Log/pagetriage-copyvio). — xaosflux Talk 15:38, 2 February 2021 (UTC)
the problem with this is that if an editor has a regular area of editing, then they may lose some credibility if they suddenly stop editing for a long period of time. --Sm8900 (talk) 19:22, 15 February 2021 (UTC)
  • I like this idea. All good organizations do something like this, although it's more commonly aimed at systems than people. See for example, Chaos engineering. -- RoySmith (talk) 16:03, 26 February 2021 (UTC)
  • I thought a more common reason for mandatory vacations was to guard against fraud. It is more likely to come to light that an employee is doing something untoward if such employee can't access an employer's systems for a couple of weeks and someone else performs their (I've been trying to avoid using the singular "they" but can't really be arsed any more here) functions. In any case, it's a nice idea that would be completely impractical in an environment where most workers are anonymous. Phil Bridger (talk) 17:14, 26 February 2021 (UTC)

Should the COI edit request queue function more like RfCs?

Conflict of interest (COI) editing has long been a challenge for Wikipedia. While much of the controversy has centered on undisclosed paid editing (UPE), there also has developed an operating consensus, with support from Jimmy Wales, to encourage an "edit request" process consistent with the Conflict of interest guideline. In a nutshell, it is for responsible paid editors to suggest changes, and for volunteers to implement them if they make the encyclopedia better. This is described in more detail at WP:PSCOI and it has worked reasonably well over time, although like many request queues at Wikipedia, it often has a lengthy backlog.

As of this writing, there are more than 180 open requests, the oldest of which dates back to October. If not an all-time record, it's certainly close, especially following a period from 2018 to 2020 where the efforts of mostly a single editor kept the queue very manageable. Various suggestions have been made at the Village pump over the years to improve upon this process, including adding new parameters to the edit request template and promoting the recently-created Edit Request Wizard. I've given some thought about another way to potentially improve this system, which I've outlined below. My goal is to outline the issues as I see them here, gain some feedback, and hopefully even some support, before taking a more defined proposal to Village pump (proposals). Here's my analysis and initial suggestion:

Review of the current process

Template:Request edit has become the preferred tool for COI editors to submit requests for editor review. Currently, when an editor adds this template to a request posted on an article's Talk page, the request is added to a queue, displayed to editors in the form of a category and summary table. Reviewing volunteers who start from this queue may click on specific links to review individual requests and reply on the article's Talk page.

This template is helpful to the community by centralizing these requests, and to responsible COI editors because there's a much greater likelihood the request will be reviewed by at least one editor, eventually. It therefore provides a guideline-compliant alternative to UPE for those who are willing to take Wikipedia's rules seriously. When the process works, everyone benefits, including Wikipedia's readers.

Problems with the current process

However, the process has its shortcomings:

  • The current framework is not user friendly, for reviewers or COI contributors
    • No instructions are provided, so it is difficult for either volunteers or COI editors to learn how it is supposed to work
    • No information about the request is available prior to clicking through, other than the name of the article
    • Requests are not sorted in any way, preventing reviewers from selecting topics based on knowledge, interest, or type of request
    • Protection level and Last protection log entry information is rarely useful
  • As a result, requests can sit for weeks or even months before being reviewed
  • It is very unusual for an edit request to receive replies from more than one editor, limiting the potential for collaborative solutions

These shortcomings have the potential to negatively impact Wikipedia as a whole:

  • Readers do not benefit from the project clinging to incorrect information only because the person who pointed out the error has a COI
  • Poorly formatted requests waste volunteer time; if the queue was located on a page with a link to WP:PSCOI or the Edit Request Wizard it would be easier to triage these requests for revision
  • Some requests are rejected without substantive consideration, as the queue sometimes attracts editors who seem to have an aversion to COI editing. I understand and appreciate why Wikipedia editors are skeptical of COI editing. They should be! But at the same time, this process exists for a reason, and requests should be decided on the merits. Greater transparency would make these summary dismissals less common
  • A cumbersome submission process and very long wait times incentivizes undisclosed paid editing
Proposed solutions for improving the process

I have lately begun to think it might be better for the edit request process to more closely resemble the Requests for comment (RfC) process, especially the way it transcludes the initial Talk page requests, sorts them into differentiated noticeboards (i.e. /Biographies), and provides a centralized noticeboard consolidating all open requests.

Whatever faults one may identify with the RfC process, it's easier to review questions at a glance, more likely to generate greater participation, and thereby reduce the burden on any one volunteer. RfCs also include designated time limits on discussion, and include invitations delivered by bots to advertise discussions to uninvolved editors. What's more, RfC statements are meant to be brief and neutral, and a revised edit request process could encourage COI editors to take a similar approach.

In this way, the RfC framework could be applied to the edit request process, where submitted requests are hosted on a centralized noticeboard and editors are given a designated length of time to discuss proposed changes and form a consensus. In many cases, requests may still be rejected, and that's fine. If a few editors quickly agree a request is unreasonable, the discussion can be closed, but at least the request was reviewed by more than one person. If editors decide a request is generally appropriate, then the article can be updated based on consensus.

My goal is to allow opportunity for reasonable requests to receive adequate consideration and implementation by neutral editors, not to influence which types of requests are accepted or rejected, nor to dictate who should be allowed to participate in discussions. I do understand that reviewing edit requests takes a toll on the Wikipedia community, i.e. the WP:BOGO analysis. But this is also why I think that making the COI request process more user-friendly and reducing the friction inherent in the current design could make things less taxing on individual volunteers.

Invitations for feedback

In addition to editors watching this idea lab page, I'd like to invite editors to this discussion who may be at least somewhat familiar with the current process because they have responded to submitted requests. Back on January 4, I reviewed the 100 most recently answered COI edit requests, dating back to December 7. Below I've compiled a list of editors who replied to those requests, and I am pinging them in the hope of getting feedback about the changes I've proposed.

Editors who responded to COI edit requests during December 7, 2020 – January 4, 2021

This test was conducted at a good time because User:Spintendo generally stopped editing on October 26. He monitored the queue closely and responded to requests often, until recently. I would certainly welcome his thoughts as well, but by completing this assessment when I did we are able to see what the process looks like without him (much slower!).

So, here's where I solicit feedback from editors. What about the current COI request system is working? What about it is not? What thoughts and concerns do you have about making changes to the system, possibly one which looks more like the RfC process? What is valuable about the RfC process that could benefit COI edit requests? Which aspects of RfC would not be suitable for this purpose?

In closing, I'm hoping to get constructive feedback here before putting forth a more detailed proposal at another village pump page. I look forward to all responses, and I'll take them into consideration as I ponder next steps. Thanks in advance, WWB (talk) 22:55, 8 February 2021 (UTC)

Quick thought: The main problem we're currently experiencing is the lack of Spintendo. The whole process worked mainly because one single editor managed to keep up with the high amount of time-intensive requests, and it broke in the moment they stopped investing volunteer time to help paid editors. There are multiple areas behind Wikipedia's scenes where too much reliance is put on a single person; having to wait years for a bot update at WT:RFPP is another one. I can't provide a proper solution, I can only complain. ~ ToBeFree (talk) 22:59, 8 February 2021 (UTC)
(ec) I have not been as active in answering COI edit requests, and am not necessarily in favor of having an overflow of what would function as RfCs (and I'm not sure how this process would be any different to the current process - RfCs are categorized just like Requested edits, and such cat pages are watched by editors), but I think a solution to addressing the number of COI edit requests is most certainly necessary. What the COI edit request queue needs is editors to address the ERs, not necessarily a bigger process. I thus think that an editor organization or editing rally would be more useful. I would be in favor of WikiProject, or maybe a edit request drive, but not this idea - I'm not sure it would fix anything. P,TO 19104 (talk) (contribs) 23:05, 8 February 2021 (UTC)
I'm not a regular COI-request editor (I answer edit requests on articles I watch), so I didn't know about Category:Requested edits. On first glance, it's rather...offputting. I like the RFC format better, but I'm not sure how simple it would be to display COI requests in that format. They don't have a brief summary or description to transclude the way RFCs do. And if the entire edit request is transcluded, it would be a complete mess. I agree that the process could be improved but I don't know what would make it better. That's probably not very helpful, sorry! Schazjmd (talk) 23:12, 8 February 2021 (UTC)
I don't watchlist Category:Requested edits. I don't like paid editing. I suspect that one of the reasons for the backlog is that I'm not the only one who feels that way. The requests are often very poorly structured, and frequently completely unreasonable. Maybe if the requesters learned how to do it properly, stopped asking for inclusion of anything that is not independently verifiable and gave up on trying to use Wikipedia as a platform for promotion. The latest entry in Talk:Wellendorff is a pretty good example of how not to do it. The solution? Decline such requests faster and block the requester for wasting volunteer time. Vexations (talk) 23:15, 8 February 2021 (UTC)
  • I haven't fulfilled many requests either. Most requests I've seen are usually not directly actionable and require a significant amount of time to fulfill properly. I would expect a good request to be formatted as paragraphs that can be copy-pasted to the article after review. --MarioGom (talk) 23:37, 8 February 2021 (UTC)
I watch Category:Requested edits and I enjoy helping making those edits, but--to be honest--I always pick from recent requests, looking for interesting or easy ones. I like educating the requesters and I like meeting editors through it. I had no idea Wikipedia:Edit_Request_Wizard existed, so I imagine most other people don't. The biggest problem with this process, as I see it, is that there is no process. Some editors list out their editors in a "change X to Y" model, which is incredibly helpful. Most don't, and half my time is spent deciphering what exactly they want to do. Fixing that would do a lot for this process. When edits are formatted like that, I can breeze through them. I'd even be willing to commit to X per month. I haven't yet checked out the wizard, but if it is formatted as:
  • Where is the change?
  • What do you want to change?
  • What's the source?
Then I could run through edits. I also wish there was a simpler approve/deny/more info approach/process in place. Talk page conversations take more time than actual edits.
Just my $0.02. Hope it's helpful. --FeldBum (talk) 23:58, 8 February 2021 (UTC)
@WWB, have you looked at the Wikipedia:Article alerts system, e.g., Wikipedia:WikiProject Medicine/Article alerts? I don't mind processing the occasional edit request (they aren't just paid editors, either), but I don't really want to see requests related to subjects that I don't know anything about. I glanced quickly through the current list of 183 edits, found just one that relates to an area I'm familiar with, and clicked through to discover that one of the best-informed editors was already there. (Then I found two more similar requests, and pinged her to those, too.) If it was easy to find just the (five?) that might be relevant to WPMED editors, then I suspect that these requests might get processed more quickly. I think that Wikipedia:Articles for creation and Wikipedia:WikiProject Disambiguation editors have found that WPMED is very responsive to small requests, and I imagine that the other large WikiProjects would be similarly responsive. WhatamIdoing (talk) 00:46, 9 February 2021 (UTC)
Also, switching hats: @PPelberg (WMF), this problem probably relates to mw:Talk pages project/Notifications and the goal of getting timely responses to comments left on talk pages. Whatamidoing (WMF) (talk) 00:48, 9 February 2021 (UTC)

The biggest problem with the queue is the number of large requests that sit there for months. These requests include changing vast amounts of information, adding paragraphs or completely rewriting the article. I try to complete the requests at the top of the queue, but these are very time-consuming. My process is as follows: I usually rewrite the text to remove the promotional language, off-topic facts and non-notable information. Then, I verify the text because I am not putting my name on a bad edit. If I can't access the sources I ask the requesters to email pdfs. If the information isn't verified, or if the source is not reliable, I discuss the problem on the talk page. This sometimes results in a back-and-forth conversation over several days. This is an exhausting, time-consuming process. I've had requests take over a month to complete. I can't quick-fail these large requests because most of the information is good, adding the text is a net-benefit to the project and I want to encourage COIs to use this process. Sometimes I feel like the queue is getting smaller (I was excited when the backlog got under 100) but then it rapidly increases a couple of days later. If this continues as-is, I'm going to burnout and devote more time to articles I am actually passionate about instead of helping companies promote themselves on Wikipedia. Here are some proposals:

  1. Clearer instructions for reviewers: Template:Request edit/Instructions#For reviewers needs a rewrite. When I started reviewing I had to read the instructions several times before I was confident to begin reviewing. One time I guided an editor on Wikipedia's Discord through the last few steps because they were confused by these instructions. It should be simple to follow, welcoming to new reviewers and feel like it will take a short amount of time.
  2. A WikiProject to support this process, similar to AfC or NPP: I like this idea, proposed above by PTO. We need a place where new reviewers can ask questions and get feedback.
  3. A process where the requester has to fix the problems, instead of putting the burden on reviewers. This might work similarly to AfC, where the article is declined and reasons are given, but the nominator has to go away and fix the problems.
  4. Spin out requests to remove tags: Some requests are to remove tags at the top of the article. If we spin this out this from the queue, it might bring in editors who will focus on that specific section and reduce the backlog.
  5. A limit to how much you can change or add to an article: Each proposal should be limited to four new paragraphs of new text, or text for one section. For example, an editor can request adding four paragraphs to the "History" section of a company, or an update to the "Operations" section, but not both. I chose four because Wikipedia articles rarely have sections that are larger than four paragraphs.
  6. The Edit Request Wizard should include a page that lists common mistakes. These include: adding non-notable awards to articles, off-topic information, announcements of future events, press releases used as sources to show something is notable, press releases to verify a controversial fact, trying to remove negative information, various promo and peacock words. This should be shown before an editor can submit their request.

It is a shame that this queue was supported by one editor for so long. We need this process to stop companies from promoting themselves our platform. I am sorry about my long comment, and I welcome thoughts, ideas, questions and suggestions. Z1720 (talk) 01:46, 9 February 2021 (UTC)

EPW does not trigger on these edit requests. Making it do so might be a good place to start. Subsequent judicious use of the standard responses would probably help keep the queue down. (Maybe an additional one of "rewrite it so it doesn't whiff of promotionalism".) --Izno (talk) 04:05, 9 February 2021 (UTC)

I believe the COI request concept is enormously important to this project. This strong comment may be somewhat surprising given how little I've contributed. I'm using this discussion as an excuse to examine this conflict — why do I sign you tenuously think it's very important yet I am barely involved. Four main thoughts come to mind:

  1. Taking on a request can be hard work if done properly. (@Z1720: hit on some of the reasons.)
  2. There are insufficient rewards for taking on a request.
  3. There are inadequate resources for collaborating with editors with experience in this area (with a slight possibility that those resources exist and I just don't know where they are).
  4. Our advice to editors preparing a request is inadequate

I'd like to address items two and three — they're not the same issue but a potential solution may address both. I invite you to take a quick glance at the CopyPatrol Leaderboard the page related to the tool used to help identify and address recent copyright violations. I pointed out to you with some trepidation — I cannot hold it up as a model of something that works very well, but it has two key elements that are not shared with the COI process. The first is that it acts as its own small reward system. My guess is that most people reading this have never seen that before, so it doesn't fully achieve the goal of being a prominent reporting of accomplishments, but if someone felt that recognizing those who take on this task up to be rewarded, one has to start with identifying them. Unless there is something about the current process that I'm missing, I have no idea who is taking on requests, and how many are handled by each editor. that leads me to the second point. If I'm evaluating a potential copyright issue, and want to consult with others, it's trivial to click on the leaderboard and identify several people to talk to. I try not to pester Diannaa all the time, use this board to identify editors to open up discussion about some thorny copyright issue. Right now, if I looked at a COI edit request, and thought I might be able to handle it but had some questions about best practices, I have no idea whom to contact.

The fourth item might be the most bang for the buck. I've looked at a number of edit requests and most are badly formed. While it would be a little bit of work, conceptually we ought to be able to mockup four or five examples of how an edit request should be formulated covering a range of situations (minor correction of a fact, addition of a reference supporting existing text, substantial rewrite, etc.) I think it's unfair to ask the responding editor to tease out exactly what the intended edit is supposed to be. While I don't propose that the responding editor simply copy and paste a proposed edit, that ought to be a minimum starting point. If we can provide decent examples, we could take a harder line on rejecting requests that don't meet the requirements.

I'm also on board with the observations that the existing list doesn't provide a lot of information about the type of edit requested, or much beyond a hint of the subject matter, and improvement in that area might help.--S Philbrick(Talk) 21:26, 9 February 2021 (UTC)

WWB, thanks for the time you've invested in this matter. The backlog is a serious issue, because COI editors would (understandably) get frustrated with the time they have to wait and it would be very tempting to edit the pages directly. A couple of points:

  • The WikiProject idea suggested by P,TO 19104 sounds like a good one to me and frankly, I am kicking myself for not thinking of it sooner.
  • The edit request wizard needs to be promoted more heavily in the COI help pages etc. Like many other editors here, I hadn't heard of it before it was brought up.
  • While the RfC comparison is interesting, I am not a fan of transcluding all of the information into a dedicated page. It only works for RfC because a short question is supposed to be posed. Edit requests are frequently extremely long. However, the centralised noticeboard is certainly interesting and should be considered alongside the WikiProject idea; classifying edit requests into different categories would make it a lot easier to answer them.
  • I am opposed to Vexations's idea of blocking COI editors who write bad edit requests. That seems over-the-top and would not be useful.
  • FeldBum's recommendations for making an "X to Y" model is great and that should be made clearer to COI editors.
  • WhatamIdoing's article alerts idea seems good, though I confess to not being very familiar with article alerts in general.
  • Z1720's recommendations for clearer instructions are much-needed and I agree strongly with suggestions #1, #2 and #6.
  • I'm on board with pretty much all of Sphilbrick's suggestions. The leaderboard and incentives seem like a natural extension of a WikiProject, and I think collaboration amongst request answerers is definitely a good thing.

All in all, streamlining and making the process more coherent is definitely a good thing, as answering COI requests is not a fashionable thing (I was dragged to COIN just today over a related incident). Making the process better is certainly welcome, and hostility to COI editors who use edit requests in good faith is not helpful. Sdrqaz (talk) 23:50, 9 February 2021 (UTC)

I'm interested in @Z1720's suggestion #5. Should large requests be broken up into smaller bits? You might end up with 10 requests on a talk page, but maybe some of them could then be accepted or rejected easily, and the overall workload would be more manageable. WhatamIdoing (talk) 04:36, 10 February 2021 (UTC)
Another restruction could be to limit one open request per article. This can be combined with limiting the length of the requests and hopefully allow for a faster completion rate. Z1720 (talk) 14:54, 10 February 2021 (UTC)

Reply by OP: consolidated list of ideas

First of all, thanks to everyone who weighed in here with a comment. I didn't know if this would find much interest, but I'm glad to see that a number of others agree that the current process could be improved upon, with many different ideas suggested.

Having read through them all, I am persuaded that a straight "RfC but for COI" is not the right approach—but the COI process could stand to incorporate some things that other projects are doing. Here is a consolidated list of suggested ideas, a few of which were mentioned favorably by multiple respondents, with short explanations where helpful:

Clearer guidance for COI editors

  • List common mistakes and corrections—Some aspects of WP:PSCOI do this, but not clearly enough
  • Point COI editors to Edit Request Wizard (ERW)—From guidelines and advice pages, and perhaps elsewhere

Suggest improvements to ERW

  • Integrate with Template:Edit request—An obvious oversight that should be easy enough to correct, good catch by Izno
  • Build out ERW around common request scenarios—Building on a point made by FeldBum, the current template asks for the suggestion, rationale, and references, which is good but could be expanded, e.g. customized for situations where the COI contributor wants to suggest additions, removals, or modifications
  • Update to use fields more than talk pages—ERW currently sends users to multiple talk pages; if fields could be used like the Commons upload wizard, it would be easier to use still

Improved process for reviewers

  • Clearer instructions for review process—As noted by Z1720
  • Leaderboard to recognize active editors—Suggested by Sphilbrick

Improve Edit request template in a few ways

  • Add a TLDR summary parameter for possible transclusion—As noted by Schazjmd and Sdrqaz, edit requests are too long to transclude; this could be one solution
  • Make more like AfC with feedback and cure period—Suggested by more than one respondent, and I wonder if some templated responses might be helpful in saving reviewers' time

Organize under a WikiProject—First suggested by P,TO 19104 and seconded by others

  • Consolidate guidance for both parties—Improved instructions for both COI editors and reviewers available here
  • Centralized noticeboard—List all requests for reviewers, perhaps with transcluded TLDR summary
  • Prominent ERW access point—Explain ERW and make access prominent here for COIs

Incorporate article alerts—Fascinating suggestion by WhatamIdoing that I don't know enough about, which would require associating the edit request with topics, likely by WikiProject

I think that's a pretty good summary of various ideas that could all work together in some form. A few questions here, to suggest next steps:

  1. If I left out an idea you think is important, by all means feel free to make the case for it in reply here. :)
  2. Any points of clarification or additional information to add about specific ideas mentioned above?
  3. Are there specific ideas in the above that editors weighing in here are experienced with or feel qualified to actively work on?
  4. Any suggestions on how some or all of this could be effectively proposed on Village pump proper?

Thanks in advance, WWB (talk) 17:45, 12 February 2021 (UTC)

WWB, excellent summary. Maybe one step on the "clearer guidance" could be adding a Wikipedia:Edit Request Wizard/COI link to Template:Connected contributor, and a Wikipedia:Edit Request Wizard/Paid link to Template:Connected contributor (paid)? That would give the wizard a little more visibility. (I didn't know it existed.) Schazjmd (talk) 18:10, 12 February 2021 (UTC)
Associating edit requests with topics is usually easy, because most articles are tagged by at least one WikiProject. WhatamIdoing (talk) 19:01, 12 February 2021 (UTC)
Those are good ideas. I just realized I should have pinged Sam-2727, who is the creator of the ERW tool, so now I have! WWB (talk) 20:59, 12 February 2021 (UTC)
@Certes has given me a URL that lets me find edit requests on pages tagged by WP:MED. Here it is:
https://petscan.wmflabs.org/?&sortby=ns_title&ns%5B1%5D=1&edits%5Banons%5D=both&ns%5B0%5D=1&search_max_results=500&cb_labels_yes_l=1&depth=3&language=en&edits%5Bbots%5D=both&project=wikipedia&interface_language=en&categories=Requested%20edits%7C0%0AWikiProject%20Medicine%20articles&edits%5Bflagged%5D=both&cb_labels_any_l=1&cb_labels_no_l=1&before=
If you click the "Do it!" button and then wait a moment, you should see that there are three articles listed at the moment. You can do the same thing for WikiProject Biographies with this link, and in general, you can swap in the analogous category for any WikiProject in the box in the middle of the page. WhatamIdoing (talk) 02:59, 14 February 2021 (UTC)
WWB, thanks for the ping. I didn't know this discussion was ongoing. I was just reviewing the performance of the ERW tool (using this search [33]), and have found mixed results. On the one hand, we seem to have some editors successfully using the suggested fields. On the other hand, we have some editors ignoring the suggested fields and writing a very unhelpful edit request. There are some other problems as well, albeit not as large such as not using the tool for its intended purpose (e.g. to request page moves). I think the proposal above to make the tool in javascript, similar to WP:FUW, is a great idea. Although we've tried to limit the technical knowledge required for edit requests as much as possible, there are still problems. In fact, I feel strongly enough that this change should be made that I would like to work on it. Unfortunately, as I have a limited knowledge of javascript (and particularly its use on Wikimedia), it will take me some time to do so, so if somebody wants to step in and help me/take over, that would be much appreciated.
Overall, I see a very large lack of organization surrounding edit requests. Inconsistency into how users should request edits, how we are responding to edits, and poor documentation surrounding the edit request process. Hopefully WP:Wikiproject Edit Requests could alleviate this. Could someone set up the wikiproject (since it sounds like most people support this idea)? Sam-2727 (talk) 03:22, 13 February 2021 (UTC)
Pinged responding editors Given that I have not had previous experience setting up a WikiProject, I have made it a formal proposal at Wikipedia:WikiProject Council/Proposals/Edit requests. If interested, please leave suggestions/feedback. Sdrqaz (talk) 02:22, 14 February 2021 (UTC)

The OP emailed me to request a comment as another paid editor. IMO, Wikipedia would be better-off consolidating processes, rather than creating new ones. Edit-requests and pending changes are already well-suited for requested edits. Both are easy to add COI disclosures to in an edit-summary or Talk page. Both already attract editors that have an interest in reviewing edits by others.

IMO, adding a feature that allows a user to opt-into pending changes is the best option. Many new volunteers may also find this feature useful, if they are uncertain about an edit. It would give the reviewing editor a diff of the requested change(s) and make it easy to request small changes at-a-time with an explanation of each change in the edit-summary. It would also avoid flooding the Talk page with something edit-summaries are better-suited for.

Frankly, I think the complaints about reviewing Request Edits being time-intensive are largely self-inflicted. Editors treat requested edits as if they were RfCs and are often obsessive about trivial details like wikilinks, accessdates, and so on. I can review most request edits in less than one minute. It may take hours to ensure the requested edit is perfect, but less than a minute to see if it is an improvement. CorporateM (Talk) 19:23, 14 February 2021 (UTC)

Agree with CorporateM--I've been through many GANs that are less exhaustive than COI requests. The current process is clearly not working. For example, I had an edit request made in October. When I reached the front of the queue in February, It looked like someone might answer it, and then they didn't, putting me back at the end of the queue with 200 requests in front of me (probably another six months of waiting at current pace). I see how proposals to limit edit request size could be tempting from a reviewer perspective, but then from the COI side, if it takes 6-10 months to get a response to a single request, you want to put in all your requested changes at once. I would love to have input from more than one reviewer for edit requests, and more of an emphasis on "is this a net positive?" rather than "does this meet the standards of FA?" Enwebb (talk) 15:32, 26 February 2021 (UTC)

Adding "Suggested edits" from Wikimedia Apps to regular Wikipedia

There is a useful feature in Wikimedia apps that suggests edits for users automatically. Wikimedia Apps/Suggested edits allows people to casually edit Wikipedia doing all sorts of recommended tasks and community related help, and its ease of use brings me to the conclusion that it would be a very good idea to implement something equivalent on the main site. I recognize that we have features for improving articles according with very different needs, but the automatic nature of Suggested Edits leads me to believe that it would be a convenient tool for those who want to take advantage of it.Tyrone Madera (talk) 07:39, 10 February 2021 (UTC)

Not sure about this one. Adding captions and short descriptions are helpful tasks, but the main type of suggested edits should probably be prose additions. If people on desktop Wikipedia are looking for little tasks to do, there's tons of backlog categories for little tasks. They're not as pretty looking as the mobile suggested edits, but have the same purpose.
For desktop users, User:SuggestBot/Requests is cool. Or, for smaller stuff, try Wikipedia:Task Center. ProcrastinatingReader (talk) 08:50, 10 February 2021 (UTC)
Tyrone Madera and ProcrastinatingReader, the WMF is actively working on doing so; it's just rolling out to mobile and to some other languages first. See mw:Growth/Personalized first day/Structured tasks and some of the Growth team's other work. {{u|Sdkb}}talk 21:25, 10 February 2021 (UTC)
Sdkb, I see no intention on the part of the WMF to do so in the article you sent. I have only seen mention of mobile and non-English languages, and none about mainstream Wikipedia. Tyrone Madera (talk) 21:42, 10 February 2021 (UTC)
Tyrone Madera, it's very typical for new features to be rolled out to small wikis first to beta test. They're then brought here once they're more fully developed. The WMF folks have communicated that this is their plan on talk pages, which you'll find if you poke around MediaWiki a bit. {{u|Sdkb}}talk 21:45, 10 February 2021 (UTC)
Tyrone Madera --
 
Newcomer tasks feature in Czech Wikipedia
I'm Marshall Miller; I'm the product manager for the WMF Growth team. As Sdkb said, we're thinking along the same lines as you are: that Wikipedians on the web could benefit from a feed of simple tasks to do. It's helpful to hear that other people have that idea, because it reinforces that we might be on the right track with our work. What we've built so far is "newcomer tasks": a feed of articles that have maintenance templates saying that they need things like copyediting, wikilinks, or references. One way to think about it is that it takes the sort of articles that ProcrastinatingReader is talking about, and puts them in a feed that can filtered by topic of interest (see image. We've run experiments in smaller wikis showing that having this feed increases the engagement of newcomers, and so we're quickly spreading it to more wikis so they can benefit.
Going forward, we're adding a new kind of task. Instead of relying on maintenance templates, we're introducing algorithms that can identify articles that might need attention, and make suggestions for changes. The first one is for adding wikilinks, which we're building now (see image). We're also doing the beginning planning around one for adding images.
 
Plans for "add a link" structured task
And like Sdkb said, we do build our features to work on both desktop and mobile web browsers. It's just that we talk about mobile more because it is a bigger design challenge, to get the same functionality on the smaller device. And eventually we want our team's features to be available on all wikis -- but we learn first on smaller wikis. Right now, they're on 18 Wikipedias, including some big ones like French and Russian. I've actually started a project page and discussion here on English Wikipedia, so that this community can start thinking ahead to having the Growth features (that page is due for some updates from me).
Anyway, I hope that anyone watching this page can join in the discussion either here on English Wikipedia or on Mediawiki.org. ProcrastinatingReader, I would definitely be interested to hear what you think about structured tasks. -- MMiller (WMF) (talk) 23:57, 10 February 2021 (UTC)
Sdkb, I apologize for being brusque in my response. Thank you for bearing with me, and thank you MMiller (WMF) for adding explanation, answering all of my questions, and responding so politely. I can't wait for this new feature! Tyrone Madera (talk) 02:14, 11 February 2021 (UTC)
@MMiller (WMF): Apologies for the delayed response. I think structured tasks, as a concept, is a great idea. I think starting out with a blank page is intimidating. I also think adding sourced content, when one has no idea about the MOS or all the other complex policies we have around here, can sometimes be difficult. Some editors will just revert something that looks ugly (ie, violates MOS) from a new editor, rather than clean it up and make it decent. That's just one example. I suspect a lot of people have knowledge to add but not the time or interest to get deep into Wikipedia to get it in the right format, so don't bother adding at all. Anyhow, if you guys can somehow lower the barrier for editing by using structured tasks I think that may be a big + for editor recruitment.
However, the screenshots on the right are not that. Tasks like adding links etc are not well done without context of the bigger picture. See WP:LINKRELEVANT / MOS:OVERLINK etc. People could just be adding links which, yes link to the right article, but shouldn't be linked. And some MOS style suggests only the first link should be linked, and the rest not. The challenge here is that the 'bigger tasks' (adding sourced content, copyediting, etc) seem to be difficult to create into structured tasks. But I admit I haven't spent much time thinking about how they could be. If you could figure it out, that would be a great feature. There's probably some more content-focused editors compared to me who may have better ideas on how this can be achieved. ProcrastinatingReader (talk) 12:11, 23 February 2021 (UTC)
Hi ProcrastinatingReader -- thanks for thinking critically about these ideas. I'm glad you think that structured tasks are generally on the right track -- that's the first step! I agree that there are lots of potential pitfalls around users having sufficient context and understanding policies. Many community members have been pointing those issues out as we go along, and we're doing our best to build in the appropriate guardrails to make a safe and productive experience for newcomers. For example, you mentioned that the algorithm could suggest links that shouldn't be made. The algorithm is built to incorporate that concern in that it is trained on existing wikilinks, so that it has a sense of which sorts of words and phrases tend to be linked. And for when it's incorrect, the full workflow has guidance and onboarding for the newcomer so they can evaluate the suggestions with some guidelines. With the example about only linking for the first occurrence of a word in an article, that's also built into the algorithm. I know we won't solve for everything, but we want to take a good first stab, get a sense of how newcomers do with this task, and start learning how to improve. We'll be piloting this on just a few wikis first (Arabic, Vietnamese, Czech, and Bengali), and so this will manage the risk. At the same time, though, I would like to start the discussion about bringing these sorts of features to English Wikipedia eventually. I'm starting that here, and I hope that you can watch or join in! -- MMiller (WMF) (talk) 21:13, 26 February 2021 (UTC)

Linking cited papers to Connected Papers graphs

I thought it might be useful for wikipedia to add a link in the Works Cited section to the Connected Papers graph of each journal article. Connected Papers finds and visualizes similar papers to the one in question. I think this would make it easier to use Wikipedia as a resource in an academic research setting. They have recently integrated with arXiv and seem likely to support FOSS projects like wikipedia, or at least support us linking to them. TripleShortOfACycle (talk - contribs) - (she/her/hers) 05:49, 12 February 2021 (UTC)

@TripleShortOfACycle: your proposal is to do this for each cited paper, right? That is an interesting idea, though I'm not sure how in-line it is with general citation styles. Elliot321 (talk | contribs) 01:14, 18 February 2021 (UTC)
@Elliot321: Yes, the idea would be to link to a graph for any paper that has a DOI included in its citation. I'm not entirely sure about how to go about setting something like that up though. TripleShortOfACycle (talk - contribs) - (she/her/hers) 07:44, 18 February 2021 (UTC)
@TripleShortOfACycle: it's quite an interesting idea, but I think it would be quite controversial - people can be touchy about citations, sadly. Elliot321 (talk | contribs) 07:59, 18 February 2021 (UTC)

Idea: discussion callout templates

Basically, templates that can go inline to call out a comment or particular groups of comments.

Discourse forums have something where an admin can post a message about a comment to everyone.

Suppose Alice opens a deletion nomination for article "Foo" and Bob writes something like "I like foo". A callout can provide a gentle reminder to remain on topic/stay civil. Of course, if it happens multiple times, then we can just use the uw series.

So the discussion would look like this:

Foo

Foo (edit | talk | etc.)

Does not meet the notability guidelines. Alice (talk) 00:00 1 January 1970 (UTC)

Foo is an amazing shaving cream that I would love to buy. Bob (talk) 00:15 1 January 1970 (UTC)
Have you tried their shaving cream? I love it. Charlie (talk) 00:19 1 January 1970 (UTC)
I could not afford it, but I think this shaving cream is notable enough that we should have it on Wikipedia. Bob (talk) 00:22 1 January 1970 (UTC)
  Please remember to stay on topic. Admin (talk) 00:25 1 January 1970 (UTC)
This article was written by a dummy, so I'd say delete. I am angry (talk) 00:15 1 January 1970 (UTC)
Yeah, look how fat this contributor is. Another angry user (talk) 00:17 1 January 1970 (UTC)
They are obviously a WP:SPA. Always suspicious (talk) 00:18 1 January 1970 (UTC)
  Please remember to assume good faith and stay civil. Admin (talk) 00:20 1 January 1970 (UTC)

I think this would be a good option before page protection if a discussion gets derailed or off topic fast. Sometimes, even a great proportion good faith contributors make mistakes and may get off topic or uncivil, so giving a gentle reminder when the discussion gets heated can cool these discussions back down. Aasim (talk) 22:11, 12 February 2021 (UTC)

  • No thanks. These templates would be cold, patronising and impersonal – editors should compose these messages in their own words. This essay gives a further overview of the problems with these sorts of templated messages. – Teratix 02:00, 13 February 2021 (UTC)
    • The goal is to give gentle reminders which is difficult to do if the discussion becomes heated. The goal of callout templates is not to bite or assume bad faith but to remind all editors about general wiki and forum ettiquette, especially if the discussion is, well, heated and derailed. These callouts would even be useful to remind a large group of new editors our purpose.

I think we should add information about how good the service is to this article. Spammer (talk) 00:25 2 January 1970 (UTC)

  Please remember to adhere to the purpose of Wikipedia when commenting. Admin (talk) 00:25 2 January 1970 (UTC)
Clearer? Aasim (talk) 07:01, 13 February 2021 (UTC)
      • I understand these templates are intended to be gentle reminders, but they will not be perceived as such. – Teratix 23:11, 14 February 2021 (UTC)
      • Putting a box around these makes them sound far stronger and more aggressive. It would be better to have just written a custom comment, if indeed it was worth making. In most cases above, making the callout was undue, and should have waited for more off topic/scope first — Preceding unsigned comment added by Graeme Bartlett (talkcontribs) 00:24, 15 February 2021 (UTC)
  • Awesome Aasim I don't think involving more templates in discussions is a good idea. And admins don't have more power in discussions than any other users. Elliot321 (talk | contribs) 01:13, 18 February 2021 (UTC)
    • I don't feel like the admins would like this much, either. I'm thinking that there might become a backlog of "Stuff the admins must put callouts on." We already have quite enough backlogs. 🐔 Chicdat  Bawk to me! 11:30, 27 February 2021 (UTC)

Monthly articles for all years since 1990

(This might have been proposed before. Also, if this idea is in the wrong place, please tell me where I should put it.)

In each year article from 1900 to 1989*, the events section links to detailed monthly articles for each month, each of which in turn lists several events for each day therein (as well as the corresponding day of the week). Meanwhile, for all the year articles from 1990 to 2021*, the events section is merely a sparse listing of various occurrences, with no monthly articles at all (each monthly title is a redirect to the appropriate subsection of the events section). However, the period since 1990 has been hardly lacking in historically important events. To fix this discrepancy, I propose that, for each year since 1990 to the present, monthly articles should be created for each month, with content for each day. This would greatly improve our historical understanding of recent & important events.


*At least I think so. I haven't bothered to check every article, but this seems to hold for every one I've visited.

Duckmather (talk) 18:08, 15 February 2021 (UTC)

You don't need to ask permission to create articles. If you think you have enough material to write a stand-alone September 1997 (or whatever) article, you can just go ahead and do it. ‑ Iridescent 20:18, 15 February 2021 (UTC)
There is no such article for any month from 1986 to 1989. April 1985 is the last. Portal:Current events/Events by month has links to portal pages about every month from July 1994. The months only transclude daily pages like Portal:Current events/1994 July 2. At Wikipedia talk:WikiProject Years/Archive 11#Using archives of Portal:Current events for month articles it was decided to not show them in mainspace. PrimeHunter (talk) 08:25, 16 February 2021 (UTC)
Thank you for the reply! I'm going to shelve this idea because it's already been discussed to death, and consensus seems to indicate that yearly articles are enough. (My dad tells me that these monthly articles have questionable historical significance anyways.) Duckmather (talk) 20:36, 19 February 2021 (UTC)

Democracy of wikipedia

I wondered if, even if it is possible, that discussions that occur, like changes to Notability, that editors are notified to make Wikipedia more democratic? At the moment it seems that when policy changes are being discussed and made, it seems to be the same small band of editors, and in most cases most editors don't know it is actually happening.

My idea is that when policy is being discussed all editors get a discussion notification, and at the end of the discussion all editors get a notification to vote. Once the vote has been completed then the notification is sent to all editors to let them know of the change, if any, to policy.Davidstewartharvey (talk) 06:59, 16 February 2021 (UTC)

Any proposed major change already gets listed on {{Centralized discussion}} which in turn appears at the top of over 5000 noticeboards and policy pages (including this one); it's not as if we're hiding discussions to keep them the preserve of a clique of insiders. At any given time, we have a lot of Requests for Comment ongoing (these are just the currently-open ones, and posting notifications of all of them to all 41,061,985 editor talk pages would totally flood Wikipedia; there isn't a practical way to only notify of the major ones, since no two editors will agree on what constitutes "major". If you want to increase the likelihood of your being notified about proposals in particular areas, add your name to the relevant sections at Wikipedia:Feedback request service. (For what it's worth, Wikipedia's definition of "notability"—significant coverage in reliable sources that are independent of the subject—has been unchanged since May 2007, and is one of the few things on Wikipedia which is never seriously challenged; changing it to even a minor degree would have such a huge knock-on effect on Wikipedia's existing content as to be unworkable.) ‑ Iridescent 07:45, 16 February 2021 (UTC)
We could advertise T:CENT discussions on watchlists, like RfAs? In a streamlined columns way (eg 3 items per row), so it's not too crowded. Usually not more than 5 enwiki CENT discussions running at a time. Not saying it's a good idea, but just a thought. Btw, surely we don't have 5000 noticeboards and policy pages? ProcrastinatingReader (talk) 14:13, 16 February 2021 (UTC)
A lot of that 5000 that have T:CENT transcluded are archives rather than active noticeboards, but if anything we probably have more like 10,000 active noticeboards. There are thousands of de facto "anyone who's interested in the topic is going to have this watchlisted" noticeboards like WikiProject talk pages and high-traffic article talk pages like Talk:Joe Biden. If there were a way to restrict who it was shown to, I think putting T:CENT at the top of everyone's watchlist would be a good idea, but if and only if we could restrict it so it wasn't shown to everyone (maybe the 500 edits and 30 days threshold we already use elsewhere?). One lesson the watchlist notice for RFAs has taught is that it can be counterproductive to invite brand new editors to participate in discussions on complex issues, as they make good-faith comments, get slapped down for failing to understand the issues, and in turn get demoralised and quit, and a lot of the issues that come up at T:CENT are quite inside-baseball. ‑ Iridescent 15:43, 16 February 2021 (UTC)
Technically speaking, at least, I think it might actually be possible to limit it to showing for ECP only. Usually you can add a class “sysop-show” or “autoconfirmed-show” to things to hide them from everything but that group. There’s probably one for ECP too. ProcrastinatingReader (talk) 16:31, 16 February 2021 (UTC)
Ah, yeah, “extendedconfirmed-show” exists in mediawiki:Group-extendedconfirmed.css, so that’d probably work. ProcrastinatingReader (talk) 16:35, 16 February 2021 (UTC)
I'd support only showing it to ECP users. We probably don't want too many newbies stumbling into these discussions, but it's better for more people to find out about them. Elliot321 (talk | contribs) 01:09, 18 February 2021 (UTC)
There's definitely room for improvement in this. Yes, super major changes might make it to centralized discussion, but let's not pretend that all discussions get the amount of discussion they deserve. There's definitely some RfCs and changes that set precedent that are done in backwater places with an element of "gaming the system" at play. One thing that we need to improve upon is reprimanding editors that appear to be doing this. Jason Quinn (talk) 12:55, 16 February 2021 (UTC)
I'm not sure how you plan to determine which editors are gaming the system and which are just raising it on the most applicable (but less viewed) pages. There isn't a clear marker on which discussions belong on the central hub and which on their relevant policy/guideline talk pages. Nosebagbear (talk) 00:50, 18 February 2021 (UTC)
Very impacting RFC's are also added to the watchlist notice, generally related to major changes that affect large numbers of editors. Inclusion criteria is subjective, but in general WLN's about RFC's are more stringent then for T:CENT. (e.g. Special:PermaLink/975679275 from a few months ago. — xaosflux Talk 20:19, 18 February 2021 (UTC)

Second Opinion Symbol Concept

Over at WP:GA they have support symbols ( ), oppose symbols ( ), and on-hold symbols ( ) to represent the various results of a good article review. However, one neglected result is asking for a second opinion, which currently is represented with a neutral vote ( ) which I believe does not make much sense and doesn't convey much. I propose an icon similar to one like this; forgive the terrible art, I made this on Chrome Canvass with a mousepad. Panini🥪 14:17, 16 February 2021 (UTC)

To clarify for folks, if I understand correctly, this would only affect the Wikipedia:Good_article_nominations queue. You can see how it currently looks by going to that page and searching for the words "Second opinion" (there's one at the top of the World history queue now, but who knows if it'll be resolved by the time you read this). I think it's a nice idea. Ajpolino (talk) 20:34, 16 February 2021 (UTC)
Panini! I like the idea of a question mark too, though obviously it should be drawn with a bit more, uhm, accuracy than what you did. Elliot321 (talk | contribs) 01:07, 18 February 2021
Well, no duh, it was just a concept. Panini🥪 02:00, 18 February 2021 (UTC)
Great idea! How to find people to make it into a proper symbol? FemkeMilene (talk) 20:56, 18 February 2021 (UTC)
  • DYK uses {{DYK?again}} to request another review(er). The symbol is  .
There are also lots of symbols on Commons such as File:SegundaOpinión-Artículo bueno.svg which was intended for this purpose. It doesn't work so well at the size of the other icons – 16px:  
Here's how it looks at 128px:
 
Andrew🐉(talk) 21:43, 18 February 2021 (UTC)
I'm not sure how helpful such a symbol would actually be, but repurposing the DYK icon that Andrew pointed out seems like a good solution. The issue I have with the Panini's proposed image is that—when used at the same px size as support and oppose symbols—the 2 and ? would probably be too hard to see. Aza24 (talk) 02:46, 22 February 2021 (UTC)
Well, how about this? 🐔 Chicdat  Bawk to me! 11:20, 27 February 2021 (UTC)
 

Wikivoyage Mobile App

Wikivoyage is one of the best projects of Wikimedia. In last days, I'm so concentrated to develop the new opened Turkish Wikivoyage page. And I think, an official mobile app for Wikivoyage is a good idea. It can be perfect for the travelers around the world. The people mostly use their smart phones during traveling. This project will not make much sense if there is no app of WV.UcuncuUlus (talk) 13:27, 20 February 2021 (UTC)

That is a separate project from Wikipedia, and so it should be discussed there instead. According to Wikivoyage Community Portal [34], feature requests go into phabricator [35]. There is also the "Traveler's Pub", which looks to be like the Wikipedia Help Desk, so maybe try there first [36] RudolfRed (talk) 21:11, 20 February 2021 (UTC)

Regarding falseblocks under Sockblock

I recently came across User:IHateAccounts's talk page, and I think that we should allow appeals through socks only if they claim that they are not actually socks of the sockmaster. Like, suppose person A is not a sockpuppet of person B (sockmaster), then under WP:SOCKBLOCK, person A cannot appeal, as all sockblock appeals must be done through the sockmaster, which they cannot access. ThatIPEditor (talk) 08:13, 23 February 2021 (UTC)

Idea for new possible skin

Since I started using Ubuntu, it has seemed like an interesting idea to have a skin on Wikipedia that makes Wikipedia look like a command prompt or a terminal. I know it probably won't get implemented, and even if it gets implemented, very few people will use it, but it seems like an interesting idea. 4D4850 (talk) 01:27, 24 February 2021 (UTC)

What do you mean by "look like a terminal"? If you just want fixed-width fonts and no graphics, just install Lynx; you don't need to mess around reskinning websites. ‑ Iridescent 05:33, 24 February 2021 (UTC)
Ok, that is basically what i was imagining. Thank you. 4D4850 (talk) 16:26, 24 February 2021 (UTC)
4D4850, Also, Wikipedia:Wikipedia-mode.el for the truly hard-core. -- RoySmith (talk) 13:29, 25 February 2021 (UTC)

i would like a article on Tim's reinforced slingshot

this is the reinforced slingshot https://cults3d.com/en/3d-model/various/tim-postma-s-reinforced-slingshot though is also available on MyMiniFactory — Preceding unsigned comment added by Tim3dPostma (talkcontribs) 17:24, 24 February 2021 (UTC)

@Tim3dPostma, TimPatAlPostma1996, TimPostma3DPrints, Timpatalpostma, and 3DPrintingTimPostma: You need to immediately stop trying to promote your catapult. It does not, nor ever will deserve an article here. Wikipedia is not for promoting your inventions or design modifications. Your editing has become disruptive, and I am about to leave you a formal warning on your multiple usepages, not only about creating and using multiple accounts at the same time (see WP:SOCK), but also to warn you to stop using Wikipedia a forum to try to discuss silly off-topic matters, unrelated to the article in question. In essence: stop editing rubber band-related articles. Nick Moyes (talk) 23:59, 24 February 2021 (UTC)

Adminbot for WP:U1

Curious if anyone has considered writing a bot to automatically handle many WP:U1 speedy deletions? To prevent abuse, it should make sure that the page was either created in the user's userspace, or never edited by anyone other than the user (so someone couldn't move a page to their userspace to get it deleted, or U1 an article they created but others had built). This could significantly speed up U1 and leave admins to do things more useful. Elliot321 (talk | contribs) 02:31, 25 February 2021 (UTC)

You might want to check out 7SeriesBOT. If you're a glass-half-empty type of person, see this instead. -- zzuuzz (talk) 03:16, 25 February 2021 (UTC)
Ah, interesting, didn't realize such a bot existed. Elliot321 (talk | contribs) 06:46, 25 February 2021 (UTC)

Allow all users to view only their own deleted contributions

Today I was looking at my edit count. It had said that I had "306 deleted edits" and I wondered, to what pages were they. I looked, and got the following message:

You do not have permission to view a page's deleted history, for the following reason:

The action you have requested is limited to users in one of the groups: Administrators, Oversighters, Researchers, Checkusers.

And I was all like, "Well, it's my contributions. Why can't I see it?" And I know all their arguments: The pages are deleted so that people can't view them, and some are actually harmful etc. But I am proposing that, say, if there was a non-admin named Example, then, under my proposal, the only people who would be able to see Special:DeletedContributions/Example would be admins, and Example himself. I must clarify that. It would be like editing /js and /css pages (only user and interface admins can) except that all admins would be able to view it. Any thoughts on this? Changes to the proposal are welcome. 🐔 Chicdat  Bawk to me! 12:25, 25 February 2021 (UTC)

This is not going to happen. We could hypothetically amend MediaWiki to allow you to view deleted pages to which you were the only contributor, but what you're proposing would mean that if someone wrote a page filled with libel and you happened to make a single typo fix to it before it was deleted, we'd be granting you the right in perpetuity to read that libel. I can't imagine any circumstances in which Legal would ever allow this. ‑ Iridescent 13:10, 25 February 2021 (UTC)
As a practical matter, if you want/need to see something of yours that has been deleted, you could ask at WP:REFUND. Depending on what it was, an admin might be willing to undelete it to your sandbox, or perhaps even email it to you (not all admins are willing to do that). Alternatively, there's a number of wikipedia mirror sites where you might still be able to find a copy. I think most of them are pretty slimy, so I won't mention by name, but I'm sure you can find them if you google for "wikipedia mirror". -- RoySmith (talk) 13:27, 25 February 2021 (UTC)
That's not what I'm looking for. I myself saved a userspace copy of my only real article that was deleted. I was talking about Aasim's idea. 🐔 Chicdat  Bawk to me! 11:19, 27 February 2021 (UTC)
I think deleted edits should show up in the same manner as revision deleted edits. So if a page is deleted, it removes the edit summary and the revision, but not the user from the contributions page. Aasim (talk) 18:37, 25 February 2021 (UTC)
But like was noted above; there are reasons outside of notability why an article might be deleted (copyvio, libel, gross vulgarity, etc.) and the software has no means of telling one edit from another. Lets say you were a new page patroller who tagged an article for speedy deletion as a offensive attack page. Now you're an editor of that article. There's no gain to be made from allowing you as the article tagger to view the content. It's not like you had a meaningful contribution. A large proportion of deleted articles fit in this type; I understand the impetus from the OP, they're envisioning an article they created which failed notability checks, and was deleted via an AFD or something, and now they want to look in on it and see if they can fix it up and make it acceptable. That's certainly some of what we delete, but it isn't all of what we delete, and much of what is deleted really should never be viewable again. The software has no means to differentiated between that kind of content NOR does it have a means of distinguishing from among a group of several editors, who created the content and who tagged it for deletion. Those are all just "edits". --Jayron32 18:57, 25 February 2021 (UTC)
I don't think Aasim is talking about content or edit summaries, but rather just revision history of deleted edits. If I remember correctly from a past discussion, this data is already available via the API. See Wikipedia_talk:Sockpuppet_investigations/Archives/Archive23#Useful_user-right ProcrastinatingReader (talk) 19:32, 25 February 2021 (UTC)
You mean like just a raw list of the edits that were deleted, not like diffs or anything? That seems less objectionable. --Jayron32 19:55, 25 February 2021 (UTC)
Basically: 1 January 1970 (diff | hist) . . (Edit summary removed) on the contributions page. Aasim (talk) 20:51, 25 February 2021 (UTC)
Yes! That's what I mean. I can't see the revision, or edit summary, or history — I can just see the name of the page I edited. 🐔 Chicdat  Bawk to me! 10:54, 26 February 2021 (UTC)
This request basically requires phab:T20493 to be resolved first, which has some issues as-is. --Izno (talk) 20:58, 25 February 2021 (UTC)

Bringing back the GA Cup

 
Congratulations! Your GA has been approved!-EEng

The GA Cup used to be a competition that directly encouraged editors to improve more articles into GA status. But the last GA Cup was in 2016 and there hasn't been a competition since. To deal with the backlog of GA nominations, as well as to improve more articles to GA status in general, I suggest bringing this competition back. Thoughts? X-Editor (talk) 06:20, 27 February 2021 (UTC)

Yes. It always says on the template, "Please wait patiently", but many editors are impatient. A GA Cup would really reduce the backlog. 🐔 Chicdat  Bawk to me! 11:16, 27 February 2021 (UTC)

Talk pages redesign

I tried looking through the archives and couldn't find something like this, so I'm posting here.

In my opinion, the whole talk page format needs to be radically redesigned. It is just plain difficult to use. For one, an editor needs to use source code to be able to participate in a talk page, which is a high barrier in terms of time (inputting the proper syntax correctly) and knowledge (source editing is not intuitive).

Four big issues I see:

  1. There is no easy way to input a comment and add it. Most other platforms you can type something in, click submit, and voila- you commented. On Wikipedia, you need to wade through the text and find where to write something, how to indent it, etc.
  2. No nesting of comments. There is no way to easily find who said what in a talk page discussion, and this is especially problematic for long comments, improperly indented comments, etc. It also makes reading through a long page quite cumbersome.
  3. No automatic signatures or notifications. If I make a comment, I would expect it to say that I wrote it and also to notify anyone else. Right now both those functions require someone to know how to do so and to take the time to add a ping, signature, etc.
  4. Source editing. As mentioned above, it's a high barrier in time and knowledge.

In an ideal world, I'd see the talk pages look more like Reddit or any other platform with discussion boards. A short-term solution would be to enable Visual Editor, which is currently not enabled on Talk pages.

I know I can't be the only one who has noticed shortcomings with the Talk page format. What are your thoughts on Talk Pages and how they could be improved?

Fredlesaltique (talk) 14:04, 27 February 2021 (UTC)

@Fredlesaltique: There is mw:Talk pages project/Replying, which is being worked on, where you can reply in the visual editor and (I think) add signatures automatically which should address #1, #4, and part of #3, with the visual editor having a button to add a ping to a user. Terasail[✉] 14:56, 27 February 2021 (UTC)
See also an example of Flow here: mw:Talk:MediaWiki - while it addresses some of your concerns it bring forth a whole new set of problems. — xaosflux Talk 15:59, 27 February 2021 (UTC)

Encourage and switch raw Infobox data to to Wikidata

This was originally proposed on Wikipedia_talk:WikiProject_Wikidata#Encourage_and_switch_raw_Infobox_data_to_to_Wikidata but nobody responded so I'm posting it here before I formally propose it.

I notice that popular templates like Template:Infobox company's documentation indicate that Wikidata is supposed to be used a fallback, and that data that you know should still be inputted as arguments.

This seems a bit counterintuitive to the purpose of Wikidata. It also makes me, a Wikidata editor and Wikipedia Infobox Wikidata converter, feel like what I'm doing is pointless.

If people are still recommended to input raw information into infoboxes, then some data that they input might not be present on Wikidata. And that means that someone else is going to have come around manually add that data and it's reference to Wikidata.

Clearly, the best situation would be everyone that adds information and references to Wikidata and the data then shows up on Wikipedia in all parameters. That way all data is linked on Wikidata with appropriate items, can be used by other language Wikis (I think this is a really strong point), and is referenced.

But unfortunately this does not happen. Yes, we have bots that copy data from infoboxes to Wikidata, but that isn't set up or running for every type of infobox. Also, it shouldn't be needed. We should just have editors edit Wikidata and we wouldn't ever have to worry about it.

What I propose

  • Encourage editors to add statements for appropriate Infobox parameters on Wikidata so that they can simply just use the Infobox template and not have to fill in any parameters.
  • Create a Wikiproject/process of deleting raw-text Wikidata-backed arguments currently in Infoboxes so that they use Wikidata. This is to demonstrate what parameters have documented Wikidata, show that they are referenced, and encourage editors who see the Wikidata to continue using it.
    I'm aware this is quite radical, but I'd really like Wikidata to be of use and "linked", and not just replaced by duplicate work.
    Another solution could be just to have Wikidata override raw-text values or maybe just make it so that raw-text values can't even be used anymore (the template parameter would not even be used). See (Extra) solution below how Wikipedia editors could add this Wikidata easily.
  • (Extra) Maybe develop an indicator on infoboxes or some sort of process or program that makes adding statements for infobox parameters easier for Wikipedia editors. For example, an edit icon on a parameter that does not have Wikidata, but whose statement could be added by clicking on the icon.
    If that parameter has a raw text value, maybe it could be highlighted red to indicate it's not on Wikidata. An edit icon could be next to that as well that leads to Wikidata, and maybe even copies the data to Wikidata.

--Lectrician1 (talk) 21:06, 28 February 2021 (UTC)

  • Strongly oppose There are many reasons why this is a bad idea. Some are:
    1. Wikidata does not insist on sourcing in the way that we do, so picking up information from Wikidata means giving up our standards on requiring reliable sources.
    2. There are many fewer active editors at Wikidata than there are here, so vandalism is much less easily detected and dealt with.
    3. Simple data, such as dates of birth and death, might be appear to be appropriate to be retrieved from Wikidata (provided WP:BLP issues were fixed). Other apparently straightforward data is both disputable and disputed. People's nationality is a good example. Different language wikipedias can legitimately have different policies on matters like these (is "Tibetan" an acceptable nationality or not? do you use current or historical borders?). Taxoboxes are a particular case of infoboxes where multiple discussions have shown why using Wikidata would be a bad idea since classifications are subjective and different wikis make different choices.
A more general problem is that the data analysis and design of the Wikidata item has to closely match that used here for this to work. As an example, review the discussions at Template talk:Cite Q to see some of the problems in the case of citations. Unless the Wikidata item handles fields in the same way that our citation templates do, the information can't be retrieved properly. I think most data design problems can be overcome, but it does require an open dialogue between editors in language wikis and Wikidata editors, and an acceptance there that Wikidata has to fit the language wikis and not vice versa. This has been difficult to achieve to date, to say the least. Peter coxhead (talk) 09:38, 1 March 2021 (UTC)
Since these same points inevitably come up in every Wikidata-related discussion, I feel obliged to comment. While the gist of the critique is correct, some details are outdated.
  1. While it is true that, in practice, Wikidata is not as well sourced as Wikipedia, in theory, the verifiability standard is very close to ours – although as of this time, the d:Wikidata:Verifiability policy has not been formally approved. In any case, whatever templates we use here may be configured to fetch only data that is referenced, and referenced to a particular standard (e.g. not to Wikipedia).
  2. It is probably true that vandalism is usually not fixed as fast on Wikidata as it is here (though I'd like to see some numbers), there is also much, much less of it.
  3. Wikidata supports multiple values for a single fact. It's up to templates on Wikipedias that use it to determine which value to fetch, or what to do with the value (such as aggregate them to a parent class or category). As for BLP, Wikidata now has a d:Wikidata:Living people policy.
Cheers – Finnusertop (talkcontribs) 11:09, 1 March 2021 (UTC)
@Finnusertop: I accept that there are changes happening at Wikidata, albeit slowly. The problem with vandalism (or indeed well meant but incorrect changes) if Wikidata is used is similar to the problem with the automated taxobox system, which pulls taxonomic data from taxonomy templates stored here. I monitor the taxobox error-tracking categories most days, and, yes, there are fewer problems caused by vandalism to the taxonomy templates than directly in articles, because they are less obvious. But vandalism does occur, and when it happens it usually impacts multiple articles and can only be fixed by an editor who understands how the system works. If we do pull data from Wikidata, we would need some way of being notified here when the relevant Wikidata items change and some good error-tracking categories or other system. Peter coxhead (talk) 12:50, 1 March 2021 (UTC)

So it looks like some more technical challenges need to be addressed before we move to this system. --Lectrician1 (talk) 18:58, 1 March 2021 (UTC)

@Peter coxhead: Oh I agree. By the way, the English Wikipedia watchlist already shows if the associated Wikidata entry has been edited. – Finnusertop (talkcontribs) 03:22, 2 March 2021 (UTC)
@Finnusertop: showing changes in the single linked Wikidata item is not very helpful – which is what I understand happens at present – given that many uses would need to pull data from multiple items. This is already an issue with taxonbars when the taxon has multiple synonyms, each with a Wikidata item from which the taxonbar draws data. To watch Acmispon haydonii fully, for example, I would need to receive notifications about the four Wikidata items the taxonbar uses. The issue is even more obvious with {{Cite Q}}. It has to be possible in some way for a language wiki article to be linked automatically to each and every one of the Wikidata items it uses. Peter coxhead (talk) 07:16, 2 March 2021 (UTC)

WMF

IP Address Masking Confirmed As Mandatory

Per a recent update on the IP Masking project, Legal has apparently decided that IP masking is no longer desirable but mandatory, with consultation now limited to implementation form.

Thus far Legal have not provided reasoning on that, but they are set to give a statement (detail level unknown), likely in the next week.


As this will have a significant effect on anti-vandalism efforts, please provide your ideas, concerns, and comments on the discussion page on how to mitigate any negative consequences and utilise any potential positives. Nosebagbear (talk) 10:19, 19 October 2020 (UTC)

This link will be useful here--Ymblanter (talk) 11:01, 19 October 2020 (UTC)
Looks like we need, and will have, an RFC on this. Alsee (talk) 09:38, 23 October 2020 (UTC)
I believe that our traditional workflow is as follows:
  1. The W?F proposes something on an obscure meta page. Nobody notices.
  2. The W?F posts it somewhere else, and literally everyone who replies hates it.
  3. The W?F reaffirms their commitment to listening to user feedback.
  4. The W?F announces that they are going to go ahead and do it anyway and you can all go and pound sand.
  5. An RfC is posted. Hundreds of people contribute. The result is overwhelmingly negative.
  6. The W?F goes ahead and does what they were always planning on doing.
  7. The shit hits the fan, admins resign, The Signpost does a feature. Wikipediocracy does a feature. The Register does a feature. The Guardian does a feature. The New York Times does a feature.
  8. The board of directors tells the W?F to knock it off. Nobody gets fired or demoted.
  9. Return to start.
I will make popcorn. --Guy Macon (talk) 17:19, 23 October 2020 (UTC)
Sometimes they skip step 4 and go straight to step 6, which we then follow with step 5. Extra butter, please. – Jonesey95 (talk) 17:58, 23 October 2020 (UTC)
 
Depiction of Wikipedia Foundation Wikimedia Foundation destroying Wikipedia with the Fram ban, IP masking, and the 2020 rebrand instead of making obvious but boring improvements to what we have. —pythoncoder (talk | contribs) 18:52, 24 October 2020 (UTC)
The W?F has thrown a lot of crap at us before, but basically saying "we want more vandals" is a new low. Popcorn tastes good. —pythoncoder (talk | contribs) 18:52, 24 October 2020 (UTC)

This might be a good next step. -- RoySmith (talk) 21:30, 1 November 2020 (UTC)

I've said this elsewhere, but didn't gain much traction. Showing IP info to logged-in users isn't a problem. Exposing it to every anon, scraper and mirror is a problem. But W?F want to hide it from all of us. Pelagicmessages ) – (20:33 Thu 05, AEST) 10:33, 5 November 2020 (UTC)

  • There should be some freedom for project communities to decide which flag should include the technical right to see IPs. Some projects may decide to allow it to patrollers, other only for admins (W?F proposal doesn't even allow admins). Ain92 (talk) 20:07, 29 November 2020 (UTC)
What is the exact legal issue? Can wikipedia just encrypt the ip address with a different id for each edit? Wakelamp d[@[email protected]]b (talk) 13:16, 14 December 2020 (UTC)
  • I think every edit should be randomized, so you never know who made what edit, on talk pages and articles. 100% mystery, even admin actions and Arb discussions. That would fix all our problems and make Wikipedia a great place to be an admin at. Maybe they will bump it up to that. Dennis Brown - 23:13, 10 January 2021 (UTC)
  • I never thought I would wind up advocating that we suspend IP editing, but that now seems to be the sensible option, at least until the WMF has a solution in place and working reasonably well on a sizeable Wikipedia. ϢereSpielChequers 23:34, 10 January 2021 (UTC)
    • What do you mean? Which Wikipedia? Jason Quinn (talk) 15:27, 26 January 2021 (UTC)
      • If the WMF comes up with a design for IP masking that one or more of the 300 language versions of Wikipedia agrees to test then I would be interested to see the results. For EN I think we should follow Portuguese. ϢereSpielChequers 23:36, 8 February 2021 (UTC)
    • WereSpielChequers, no kidding—I have always viewed IP editing as an integral part of Wikipedia, but this project is only making me think that can't last. I typically am blasé about general WMF/project governance decisions, but this one I have some serious concerns about. Perryprog (talk) 21:58, 14 February 2021 (UTC)
I say this advisedly. You have got to be fucking kidding?--Fuhghettaboutit (talk) 06:02, 24 February 2021 (UTC)

UCOC Survey

There doesn't seem to be an UCOC survey for enwiki, but you can participate in e.g. the Wikidata one, here. Most questions are not Wikidata specific anyway, and a fair number are hardly intelligible. E.g. "In the event consensus will be reached about the establishment of an "enforcement body", either on Wikidata or within the Wikimedia community, to address harassment and threats, how much do you agree with the following statements? ... Larger communities should have the possibility to opt-in the scope of action of such "enforcement body", should there be consensus about it." Do you agree or disagree with this? No idea, I don't know how a community can "opt-in the scope of action"[sic] if the enforcement body is established locally in the first place. Fram (talk) 14:35, 12 February 2021 (UTC)

I have seen that a survey has been sent to some people on Commons though the questions are different between the two surveys seemingly reflecting that the two "facilitators" are different people. Xeno (WMF) what can you tell us about enwiki? Best, Barkeep49 (talk) 16:07, 12 February 2021 (UTC)
Thanks for the questions Fram & Barkeep49: some local consultations started earlier as they required more time due to the translation workflows or multilingual nature of those projects (and while I've been following along, the individual facilitators would be better placed to discuss).
For enwiki, the upcoming consultation planned for March (entitled "Meta-wiki consultation") which I'm designing will involve global discussions as well as discussions that are tailored to individual projects. I hope to ensure that any points where the global policy is impractical in individual community contexts are identified and clearly highlighted to the drafting committee writing the application section.
Please let me know about any other ongoing local discussions, or if you have any thoughts about the upcoming consultation. Xeno (WMF) (talk) 20:40, 18 February 2021 (UTC)
@Xeno (WMF) I feel like I have less of a grasp on what will happen than before i started reading this message. Enwiki editors will be expected to participate in meta conversations if they want a voice? Best, Barkeep49 (talk) 21:11, 18 February 2021 (UTC)
Barkeep49: The goal is seek feedback from editors of all communities, so discussions that happen locally will be considered and are linked from meta:Universal Code of Conduct/Discussions#Community discussions. Since the formal consultation will involve many different languages and project types, we're still finalizing the exact process to ensure all the feedback is properly organized and considered. Xeno (WMF) (talk) 21:49, 18 February 2021 (UTC)
Well it seems to me that the goal is to solicit feedback from everyone but especially the Arabic, Bangla, Indonesian, Italian, Korean, Malay, Nepali, Polish, and Yoruba Wikipedias plus Wikimedia Commons and Wikidata. Like the nice part of me wants to be sympathetic to the idea that there are probably some really great ideas being planned behind the scenes that just aren't finalized enough for you to reveal yet and if I'm patient there will be some comparable consultation with enwiki.
However, there's another part of me that is less charitable. That part of me is based on past experiences with foundation initiatives. Not with foundation staff, I have worked with a variety of foundation staff and on the whole have found them just absolutely delightful and competent at their jobs. However, initiatives seem to be this other thing at the foundation and so my personal affinity and respect for a number of staff doesn't translate to good results. Perhaps it's the people who I haven't worked with driving those initiatives and overruling the good staff who I do know. That part of me says that I should be alarmed that you won't commit to a discussion with enwiki. That part of me is resigned to the fact that it's only large scale anger that has a prayer of getting foundation attention and has me already beginning to think how we would go about generating that kind of attention, perhaps building on our own ability to work cross wiki without the foundation in the middle. I don't like it when I can't convince myself that the nice part of me is what should win out. Sadly, Barkeep49 (talk) 22:52, 18 February 2021 (UTC)
Barkeep49, I had the impression (I'd have to look for diffs to support that claim) that the UCoC was written to codify the existing consensus on the projects that have robust behavioural policies. It was not supposed to conflict with existing enwp policies. As far as its authors are concerned, if I understand them correctly, nothing will change for English Wikipedia. Unfortunately, they are very quiet. Not one has engaged in the discussion of their work. Vexations (talk) 23:10, 18 February 2021 (UTC)
Vexations, I mean I've heard Maggie Dennis (noping: Mdennis (WMF) ) say something similar during office hours. And I don't actually have much to quibble with in the UCoC and certainly don't see anything that brings it into conflict with enwiki policies/guidelines. I would go so far as to say I support the UCoC in principle. However, enforcement is the whole ball game and if it is decided that the UCoC is to be regularly enforced on enwiki that's going to be a problem. And that's what phase two is about: how should the UCoC be enforced. So I would expect that enwiki is consulted so they don't just hear these concerns from me, but from the community writ large. And we're here because Xeno can't or won't say that enwiki will be consulted unlike 9 specific Wikipedias plus the two largest non-wikipedia projects. Instead Xeno seems to have written a response to a nice open ended question asking about what he can tell us about enwiki with an answer that boils down to "I can tell you nothing about enwiki". The answer maybe implies enwiki will be one of the "individual project" discussions are "tailored" to. Or maybe it doesn't imply that at all. And so rather than being patient knowing that our time will come, I'm forced to be a Talmudic scholar deciphering missives from a foundation representative. Best, Barkeep49 (talk) 23:28, 18 February 2021 (UTC)
@Vexations: I too have had this impression. Frankly, I am worried that communications from WMF staff on this front have been deceptive, and that enwiki will be more deeply affected by the UCoC and the Global Council than anyone would have reasonably anticipated. KevinL (aka L235 · t · c) 23:50, 18 February 2021 (UTC)
Sorry Barkeep49 if I wasn't clear: input from enwiki will be integral to the consultation, and my goal is to ensure the input of this community (and every community) is given due attention, and that individual users are comfortable expressing their thoughts and opinions. I welcome input on how best to achieve that goal. Xeno (WMF) (talk) 00:09, 19 February 2021 (UTC)
"input from enwiki will be integral to the consultation": I sure hope so, but that would be a first in this whole UCOC thing, where the actual UCOC is already finalized and the enforcement rules will be written before the largest communities (en, fr, de) are heard for the first time. I fear this is yet another token consultation which won't change a thing, with feeble excuses like "we are already too far in the process to change that now" or "we hear you" (without actually doing anything). All of this is yet another top-down WMF effort (like the rebranding and so many other things), with the same mistakes being made in all of them. The query I linked will probably used to justify some decisions as well, even though some of the questions are incomprehensible and thus the answers worthless (and some others are very leading in the choices given). Anyway, thanks for answering here. Fram (talk) 09:09, 19 February 2021 (UTC)
@Xeno (WMF): I'm a bit confused. Should we be waiting for someone from the WMF to organise a survey or discussion on the UCOC on enwiki? Or should we start one ourselves and then link it at meta? – Joe (talk) 11:11, 19 February 2021 (UTC)
Joe Roe: It probably makes sense to hold for the structured conversations, where the discussions will be facilitated and organized into major topic groups. The first round (planned for March) will be asking broad questions about potential application of the UCoC globally and in individual community contexts. There is also a parallel consultation ("Functionary consultations") inviting input from Arbitration Committees, CheckUsers, Oversighters, Stewards, and other functionaries. The second round (planned for mid-2021) will seek community input on the proposals created by a drafting committee using the input gathered in earlier rounds. Xeno (WMF) (talk) 14:51, 19 February 2021 (UTC)
The statement I was looking for is summarized in the answer to question 13 of the Universal Code of Conduct/FAQ I'm not sure if there ever was a statement that enwp's policies do meet or exceed the UCoC expectations
Earlier statements from the board do not give the impression that the existing enwp policies are sufficient: [37] for example, and especially the Board's Statement on Healthy Community Culture, Inclusivity, and Safe Spaces, which states rather bluntly : The Board does not believe we have made enough progress toward creating welcoming, inclusive, harassment-free spaces in which people can contribute productively and debate constructively. Vexations (talk) 21:17, 20 February 2021 (UTC)
Re. "some local consultations started earlier as they required more time ... individual facilitators" and "welcome input on how best to achieve that goal". I read the Commons and 'Data conversations last week, and ran the non-English-language discussions through Google Translate (haven't checked back this week yet). I hope they get down to the nitty gritty in time. I got the impression that the questions being asked so far are very general and bland, like 'how do you feel about the Code?' and 'how do you think you should report conduct problems?'.
It's interesting to compare the general tone of the responses across language communities. Bangla seems to be like 'this is really good we need this'. Polish is 'go away why is Foundation imposing this we already have an admin noticeboard and an arbcom and we are a lot more civil than wp:en'. In Arabic several people said they would support a Code if they could have input into its formulation, not realizing that ship had already sailed. (Apologies if I am misinterpreting or misrepresenting those discussions.)
I'm glad to see that Xeno (WMF) is involved in this. But I still fear that despite having some good facilitators, management direction will result in the consultations just asking us in vague terms what we want, then doing something else anyway. (Then W?F will claim community support for whatever the hell it is the W?F wanted in the first place, because "consultations were held and they were very thorough and successful". And when we say that we didn't ask for this, W?F will say it was directed by the Board, and the Board will say it was "requested by the community" in the Strategy 2030 process, just like how Shani is saying the community requested rebranding.)
What we really need is some concrete proposals on the table that we can hash out. Probably English Wikipedia and some of the other "ornery" Wikipedias (de, ru?) will go into depth regardless of the questions asked. But will we be listened to? Pelagicmessages ) – (11:30 Sat 20, AEDT) 00:30, 20 February 2021 (UTC)
  • @Barkeep49, Vexations, L235, and Xeno: - it clearly isn't intended to be just a formalisation for those communities with significant conduct policy already in place, because in the UCOC-formation "consultation" there were multiple comments from WMF staff, plus the ongoing surveys' questions, suggesting they want a private conduct submission process (even for just on-wiki conduct issues). That suggests the ability to know one's accuser, accused knowing all the evidence against them (in all but the most egregious cases), standard review of accuser's behaviour, etc are not going to be the case. If there is going to be a later meta discussion, there must also be an earlier en-wiki (and de-wiki, etc etc) discussion. The WMF, to me, seems to be prepping to go "some communities want this, and that outweighs what 75% of the editors want" or "we're too far into the process, we'll take your thoughts into account in the actual execution) Nosebagbear (talk) 15:44, 20 February 2021 (UTC)
    Listen I'm clearly willing to gripe at the foundation and am skeptical about their intentions. But I think it's a stretch to say they want a private conduct submission process (even for just on-wiki conduct issues). That suggests the ability to know one's accuser, accused knowing all the evidence against them (in all but the most egregious cases), standard review of accuser's behaviour, etc are not going to be the case. I think they're throwing out a lot of concepts - see the idea of "volunteers" being paid for this work mentioned in the commons survey - not knowing what will work best. I think they don't have the answers. But I also don't think they're going to have a process that will allow for comments except for answers to questions they ask and I think they're going to move at a speed incompatible with the scope of this task. Barkeep49 (talk) 16:30, 20 February 2021 (UTC)
    Since you pinged me as a volunteer, I get to reply as one: This is the way =)
    From the commons/wikidata prompts: "How do we balance privacy and safety of reporters with transparency and accountability of reports?" This is something that our community grapples with also, so it is not unexpected the Foundation is seeking advice on how to balance these needs in a manner acceptable to the communities. Enwiki already has a private conduct submission process (even for just on-wiki conduct issues), so the answer from enwiki users might be: "route it to arbcom-en". Shunting it to community members doesn't necessarily solve the problem, though as the balance still needs to be struck by someone. I've found that the private reporting system can still reduce harm without necessarily throwing transparency and accountability out the window: Private reports received at arbcom-en may result in a dialog with the reporting user to determine their level of comfort for the committee's possible responses, as even taking on-wiki action (or even privately contacting the reported user(s)) to address the reported behaviour can cause additional harm in unintended ways. A private reporting system could allow editors to seek assistance with experiences they are receiving as harassment in a non-public space and receive support from users experienced or trained in harm reduction to assist them with addressing the concern in ways the editor had not previously contemplated. –xenotalk 18:00, 20 February 2021 (UTC)
    @xeno: okay but what does Xeno (WMF) have to say about this?  MJLTalk 23:24, 20 February 2021 (UTC)


What we've got here is failure to communicate (some mobile editors you just can't reach)

Over a year ago, I reported two problems to the WMF:

(1) Logged-in mobile web editors are not given a very strong indication that they have new messages. There's just a little number in a red circle. It's similar to what many other sites use for "Exciting! New! Offers!" and other garbage. There's nothing to say "A human being wants to talk to you."

(2) Mobile web IP editors are given no indication at all that they have new messages. Nothing. Every template warning, every carefully thought out personal message, and everything else just disappears into a black hole, unless the user stumbles across their talk page by accident, or switches to the desktop interface.

But I get it. Bugs happen. They can be fixed. Instead both problems were marked as a "low" priority.

This is baffling. Problem 1 is a serious issue. Problem 2 is utterly unacceptable.

We are yelling at users (or even dragging them to WP:ANI) for "ignoring" our messages that they have no idea exist. We are expecting them learn without any communication all sorts of rules from WP:V to WP:3RR to WP:MOS that don't even apply to most other sites on the web.

Until they get blocked, of course. What a terrible experience. How are we supposed to gain new users when their very first interaction with a human is being told to f--- off, for "ignoring" a message they didn't even know about?

WMF, please explain to this community why this is a "low" priority. One year is long enough. Suffusion of Yellow (talk) 22:55, 16 February 2021 (UTC)

I'll just note that a majority of our users are accessing us on mobile so this isn't a niche problem either. Best, Barkeep49 (talk) 23:26, 16 February 2021 (UTC)
Wow. Neglected high-priority phabricator tickets are nothing new, but this is another level. Jimbo Wales, this deserves your attention. {{u|Sdkb}}talk 08:11, 18 February 2021 (UTC)
I would like to point out that the majority of messages left to IPs will never reach the user in question anyways, ESPECIALLY on mobile connections. Due to shared ips, the chance of someone else viewing the message before the person you are trying to reach is probably about 50/50. I realise that sometimes leaving a message is effective, but there are serious questions about all the cases where it is simply leaving a very confusing and often aggressively toned message to a completely different user just randomly reading an article at the busstop a month later. What we really need is a completely new way to leave messages to anonymous users. Possibly with some sort of very short lived session or something. But as ip users are more or less stateless (the software concept) right now, that is probably hard to implement. —TheDJ (talkcontribs) 09:26, 18 February 2021 (UTC)
@TheDJ: I would have no objection to expiring the OBOD if the talk page isn't clicked in a few days. Many messages come only a few minutes after the user makes the edit; most mobile carriers aren't that dynamic. Suffusion of Yellow (talk) 17:14, 23 February 2021 (UTC)
Equally baffling is that mobile app users do not see any notifications, including no talk page notifications, logged in or out. The link to talk is buried within the settings. Official mobile apps! They don't even see block messages! See T263943 and others. This block review and also this discussion where an editor also tested block messages. The editor was blocked multiple times for something that was not their fault but that of a poorly thought out app. They are not alone. Quote from phab task: Conclusion: Using the app is like being inside a bubble, without contacts with the exterior. It's no wonder there's so much people complaining here that using the app caused their Wikipedia account to be blocked, for reasons they don't understand. ProcrastinatingReader (talk) 09:33, 18 February 2021 (UTC)
I have filed T275117 and T275118. ProcrastinatingReader (talk) 10:22, 18 February 2021 (UTC)
I'm always surprised that anyone manages to edit with the mobile interface. As another example, if you're not logged in, there is no way to access the talk page of an article, or even any indication that it exists. If an unregistered user makes an edit and is reverted with a common summary like "see talk", I imagine many will have no idea what's going on. – Joe (talk) 09:39, 18 February 2021 (UTC)
The mobile web, and mobile apps, appear to be designed for readers and not writers. Having used mobile web occasionally, I think it's usable for logged in editing, but I do have to switch to desktop every now and then. I've used the iOS app only for a test - it is not usable for editing imo. ProcrastinatingReader (talk) 09:55, 18 February 2021 (UTC)
The number of edits I have made with the mobile web or app interface is most likely less than 50 (out of 13,000). Even for reading, the mobile interface is borderline unusable. I do frequently edit from my 4-inch cell phone screen (in fact, I'm doing that right now)... but I use the desktop version. —pythoncoder (talk | contribs) 14:04, 18 February 2021 (UTC)
I agree with Joe and have always found Cullen328 to be a bit of a superhero for being who he is on a mobile device. Best, Barkeep49 (talk) 18:19, 18 February 2021 (UTC)
Thanks for the kind words, Barkeep49, but I simply use the fully functional desktop site on my Android smartphone. It's easy. If I was the king of the Wikimedia Foundation, I would shut down the mobile site and apps, because they are an ongoing impediment to serious editing. RoySmith, there is no need to invest more effort (money) on a good editing interface for mobile, because that interface already exists - the desktop site. Just change its name from desktop to universal or something, and the problem will be solved.Cullen328 Let's discuss it 18:34, 18 February 2021 (UTC)
  • In some parts of the world, laptops and desktops are common, and people's phones are their second screen. In an environment like that, yes, it makes sense for mobile devices to be thought of as a read-mostly interface. On the other hand, in other parts of the world (particularly India in the context of English language users), mobile is how people access the internet.[38] There's no doubt that building a good editing interface for mobile is a hard thing, but we should be investing more effort there. Poor mobile editing tools disenfranchises a large segment of the world's population. -- RoySmith (talk) 14:41, 18 February 2021 (UTC)
  • @Suffusion of Yellow: Thank you for basically expressing exactly the same problem I wanted to. I have blocked a few editors who seem to be editing in good faith but just don't communicate, which eventually end up at ANI and after much agonising, get hit with as friendly a WP:ICANTHEARYOU block as we can muster. In the last instance, Mdd97 (talk · contribs), I specifically made a custom block template that said "CLICK HERE TO READ YOUR MESSAGES" in a way that they surely couldn't miss .... but again, following the block they've not edited again. We have to get to the bottom of this; if it's got to the stage where I've got to block people and the root cause is a software fault, it needs to be fixed. Surely the WMF can't be happy that I've needed to issue blocks on good-faith editors in this manner. Ritchie333 (talk) (cont) 16:10, 18 February 2021 (UTC)
  • To address a reaction some might have, yes, the vast majority of users on mobile are readers, not editors, and no, I wouldn't want the community totally in charge of redesigning the mobile interface, since we'd end up with the phenomenon we have at desktop where e.g. the tools section of the sidebar is visible to every user on every page despite it being of zero use to 99.9% of them. But this request is not just editor-centrism; it applies to users who have already edited and who badly need a notification to help them not get lost. {{u|Sdkb}}talk 18:55, 18 February 2021 (UTC)
  • I think the mw:Talk pages project, especially now that they are beginning to work on subscribing to notifications for talk page sections, could be interested in this discussion. Pinging User:PPelberg (WMF) and User:Whatamidoing (WMF). It also touches on UCoC Enforcement, highlighting that there needs to be funding for software dev. in addition to other measures. Pinging User:SPoore (WMF) and User:BChoo (WMF) for want of knowing who to contact regarding Phase 2. Pelagicmessages ) – (09:51 Sat 20, AEDT) 22:51, 19 February 2021 (UTC) ... Adding User:Xeno (WMF) after seeing section above. Pelagicmessages ) – (09:55 Sat 20, AEDT) 22:55, 19 February 2021 (UTC)

Question - Is this something that could be cured by bringing back the "Orange Bar of Death"? Mjroots (talk) 16:31, 22 February 2021 (UTC)

@Mjroots: the orange bar of death never went away. Last I check, it's still there for non mobile IP editors. That's why they get an indication of new messages. AFAIK, it was never there for the mobile web editor, that's probably part of the problem. Nil Einne (talk) 03:06, 23 February 2021 (UTC)
What no one has ever told me is why it was left out in the first place. Was it a simple oversight? Did someone have such a little understanding of how the sites work that they thought communication was unnecessary? Some other reason, that I'm not thinking of? This is the most confusing part. Suffusion of Yellow (talk) 17:14, 23 February 2021 (UTC)
I wish it could be brought back for all editors. Looks like bringing it in for IPs on mobiles could be the cure here. Mjroots (talk) 18:40, 23 February 2021 (UTC)
This is alarming but not surprising. Since I do a lot of question answering at the Teahouse, I'll point out a random IP's post from yesterday, in the same vein as some of the sentiments noted above: "Also, why don’t they get rid of the mobile view? So terrible!".--Fuhghettaboutit (talk) 00:29, 24 February 2021 (UTC)


Broader concerns about difficulty of getting phab tickets resolved

  • Also, I hope that this specific issue gets handled here, but the larger point that I think this highlights is that it's incredibly difficult to get phab tickets resolved. I sympathize that there are limited developer resources, but Wikipedia has fallen really far behind most of the rest of the web in the basics, and the focus seems to be on building new (sometimes desired, sometimes not) products rather than patching up the core. Having a wishlist once a year where the community collects together hundreds of urgent problems that have already been reported (in some cases for years) and then a tiny team tackles the top 10 is nowhere near enough. Items 10-50 are essential, too. When a problem like this has been on phabricator for a year, we shouldn't have to come here to beg for it to get attention. I could point to plenty of other tickets in a similar situation. What steps could be taken to get significantly more phab tasks out of the backlog? {{u|Sdkb}}talk 18:55, 18 February 2021 (UTC)
    Sdkb, To be fair to the MWF, the focus seems to be on building new (sometimes desired, sometimes not) products rather than patching up the core has been true on every project I've ever worked on. New stuff is sexy. It's what everybody wants to work on. Most engineering organizations overtly encourage this attitude by putting their best people on new projects, and by rewarding shipping new stuff with raises and promotions, to a greater extent than doing maintenance. -- RoySmith (talk) 19:08, 18 February 2021 (UTC)
    RoySmith, for the foundation, the cause is slightly different. The original idea was that they would work 'on the big things' and that the MediaWiki community can pick up the smaller tasks. This concept really stems from around 2009. Unfortunately since then volunteer development hasn't really increased, while MediaWiki itself has become a lot bigger and more complex. I've indicated multiple times in multiple interviews with WMF that I think it is not wise to have so many smaller problems in existing code, with NO owner, and that it creates quality problems.
    Since 2015 there is a core team that thinks about such problems in core, but that team is rather invisible to most of the community (they deal mostly with database, caching, api and authentication issues, keeping things running rly). I have also stated multiple times that we should have at least a 1000 developers.... but this seems to be impossible/unwanted. —TheDJ (talkcontribs) 09:58, 19 February 2021 (UTC)
    I agree that the urge to work on shiny new features persists everywhere - maintaining things is often boring and repetitive, with little 'to show' for your work, while developing new features has an obvious impact. However, maintenance is incredibly important lest a proje