Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Rexogamer (talk | contribs) at 15:44, 3 March 2024 (→‎Allowing editors to opt out of private information on XTools.: opt1). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

"WP:PROPOSE" redirects here. For proposing article deletion, see Wikipedia:Proposed deletion and Wikipedia:Deletion requests.
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:

Discussions are automatically archived after remaining inactive for nine days.


RfC: allow soft deletion of unopposed nominations

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
No consensus for proposal. As indicated in the discussion there is already provision for the AfD closer to soft delete an article that has been de-prodded. The consensus appears to be that the current system of the closer making an informed judgement based on the circumstances to either relist or soft delete after one week is fairer than encouraging or requiring a soft delete after just a week. SilkTork (talk) 01:24, 24 February 2024 (UTC)[reply]


Should all articles listed at articles for deletion for a week without opposition be eligible for "soft deletion"? HouseBlastertalk 01:15, 13 January 2024 (UTC)[reply]

probably, yes. This shows that there is probably little reason to keep the article in question, so can be deleted. However, if a good reason does exist, it should be reinstated, hence soft deletion Cal3000000 (talk) 16:08, 13 February 2024 (UTC)[reply]

Details (RfC: allow soft deletion of unopposed nominations)

Wikipedia:Deletion process § No quorum says (underline in the original):

If a nomination has received few or no comments from any editor, and no one has opposed deletion, and the article hasn't been declined for proposed deletion in the past, the closing administrator should treat the XfD nomination as an expired PROD and follow the instructions listed at Wikipedia:Proposed deletion#Procedure for administrators.

This proposal would remove the requirement that an article be eligible for PROD to be "soft deleted". In effect, this would mean poorly-attended but unopposed deletion debates can be closed as WP:REFUND-eligible soft delete.

Survey (RfC: allow soft deletion of unopposed nominations)

  • Support as proposer. In December, there were 46 deletion nominations ultimately closed as delete after being relisted as "ineligible for soft deletion": 1, 2, 3, 4, 5, 6, 7, 9, 10, 11,[a] 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 30, 31, 32,[b] 33, 34, 35, 36, 37, 38,[c] 39, 40, 41, 42, 43, 44, 45, and 46.
    In fairness, there were four (4) articles that are still bluelinks because they were ineligible for soft deletion: 1,[d] 2, 3,[e] and 4. But I don't think that a redirect, a stub, a non-neutral REFBOMB mess, and No Pants Day justify the volunteer time rubber-stamping nominations. WP:OFD2023 shows that ~15% of AfD nominations are closed as keep, which is ~twice the 8% survival rate of the "ineligible-for-soft-deletion" December group. This suggests that editor time is better spent rescuing other articles.
    Finally, I will note that this change would still allow for WP:REFUNDs of the affected articles. HouseBlastertalk 01:15, 13 January 2024 (UTC)[reply]
    I want to add a little bit to my rationale: this proposal would result in PROD and soft deletion being treated differently, and that is the point. A well-advertised-but-unattended discussion is not the same thing as a banner staying atop a page for a week. Arguing against this proposal because it would treat soft deletion and PROD differently is textbook circular reasoning: treating them the same way is A Good Thing because they should be treated the same way. Respectfully, why should fundamentally different processes have the same outcome?
    I would also point out that the status quo is the 46 articles from December are "hard" deleted: you either need some showstopping sources to show the closer/an admin at WP:REFUND or else must make your case at WP:DRV to get them undeleted. This proposal would result in all of them being REFUND-eligible. HouseBlaster (talk · he/him) 03:29, 14 January 2024 (UTC)[reply]
  • Strong support no irreversible harm. Potential abuse/misuse is mitigated by a single user and in worst case, a guaranteed WP:REFUND is always possible. ~ 🦝 Shushugah (he/him • talk) 01:36, 13 January 2024 (UTC)[reply]
  • Support Makes it easier to restore deleted articles and discourages drive-by/rubber stamp !votes. Seems like a net-positive. -Fastily 01:54, 13 January 2024 (UTC)[reply]
  • Support but caveats: The nominator must make a clear delete rational; the nominator must declare that they have followed WP:BEFORE, and say why the BEFORE options, especially WP:ATD are not suitable. I assume that this can override a previous PROD removal. —SmokeyJoe (talk) 05:29, 13 January 2024 (UTC)[reply]
  • Oppose I have always held that soft deletion at AfD is simply a procedure where we pretend that the nominator, instead of nominating the article for AfD, tags it for PROD instead. So there should be no difference in the rules for soft deletion vs. PROD IMO. However, I am open to considering introducing an expiration for PROD declines, such that an article which has not been declined for PROD in, say, the last five years becomes eligible for both PROD and soft deletion. The reason why declined PRODs are ineligible for PROD is the same reason why we discourage edit warring - you shouldn't be able to get the last say just by being more obstinate at forcing your changes through. However, five years is long enough to presume that the original decliner may have forgotten about the article; they can always maintain their opposition by re-removing the PROD or !voting keep at AfD. -- King of ♥ ♦ ♣ ♠ 06:19, 13 January 2024 (UTC)[reply]
  • Strong support as outlined by nominator. Makes perfect sense. Best Alexandermcnabb (talk) 09:02, 13 January 2024 (UTC)[reply]
  • Strong support I don't understand but i support. LionelCristiano (talk) 12:44, 13 January 2024 (UTC)[reply]
  • Support: I thought we already did this? 🌺 Cremastra (talk) 15:43, 13 January 2024 (UTC)[reply]
  • Support. It took me a bit to parse the proposal, which boils down to "can articles be soft deleted if they've had a contested PROD?". Q for nom: would this change mean that after a single week a decision would be made, or would the normal relisting cadence happen? I'm with King of Hearts in an alternate solution where a soft deletion would only be blocked if the PROD was less than some number of years ago. Eight years, perhaps? Ten seems too long (2014 was a decade ago) but 5 feels too soon (2019 was just a few days ago). SWinxy (talk) 19:22, 13 January 2024 (UTC)[reply]
    I envisioned it being a tool in the closer's toolbox: namely, if they feel relisting would be productive, relist. If not, it would be eligible for soft deletion. HouseBlaster (talk · he/him) 22:33, 13 January 2024 (UTC)[reply]
  • Oppose per King of Hearts. If someone nominates an article for PROD, which is contested, and then immediately renominates it for AfD, just because the person who opposed that PROD didn't show up to the discussion, doesn't mean the article should be deleted. Also open to allowing PROD again after 10 years or something like that, but soft deletion is just applying PROD rules to AfD. Galobtter (talk) 19:31, 13 January 2024 (UTC)[reply]
  • Oppose. This proposal would effectively allow an article to be PRODed twice. If a PROD has already been removed once, the nomination is controversial. If the person who removes the PROD states in his edit summary that the article should not be deleted, or that the grounds for deletion are erroneous, or that the article satisfies GNG, or the like, I can only infer that the AfD is not unopposed, and that making a comment like that amounts to opposition. James500 (talk) 02:53, 14 January 2024 (UTC)[reply]
    • This proposal is also explicitly based on the assumption that changing the rules of AfD will not change the behaviour of AfD participants described by the statistics cited. It is not obvious that the assumption is true. This proposal might result in an increase in the number of nominations being made in the first place. Nominators might decide to send every declined PROD to AfD in the hope of getting a soft deletion while no one is watching. This proposal might also result in more keep !votes being made in the first place, if deprodders cannot just wait for an unattended AfD to be closed as no consensus. I also notice that the statistics cited are for December (the time of year when we have the fewest active editors), and do not take into account any seasonal variation that might exist. James500 (talk) 18:06, 14 January 2024 (UTC)[reply]
      • Fair enough point about seasonal variation. I pulled the statistics for June 2023 (chosen as halfway through the year): 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 30, 31, 32, 33, 34, 35,[f] 36, 37,[g] 38, 39, 40, 41, 42, 43, 44, and 45.
        Bluelinks: 1, 2, 3, 4, 5, 6. There is also Wikipedia:Articles for deletion/Log/2023 June 16#Explore Learning, which I am not sure which category to put in. It was closed as "delete", but is currently a redirect to ExploreLearning (without a space). That article appears to be on an entirely different company. At the very least, the two articles (Explore Learning and ExploreLearning) coexisted for a period of time—maybe there was a WP:CONTENTFORK? I'd appreciate it if someone with admin goggles could take a look.
        Finally, the behavior changes you cite seem to be positive changes. The point of any discussion is to find consensus, which logically means "no consensus" closes are not an ideal outcome. We allow speedy renomination of no consensus closes for a reason, after all. Thus, I would argue that discouraging dePRODers from seeking a "no consensus" close is a good thing. I also take issue with the assertion that Nominators might decide to send every declined PROD to AfD in the hope of getting a soft deletion while no one is watching. First, I would hope that people would not attempt to game the system. But holding a full-blown AfD is absolutely not while no one is watching. There is a banner atop the page (which was evidently enough to attract the dePROPer), it is listed on the daily AFD log, and there is literally an entire WikiProject dedicated to ensuring other interested participants see the discussion. HouseBlaster (talk · he/him) 22:13, 14 January 2024 (UTC)[reply]
        • ExploreLearning and the deleted Explore Learning (AfD discussion) are two different subjects on two different continents. The latter went through Proposed Deletion in July 2008, one month after it was written. Also relevantly, a succession of copyright violations of corporate advertisements, editors with declared and undeclared (but obvious) conflicts of interest rewriting most of the article, and preference for the company WWW site over independent sourcing caused the non-company sources cited in 2008 when Proposed Deletion was challenged to have been long-since lost, buried years deep in the edit history, in 2023 when the article came to AFD. Uncle G (talk) 12:31, 18 January 2024 (UTC)[reply]
  • Oppose there is often low participation at AfD so waiting a second week for comments is reasonable. Also the deprodder would be rushed into responding when they may be offline for a period. This suggestion would unnecessarily speed up deletion without any consensus in my view, Atlantic306 (talk) 22:48, 14 January 2024 (UTC)[reply]
  • Support per nom and Fastily. voorts (talk/contributions) 23:47, 14 January 2024 (UTC)[reply]
  • Strong support Slacker13 (talk) 15:17, 04 February 2024 (UTC)[reply]
  • Oppose. If an article is ineligible for PROD then it is, by definition, controversial and is thus completely unsuitable for deletion without an active consensus to do so. Thryduulf (talk) 11:01, 15 January 2024 (UTC)[reply]
  • Oppose, although well-motivated, this proposal would open the door to deletion of articles that just don't happen to be interesting to the handful of editors who regularly visit AfD, even when the nomination is obviously spurious or misguided. Admins should be both allowed, and expected, to use their discretion to relist, or otherwise ensure that deletion is for policy-based reasons, not just because no one could be bothered that week. Elemimele (talk) 12:10, 15 January 2024 (UTC)[reply]
  • Oppose may open door for misuse. I see these cases as no consensus to delete which if anything should default to keep. Well-meaning proposal but defies conventional wisdom. --PeaceNT (talk) 04:36, 16 January 2024 (UTC)[reply]
  • Support. If nobody cares enough about an article to make a brief comment on an AFD, it does not have enough support to exist. Stifle (talk) 09:52, 16 January 2024 (UTC)[reply]
  • Support. If nobody can rebut the argument for deletion then we shouldn't be keeping the article, per WP:CONSENSUS. BilledMammal (talk) 11:44, 16 January 2024 (UTC)[reply]
  • Meh This RFC seems poorly written, as it fails to note that very section the nomination links to goes on to offer several options for when it was an opposed prod, one of which already is soft deletion. It's unclear to me whether "supports" will be interpreted as supporting the status quo or as calling for something more strict, and I could see some opposes actually supporting the status quo too. I see there was a better-worded RFC on this topic at Wikipedia talk:Deletion process#Clarifying NOQUORUM Soft Deletes that didn't get many responses.
    Personally I think we can afford a relist or two before soft-deleting, even if the de-PRODder didn't notice the AFD to oppose there too, per WP:NODEADLINE. But leaving it open to admin discretion (i.e. the status quo) is ok with me too on the assumption that admins will save immediate soft deletion for clearer cases. Anomie⚔ 12:12, 16 January 2024 (UTC)[reply]
  • Oppose For similar reasoning as King of Hearts. I would not necessarily be opposed to this in cases with a multi-year gap between PROD and AfD, but I do not like the idea of essentially being able to PROD an article twice in a short period of time. As for a timeframe, leave it to admin discretion. Curbon7 (talk) 12:24, 16 January 2024 (UTC)[reply]
  • Oppose - a week is nowhere near enough time, a lot of articles for deletion are likely to be on more obscure topics, that we possibly should have articles about, but that most editors will not be familiar with. A week is not enough time to be seen by someone who might be able to expand the article or explain it's importance. If there's an automatic deletion cut-off it should be closer to a year. Irtapil (talk) 15:11, 16 January 2024 (UTC)[reply]
  • Procedural Oppose per Anomie. There is a lot of context missing from this RfC, such as how that sentence got added to the process and the conflict with another part of the same section, i.e. it may already be an option. I put forward a discussion at Wikipedia talk:Deletion process#Clarifying NOQUORUM Soft Deletes to try and discuss some different wordings and options that could be used in a proper RfC per WP:RFCBEFORE. It would be advisable to close this discussion, workshop the wordings on that talkpage, and come up with a more comprehensive one since the current wording is self-contradictory. The WordsmithTalk to me 20:52, 16 January 2024 (UTC)[reply]
    I take this proposal to be stating that we should strike and the article hasn't been declined for proposed deletion in the past, which I think would resolve the contradiction. voorts (talk/contributions) 04:01, 17 January 2024 (UTC)[reply]
    If that's what this means, then support, to strip away some bureaucracy and also get rid of the kind of nonsensical idea that some CoI or other "problem article" writer gets a special "right" for having removed a prod tag while addressing no problems in the article.  — SMcCandlish ☏ ¢ 😼  01:31, 18 January 2024 (UTC)[reply]
    One side effect is that notable articles could be deleted if this were to be implemented. For instance, it took two weeks to find sources for Wikipedia:Articles for deletion/TL;DR (2nd nomination) 71.239.86.150 (talk) 13:24, 19 January 2024 (UTC)[reply]
    I don't think that would have been deleted after just one week. There's no consensus for deletion in the first week - two different redirect arguments and a delete !vote. -- asilvering (talk) 00:07, 20 January 2024 (UTC)[reply]
  • eh. I appreciate the reasoning, but I don't much like the idea of an unopposed AfD being soft-deleted at the end of a single week, and I don't really think it's too much to ask that someone second an AfD in the event that an article was deprodded. I'd be happier with the idea if it was something like "can be treated as an expired PROD if they've been relisted at least once", I suppose. -- asilvering (talk) 00:14, 20 January 2024 (UTC)[reply]
  • I'll generally relist a no comment nom when I'm patrolling the logs but when no one has argued in support of retention or even commented indicated an interest, I will close these as a soft delete. No one has shown up in that two week window but if they do down the road, they don't need to do the DRV dance. They can have it restored and it can be addressed, if necessary at that time. I do think a week might be too little of a time though so while i do this, I'm not in full support. It's something that deserves merit though. Star Mississippi 01:31, 20 January 2024 (UTC)[reply]
  • Oppose a week is too short; at least one relist is reasonable. LEPRICAVARK (talk) 02:14, 20 January 2024 (UTC)[reply]
  • Oppose if an article is ineligible for PROD, it is because someone has deprodded the article and would, presumably, !vote to keep in an AfD. They should not be expected to have to do this twice. I would be in favor of considering a time limit on prod (ie articles proposed for deletion >10 years ago can be re-proposed), when considering how much our notability standards have changed, and the possibility for PROD to be abused. Eddie891 Talk Work 15:55, 20 January 2024 (UTC)[reply]
    @Eddie891 I don't think this is an accurate assumption. I frequently see PRODs like "article has existed since 2007, take it to AfD". Many de-prodders give no reason at all, and also do not show up to the AfD. -- asilvering (talk) 00:00, 22 January 2024 (UTC)[reply]
    yes, but the implied de-prod reason in the first instance you give is that the person is suggesting the article be taken to afd, where more editors can !vote on the afd. And editors not showing up to the AfD is part of why I opposed— we cannot expect good faith de-prodders to have to keep tabs on a subsequent afd nomination and comment again. Eddie891 Talk Work 00:13, 22 January 2024 (UTC)[reply]
    If I PROD an article, I keep it on my watchlist in case it is de-PRODed, so I can then determine if I want to take it to AfD. Presumably a person asking to take something to AfD will want to participate in that discussion, and if they do not, I don't think asking someone to take something through another bureaucratic hoop is a great reason to de-PROD. voorts (talk/contributions) 00:21, 22 January 2024 (UTC)[reply]
    The person is suggesting the article be taken to AfD, yes. But it doesn't make sense to infer from that that the de-prodder would vote "keep". In my experience, they do not, since "article has existed since 2007" (or whatever) is not a valid keep rationale, and they can find no other. -- asilvering (talk) 00:27, 22 January 2024 (UTC)[reply]
    On multiple occasions I've deprodded something not because I think it should be kept necessarily, but because I believe determining whether the topic should or should not have coverage on Wikipedia and/or whether it should have a standalone article or be covered on a broader one (i.e. merge and/or redirect) needs more time and effort than PROD allows. For example, I deprodded The Roaring Twenties (band) recently because google searches brought up so many false positives that determining whether sources exist for the subject is not possible from just a cursory look - especially as many of the obvious ways of excluding false positives will also exclude an unknowable proportion of true positives if they exist. In other cases I've deprodded because the most likely place sources are going to exist is in offline resources and/or in languages other than English. A third category is where the only realistic outcomes at AfD are keep, merge or redirect. Thryduulf (talk) 22:38, 7 February 2024 (UTC)[reply]
    Sure, those are all fine reasons to contest PROD. That's exactly why it doesn't make sense to infer that a de-prodder would vote "keep". -- asilvering (talk) 03:25, 8 February 2024 (UTC)[reply]
    But a PROD isn't a keep vote, it's a statement saying "this article should not be deleted by PROD." If there's no subsequent discussion at an AfD on an article that has been PROD-ed, the two statements are "delete this article" (nominator) and "don't delete this article through PROD" (the de-prodder) which is a no consensus as far as deletion is concerned. SportingFlyer T·C 20:29, 13 February 2024 (UTC)[reply]
    Yes, that's what I'm saying. -- asilvering (talk) 22:42, 13 February 2024 (UTC)[reply]
  • Oppose - per Thryduulf and others. Rlendog (talk) 18:44, 20 January 2024 (UTC)[reply]
  • Support: it is too easy to create an article that worsens the encyclopedia's quality and too difficult to delete it. Anyone may object to a PROD without a valid reason, but only justified AfD comments are taken into account by the closer. Deletion should not be prevented because of baseless objections by article creators. Soft deletion after no reasoned opposition at AfD is a good approach. Relisting indefinitely is not a solution to low participation at AfD as a venue: the same number of discussions will need contributors regardless of how long they are open. A closing admin who sees the nomination is poorly reasoned should not delete the page. They should instead !vote in the AfD, present some references and/or improve the article (just as they should if it was a nomination and three baseless "delete" !votes). — Bilorv (talk) 21:37, 21 January 2024 (UTC)[reply]
  • Oppose - A week is too short of a time, so I would appreciate at least one relist. Since there are no requirements for editors in nominating an article for deletion (just expectations), suggestions to require a more complete nominations are unrealistic, or subject to interpretation by the closing editor. --Enos733 (talk) 19:13, 22 January 2024 (UTC)[reply]
  • Oppose I don't see anything wrong with the procedure here of relisting ineligible AfDs when discussion is light. The problem is really just that we need more AfD participants. SportingFlyer T·C 19:16, 22 January 2024 (UTC)[reply]
  • Oppose - One week is not long enough. If it went through the cycle three times with nobody offering an opinion, I might see it — but when's the last time that has happened? A solution in search of a problem — or a short-sighted "solution" that will create problems. Carrite (talk) 03:53, 23 January 2024 (UTC)[reply]
  • Strong support If the administrator believes an relist would be appropriate, they should relist it. If an administrator believes an article that has received no opposition to deletion should be deleted similar to PROD, they should delete it, with the opportunity for REFUND. I see no need to forbid soft deletion in these cases that typically still result in deletion and no need to expect others to expend time casting a !vote for what may be obvious or easily undoable. Reywas92Talk 21:42, 24 January 2024 (UTC)[reply]
  • Oppose per KoH (who, no, I am not related to). If someone has previously objected to deletion, we should not just go behind their backs deleting it. QueenofHearts 04:13, 26 January 2024 (UTC)[reply]
  • Oppose on general principles. Sandizer (talk) 19:36, 29 January 2024 (UTC)[reply]
  • Oppose A handful of editors are saying it doesn't harm anyone. It will drive off many a new editor who sees their hard work turn into a red link and who leaves without asking for a WP:REFUND, either due to ignorance of its existence or anger/sadness with the community. Also per Thryduulf in particular. Sincerely, Novo TapeMy Talk Page 18:30, 30 January 2024 (UTC)[reply]
    If people use AfD as cleanup, then this would be true. But it an experienced editor truly believer an article was not notable, no process whether DRAFT'ication, reviewing it or even PROD'ing it will make it notable. New editors should interact with kind AFC reviewers and or NPP reviewers. I see this proposal as reducing the amount of time in AfD to precisely increase time for reviewing AfDs themselves and reviewing new articles. But testing this out would reveal that better. ~ 🦝 Shushugah (he/him • talk) 21:46, 7 February 2024 (UTC)[reply]
    People shouldn't use AFD as cleanup, but it happens quite often. New editors should interact with kind AFC/NPP reviewers, but many get bitten instead. This proposal will not go any way to remedying either problem, rather it will make the impact of people incorrectly using AfD as cleanup worse and it will increase the number of new editors who are bitten. Thryduulf (talk) 22:24, 7 February 2024 (UTC)[reply]
    As Thryduulf wrote, unfortunately many do use AfD as cleanup.
    Also, any logged-in user, regardless of knowledge of policy, may nominate. The proposal doesn't require anyone to vote (assuming I'm reading it correctly), so experienced editors may not even voice an opinion. Sincerely, Novo TapeMy Talk Page 18:12, 9 February 2024 (UTC)[reply]
  • Oppose The default shouldn't be deletion when we know that the deletion is controversial due to a contested PROD. --Ahecht (TALK
    PAGE    ) 19:30, 1 February 2024 (UTC)[reply]
  • Strong Support AFDs with no participation is a major problem in this process, there are at least 20-30 of them that get zero attention at any given point of time - just look at Cyberbot. Saying that more people should join AFD is NOT going to solve things, most people gather around a few popular AFDs anyway and ignore the rest. Swordman97 talk to me 22:17, 5 February 2024 (UTC)[reply]
  • Support? oppose per below - I don't think I understand the opposition. The proposal requires closing admins to go through the "before deletion" part of WP:PROD, right? That includes making sure "The page is eligible for proposed deletion: the page is not a redirect, never previously proposed for deletion, never undeleted, and never subject to a deletion discussion." So let me spell out what I'm supporting:
    PROD → DEPROD → NO-VOTE AFD → NO SOFT DELETE
    [NO PROD/DEPROD] → NO-VOTE AFD → SOFT DELETE
    What am I missing? — Rhododendrites talk \\ 18:11, 6 February 2024 (UTC)[reply]
    @Rhododendrites that's what it says now. I think you've missed the proposal immediately underneath that, since your explanation appears to me to be an !oppose. -- asilvering (talk) 18:23, 6 February 2024 (UTC)[reply]
    I think I got caught on the fact that once an article has gone to AfD, it is by definition ineligible for PROD, and this was to address that problem but is worded in an overly broad way. Sounds like extra breadth (to apply to articles that have been prodded/deprodded in the past) is kind of the point. In that case, yes, I am opposed. — Rhododendrites talk \\ 18:27, 6 February 2024 (UTC)[reply]
  • Oppose per king of hearts but I do think that allowing a PROD again after a long time period (10 years? 5 years?) is reasonable. Hobit (talk) 21:13, 7 February 2024 (UTC)[reply]
    Why does the passage of time automatically make something that was controversial no longer so? Sure it will in some cases, but unless it does in at least the significant majority (which I'd be interested to see evidence for) then it doesn't strike me as beneficial to the project. Thryduulf (talk) 22:26, 7 February 2024 (UTC)[reply]
    To me it's because an objection from years ago has little weight now. Our inclusion guidelines (and more so, how they are interpreted) have changed significantly in that time. An old objection based on how things were doesn't seem like it's hugely relevant at this point. It's not something I really want, but I think it would be a reasonable compromise. Hobit (talk) 23:49, 7 February 2024 (UTC)[reply]
    That assumes that the old objection related to something that is no longer relevant and/or standards that have been superceded. That is going to be true in some cases, but in other cases the objection is still going to be "hugely relevant" today. For example rationales like "plenty of sources in books", "seems notable based on the <other language> Wikipedia article", "widely covered in contemporary (non-English) newspapers", "sources seem to be available but they're paywalled so I can't check myself" and "if this is not individually notable it should be merged not delete", for example. It would be better if sources were in the article of course, but assertion that sources existed 5-10 years ago is as much a reason to take it to AfD today as it was 5-10 years ago. Thryduulf (talk) 01:12, 8 February 2024 (UTC)[reply]
    Fair. And because AfD is always a way forward, that's reasonable. But it feels reasonable to me to let them expire as described. I agree it could be abused. Hobit (talk) 01:48, 8 February 2024 (UTC)[reply]
  • Oppose I've been here for (mumble, mumble) a very long time, & this is the first time I've heard of "soft deletes" & I don't understand the point of it: an article is either kept or deleted. And if someone as experienced as I doesn't understand the point, I figure new volunteers will be equally confused. (Unless they are uniformly smarter than me, which is entirely possible.) -- llywrch (talk) 22:18, 8 February 2024 (UTC)[reply]
    A WP:Soft delete is basically a PROD that spent some time at XfD and received very few (if any) comments rather than being prodded. If a page has been prodded or soft deleted anyone can get it back by going to WP:REFUND and asking. If a page has been deleted following a consensus, they need to go to DRV and convince folk there that there was something significantly wrong about the deletion. Thryduulf (talk) 22:44, 8 February 2024 (UTC)[reply]
    If you're curious, scroll down any past AfD log and you'll see a bunch of them. -- asilvering (talk) 02:53, 9 February 2024 (UTC)[reply]
  • Oppose I think that this is the defacto process for those anyway, except that this proposal speeds up the time table. Lots of AFD's need more than a week to get some input. North8000 (talk) 23:04, 8 February 2024 (UTC)[reply]
  • Reluctant oppose This creates a loophole where deprodding can be bypassed through a low-attendance AfD (i.e. you prod, they deprod, you AfD, they ignore or fail to notice it, the article gets deleted, all in a relatively short amount of time). I would support if the proposal specified that the deprod must have been at least (say) five years ago. I would alternatively support a proposal to "expire" old deprods as King of Hearts suggests (in which case this proposal would be unnecessary). I would also also support a proposal to discourage (but not prohibit) relisting more than N times (for, say, N=3), to encourage the closing admin to select another option (policy already allows the use of soft deletion at the discretion of the closer).This is already in the policy, oops. Any proposal along those lines would have my support. It's just this particular combination of features that, in my opinion, is problematic. --NYKevin 04:17, 11 February 2024 (UTC)[reply]
  • Support If inclusionists won't appear at AfD to make an argument, deletion is the result. Chris Troutman (talk) 18:22, 15 February 2024 (UTC)[reply]
  • Mild support though I think one re-list is a reasonable check on this. It's pretty rare that something slides through AFD without any comments, and there is always a WP:REFUND later. Shooterwalker (talk) 14:42, 16 February 2024 (UTC)[reply]
  • Oppose per Llywrch and KQ♥. No need to default to deleation. – SJ + 01:06, 17 February 2024 (UTC)[reply]
  • Strongest possible oppose This will certainly result in articles that should not be deleted getting deleted and remaining deleted, per other opposes above. AFD soft deletes are a problem and we don't need any more of it. One takes an article to AFD in the hopes that an enforceable consensus will determine the fate of the article for what is usually a considerable amount of time. Soft deletes of AFDed articles are a loophole for COI/UPE. If I counted all the times problematic articles got soft deleted by admins not knowing to evaluate whether a misuse was likely, and got refunded soon after, I would be very mad right now, and that's just not healthy. Usedtobecool ☎️ 15:49, 19 February 2024 (UTC)[reply]
  • Oppose It's very difficult to get a clear consensus if there are only a few participants (e.g. nominator plus one or two) in an AfD. That being said, anyone concerned about an article absolutely should take the time and make their argument at its AfD nomination. XtraJovial (talk • contribs) 21:39, 21 February 2024 (UTC)[reply]
  • Oppose Very often I see "relisted" in AfDs, meaning that participation is low (or too many AfD nominations to consume :-) - Altenmann >talk 02:04, 23 February 2024 (UTC)[reply]
  • Oppose as written. Something with more checks and balances might work. Perhaps we should require a delete !vote by someone other than the nominator. An alternative would be for the closer to do due diligence to check for sources etc, but that's not the closer's job and they may have better things to do. We could say that anyone other than the nominator can close the unopposed AfD as delete, but only if they repeat the WP:BEFORE as a check. Certes (talk) 10:03, 23 February 2024 (UTC)[reply]

Discussion (RfC: allow soft deletion of unopposed nominations)

So to be clear and article like MIKTA would be deleted even though the rationale doesn't make sense?Moxy- 22:42, 13 January 2024 (UTC)[reply]

No, because someone expressed opposition to deleting the article in the discussion. (If that comment had not been made, the article would be eligible for soft deletion under the current rules.) HouseBlaster (talk · he/him) 22:54, 13 January 2024 (UTC)[reply]
So not comment then default deletion ..... do those involved in deletion at least look for sources...as in is there an common sense or effort involved if noone comments? Moxy- 04:48, 14 January 2024 (UTC)[reply]
If people are not looking for sources before !voting, I would argue that is a problem beyond the scope of this proposal. HouseBlaster (talk · he/him) 02:42, 15 January 2024 (UTC)[reply]
MIKTA is just a case of a really bad nomination by a user who clearly sent an article to AfD without Googling its title. Lazy nominations are a problem with or without soft deletion. Pichpich (talk) 04:35, 15 January 2024 (UTC)[reply]
But soft deletions make the effects of lazy nominations very significantly worse. Thryduulf (talk) 11:02, 15 January 2024 (UTC)[reply]
Perhaps, although I'd be counting on the closing admin to review the deletion rationale before actually soft-deleting the article, just as I'd expect admins to close PRODs as deletions only after performing the usual and basic WP:BEFORE checks. Am I just being naïve here? Pichpich (talk) 12:58, 15 January 2024 (UTC)[reply]
Am I just being naïve here? unfortunately you are. While the worst offender that I know of was desysopped, there is no shortage of deletions being done without proper checks. Thryduulf (talk) 14:56, 15 January 2024 (UTC)[reply]
I know for a fact at least some admins don't look at articles at all when closing deletion discussions, so no. (And TBF deletion closers have a lot of work to do without replicating the participants work) Mach61 (talk) 16:49, 15 January 2024 (UTC)[reply]
The admin instructions for handling expired PRODs do not require us to conduct checks for sources (etc.) prior to deletion, but if you feel they should be changed to include such a requirement, feel free to gather a consensus to that effect at Wikipedia talk:Proposed deletion. WP:BEFORE is a part of a different process, namely WP:AFD; PROD is intentionally a more streamlined process. Stifle (talk) 08:55, 23 January 2024 (UTC)[reply]
Well admins could do checks for a prod and decline, but so could any one else. Graeme Bartlett (talk) 23:07, 25 January 2024 (UTC)[reply]
The intention behind this proposal is decent. I might encourage another proposal with a few more checks and balances, but I think it's so rare that a deletion discussion would go more than a week with no response. Shooterwalker (talk) 14:38, 16 February 2024 (UTC)[reply]
I assure you that this is absolutely not rare. -- asilvering (talk) 06:56, 23 February 2024 (UTC)[reply]

Notes

  1. ^ with the relist comment Not eligible for soft-deletion (due to contested prod back in 2006 (!) ...)
  2. ^ a batch nomination of seven was relisted because one had been dePROD'd
  3. ^ deleted as "unopposed"
  4. ^ kudos to User:FormalDude for finding sources
  5. ^ closed as redirect after the closer found an appropriate target
  6. ^ Closed as no consensus due to no participation, but deleted at Wikipedia:Articles for deletion/Quentin Newcomer (2nd nomination)
  7. ^ Closed as no consensus due to no participation, but deleted at Wikipedia:Articles for deletion/KoiKoi Nelligan (2nd nomination)
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.

Purpose of ANI

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
It is snowing here. This is not going to happen. Seawolf35 T--C 19:49, 18 January 2024 (UTC)[reply]


Should the scope of Wikipedia: Administrators' noticeboard/Incidents limited to user conduct discussions only, and should ANI's secondary role of addressing "urgent incidents" be transferred to WP:AN? Ca talk to me! 15:25, 18 January 2024 (UTC) modified 16:31, 18 January 2024 (UTC)[reply]

Background information

Back in 5 January 2024, I requested a retitling of Wikipedia: Administrators' noticeboard/Incidents to Wikipedia:Administrators' noticeboard/User conduct. User:Ritchie333 has recommended on my talk page that the scope of ANI should be decided upon first rather than heading for a move request straight away.

  • Support as nom The new title would clarify the noticeboard's purpose to new editors. AN is much less clogged than ANI, and complex issues can be discussed in AN without the trouble of short archive durations or large page sizes. Ca talk to me! 16:31, 18 January 2024 (UTC)[reply]
  • Oppose I'm not convinced anything is broken here. SportingFlyer T·C 15:56, 18 January 2024 (UTC)[reply]
  • Oppose ANI's original purpose is for "urgent incidents", which overlap with user conduct issues much more than they overlap with the routine administrator actions and ban appeals than AN sees more often. ChaotıċEnby(talk · contribs) 16:01, 18 January 2024 (UTC)[reply]
  • Oppose: “ANI” is just too iconic, and incidents that aren’t user conduct can sometimes appear. Both urgents and user conduct need urgent review, and splitting would require prospective people to watchlist subscribe to both pages and get everything at once. Aaron Liu (talk) 16:22, 18 January 2024 (UTC)[reply]
  • Weakish oppose. This isn't a bad thought, and if we were just setting up the noticeboard, I'd want to give it serious consideration. I do think it'd help newcomers understand the noticeboard's purpose more easily, and that it'd discourage the (frequent) misuse of ANI as a place to litigate content issues. My main hesitation would be that titling the noticeboard "user conduct" would make the "you've been mentioned on ANI/ANUC, therefore you've done something wrong" implication even stronger than it already is, which might in turn raise the heat level, which is, uh, not what that noticeboard needs. That said, I have to oppose because, in 2024, the noticeboard has been ANI for ages, and retitling it would cause disruption/make it harder to read the historical record. There is not a compelling enough need for a change to make that worth it. {{u|Sdkb}} talk 16:50, 18 January 2024 (UTC)[reply]
  • Oppose - Aren't "urgent incidents", usually caused by editorial behavior? GoodDay (talk) 17:02, 18 January 2024 (UTC)[reply]
  • Oppose. As I showed in the RM, incidents requiring immediate admin intervention aren't ANI's "secondary purpose"—the clue is in the name—they're the original and primary reason that the board exists. Its mob-justice user conduct function crept in over time without anyone really meaning it. If change is needed, it's in the other direction: we should be directing user conduct complaints away from ANI and towards lower-drama options like WP:DR and WP:XRV. – Joe (talk) 17:20, 18 January 2024 (UTC)[reply]
  • Oppose - This feels a bit like rearranging deck chairs on the Titanic, and would just continuously confuse users with 33% of posts being closed as "No action, take it to WP:AN". We don't need to create more problems in a board that's already rife with problems. Duly signed, ⛵ WaltClipper -(talk) 17:24, 18 January 2024 (UTC)[reply]
  • Oppose and topic ban Ca from meta edits/discussion about ANI Ca seems to be unable to drop the stick about ANI being not what they want it to be. The requested move was closed only 12 days ago and we are having a very similar discussion. --Guerillero Parlez Moi 17:57, 18 January 2024 (UTC)[reply]
    Ehhh, seriously? It was just seekings of consensus within process (the RM) after a bold edit, and following okay advice from someone else. I don’t see why this warrants a topic ban. Aaron Liu (talk) 18:03, 18 January 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Discussion (Purpose of ANI)

  • Ca, could you sign your !vote above? Could you also move the rationale from the opener to your !vote. The opening RfC statement needs to be neutral and brief. Firefangledfeathers (talk / contribs) 15:56, 18 January 2024 (UTC)[reply]
    Thanks for the advice, I'll be shortening my RfC question and sign my !vote. Ca talk to me! 16:28, 18 January 2024 (UTC)[reply]
    Better. Can you please add a signature before the background information header. Only the neutral question should be copied over to the central RfC listings. Firefangledfeathers (talk / contribs) 16:37, 18 January 2024 (UTC)[reply]
     Done I presume LegoBot will do its thing and copy the new RfC text over. Ca talk to me! 16:56, 18 January 2024 (UTC)[reply]
    'Twill. Firefangledfeathers (talk / contribs) 17:03, 18 January 2024 (UTC)[reply]
  • I think I would prefer the reverse: discuss patterns of user behaviour at the administrators' noticeboard, and leave the incidents noticeboard solely for incidents that require immediate attention. isaacl (talk) 17:19, 18 January 2024 (UTC)[reply]
    I find AN to be a place I'm more likely to check in on given the pace, volume, and temperature of discussions when I'm busy than ANI. Bringing some, but not all, of the discussions where temperatures flare the most to AN would, for me, not be any sort of improvement. Joe's suggestion above about directing some stuff to other forums already setup to handle them is also a good one. Best, Barkeep49 (talk) 17:41, 18 January 2024 (UTC)[reply]
    To double-check my understanding, are you saying that you feel discussions on patterns of user behaviour as well as discussions of incidents requiring immediate attention are both discussions where temperatures flare the most? isaacl (talk) 18:07, 18 January 2024 (UTC)[reply]
  • I wrote the following a few minutes before the RfC closed, and I am not convinced there is WP:SNOW possibility of a change in the opposite direction: [Oppose, but] delete the words "and chronic, intractable behavioral problems" that were added to the page header in June 2018 per Joe Roe. ANI is certainly not a suitable venue for dealing with accusations of that kind. At the moment ANI certainly sometimes functions as a kangeroo court, where it is not possible to get natural justice or a fair hearing (!voters are not even required to be impartial, or to be capable of telling the difference between reality and fantasy, and there are no rules of evidence etc); such discussions there are sometimes vehicles for subjecting regular editors to harassment and psychological abuse, that sometimes rises to the level of a massive public show trial, complete with ritual public humiliation and threats, bullying, gaslighting and other pressure to make forced false confessions; such discussions there are sometimes vehicles for trying to gerrymander a content dispute by making false or frivolous conduct accusations in attempt to get the other side blocked or banned so that they won't be able to !vote in the content dispute; and such discussions there are sometimes a an exceptionally toxic environment, and sometimes not an environment compatible with the safety of editors either. James500 (talk) 20:08, 18 January 2024 (UTC)[reply]
    @James500 I closed it due to the fact that the RFC is for changing the whole purpose of ANI in general, (which doesn't have a chance right now)) not just the header, that is why I left this section open so things like changing the header can be discussed. Seawolf35 T--C 20:23, 18 January 2024 (UTC)[reply]
    I agree with the many of the points you made. If we were to not use ANI for such purpose, what should be the alternative(s)? Ca talk to me! 00:38, 19 January 2024 (UTC)[reply]
    I think there should be a more concerted effort to direct people to the more structured alternatives that already exist for specific types of disputes (WP:DRN for content disputes, WP:XRV for contested use of permissions, WP:AE for edits in contentious topics, etc.) and, as a last resort, ArbCom for the remainder. – Joe (talk) 07:54, 19 January 2024 (UTC)[reply]

Bump XfD heading sizes

Should the daily WP:XfD logs have a level-2 heading for each page and a level-1 heading for each day? Aaron Liu (talk) 17:00, 26 January 2024 (UTC)[reply]

For example, the heading "April 18" would appear as large as the page title, and an article title like OneGet would look like the "Bump XfD heading sizes" heading above. For obvious reasons, this does not include WP:Requested moves.

  • Yes. This would make all such individual page discussions subscribable, and only level-2 headings are subscribable due to technical complexity. As for the level-1 heading, most XfDs already have a separate page for each day's log anyway, so displaying it as large as the page title shouldn't cause much problems. Aaron Liu (talk) 17:00, 26 January 2024 (UTC)[reply]
  • @Aaron Liu: Two questions. (i) Have you informed all relevant bot operators, and the maintainers of scripts like XfD Closer? (ii) do you intend to alter old XfD pages? --Redrose64 🌹 (talk) 20:26, 27 January 2024 (UTC)[reply]
    No and no. You do bring up a good point with notifying scripts, but I don't see any scripts other than @User:Evad37's XfDcloser and @Awesome Aasim's xfdvote that could be affected.
    I do not intend to alter old XfD pages, as there really isn't much of a point in doing so. Maybe we could only alter these beginning in March so monthly logs retain some uniformity. Aaron Liu (talk) 23:20, 27 January 2024 (UTC)[reply]
  • I see it as pointless. At the most, the heading for the top level should be level 2, not 1. If anything it could mess with scripts as stated by Pppery Redrose. I don't think my script would be affected, but others certainly can be. Awesome Aasim 23:49, 27 January 2024 (UTC)[reply]
    Maybe the solution is to have deletion discussions on talk pages and transcluded at the appropriate forum... Hmm.... Awesome Aasim 23:59, 27 January 2024 (UTC)[reply]
    I think you meant Redrose
    Having the top heading would be very confusing and wouldn't have everything below it fold, and I can name at least one other discussion page that has level-1 headings. I don't see why it would be bad either, and while I don't know much about XfD closer's code, I suspect it'll be an easy fix of adding one equal sign to everything. Aaron Liu (talk) 01:08, 28 January 2024 (UTC)[reply]
    It's also definitely not pointless. It allows people to subscribe to a section instead of watchlisting the entire page for notifications. Wikipedia:Help desk has already done basically the exact same thing. Aaron Liu (talk) 01:25, 28 January 2024 (UTC)[reply]
  • Subjectively I prefer the look of the current smaller headings. Though I realise this is pretty small compared to the practical advantages of subscribing to a new topic. ― novov (t c) 11:15, 28 January 2024 (UTC)[reply]
  • Notified: WT:TW. NW1223<Howl at me•My hunts> 19:09, 29 January 2024 (UTC)[reply]
    WT:XFDC notified. Primefac (talk) 20:23, 29 January 2024 (UTC)[reply]
  • Yes, makes sense; it's easy to miss out on further discussion at XfDs that use log pages. J947 ‡ edits 22:54, 29 January 2024 (UTC)[reply]
  • We've done it this way since the dawn of time over on Wiktionary. See wikt:WT:RFDE for an example. This, that and the other (talk) 01:11, 30 January 2024 (UTC)[reply]
  • I did some work on T275943 Add support for subsection subscriptions in December, then got busy. It looks doable and I intend to return to it when I get some time. –Novem Linguae (talk) 09:18, 30 January 2024 (UTC)[reply]
    Some other thoughts: 1) Using H1's seems to be a bad practice and is avoided almost everywhere on enwiki. 2) Changing this would likely require patches to several pieces of software including WP:Twinkle and mw:Extension:PageTriage. 3) It may be a good idea to sandbox this and drop a link here so we can see what it would look like. –Novem Linguae (talk) 09:26, 30 January 2024 (UTC)[reply]
    Traditionally the advice has been to avoid multiple first-level headings on the web, but for semantic reasons, rather than technical problems, assuming the heading structure is laid out in appropriate hierarchical order. (As far as I know, assistive technology such as screen readers don't have a problem, and search engines deal with it as well.) It can be argued, though, that a web page could semantically be a container for multiple documents, each with its own first-level heading. In the context of MediaWiki, since the software automatically generates a first-level heading for the page title, then semantically everything before the first = heading = in the wikitext would be its own document.
    Although personally I feel a bit uneasy with more than one <h1> element on a page, I can't say that it causes any practical problems from a general web perspective (I don't know about the various tools and extensions used by editors). There are of course already English Wikipedia pages with multiple first-level headings, such as Wikipedia talk:Mass message senders. isaacl (talk) 18:44, 30 January 2024 (UTC)[reply]
    I agree that there should be no technical wider-web issues; the HTML spec even provides an example of how outlines with multiple h1 elements can be rendered, so any fully-compliant user agent will take it in stride. Having said that, if there are a bunch of internal tools that will need to be updated to handle the change (and it seems that there are), then that's the more relevant technical issue. I'm not worried about the semantic aspect, given that something like XfD should prioritize the needs of its specific users, determined through consensus, rather than doggedly adhere to general advice. Regards, Orange Suede Sofa (talk) 00:18, 31 January 2024 (UTC)[reply]
  • Won't work at WP:RFD due to its current header hierarchy. In other words, this proposal is probably too broad since it includes all WP:XFD forums. Steel1943 (talk) 23:16, 8 February 2024 (UTC)[reply]
    If you mean how the list is transcluded under the final section, I actually don't see much of a problem with that as the headers will only appear at the end of the ToC. RfD was an intended target. Aaron Liu (talk) 23:48, 8 February 2024 (UTC)[reply]
    @Steel1943, why not change the current header hierarchy? Changing it seems feasible to me. WhatamIdoing (talk) 05:26, 12 February 2024 (UTC)[reply]
    Already did that once. What I see currently works best, IMO. Steel1943 (talk) 08:47, 12 February 2024 (UTC)[reply]
    Also, my comment at Wikipedia talk:Redirects for discussion#Can we reduce the number of RfDs transcluded on this page? is relevant here as well. Steel1943 (talk) 06:25, 13 February 2024 (UTC)[reply]
  • No for MFD, page works fine, anyone that wants to follow a specific entry can watchlist it. — xaosflux Talk 13:28, 9 February 2024 (UTC)[reply]
    I wonder how well the existing structure of MFD works for people using screen readers, when they go directly to the page. It has a =Level 1= (the page title), then nothing for ==Level 2== or ===Level 3===, but there is a ====Level 4====. I'm pretty sure that skipping levels like that is not recommended. WhatamIdoing (talk) 05:27, 12 February 2024 (UTC)[reply]
    @WhatamIdoing: It's not in the HTML spec; you need to burrow about in WCAG 2.2 in order to find G141 Organizing a page using headings, which says To facilitate navigation and understanding of overall document structure, authors should use headings that are properly nested (e.g., h1 followed by h2, h2 followed by h2 or h3, h3 followed by h3 or h4, etc.). In the "Other sources" on that page, we have a link to WebAIM: Semantic Structure: Regions, Headings, and Lists which has The <h1> describes the page as a whole (and should be similar to the page <title>). A page should typically have only one <h1>. Headings <h2> through <h6> represent increasing degrees of "indentation" in our conceptual "outline". As such, it does not make sense to skip heading levels, such as from <h2> to <h4>, going down the page. --Redrose64 🌹 (talk) 18:19, 12 February 2024 (UTC)[reply]
    The primary page for readers to land on is Wikipedia:Miscellany for deletion, which emits h1, h2, h3, h4 in a standard tree already. — xaosflux Talk 15:02, 13 February 2024 (UTC)[reply]

RfC: Converting all current and future community discretionary sanctions to (community designated) contentious topics procedure

Should all community discretionary sanctions (DS) be updated to use the new contentious topics procedure? Awesome Aasim 05:55, 7 February 2024 (UTC)[reply]

Background

In late 2022/early 2023, the discretionary sanctions procedure was overhauled by ArbCom and converted to "contentious topics". With now two different processes for two different kinds of sanctions there is now a lot of fragmentation and inconsistency in how contentious topics should be handled, with even conflicting wording. The main goal of this RfC is to unify the procedure used for all areas where general sanctions are in effect with the one designated by ArbCom, going forward.

As proposed at this time, there will be the some similarities and differences between community and arbitration contentious topics, including:

  • The imposition of the standard set of restrictions by consensus of administrators in a community designated topic would be at WP:ANI rather than WP:AE.
  • Reconsideration of contentious topic restrictions would be done at WP:AN instead of at WP:AE or WP:ARCA.
  • Awareness of a community contentious topic would include but not be limited to being mentioned in the discussion closing summary regarding that contentious topic, which is the closest there is to a "final decision".

And of course, ArbCom would be able to convert community contentious topics to those designated by the committee, after which all the ArbCom venues would have to be used from that point forward, though existing restrictions would remain appealable to WP:AN until renewed at ArbCom.

Survey (community contentious topics)

  • Support as proposer. It needs to be clear, especially for new editors, what contentious topics are and what the expectations are for editing topics designated as contentious by either ArbCom or the community. A unified procedure will ensure consistency rather than fragmentation and will make editing the list of contentious topics and their restrictions much easier. (I did do a little bit of work in the Module:Sanctions/sandbox adding in support for ArbCom contentious topics, as it would make it so much easier to use the related sanction templates. I also did work in user space to help envision what a unified contentious topics page might look like.) Awesome Aasim 05:55, 7 February 2024 (UTC)[reply]
  • Strong Oppose The current iteration of WP:CTOP is far too tied in to the Arbitration Committee. The available sanctions and procedures are under the jurisdiction of WP:AC/PR can be modified by the Committee by motion at any time, which in this scenario would be binding on decisions made by the community without community consensus. Additionally, many of the General Sanctions areas have a set of restrictions that either exceed what CTOP would allow, or have a more limited subset of them. The community currently has the flexibility to customize sanctions based on the needs of the individual topic area (similar to how Arbcom can impose their own restrictions either alone or on top of the CTOP designation), rather than relying on a "one size fits all" solution. Regarding the possibility of Arbcom choosing to convert community-based CTOP to Arbitration Enforcement, the Committee already has the power to supercede and convert General Sanctions. They've done so before, in cases including WP:ARBCC and WP:ARBTPM. This proposal as written would reduce the community's autonomy and flexibility for the sake of consistency, and I don't see that as a net positive.
    I would, however, support the community adopting a "standard/default" DS language that could be used when customization isn't needed, and reviewing all the existing GS areas to see if they should be abolished or modernized. Updating our own process, templates, info pages etc to completely separate from the Arbcom version would also accomplish this proposal's goal of reducing confusion and would be better than the current system of sometimes linking to CTOP, sometimes linking DS which redirects to CTOP (when they really mean the older version of DS), sometimes a completely different thing with no consistency. Template:Gs/alert is one example of this, where it links to WP:CTOP even when the actual restrictions are unrelated to that designation. Revamping our own procedures would be a better way to reduce fragmentation and confusion than glomming onto what Arbcom chooses to do. The WordsmithTalk to me 18:32, 7 February 2024 (UTC)[reply]
    I am not exactly seeing how this is a dealbreaker. The CT procedure applies only to designated contentious topics; community consensus or arbitration remedies can always add additional sanctions regardless of WP:CTOP like in WP:ARBPIA. Awesome Aasim 22:13, 7 February 2024 (UTC)[reply]
  • Support The phrase "discretionary sanctions" is not clear and so the phrase "contentious topics" was introduced as an improvement. We should have clear and consistent language for contentious matters so that discussions and actions are comprehensible. Andrew🐉(talk) 08:57, 10 February 2024 (UTC)[reply]
  • Support. The "sanctions regimes" are too complex as it is, and we need to use consistent terminology to reduce that complexity when possible.  — SMcCandlish ☏ ¢ 😼  13:03, 21 February 2024 (UTC)[reply]

Discussion (community contentious topics)

Cooperation of ArbCom

I wonder if adding in stuff to the WP:CTOP page and similar would require the petition and referendum process. If so, then I guess the merging of templates would have to hold off until a former petition and request for amendment actually passes. It is possible ArbCom will green light the merge if this RfC passes, but I do not know. Awesome Aasim 05:55, 7 February 2024 (UTC)[reply]

I feel the community should work with the arbitration committee to assume responsibility for the contentious topic process, with a pointer to an arbitration-committee specific page where it can customize the process as it feels necessary. This would bring the process under community control, while still allowing the arbitration committee to adapt it to its needs. (There is no change to arbitration policy and so no need to amend it.) isaacl (talk) 19:07, 7 February 2024 (UTC)[reply]
Wouldn't that just be the status quo (or perhaps the old GS/DS) status quo? I think Arbcom is more agile than the community in drafting this kimd language given that passing a motion is easier than an RfC and motions can be adjusted mid vote which is nearly impossible to do with an RfC. Truthfully I think the right place to start is with the standardized language for community GS and perhaps to be more intentional about whether it wants its restrictions to be eligible to be heard at AE, though as The Wordsmith points out there are really good reasons for the community to decide not to do that. Barkeep49 (talk) 04:30, 9 February 2024 (UTC)[reply]
The process for authorizing discretionary sanctions was documented by the committee, and then later the community started authorizing discretionary sanctions, with its process pointing to the Arbitration Committee pages and saying, "like that". This resulted in the community's process being coupled to decisions made by the arbitration committee. I'm suggesting the reverse: have the community assume responsibility for the contentious topics process, and then the arbitration committee can point to it and say, "like that, but with our specific customizations". I agree the community can decide on its own on what contentious topic process it wants to create. I think it would be good, though, to check with the committee that it is amenable to adopting the community process as a base, and layering any desired differences on top. isaacl (talk) 04:52, 9 February 2024 (UTC)[reply]
That also sounds like a good idea: community authorizes the remedies that are appropriate, ArbCom implements them. If ArbCom were to deviate then they would just need to ask the community whether it is an appropriate deviation or not. Awesome Aasim 17:28, 9 February 2024 (UTC)[reply]
The committee doesn't have to be constrained by the community as it is already authorized through the arbitration policy to enact remedies of its devising for matters within its scope. It would be simpler for editors to understand, though, if the arbitration committee version of the process was just a set of differences upon a common process. Differences could include things like additional administrator actions that could be performed, or a specific venue for appeals. isaacl (talk) 18:03, 9 February 2024 (UTC)[reply]
I think you know what I mean :)
WP:ARBECR is already used a lot by both the community and by ArbCom, like in WP:RUSUKR and WP:CT/A-I. What I am saying is if ArbCom feels that a specific sanction that there has never been any precedent for is necessary, they should propose it to the community, where there then can be consensus on the exact wording. Placement, enforcement, and appeals are all going to differ though depending on whether the restriction is placed by the community or ArbCom. Awesome Aasim 18:43, 9 February 2024 (UTC)[reply]
The community can provide feedback on proposed decisions. I disagree that the committee needs to obtain community consensus on new types of remedies. The arbitration committee is empowered to impose a restriction that community consensus has been unable to reach through prior dispute resolution. If you are referring specifically to the standard set of restrictions that can be imposed for designated contentious topics, I still disagree that community consensus should be mandatory. Typically the committee will provide an opportunity for feedback and the last review of discretionary sanctions illustrates that it strives to lighten the load of enforcing administrators. isaacl (talk) 19:17, 9 February 2024 (UTC)[reply]
Regarding the extended-confirmed restriction, it was initially devised by the committee on its own. After taking some time to evaluate its effectiveness, the community chose to adopt it as an available restriction. isaacl (talk) 19:25, 9 February 2024 (UTC)[reply]
I agree with isaacl that ARBPOL and CONEXEMPT explicitly mean that the committee does not have to, with-in its scope, get community consensus.
However, ECR is a example of why I think the committee is better placed at the moment to be a leader when it comes to contentious topics. The committee having to deal with the absolute hardest conflicts means there is going to be more of an incentive to try something new and ~15 people are going to have an easier time getting to yes than what is required to get community consensus for that newness. It's also revealing to me that ArbCom gets more requests for us to assume community imposed sanctions (examples: COVID, Horn of Africa as two that the committee did assume and Russia-Ukraine War as one that committee has twice been asked to assume and haven't). I would really love it if the community could, as it does in so many other ways, demonstrate broader capabilities when it comes to general sanctions than it has in the past. And to that end getting consensus for some standard wording would be a great place to start. Barkeep49 (talk) 19:48, 9 February 2024 (UTC)[reply]
I agree that the arbitration committee is better positioned to try new approaches (consensus doesn't scale up well, so getting consensus amongst 15 people is definitely easier). In a similar vein as you expressed, I feel it would be ideal for the community to agree on a base contentious topics process, which the committee could extend in new ways that the community could later choose to incorporate back into the base process. isaacl (talk) 19:57, 9 February 2024 (UTC)[reply]

In WP:DS2022, one of the changes made was to allow the community to make use of AE. I think we should do so. HouseBlaster (talk · he/him) 03:42, 9 February 2024 (UTC)[reply]

I definitely think we should split contentious topics from WP:AELOG. A separate contentious topics log would make restrictions much easier to follow - and, if the restriction is rescinded or converted from community to ArbCom or the other way around - it can be logged as well. Awesome Aasim 21:21, 10 February 2024 (UTC)[reply]

Request revision to initial question

The statement all community general sanctions (DS) in the initial question is misleading. "General sanctions" is not synonymous with community authorization for discretionary sanctions. I think the intent should be clarified that the proposal only affects discretionary sanctions authorized by the community, and not all general sanctions. isaacl (talk) 19:03, 7 February 2024 (UTC)[reply]

Isaacl Done. Awesome Aasim 20:07, 7 February 2024 (UTC)[reply]

Is it time for a new design for the main page?

Hi, Wikipedians,

I believe it's time to consider updating the design of the main page. I'm not certain when the current style was implemented, but it seems to date back to 2006 or even earlier. Nowadays, there are numerous modern and colorful box templates available that could give the page a more contemporary look. What are your thoughts on starting this initiative? After all, the main page represents our entire community. I understand that changing a familiar style can be challenging for many users, but it's part of the natural cycle of updates.

Best regards, Riad Salih (talk) 02:50, 14 February 2024 (UTC)[reply]

Ain't broke, don't fix it. * Pppery * it has begun... 03:02, 14 February 2024 (UTC)[reply]
+1 It still looks good on Desktop and even on my phone, in Monobook and Minerva. Everything is in one column and the content is very readable.The WordsmithTalk to me 17:03, 14 February 2024 (UTC)[reply]
This contradicts the well-established community consensus of “ain’t broke, let’s break it and pretend we might fix it later”. 216.147.126.60 (talk) 20:52, 14 February 2024 (UTC)[reply]
Fair, true, and appropriate.
I agree. ProofCreature (talk) 18:24, 15 February 2024 (UTC)[reply]
You may want to review Wikipedia:Perennial proposals#Redesign the Main Page. Anomie⚔ 03:47, 14 February 2024 (UTC)[reply]
Wikipedians don't like change (see above), so it's not going to happen without a lot of work, but I do agree that it's time for a redesign. Since the last major attempts a decade ago, responsive design technology has advanced enormously, a new design system has been rolled out across Mediawiki, and we got a new default skin. All of this makes the main page look particularly dated and out of place in 2024. Ideally, we'd proceed by asking Wikimedia's design team to lend us their expertise and create something new – subject to community-agreed goals and constraints but not a crude yes/no vote on using it (which would inevitably fall afoul of the "change is bad" phenomenon). – Joe (talk) 07:36, 14 February 2024 (UTC)[reply]
Riad Salih You could probably get consensus for the general idea that the MP should be changed, but the consensus would break down over what specifically to change it to, as everyone has their own idea about that. As noted, this is a constantly made proposal. The best chance of success would probably be to propose incremental changes, one at a time- a wholesale redesign would never gain consensus. Even a small change would take much work to convince others to support and implement. 331dot (talk) 08:53, 14 February 2024 (UTC)[reply]
One idea that might get approval is moving to a single column. The current layout was well designed when pages used the whole screen, but there are very few words on each line now that we have two thin columns shoehorned into a narrow stripe down the middle of the screen with an acre of empty white space either side. Certes (talk) 10:17, 14 February 2024 (UTC)[reply]
The white space is probably from the skin you are using. It looks fine in legacy vector. Easier to change the skin to something that you like rather than change the main page for everyone RudolfRed (talk) 01:41, 15 February 2024 (UTC)[reply]
From a purely selfish viewpoint (which is allowed, as this is an aesthetic matter), I want the main page to remain unchanged. I use Vector 2010, and everything looks just fine to me. However, the vast majority of readers don't have the luxury of setting that preference, and are stuck with wide blank sidebars. Certes (talk) 09:51, 15 February 2024 (UTC)[reply]
I use the full width view of new Vector, but when checking it on the narrow width, it looks fine to me. A little narrow perhaps, but not nearly constrained enough IMO to obviate the advantages of a two-column view. ― novov (t c) 08:33, 15 February 2024 (UTC)[reply]
VECTOR2022 should just be reversed. ~WikiOriginal-9~ (talk) 18:35, 15 February 2024 (UTC)[reply]
As Joe Roe said, Wikipedians are usually a little less open to change than a cube of iron. But do you have any specific ideas? 🌺 Cremastra (talk) 13:17, 14 February 2024 (UTC)[reply]
Hi @331dot @Anomie @Certes @Cremastra @Joe Roe @Mir Novov @Pppery @RudolfRed @
What do you think, for example, of the design of the main page of the Spanish Wikipedia? Or the Portuguese version or Turkish?
Regards Riad Salih (talk) 10:39, 15 February 2024 (UTC)[reply]
I kind of like the Spanish version, but Vector 2022 forces the text to wrap in a weird way because it's so narrow. The Turkish version is pretty similar to en.wiki's, and wouldn't be much of an improvement. I also looked at the Chinese MP (fine, but too white) the French one (I quite like it, actually), and and what I believe is the Slovakian one, which I also quite like. 🌺 Cremastra (talk) 12:58, 15 February 2024 (UTC)[reply]
@Cremastra Yes, I do agree with that, especially the Slovakian one. However, you know we still need ideas from other contributors, which can be challenging. Nevertheless, I will make an effort to advocate the idea of changing the main page design. Riad Salih (talk) 14:19, 16 February 2024 (UTC)[reply]
With all due respect, the gradients in the Slovakian one make it look very dated, like an early-2000s PowerPoint template. --Ahecht (TALK
PAGE) 15:15, 19 February 2024 (UTC)[reply]
I agree that the Slovakian one is too dated. I don't see any problems with the Spanish version under vanilla V22. Maybe swap POTD with On this day for slightly longer line lengths for the latter, make Other projects full-width (and maybe unbox it), and of course adapt ITN to our format, but I don't think the Spanish version needs any more changes. Aaron Liu (talk) 16:25, 19 February 2024 (UTC)[reply]
I would concur that it's a good idea. IMO, some of the other Wikipedias have Main Pages that put enWP's one to shame. But as others have stated, good luck finding something that everyone can agree on. ― novov (t c) 08:38, 15 February 2024 (UTC)[reply]
Is there something particular you feel is a problem with the current design? – Teratix ₵ 09:17, 15 February 2024 (UTC)[reply]
I think that it’s probably best to make changes one by one, so that consensus would be more likely. Like one change per discussion. 71.239.86.150 (talk) 16:01, 17 February 2024 (UTC)[reply]
Redesign it, but in a way that removes ITN and DYK. Both are massive investments for very little return, and much of the content they display is low quality. Thebiguglyalien (talk) 00:50, 19 February 2024 (UTC)[reply]
Fucking excuse me? How the heck are the articles that we've vetted low quality? ITN gives us some global perspective and is one way readers could keep themselves up to date in current events. DYK makes everything a bit more fun for everyone and trivia is fun. Both highlight our utility as an online encyclopedia and good work on our behalf. Removing it would make no sense at all. It has worked, it is working, and it returns. Aaron Liu (talk) 02:51, 19 February 2024 (UTC)[reply]
@Aaron Liu: The problem with opening remarks such as Fucking excuse me? is rather that they invite a retort along the lines of, yes, well, "fucking excuse you".
Regarding the gist—How the heck are the articles that we've vetted low quality—I think what Thebiguglyalien might be getting at is that simply undergoing a vetting process is insufficient; it is the quality of the vetting that is important, and so by extension, the quality of those doing the vetting. If, for example, ITN and DYN undergo a lightweight review which is perhaps keener on filling slots and reducing backlogs than ensuring the integrity of the main page, then it would be unsurprising, in some eyes, if these processes came under extra scrutiny, hein. Some might also argue that trivia—however much "fun" it is—is incompatable with an encyclopedia that aspires, where possible, to serious scholarship. HTH! ——Serial 16:30, 20 February 2024 (UTC)[reply]
Thanks for the detailed explanation, though I don't think the vetting that we do is low-quality. At least at ITN we do a pretty big referencing pass.
I also wonder what you mean by "hein". A dictionary search shows that it is 1. surprisingly not German 2. Dutch for death 3. French and Portuguese for "huh?". Is that last one what you meant? Aaron Liu (talk) 17:10, 20 February 2024 (UTC)[reply]
@Aaron Liu:, indeed, I know no German or Dutch! But yes, a "huh" because I wasn't speaking for myself on the quality of the vetting, merely that it's a view (among others, of course, as you point out.) Cheers, ——Serial 17:14, 20 February 2024 (UTC)[reply]
User:Cremastra/MP looks fine to me. What do you think of the changes here? 🌺 Cremastra (talk) 01:49, 19 February 2024 (UTC)[reply]
Thanks for the work, but unfortunately I don't like it very much:
  1. I don't know any good ways to fix this, but flushing the Welcome banner's text to the left leaves a lot of blank space in the rest of the box, making it feel weird.
  2. We already have a search box; we don't need another one.
  3. The third column has line lengths that are way too short in the limited width. That makes the excessive space to the right of the descriptions all the more jarring. And that is in my version of V22 enhanced with my private styles. Under the normal limited width all the columns have line lengths that are too short and the sister projects' descriptions run off the page.
  4. Something feels wrong about the concept of giving that much prominence to our sister projects. Wikipedia readers are hardly gonna go there and this introduces a lot of colorful icons that clutter up your attention. Previously it'd only take attention when you scroll/look down and want to dedicate attention to it.
  5. Lots of useless blank space under the third column.
  6. Probably a bug, but Other areas of Wikipedia appears twice.
Aaron Liu (talk) 03:02, 19 February 2024 (UTC)[reply]
User:Cremastra/MP: using Galobtter's design for the main portion. I think a large prominent search box on the main page is a good idea, though, as opposed to a redundancy. 🌺 Cremastra (talk) 16:59, 19 February 2024 (UTC)[reply]
That does look much better! Combining the search box with the first box seems alright, though maybe I'd use the tagline "Search free knowledge". I'd also recommend making the globe logo stick to the bottom of its box, replacing the whitespace between the first two boxes with a horizontal rule, and maybe put the occasional banner before that rule with a white background. Aaron Liu (talk) 18:48, 19 February 2024 (UTC)[reply]
I'm not sure about the search box, but I like the top banner otherwise, especially the logo in the bottom left. Galobtter (talk) 01:09, 20 February 2024 (UTC)[reply]
I don't think WPAds should be isolated. Maybe it could replace the search box.
Also, any ideas for how to eradicate that awkward gap below the image for the first box? Aaron Liu (talk) 02:20, 20 February 2024 (UTC)[reply]
There has been consensus to remove portal links, so the "Look through content portals" part should be omitted. ObserveOwl (chit-chat • my doings) 09:05, 2 March 2024 (UTC)[reply]
If we modernize it, I suggest we make it like eswiki's (which happens to be adapted from ruwiki's). It's OOUI, modernized and is in a familiar layout, though I might make the "other projects" part full-width. Aaron Liu (talk) 02:48, 19 February 2024 (UTC)[reply]
I think people will support a new main page design as soon as they're shown a new main page design that they like. I would encourage people who are so inclined to create and share mockups of new main page designs. Eventually someone will make something that enough people like. Levivich (talk) 17:16, 20 February 2024 (UTC)[reply]
BTW my 2c: make the main page, en.wikipedia.org, look much more like www.wikipedia.org: a minimalist interface, with a prominent search bar, to which I'd add prominent display of TFA and FP. Like maybe FP centered at the top, search bar below that, and TFA below that. But I'm no web designer though so I'm not sure exactly how that should all look. Levivich (talk) 17:21, 20 February 2024 (UTC)[reply]

Is it possible to have, say, the current main page visible to users with the Vector legacy skin, but a main page similar to eswiki's for Vector 2022 users? This way we could keep up the "modern" look for Vector 2022, but keep the "legacy" style for Vector legacy. I just don't know if this is technologically feasible. ‍ Relativity 03:06, 19 February 2024 (UTC)[reply]

The current main page has no problems to view in Vector 2022. That said, it should be possible with CSS selectors. Aaron Liu (talk) 03:35, 19 February 2024 (UTC)[reply]
  • I am dubious Why? No clear argument for why this would be desirable. Can we be sure it would not lower general accessibility depending on the device being used to access the site? I am not adamantly opposed to sprucing things up a bit. But the oft quoted adage "if it aint broke, don't fix it," definitely comes to mind. -Ad Orientem (talk) 04:43, 19 February 2024 (UTC)[reply]
  • I think where previous proposals have failed before is in trying to do many changes at the same time (e.g. changing the emphasis of different parts of the main page while also restyling it). Anyways I have a modest proposal, under the principal that less is more and that the boxes around everything is the most dated part of the main page, at User:Galobtter/sandbox/Main page. It could do more work from someone who actually knows how to design (I like ptwiki's main page header a lot and that could be incorporated), but all I did was basically remove unnecessary (imo) styling. Galobtter (talk) 06:13, 19 February 2024 (UTC)[reply]
    Hey, I like that! Zanahary (talk) 06:34, 19 February 2024 (UTC)[reply]
    I like that! It's simpler but clearer. Although something seems a little off with the header box, the lack of border makes it feel poorly-defined to me. 🌺 Cremastra (talk) 13:45, 19 February 2024 (UTC)[reply]
    I like it, but I think the margins around each section need to be a little more generous if there are no borders. --Ahecht (TALK
    PAGE    ) 15:17, 19 February 2024 (UTC)[reply]
    I also like this. While we're at it, maybe align DYK with On this day Aaron Liu (talk) 16:26, 19 February 2024 (UTC)[reply]
    That's done manually by admins each day since aligning depends on how much content is in each of the sections. Galobtter (talk) 23:17, 19 February 2024 (UTC)[reply]
    Can't we add padding to the bottom of TFA, like ptwiki seems to do? Also the manual alignment doesn't seem to be working for me Aaron Liu (talk) 23:47, 19 February 2024 (UTC)[reply]
    I like a lot of that, but (at least on Desktop on MonoBook) the colored section headers only seem to have a thin border on the bottom and nothing on the other 3 sides. Much better than the es.wiki one linked above, which is visually clean but seems to lack any sort of flavor. The WordsmithTalk to me 16:42, 19 February 2024 (UTC)[reply]
    I think the border's supposed to be like the heading's border.
    I believe that whatever we think about the rest of it, we should adopt the first box of the eswiki/ruwiki main page. Aaron Liu (talk) 16:52, 19 February 2024 (UTC)[reply]
    colored section headers only seem to have a thin border on the bottom and nothing on the other 3 sides is intentional - I wanted to have a simple header style rather than having an unnecessary box around the headers. Yeah, I liked ptwiki's a lot more than eswiki's, which is probably technically the "best" in terms of modernization but is too bland. Galobtter (talk) 23:17, 19 February 2024 (UTC)[reply]
    My proposal would be to change the boxes to a very light gray and then remove the border. 71.239.86.150 (talk) 18:20, 19 February 2024 (UTC)[reply]
    @Ahecht I added 1px of margin, which was missing since I removed the 1px border. It looks ok to me now, although you might be right that more margin is needed. @User:Cremastra I stole the box shadow from ptwiki - what do you think now?
    I want to avoid doing more with this, since I think that's where previous proposals have failed - people want some of the changes but not others so it ends up a whole mess. And since at least some people seem to like this, I might try to put it up for RfC soon, but want to make sure there aren't small tweaks needed to what I've done. Galobtter (talk) 00:24, 20 February 2024 (UTC)[reply]
    I'd support it at the RfC stage, but unfortunately I doubt it would pass. 🌺 Cremastra (talk) 00:40, 20 February 2024 (UTC)[reply]
    Another idea would be to use light gray rounded rectangles, because rounded rectangles are a very common part of modern web design. 71.239.86.150 (talk) 13:47, 20 February 2024 (UTC)[reply]
    Yes they're common but Wikipedia and mw:Codex, our design language, never use them. That would be completely alien to the rest of the encyclopedia. Aaron Liu (talk) 14:43, 20 February 2024 (UTC)[reply]
    I have a visceral dislike for rounded rectangles, possibly because they are now so prevalent. 🌺 Cremastra (talk) 20:49, 20 February 2024 (UTC)[reply]
  • Probably, yes it is time, however the problem is not to change the design, it is how to herd the cats without them canabalizing themselves. —TheDJ (talk • contribs) 21:14, 20 February 2024 (UTC)[reply]
    What is that graphic metaphor supposed to mean? Aaron Liu (talk) 22:26, 20 February 2024 (UTC)[reply]
    When you try to get a lot of people to make a decision together, they often spend more time attacking each other than they do collectively moving in any productive direction, if I understood the metaphor correctly. Levivich (talk) 23:15, 20 February 2024 (UTC)[reply]
    What's needed is a brainstorming RfC process like is currently being done for RfA. This gives an opportunity for a variety of ideas to be suggested and we can then see what sticks. For example, I'm most interested in structural change -- amending the section order and content so that the featured picture and ITN swap places so that ITN can expand coverage of its recent death entries. Issues like this can't be resolved by the editors who maintain the individual sections and so an overall mainpage forum is needed. Andrew🐉(talk) 09:33, 21 February 2024 (UTC)[reply]
    I don't think expanding coverage of RD entries is needed much, and the POTD often needs a dedicated row due to its image size.
    We're currently kinda designing some layouts, so a more formal workshopping process should begin when we have more proposals. Aaron Liu (talk) 16:01, 21 February 2024 (UTC)[reply]
    If you go to one column, you won't have to worry about balance. --User:Khajidha (talk) (contributions) 19:17, 21 February 2024 (UTC)[reply]
    That would be wasting a lot of space. Aaron Liu (talk) 20:06, 21 February 2024 (UTC)[reply]
    No, that would be allowing the text and images to spread across the screen instead of being cramped into tiny corners. --User:Khajidha (talk) (contributions) 20:19, 21 February 2024 (UTC)[reply]
    Why would we need all the text and images to spread across the screen? They don't gain anything from being wider. Aaron Liu (talk) 20:41, 21 February 2024 (UTC)[reply]
    You don't think that a larger image and prose that isn't chopped into tiny sections that resemble the old "See spot. See Spot run. Run, Spot, run." children's books would be useful?--User:Khajidha (talk) (contributions) 01:51, 23 February 2024 (UTC)[reply]
    As I don't have a childhood,[Joke] I'm not sure what you're talking about.
    We do not have an overabundance of blurbs, blurb words, recent deaths or DYK hooks. Besides size limitations, there's a reason newspapers separate every single article into columns. Aaron Liu (talk) 01:59, 23 February 2024 (UTC)[reply]
    The most popular view or Wikipedia is the mobile one and that's already one column. We should therefore be designing and optimising for that as the primary interface. The balance issue is absurd in that it often causes ITN admins to remove news entries -- form rather than function. Andrew🐉(talk) 20:31, 22 February 2024 (UTC)[reply]
    Remind me what happened the last time a bunch of editors thought Wikipedia was optimizing for the mobile view. Aaron Liu (talk) 20:36, 22 February 2024 (UTC)[reply]
    The most popular editing view for Wikipedia is desktop, not mobile. Alienating the site’s most essential users is a serious risk to take. If there had been no way to revert the Vector 2022 and recent line height changes, I would have been strongly alienated from Wiki and contributed way less. Zanahary (talk) 23:58, 22 February 2024 (UTC)[reply]
    Most editors are not allowed to edit the main page and so we have a frozen format which is alienating too. What's needed is a process for making changes which allows the main page to evolve. Perhaps there could be an annual update. During the year, there would be a beta test version to trial proposals and then a confirmation and release process at the end of each annual cycle. Andrew🐉(talk) 09:37, 23 February 2024 (UTC)[reply]
    I don't think we'd need to change the main page every year. Aaron Liu (talk) 14:00, 23 February 2024 (UTC)[reply]
    I agree. Maybe changing every 3 years would be a better idea. 71.239.86.150 (talk) 21:34, 24 February 2024 (UTC)[reply]
    I feel like we should only change it if we should, not force a change every 3 years. Aaron Liu (talk) 21:45, 24 February 2024 (UTC)[reply]

Allowing editors to opt out of private information on XTools.

Many wikis (such as Wikisource) allow users to opt-in to showing some of the more private information on XTools. En-WP, on the other hand, has done a project-wide opt-in by default. This is not an RfC, per WP:RFCBEFORE, but should we:

  • Option 1— do not allow English Wikipedia users to opt-out. (This is the status quo).
  • Option 2— allow English Wikipedia users to opt-out.
  • Option 3— make it an opt-in process by default.

Thank-you. 🌺 Cremastra (talk) 20:10, 19 February 2024 (UTC)[reply]

  • Option 2 at the least, as proposer. The current state of affairs does not seem like a good thing. Isn't automatically revealing more private information on XTools unsavoury at the very least? Users should at the minimum have the right to restrict more private data such as the timecards from appearing in the XTools analysis. As SlimVirgin wrote during a 2014 discussion on the issue, Even though the information is in theory publicly available, presenting it in this format is still a privacy issue. (Just because we all walk down the street doesn't mean we'd want CCTV cameras joining up our activities and someone posting it online.)🌺 Cremastra (talk) 20:10, 19 February 2024 (UTC)[reply]
  • Option 1 The data in question is not private to begin with, and never was. This does nothing but create privacy theater. * Pppery * it has begun... 20:13, 19 February 2024 (UTC)[reply]
  • Option 1 I do not think users should have any expectation that information extractable from WP logs won't be compiled, and would argue that allowing them to is (mildly) against WP:5P3 Mach61 (talk) 20:21, 19 February 2024 (UTC)[reply]
  • Option 1 per Pppery. This doesn't qualify as "private information". InfiniteNexus (talk) 20:21, 19 February 2024 (UTC)[reply]
  • Option 2. Option 3. Option 2.5. As I understand it, the devs only allow opting out of three areas: timecard, monthly counts, and top edits by namespace. My !vote is to require users to affirmatively opt-in for timecard and monthly counts, but not top edits by namespace, which should not allow an opt-out. I agree with @Cremastra and @SlimVirgin. When you're editing on Wikipedia isn't private information per se, since anyone can take a look at someone's edit history. However, an easy-to-use tool that lets someone know when you're generally online and making edits can pose security risks (e.g., it can show when you're usually home and usually not at home; similarly, monthly counts can show what months you're generally on vacation or away from home). Regarding @Mach61's point that users should [not] have any expectation that information extractable from WP logs won't be compiled, the only tool that currently does that compiling is XTools, and I doubt someone would go through the headache of creating, hosting, and maintaining a new tool in the event that en-wiki users are allowed to opt out. This should be disabled by default because new editors won't know that it exists, and anyone who knows enough to know that XTools exists would know how to opt in if they choose. voorts (talk/contributions) 20:44, 19 February 2024 (UTC), changed !vote 20:49, 19 February 2024 (UTC) and again 21:08, 19 February 2024 (UTC)[reply]
    I doubt someone would go through the headache of creating, hosting, and maintaining a new tool in the event that en-wiki users are allowed to opt out. It's quite simple to write a quarry query doing all of this - it wouldn't look as nice, but the information would be there. BilledMammal (talk) 21:44, 19 February 2024 (UTC)[reply]
    Sure, but how many people know how to do quarry queries or will take the time to learn how to do so? voorts (talk/contributions) 22:25, 19 February 2024 (UTC)[reply]
    There already is at least one other tool that shows timecards and monthly counts (wikichecker), and I'm pretty sure that creating a new version of the xtools edit counter tool would be relatively trivial, since the source code is freely available. Firefangledfeathers (talk / contribs) 23:27, 19 February 2024 (UTC)[reply]
    Fair enough. Xtools is fairly integrated into Wikipedia though, so I think removing that option creates an extra step for potentially malicious people to poke around. voorts (talk/contributions) 23:30, 19 February 2024 (UTC)[reply]
  • Option 1.5 - Mostly agree with Pppery and Mach61. Edits are public and transparent. If someone wants to gather our public edits and make a neat tool to show patterns in those edits, that's generally a good thing IMO. What's more, we have no real say, because we already agree to make edits on a public, transparent, free, and open wiki. It's 100% up to the developers what they want to do, and an RfC about opt-in/opt-out is really just a request. If the devs honor it, anyone else could just fork it and host the same thing elsewhere. For the most part, I don't think the devs should allow opt-out. Again, it's all public information and the tool is frequently useful. The only argument I find myself sympathetic with is the one about timecards per SlimVirgin/Cremastra. Although I just finished talking about how it's all public and up to the devs, to take it to an extreme, I think this community wouldn't take kindly to developers of a tool that, for example, processed the entire text of a user's contributions to produce a profile guessing at their real life identity. In short, if you run an RfC, be sure to separate the timecard from everything else or you'll get a bunch of people like me who sortakinda think the timecard should have an opt-out, but would oppose a blanket question. — Rhododendrites talk \\ 21:00, 19 February 2024 (UTC)[reply]
    Along the SlimVirgin/Cremasta line of reasoning, let me toss out another way edit timestamps might leak personal information. Lets say I looked at all your timestamps and observed that near the end of every week, you abruptly stop editing at a specific time, and pick up again 24 hours later. I might guess that those are the times of sunset where you live and thus surmise that you're an observant Jew/Muslim/etc, who stops editing on the sabbath. Other editing gaps around major religious holidays might confirm my guess. A few minutes with an almanac could narrow your location down to a few cities where sunset happens at those times over the course of a year. That's quite a bit of information just from looking at your timestamps.
    If I've figured out that you're an observant Jew who lives in New York, I've narrowed you down to maybe a million people. On the other hand, if I've figured out that you're an observant Jew who lives in the Falkland Islands, according to Jewish population by country, there's only one of you, so I've got you nailed. RoySmith (talk) 22:33, 20 February 2024 (UTC)[reply]
  • Comment - The info page on xtools says Your wiki should have had a local discussion showing consensus for these statistics to be allowed. Did that discussion ever happen, and if so when? If not, then en wiki needs to go back to hiding that info until that discussion happens (which would be this topic if/when it becomes an RFC). RudolfRed (talk) 21:09, 19 February 2024 (UTC)[reply]
    It happened at Wikipedia:Village pump (proposals)/Archive 111#Edit Counter Optin. --Ahecht (TALK
    PAGE    ) 21:10, 19 February 2024 (UTC)[reply]
  • Option 1 Your edit history is always publicly available and visible to anyone and everyone, and pretending otherwise is at best ineffective and at worst misleading and harmful to the transparency that Wikipedia tries to support. Even allowing opt-out for timecards is potentially harmful, as it gives the false impression that users can hide PII such as the times they are active. Finally, it seems somewhat silly to have all this handwringing about XTools when completely unaffiliated sites such as https://en.wikichecker.com/ exist. --Ahecht (TALK
    PAGE    ) 21:11, 19 February 2024 (UTC)[reply]
  • Option 2.5 (My !vote is to require users to affirmatively opt-in for timecard and monthly counts, but not top edits by namespace, which should not allow an opt-out. -- voorts) What harm can one do with someone's edit count and top edits? I can see an argument against time cards and monthly edits. Someone could always try to create a tool to replicate these functions in order to act maliciously, but there's no reason for us to facilitate their aims by providing a tool to do this.Sincerely, Novo TapeMy Talk Page 21:17, 19 February 2024 (UTC) Option 1 per Novem Linguæ below. Sincerely, Novo TapeMy Talk Page 18:12, 1 March 2024 (UTC)[reply]
Why are the time cards implemented in the first place? What purpose do they serve? 🌺 Cremastra (talk) 21:25, 19 February 2024 (UTC)[reply]
Several purposes: they can help users in identifying sockpuppets, they can can help visualize when a user is likely to be active if you're waiting for feedback from them, and they can help make it obvious to editors that such an analysis is possible and that it is something they should be aware of if they are trying to keep their anonyminity. --Ahecht (TALK
PAGE) 21:36, 19 February 2024 (UTC)[reply]
  • Option 1; scrutiny protects both the encyclopaedia and the user. Allowing some users to opt out would allow maleficent users to evade / delay proper scrutiny. If some editors' editing patterns are available, then all editors' editing patterns should be available. This data is not private like one's medical records or finances. Having said that, a warning to editors, say in the edit window, might not go amiss. The principle is simple; if you don't want your editing patterns available to all and sundry for scrutiny, then do not edit Wikipedia. Baffle☿gab 21:30, 19 February 2024 (UTC)[reply]
    Scrutiny such as what? In what circumstance would the timecards serve a demonstrable purpose? 🌺 Cremastra (talk) 21:32, 19 February 2024 (UTC)[reply]
    One use is to help identify sockpuppets. BilledMammal (talk) 21:33, 19 February 2024 (UTC)[reply]
  • Option 1; this won't improve privacy, all it will do is gate-keep it - more technically minded users will still be able to access it, while less technically minded users won't. I don't think that is a productive division. BilledMammal (talk) 21:33, 19 February 2024 (UTC)[reply]
    Option 3, per North8000. I hadn't considered non-editors accessing and using this information; to reduce the potential harm caused by outing, having a technical barrier in place is a good idea. BilledMammal (talk) 21:48, 19 February 2024 (UTC)[reply]
    Security through obscurity is a bad thing, and in this case it's not even that obscure since sites like https://en.wikichecker.com/ exist. --Ahecht (TALK
    PAGE    ) 22:09, 19 February 2024 (UTC)[reply]
  • The timecard should go. I see no reason for this data to be aggregated like this - what legitimate purpose does it serve? But the others, I see legitimate uses for them, and I don't see any good reason to allow opt-out. I think opt-out would possibly be harmful as mentioned by some responses above (ie, that it would make people think their edits are more private than they are). We've already given up that kind of privacy by editing here in the first place. -- asilvering (talk) 21:34, 19 February 2024 (UTC)[reply]
  • Comment Aside from all-important anonymity, Wikipedia is the most privacy-violating website that there is. It it a very easy convenient publicly searchable database of every edit that the editor ever made including the exact date and time that they made it. And there isn't a simple line between public and non public. Degree and ease of public access is important. Scratching your butt on your front lawn is technically public, as is your name and address, but if I take a telephoto video of you doing it and have it put on television and make a permanent searchable youtube video of it, I'm changing the degree of privacy and can't just say that I'm not because it's all public already. For example, if somebody outs you, anybody with no expertise can just click "edit count" can prepare a study on you in 30 seconds on how much editing you did when you were supposed to be at work and give it to your boss. I think that protecting anonymity is far more important than this proposed change, but I think that the proposed change is also a good idea. North8000 (talk) 21:44, 19 February 2024 (UTC)[reply]
  • Option 1. The privacy of editors is important, but we need to balance this against our goal of making an encyclopedia, which requires a degree of transparency in order to track sockpuppets and malicious editors; failing at that doesn't just hurt our mission, it has the potential to cause real-world harm even to people who haven't edited the encyclopedia, either because of BLP issues or because of harm caused when they try to rely on it. On the balance, these things are not a high privacy interest for most editors, while they are extremely valuable for identifying sockpuppets and COI editors. --Aquillion (talk) 22:02, 19 February 2024 (UTC)[reply]
  • Comment regarding tracking SOCK accounts: There are other tools available that have different, but close, functions, such as the Interaction Timeline and Intersect Contribs. — Preceding unsigned comment added by Voorts (talk • contribs)
    • No, those are not even remotely close. When you suspect that someone might be a sock of a previous user and are trying to build a case for SPI (or whether you even should attempt to do so), comparing the users' time cards is an extremely valuable way to get an initial at-a-glance sniff test. It doesn't prove anything on its own, ofc, but it allows you to avoid wasting time on editors that are clearly and obviously distinct. Editor interactions are far less valuable for this because it's natural for editors with overlapping interests to edit the same articles, and because it is easier for a sock trying to evade detection to move to another article than it is for them to change the entire times at which they edit over an extended period of time. And of course combining the two can provide enough information to tell you whether it's worth digging into their edits for more specific similarities. Losing access to time cards would make it far more difficult for editors who hunt sockpuppets to perform an initial pass to rule out possible sockmasters, while providing a "privacy" benefit that is purely symbolic at best. --Aquillion (talk) 13:09, 21 February 2024 (UTC)[reply]
  • Option 1. Status quo. The information proposed to be obfuscated doesn't seem particularly dangerous to me except maybe the timecard, and the timecard is an important tool for sock hunters. –Novem Linguae (talk) 22:53, 19 February 2024 (UTC)[reply]
  • Option 1 per Novem. —Compassionate727 (T·C) 23:47, 19 February 2024 (UTC)[reply]
  • Option 1. This is silly. It's all public information, and absolutely nothing is stopping me from forking xtools and/or developing a similar service and running it out of my personal website. -Fastily 01:23, 20 February 2024 (UTC)[reply]
  • Option 1 I don't see the privacy concerns with monthly counts or edits by namespace, and these are very often used by e.g. people at PERM/RfA evaluating a someone's activity and where they spend their time editing. The timecard is more concerning, but is used to find socks, and so it is useful that way; but I wouldn't necessarily be opposed to the "option 2.5" suggested above. Galobtter (talk) 01:28, 20 February 2024 (UTC)[reply]
  • Option 4 don't allow opt-out, but only let CUs see it, for privacy reasons. Just because something can be done doesn't mean it should be. Levivich (talk) 04:24, 20 February 2024 (UTC)[reply]
  • Option 1. The data is public, will remain public even if you were to opt out and even if you did opt out on Xtools it could be compiled and displayed in the exact same way by some other tool. Pretending editors can opt out from this would therefore be misleading. Thryduulf (talk) 05:19, 20 February 2024 (UTC)[reply]
  • New option 5 Allow only users that are not on Special:ActiveUsers to opt-out.
I tried using the en.wikichecker.org tool to look up an user that has agreed to it, and got an html code 403, so the argument of it being possible to view this aggregated data elsewhere is still moot. Might be an EU issue. I have never used timecards as an admin on an smaller wikipedia for my entire time of serving as one, which is over an decade, so I reject the argument of timecards being useful for moderation. As for timecards being useful for communication, just use some patience, volunteers do not owe you to respond within the hour.--Snævar (talk) 10:51, 20 February 2024 (UTC)[reply]
WikiChecker does that sometimes. Usually refreshing the page gets it to load correctly without the 403 error. It's probably a CDN issue. --Ahecht (TALK
PAGE) 14:38, 20 February 2024 (UTC)[reply]
  • Option 1 with the strong reminder that no private information about editors is available in this tool at all. — xaosflux Talk 11:34, 20 February 2024 (UTC)[reply]
  • Option 2. Allow users to opt out if they want - it should only be up to them and it's the kind of situation where giving the choice doesn't really hurt anyone. But because we are only speaking of publicly accessible info, GDPR isn't implicated so I don't particularly care either way. Szmenderowiecki (talk) 11:37, 20 February 2024 (UTC)[reply]
  • Option 1: basically per Pppery and Ahecht. The data is already publicly available for all and can be easily accessed by an external source (and one such platform is mentioned above). JavaHurricane 12:46, 20 February 2024 (UTC)[reply]
  • Option 1 and the RfC question is misleading. XTools does not show any private information. the wub "?!" 13:29, 20 February 2024 (UTC)[reply]
  • Option 1 I reject the premise in the heading. The times editors make their contributions are public information and there's no reasonable expectation they ought to be private. As others have outlined, there are many legitimate reasons to audit a user's pattern of editing – detecting sockpuppets, evaluating RfA candidates, and working out when you can expect them to respond to a question. – Teratix ₵ 14:46, 20 February 2024 (UTC)[reply]
  • Option 1. I disagree that hiding timecards gives a false sense of security. Making it less accessible does mean fewer people are likely to see it, and I hope that doing so would be widely-accepted as still being possible to view. That being said, I strongly disagree with the idea that publicly showing XTools data should be opt-in. I also disagree that there should be an opt-out. There may be an opportunity for the XTools maintainers to remove timecards publicly, and our checkusers given an internal tool for timecards. SWinxy (talk) 19:57, 20 February 2024 (UTC)[reply]
    There's already another tool which provides timecard information: https://spi-tools.toolforge.org/spi/ (which I maintain). It's integrated into the SPI toolset, but there's nothing to stop people from running it as a stand-alone tool. XTools presents the data in a nice U/I, but the basic functionality is trivial to implement, so making XTools opt-in would be meaningless. RoySmith (talk) 20:23, 20 February 2024 (UTC)[reply]
  • Option 1 The data is public and apparently easy to recreate. Now, I could get behind encouragement to only allow logged-in editors access x-tools, but that is a separate question. --Enos733 (talk) 20:43, 20 February 2024 (UTC)[reply]
  • Option 1 The data is public and anyone can aggregate it to show the same. To pretend otherwise is security through obscurity and just encourages people to have a fake sense of safety. —TheDJ (talk • contribs) 21:18, 20 February 2024 (UTC)[reply]
  • Option 1 the data is public; I do not think this is a privacy issue. LEPRICAVARK (talk) 03:03, 21 February 2024 (UTC)[reply]
  • Option 2 though it wouldn't be my ideal formulation (which would be to have a public opt-in version and a no-opt-out version accessible only to particular rights-holders). I seem to recall opining in the opposite direction when the same question was raised several years ago but my view has changed due to a factor strangely absent from this discussion: volunteers' experiences of harassment. Even though the information is all public and can be collated with some technical knowledge, reducing the ease of access of information would limit or prevent certain types of harassment and violence against volunteers. It is worth noting that privacy of a volunteer can reduce rather than increase when they create an account, as many IP addresses are not highly sensitive to that individual but the pattern of their editing behaviour is. I'm reluctant to spell out more per WP:BEANS. — Bilorv (talk) 22:26, 22 February 2024 (UTC)[reply]

Option 1 - this is all publicly available information that could just be compiled by someone self-hosting the tool to ignore opt-outs. a false idea of privacy is arguably more harmful than the status quo. Rexo (talk | contributions) 15:44, 3 March 2024 (UTC)[reply]

New Anonblock/Schoolblock template

A long time ago I wondered why we have a separate anonblock template for educational institutions, and one pointed out that the educational one has information specific to educational institutions (specifically, it provides information related to class projects). The problem with this is that sometimes IP addresses belonging to educational institutions are not easily identified. So to address this, I've boldly created a new template that merges both of them at {{New Anonblock}}. Thoughts? PCHS-NJROTC (Messages)Have a blessed day. 00:24, 24 February 2024 (UTC)[reply]

PCHS-NJROTC, I've added a dividing line to make the generals paragraphs separate from the school specific one. You can revert if you'd like, but I think this makes it more readable. Sincerely, Novo TapeMy Talk Page 17:50, 25 February 2024 (UTC)[reply]
I like it! PCHS-NJROTC (Messages)Have a blessed day. 21:17, 25 February 2024 (UTC)[reply]

Proposal: Implement a community-based process for appointing CheckUsers and Oversighters

I propose that we implement a community-based process for appointing CheckUsers and Oversighters similar to how RFAs are run. Because these positions require a high degree of community trust, I believe consensus should be higher like in appointing bureaucrats and interface administrators. I believe in this way, the community has more of a say of who gets to be a CU and OS other than our current arbitrators who currently hold those positions. I would also be open to saying with arbitration approval. Interstellarity (talk) 13:57, 26 February 2024 (UTC)[reply]

Support (CU and OS appointments)

  1. As proposer. Interstellarity (talk) 13:57, 26 February 2024 (UTC)[reply]
  2. (Moral Support) I'd love arbcom to be out of the CUOS business, primarily so that we can focus on putting people on the committee primarily on the strength of their dispute management skills. — xaosflux Talk 15:42, 26 February 2024 (UTC)[reply]
  3. It might be good to take something off of ArbCom's plate. ArbCom has many responsibilities. SWinxy (talk) 17:42, 26 February 2024 (UTC)[reply]
    ARBCOM were elected on the basis that this would be one of their responsibilities. They can tell us if they think they've got too much on their plate. Phil Bridger (talk) 19:46, 26 February 2024 (UTC)[reply]
    Arbcoms tell us this year after year through their very slow action. Levivich (talk) 15:17, 27 February 2024 (UTC)[reply]
    If you look at what proposals come out of the committee to increase their productivity, they are almost always about streamlining case management and especially dealing with appeals. That none of them relate to CU or OS appointments should give you a clue that it's really not a significant aspect of their workload. Over the last five years, functionaries have been asked by arbitrators to evaluate 26 candidates for CU and 16 for OS (people applying for both tools are included in both counts), This is not a large burden. Thryduulf (talk) 15:27, 27 February 2024 (UTC)[reply]
  4. Per nom and above, and also the arbcom appointment process has generated too many false positives. Levivich (talk) 15:07, 27 February 2024 (UTC)[reply]
    Please can you give some examples of these "many false positives" and explain how a different process would have produced a different outcome. Thryduulf (talk) 15:18, 27 February 2024 (UTC)[reply]
    That is an inappropriate question and you're old enough to know that Thryd. No, I'm not going to name the CUs/OSs who I think shouldn't have been appointed over the years. But for starters, the ones who were suspended or removed from those positions would be good examples.
    Arbcom elections and RFAs have also produced false positives, in fairness, but I think RFA has produced the fewest false positives (proportionately) of the three systems.
    But you really should be ashamed for asking for names. I'll give you one name: yours. That's not nice but neither is what you just asked me. Levivich (talk) 15:30, 27 February 2024 (UTC)[reply]
    OK, that wasn't a well phrased question. I was trying to understand what you meant by "false positive" (which you've now made clear means people who were appointed who you think should not have been) and importantly why you think an RFA-like process would have produced a different result. I will also follow-up your answer regarding me by asking why you feel I was/am a "false positive"? Thryduulf (talk) 15:43, 27 February 2024 (UTC)[reply]
    You know what I meant by "false positive": that people were appointed who shouldn't have been. You're not confused about that. What you are asking is for me to substantiate the claim, which is an inappropriate question, because it would require naming names.
    I never said I think an rfa-like process would produce a better result. The proposal is for a community based process, not an rfa-like one. I think rfa is terrible, hence my voting in favor of various reforms, consistently for years. I said I thought rfa produced fewer false positives (for rfa), but that's not the same thing as saying an rfa-like process would produce fewer false positives for CU/OS appointments. I don't know if it would or wouldn't.
    But I'm in favor of trying a community based system because it might be better than the current system. In general, I think community-based systems work better than representative-based systems on Wikipedia. ANI works better than AE. RFA for all its problems yields better results on average than arbcom CU/OS appointments (calculate the #-removed-per-#-selected ratio and you'll see a much higher % of CU/OS appointments are reversed than the % of RFA passes who are later desysoped, even though both are extremely rare).
    As for you personally, not really the place to discuss that nor a topic I care to spend time on, but for example this line of questioning was a poor choice. Levivich (talk) 16:02, 27 February 2024 (UTC)[reply]
    ANI works better than AE if this is your opinion, then I think I understand why we feel so differently about this issue. From my perspective, AE is a very significantly better board (for the situations where they overlap) than is ANI, which vies with RFA for the title of worst venue on the project. Thryduulf (talk) 16:50, 27 February 2024 (UTC)[reply]
    @Thryduulf: I'm sorry for personalizing this discussion with my earlier comments. I thought by personalizing this discussion I could make a point about not naming names and personalizing the discussion, but that was a dumb idea on my part in retrospect, my apologies. Levivich (talk) 05:29, 28 February 2024 (UTC)[reply]

Oppose (CU and OS appointments)

  1. I see no current problem with ArbCom selecting them, and this has the slightly greater risk of granting the power to the wrong people. Moreover, it could lead to a flood of premature self-nominations. Aaron Liu (talk) 14:11, 26 February 2024 (UTC)[reply]
  2. I don't think there's a shortage right now? Mach61 (talk) 14:58, 26 February 2024 (UTC)[reply]
  3. No clear motivation. * Pppery * it has begun... 15:18, 26 February 2024 (UTC)[reply]
  4. Per WP:NOTBROKEN. Sdkb talk 15:39, 26 February 2024 (UTC)[reply]
    lol, that's a page about redirects. You're looking for the WP:AINT essay. Levivich (talk) 15:09, 27 February 2024 (UTC)[reply]
  5. The last year in which CUOS were selected by the community (it has been done before) was a disaster for providing the relevant privileges. Izno (talk) 16:21, 26 February 2024 (UTC)[reply]
    The one from 15 years ago? That wasn't really a direct community process. It started with arbcom being able to veto any candidate and was then advisory in nature only. 15 years is a long time in the project, I'm not sure we should discard an idea based on such an old example. There are certainly things that can be learned from it - along with years of experience in how many other projects have been able to run CUOS elections themselves. — xaosflux Talk 18:04, 26 February 2024 (UTC)[reply]
  6. The current process is that applications, which are accepted at any time, are scrutinised by ARBCOM, those that cannot be dismissed out of hand are passed to the functionaries to for scrutiny. Based on the feedback from functionaries and arbitrators' own discussions, applications that are clearly unsuitable are closed as unsuccessful, community input is sought for all the others. All the comments (arbs, functionaries, community) are then evaluated by arbcom and the successful applicants appointed. An RFA-like process would lead to mostly the same people being appointed as now, just with a greater likelihood of acrimony, incivility, and clearly inappropriate nominations and an increased risk of untrustworthy people being appointed. I'm not clear what problem this is attempting to solve. Thryduulf (talk) 18:07, 26 February 2024 (UTC)[reply]
    If that summary is correct (and I have no reason to doubt it) then it sounds like an ideal way to appoint people to those positions. Certainly better than any RFA-like process. Let's remember that ARBCOM is elected by popular vote. Phil Bridger (talk) 19:40, 26 February 2024 (UTC)[reply]
    Mostly - except that that is the general "routine" process, arbcom also can just appoint anyone they want if they pass with a 50%+1 committee vote (we see this the most when there is a request from a former funct.) — xaosflux Talk 22:02, 26 February 2024 (UTC)[reply]
    This is equivalent to former admins regaining the tools on request as long as at least one 'crat is happy to flip the bit. The only difference is that there is no written activity requirement to be regranted CU/OS (although there is to retain the tools). Thryduulf (talk) 22:33, 26 February 2024 (UTC)[reply]
    That process is also generally done in secret without requiring an opportunity for community feedback. — xaosflux Talk 14:17, 27 February 2024 (UTC)[reply]
    That the two are essentially the same was my point. Thryduulf (talk) 14:41, 27 February 2024 (UTC)[reply]
  7. Thryduulf gives a good summary. I don't currently suspect that the CU/OS system we have is appointing the wrong people, and RfA is exceedingly toxic. — Bilorv (talk) 18:45, 26 February 2024 (UTC)[reply]
  8. Oppose. I'm uneasy about making people go through the fiery pits of hell thrice total if they want CUOS. That aside, my bigger concern is the wider community's ability to judge whether someone is trustworthy enough to handle private information. CUOS isn't admin or crat, they're specific roles used to fulfill specific purposes. They carry no "social" value (no accountability requirements, etc.), and if someone who hasn't held an NDA role before asks for it, the whole thing basically boils down to "will this person invade upon privacy or leak personal information?". I sure as hell cannot answer that question. Can you?
    ...yeah, you probably can, because you've probably been here for 15 years or something. But you are not the only demographic that goes to RfX, and with this system it won't be any different.
    If the problem is that you want arbcom out of the way, then sure, I could potentially get behind that. But experienced, non-temperamental people need to make this decision, not the RfA mob. Snowmanonahoe (talk · contribs · typos) 00:45, 27 February 2024 (UTC)[reply]
  9. Oppose as I said in the RFA 2024 review @ proposal 15. I dare not to repeat the same statement. Toadette (Let's discuss together!) 07:28, 27 February 2024 (UTC)[reply]
  10. Oppose What is the problem that has to be solved? The present RfA-process is quite a bit of mud slinging, so it only decreases the number of able & willing candidates. The Banner talk 08:53, 27 February 2024 (UTC)[reply]
  11. Oppose per above. Solution in search of a problem, nothing is broken. -Fastily 09:51, 27 February 2024 (UTC)[reply]
  12. The last attempt at community-based CUOS appointments was a total failure, and the current system is more than good enough. JavaHurricane 13:37, 27 February 2024 (UTC)[reply]
  13. Previous attempts to try this have descended into a popularity contest and produced no useful feedback about the candidates' suitability for these specific roles. These roles do not necessarily need popular editors who avoid sticking their heads above the parapet for fear of not being elected, but trustworthy, active admins who know how to use the tools and deal with abuse within the bounds of policy. ArbCom appointments with community consultation strikes the right balance in my opinion. HJ Mitchell | Penny for your thoughts? 14:13, 27 February 2024 (UTC)[reply]
  14. Oppose A very sensitive position (including being able to do real life harm to people) which has very specific proven-trust requirements. I'm more comfortable with some experienced (elected) people making that analysis and decision. Sincerely, North8000 (talk) 15:23, 27 February 2024 (UTC)[reply]
  15. Current system does just fine. NW1223<Howl at me•My hunts> 15:48, 27 February 2024 (UTC)[reply]
  16. Oppose A process "similar to how RFAs are run"? Good God, no. Also, per HJ Mitchell.-- Ponyobons mots 19:40, 27 February 2024 (UTC)[reply]
  17. Not only is the current system not broken, the community as a whole is very poorly placed to judge an admin's skill at handling those areas that are mostly directly relevant to CUOS skills; revision deletion, SPI activity, deletion-related activity at RC patrol, VTRS activity, and more technical areas like edit-filter work. Non-admins cannot scrutinize most of this activity at all. While trust and judgement are important aspects of being a functionary, there's more to it than that. Community scrutiny is necessary but not sufficient, and the current system of the community being able to provide feedback is exactly what it should be. Vanamonde93 (talk) 19:45, 27 February 2024 (UTC)[reply]
  18. This seems to be a solution in search of a problem. Seraphimblade Talk to me 20:07, 27 February 2024 (UTC)[reply]
  19. Arbcom managing this seems to be working well, and producing both enough permission holders to get the work done but not spreading access too widely. Arbcom is exceedingly unlikely to appoint any person the community expresses a decent amount of reservation in, and is aware of things the community is not that may make an individual unsuitable. Courcelles (talk) 16:35, 28 February 2024 (UTC)[reply]
  20. RfA is a broken process as it is, leading in part to a shortage of admins. Doing the same for CUOS without improving the RfA process is asking for trouble, not in the least because CUOS deals with way more sensitive data and the community as a whole is ill equipped to assess trustworthiness. ConcurrentState (talk) 18:58, 28 February 2024 (UTC)[reply]
    In discussions about the low number of applicants for functionary permissions in the 2023 round it was noted that the shortage of new administrators was likely an influential factor. RFA's brokenness is the most significant reason for the shortage of new administrators. Thryduulf (talk) 15:05, 29 February 2024 (UTC)[reply]
    I don’t disagree in the slightest. I was just hedging to avoid nitpicking about all the possible factors that lead to a shortage of admins. ConcurrentState (talk) 19:28, 29 February 2024 (UTC)[reply]
    I was actually agreeing with you, just noting a downstream problem of the one you identified. Thryduulf (talk) 20:13, 29 February 2024 (UTC)[reply]
    Ah! My bad, I misinterpreted your comment. ConcurrentState (talk) 21:35, 29 February 2024 (UTC)[reply]
  21. Solution in search of a problem. Sandstein 14:55, 29 February 2024 (UTC)[reply]
  22. In agreement with Sandstein. TrangaBellam (talk) 18:17, 29 February 2024 (UTC)[reply]
  23. The process often requires considerable privacy. ArbCom may have to learn, or deal with, very personal information of potential CUOS. An RfA like process is incapable of handling such sensitive issues. We already ask for community feedback for candidates. Why would we want more RfA, when RfA is concededly broken? (case in point: the concurrently running RfA RfC). If it ain't broke, don't fix it. CaptainEek Edits Ho Cap'n!⚓ 05:14, 1 March 2024 (UTC)[reply]
  24. Appears to be a solution looking for a problem. Stifle (talk) 10:22, 1 March 2024 (UTC)[reply]
  25. RfA, while it might be the only method we've come up with for selecting administrators, is not such a glorious success that we ought to be using it as a model for anything else, at least not when the current system is perfectly functional. And there are substantial differences between CU / OS and admins - adminship involves a large number of often very subjective judgments on things like eg. whether someone is likely to continue to be a problem in the future and what sanctions are necessary to prevent this. CU / OS, by comparison, are much more rigid and technical - there is a bit of subjectivity around the edges, but not nearly so much, and it mostly comes down to very simple categorizing using a few straightforward rules. This means that while judgment is important for those roles it doesn't imply as much need for additional community trust. Admins need to understand, and be trusted to accurately enforce, essentially all of Wikipedia's policies and practices; CU / OS are each mostly about a much more narrow slice of it, and a slice that generally involves a bit less subjectivity at that. --Aquillion (talk) 00:46, 2 March 2024 (UTC)[reply]
    Have to be honest, but I think this is backwards in terms of how much trust is required. Admin actions can be and are scrutinized easily and regularly, that can't happen in the same way with CU/OS. OS is maybe straightforward in the way you describe though the information involved can be as sensitive as can be. CU, on the otherhand, is far from categorizing a few straightforward rules. There is a huge amount of discretion involved and judgement calls are regularly required in terms of whether a check has been justified and if it has whether the results indicate a violation of policies and guidelines. I also think most admins only operate in a narrow slice of the admin universe so they don't actually need to know every policy and guideline. Best, Barkeep49 (talk) 00:56, 2 March 2024 (UTC)[reply]

Neutral (CU and OS appointments)

Discussion (CU and OS appointments)

Note managing access to CheckUser and Oversight tools is currently in the scope of the arbitration committee by policy. Changing this requires an amendment to the arbitration policy. isaacl (talk) 18:20, 26 February 2024 (UTC)[reply]

So that would be 100 petition signatures and a majority on an up and down vote? I believe that is what it was on the vote that removed any remaining provision for an appeal to Jimbo.--Wehwalt (talk) 20:06, 26 February 2024 (UTC)[reply]
I didn't want to repeat the process since I linked to it, but mostly yes. An amendment can be also be proposed for ratification if it is approved by the committee. The majority vote to ratify must have at least 100 supporting statements. isaacl (talk) 20:38, 26 February 2024 (UTC)[reply]
Maybe ... while changing the arbcom policy requires those hoops, changing the cu/os polices don't really. This would really need to be well supported to make the change either way (with more than enough support to do both). — xaosflux Talk 22:19, 26 February 2024 (UTC)[reply]
I think the wording in the current arbitration policy has given sole responsibility to the arbitration committee for appointment of checkusers and oversighters. I agree that meta:Oversight policy states that local elections can still be preferred over appointment by the arbitration committee, and it could be argued that meta:CheckUser policy leaves the question open. However by ratifying the arbitration policy, the community agreed on giving this responsibility to the arbitration committee, as well as agreeing that this scope has to be altered via the arbitration policy amendment process. isaacl (talk) 22:54, 26 February 2024 (UTC)[reply]
It could certainly create one of those community consensus crisis sort of situations. Regardless, I certainly would want a wholesale cleanup of everything related, including the arbpol, if this were to gain traction. Realistically, I think this proposal should have gone through more development and leaves more questions open then the change it is trying to promote. — xaosflux Talk 23:11, 26 February 2024 (UTC)[reply]
I'm not sure if there would be a crisis. The stewards would have to ignore the English Wikipedia arbitration policy and accept community-requested assignments, and it doesn't seem to me that's likely to happen. I agree that it would have been fruitful to have more discussion to develop a rationale and proposed process. isaacl (talk) 23:24, 26 February 2024 (UTC)[reply]
I'm inclined to trust the steward when he says such a situation with the stewards would create a crisis. Perhaps it would be resolved the way you suspect but perhaps not. Best, Barkeep49 (talk) 23:07, 29 February 2024 (UTC)[reply]
In essence I agree with Xaosflux that the arbitration policy should be amended to align with community desires on appointing checkusers and oversighters. Thus I raised this need in my initial comment. In theory the arbitration committee could just agree to rubberstamp community appointments, but I think the community wouldn't feel satisfied by an approach that relied on the benevolence of the committee. isaacl (talk) 23:38, 29 February 2024 (UTC)[reply]
It would end up being a case if changing the local checkuser policy to allow elections were to be strongly supported by the community, and then there we to be an actual successful election - and how much of a counter argument the committee wanted to put up. This sort of change would certainly require a very well attended RFC for a project this size (where the supporters would likely already be over 100 as well). The best case would be that if successful a graceful transition from the current committee happened. I could see the stewards team stalling any appointment pending additional community deliberations over collisions between multiple policies. — xaosflux Talk 23:39, 29 February 2024 (UTC)[reply]
Sure, that would be a reasonable approach. We might be thinking of different connotations for the word crisis. I agree that most likely there would be sufficient support to amend the arbitration policy at the same time. isaacl (talk) 00:03, 1 March 2024 (UTC)[reply]
Likely - it certainly wouldn't stop people from reading or creating articles! — xaosflux Talk 00:11, 1 March 2024 (UTC)[reply]
This is a tangent, but if any of you are willing to take on these roles, please consider volunteering. I am worried that whenever m:IP masking/mw:Help:Temporary accounts gets here (not in the next few months, but could possibly be later this calendar year), that we might need more CUs than we have now, particularly during the first few months of the transition. WhatamIdoing (talk) 04:22, 27 February 2024 (UTC)[reply]
Another point that I don't think has been made is that, particularly for OS applicants, one thing that is often significant is what the requests they've submitted have been like as this can give an indication of what their judgement will be like in assessing requests from other people. For example I likely would not support an application from someone who frequently asked us to suppress things that clearly don't need it, and I likely would support someone whose reports were almost always of things that do need suppression. However, editors who are not oversighters do not have access to this information (indeed when oversight works perfectly almost nobody knows it has happened). Thryduulf (talk) 01:11, 2 March 2024‎ (UTC)[reply]

Adding move, create and upload protection locks to the top right corner

Relevant links: Wikipedia:Protection policy and Special:MovePage/Wikipedia:Protection_policy (To see what it looks like to try and move a protected page. non admins only). Originally posted at the village pump (ideas)

Currently, articles that are protected from editing have the relevant lock in the top right hand corner. Userpages may not have the relevant edit lock on the top right. With regarding edit protection, it will stay as it is but why don't we do the same for move, create and upload so that articles (other than user pages) require all types of protection to be shown on the top right. The lock icon will display in the same way shown in the protection policy page (linked above). With move protection, the only way to tell that the page is protected is if the move button is not seen (this article for example, doesn't have the move button for me, but it does have subscribe) with the possible exception for administrators as they can move any page even if it's protected. Even if accounts are able to edit semi and EC protected pages, the relevant lock is still there. But like I said, that will not change. Admins will also be able to see if a page is move protected from the green lock icon at protection policy page.

The only way to see the green (move) and blue (create/also known as salting) lock is if the URL was typed for some reason, like here and here respectively. (for ECP create protection this appears instead). JuniperChill (talk) 21:40, 22 February 2024 (UTC)[reply]

Also, I forgot to realize most people (I think) replying to be are actually ECP, so please do not even try to recreate the linked page. I am not ECP myself (have ~260 edits). This is just an example of what it looks like for non ECP users to try and (re)create a salted page. You may wish to use an incognito tab to do so.

JuniperChill (talk) 15:57, 27 February 2024 (UTC)[reply]

Support, though what's stopping us from doing this right now? Aaron Liu (talk) 16:03, 27 February 2024 (UTC)[reply]
{{Pp}} already supports move protection, it just needs admins to apply the template when they move protect a page. It cannot be used for create and upload protection as there is no page to put the template on. It might be possible to add the padlock icon to MediaWiki:Nocreatetext, but that seems redundant. --Ahecht (TALK
PAGE) 20:12, 27 February 2024 (UTC)[reply]
Comment {{pp-move-indef}} hasn't displayed a visible icon since 2009 [1], and visible display for {{pp-move}} was removed following this TfD because participants saw it as unnecessary bloat. Personally I always found them a little useful, even though us unregistered types haven't been able to move pages for a long time since it was still a quick indicator that a title was potentially contentious, but I can understand why it was removed. 184.152.68.190 (talk) 20:52, 27 February 2024 (UTC)[reply]
I'm fine with a lock icon for creation-protected pages if technically feasible (obviously not by placing a lock template on the non-existent page). I'm also fine with an upload protection icon although almost all files are at Wikimedia Commons and we don't need to invest a lot of time into improving the display of the few remaining local image pages. A move protection icon, however, is an unneeded gimmick that is more likely to confuse readers than to help the few editors who intend to move the page. ~ ToBeFree (talk) 21:08, 27 February 2024 (UTC)[reply]
Displaying a lock for move-protected articles would confuse far more people than it would help, I agree with ToBeFree. I'm ambivalent about displaying a lock for the other two cases. Daniel Quinlan (talk) 08:24, 29 February 2024 (UTC)[reply]

Feedback sought for proposal to drop archival bot notice params from Template:Talk header

Your feedback would be appreciated at Template talk:Talk header#Proposal to drop archiving params. The {{Talk header}} template has no control over Talk page archiving, but it does have four params used to generate a "bot notice" in the header box which says something like: "Archiving: 90 days" (plus a tooltip with more info). It's just a string displayed in the header, which may or may not reflect what the actual archiving period is. A recent change to Template:Talk header automates the generation of this string directly from the archive config, rendering the four Talk header params unnecessary. Imho, they should be deleted from the template in order to prevent misleading bot notices in the Template header box when the given params get out of sync with the config. More details at the proposal discussion. Thanks, Mathglot (talk) 04:43, 29 February 2024 (UTC)[reply]

Template:Talk header is a highly visible template, so I've added {{subst:DNAU|3|weeks}} to this discussion to give it sufficient time to air. Mathglot (talk) 10:37, 3 March 2024 (UTC)[reply]

Proposal: Remove the topicons for good and featured articles

We recently rejected a proposal that would put the vital article topicon on the page. Discussion: Wikipedia_talk:Vital_articles/Archive_25#Proposal_for_a_VA_"top_icon". Some editors in that discussion said that they would support removing the good and featured article topicons as well. If either readers or editors are interested in whether they are good or featured articles, they can be found on the talk page. Interstellarity (talk) 00:30, 2 March 2024 (UTC)[reply]

Support (remove GA & FA topicons)

  1. As proposer. Interstellarity (talk) 00:30, 2 March 2024 (UTC)[reply]
  2. Strongly support removing GA topicons. GA reviews are essentially random. It's just one editor reviewing it and there is literally no training or qualifications that the reviewing editor needs to have. To suggest a GA article has gone through any kind of meaningful review process is misleading the reader. All it means is someone else has read it. Exhibit A is the editor from a year and a half ago who had hundreds of GAs that turned out to be full of misinformation (and copyvio and other stuff, the editor ended up indef'd).

    I'm neutral about removing FA topicons. At least that process can be said to involve multiple editors reviewing it, and the FA folks take their FA reviews pretty seriously AFAIK (unlike GAs, which some take seriously but others don't). I don't think it matters much if the FA topicon is there or not -- I don't think readers know or care about that -- but GA should definitely go IMO. Levivich (talk) 04:02, 2 March 2024 (UTC)[reply]

    Actually, I support removing FA top icons too. I'd forgotten that most FAs no longer meet the criteria. Levivich (talk) 17:19, 2 March 2024 (UTC)[reply]
  3. I support removing both. — Fourthords | =Λ= | 14:02, 2 March 2024 (UTC)[reply]
  4. - due to the fact readers have no clue what these mean and the fact the majority no longer meet their FA and GA criteria and 60%+ are mobile viewers don't even see them anyways. I can see how they are an incentive to get editors to improve articles though. That said I would slow down on rfcs that will go nowhere..... Time wasters.Moxy- 16:50, 2 March 2024 (UTC)[reply]
  5. Our loyalty is to the WP:READER, to whom these icons—where they're even noticed, that is (on mobile view they don't exist!)—are merely inside baseball. Their real purpose to allow editors a chance to gussify their user, talk pages etc. Stick em a table on a subpage if you have to  :) ——Serial 16:58, 2 March 2024 (UTC)[reply]

Oppose (remove GA & FA topicons)

  1. The topicons are useful for readers as indicators that an article has gone through some kind of review process. This is in contrast to vital articles which is editor facing information. Barkeep49 (talk) 00:40, 2 March 2024 (UTC)[reply]
  2. I think all quality ratings should be shown, not just GA/FA. Analogous to maintenance tags, it's useful for readers to know how much they should trust what they're reading on Wikipedia. Moreover, topicons are unobtrusive and might have the benefit of converting a few readers to editors. As an aside, I think the distinction that's been drawn between quality ratings and vital article status is strained. Both are done through the work of a relatively small group of editors and both indicate something important to the reader about how the community has assessed an article. voorts (talk/contributions) 00:46, 2 March 2024 (UTC)[reply]
    Why should a reader care about how vital wiki editors think an article is? The reader has their own ideas about how vital that article is to them in that moment and in general. The idea of showing all rating indicators is an interesting one in terms of helping readers clue into what they are. I'd love to see that discussed more. Best, Barkeep49 (talk) 00:49, 2 March 2024 (UTC)[reply]
    By that logic, I think one could say: Why should a reader care about that one editor came to the conclusion that an article is GA quality and 5-10ish editors—none of whom are necessarily subject matter experts—came to the conclusion that an article is FA quality? I'll make a note to return to the topic of showing all ratings after this discussion closes. voorts (talk/contributions) 00:55, 2 March 2024 (UTC)[reply]
    I've had a similar thought before myself, but I've come to believe that in practice, the distinction between Start/C/B-class is often too poorly defined to be useful information to the reader. —Compassionate727 (T·C) 15:34, 2 March 2024 (UTC)[reply]
    This is how I think about the distinctions: start is longer than a stub, but either not very well-cited or written, C is a start class article that's starting to meet some core PAGs, and for B we have clear criteria. voorts (talk/contributions) 20:41, 2 March 2024 (UTC)[reply]
    Plus from my experience it is often not kept up to date as the article content changes. ― novov (t c) 01:58, 3 March 2024 (UTC)[reply]
  3. Oppose. The topicons are useful, and have been this way for a long time. What exactly is the advantage of removing them? –Novem Linguae (talk) 00:50, 2 March 2024 (UTC)[reply]
  4. Per Barkeep. Nikkimaria (talk) 00:59, 2 March 2024 (UTC)[reply]
  5. Per Barkeep. I'm not sure how valuable fronting the lower ratings would be (they're often out of step with the quality of the article) but I'm not immediately opposed to adding them. Thryduulf (talk) 01:14, 2 March 2024 (UTC)[reply]
  6. Oppose: It's good to show readers in an unobtrusive way that the article they're reading has been reviewed and is of quality. There is no benefit to removing them. 🌺 Cremastra (talk) 01:59, 2 March 2024 (UTC)[reply]
  7. Oppose: per Barkeep, however, the GA topicon was a bit confusing to me when I was only a reader and I wouldn't mind a reform. ❤HistoryTheorist❤ 02:36, 2 March 2024 (UTC)[reply]
  8. Why? I think it's a convenient way to show that articles are of a decent quality to our readers. It's not causing any problems. Elli (talk | contribs) 03:51, 2 March 2024 (UTC)[reply]
  9. Oppose per Barkeep49. Headbomb {t · c · p · b} 04:19, 2 March 2024 (UTC)[reply]
  10. Oppose per Barkeep49. We should be making the icons more prominent, not less. Sdkb talk 07:03, 2 March 2024 (UTC)[reply]
  11. Oppose: GA and FA symbols are no guarantee of any kind of quality, but it is one piece of information that media literate readers should be using to help them assess the reliability of what they read. These topicons may also be motivating to editors who put articles they have improved through GA/FA processes. — Bilorv (talk) 09:41, 2 March 2024 (UTC)[reply]
    +1 Sdkb talk 16:19, 2 March 2024 (UTC)[reply]
  12. Oppose per all the opposers, but I'm mainly here to comment: I consider it a win that no one has even mentioned featured lists in this discussion or the previous one. The process basically works, and judging from the silence, it doesn't seem to be contentious these days. Congratulations all around. - Dank (push to talk) 15:32, 2 March 2024 (UTC)[reply]
  13. Per Barkeep. —Compassionate727 (T·C) 15:33, 2 March 2024 (UTC)[reply]
  14. The topicons are what first informed me of the GA and FA processes back when I was an unregistered lurker. I can imagine other unregistered users falling down a rabbit hole and potentially getting involved with curating content after seeing one of them. Also Barkeep49 presents another good rationale for keeping them. The Night Watch (talk) 17:22, 2 March 2024 (UTC)[reply]
  15. Oppose We need to make them more prominent, not less. Sohom (talk) 17:35, 2 March 2024 (UTC)[reply]
  16. Oppose per Barkeep and Bilorv. Moreover, just because mobile readers are unable to see them it does not mean we should remove them from PC readers (if anything it means that we should add them to mobile view).  Spy-cicle💥  Talk? 17:43, 2 March 2024 (UTC)[reply]
  17. Oppose per Spy-cicle. – SD0001 (talk) 21:48, 2 March 2024 (UTC)[reply]
  18. Oppose, per Barkeep and Bilorv. ♠PMC♠ (talk) 00:02, 3 March 2024 (UTC)[reply]
  19. Oppose Like voorts, I would not object to all ratings being shown. In fact, I use a plugin that does just that. Hawkeye7 (discuss) 00:51, 3 March 2024 (UTC)[reply]
    I use the same plugin, which is where the idea came from. voorts (talk/contributions) 00:59, 3 March 2024 (UTC)[reply]
  20. Oppose - I agree with Levivich that the quality of the GA process can be inconsistent, but in practice I still find that they are almost always better than your average non-good article. Yes there can be stuff like what Doug Coldwell did, but the same goes for every other part and process of Wikipedia. Most readers aren't likely to grasp what the means anyway, in my mind it serves as more of a motivational little trinket for editors, and I'm concerned that removing the most prominent area where it's featured could decrease the impetus to improve content. ― novov (t c) 01:57, 3 March 2024 (UTC)[reply]
  21. Not clear what the harm is, and if the only benefit is making people feel good about getting an article to GA/FA (by having a shiny icon on the article) that seems enough. Galobtter (talk) 01:58, 3 March 2024 (UTC)[reply]
  22. Oppose. The provided rationale is extremely unconvincing - "some people mentioned it?" Lay out the case yourself if you believe it. Marking quality is fine (which is what FA / GA icons do), the problem with VA marking was - too many to list, see previous discussions. This proposal comes across as an extremely weak "well this one proposal was voted down, let's do the same thing in a separate vaguely similar area out of some misguided fairness." SnowFire (talk) 02:27, 3 March 2024 (UTC)[reply]
    RfC statements are required to be brief and neutral, and the fact that earlier discussions occurred at that RfC satisfies WP:RFCBEFORE. voorts (talk/contributions) 02:39, 3 March 2024 (UTC)[reply]
      • @Voorts: The statement is expected to be neutral, yes. However, somewhere (whether in a separate section after the description, or in the nominator's initial !vote) there's expected to be some reasoning for why the heck we're voting on this at all and some sort of case to modify the status quo. The RFC creator gave no such explanation other than what I already cited that "other people mentioned it" and "readers can find out on the talk page" which is not conversant at all with the issues involved. People could propose random changes all day; why is this change being proposed? You shouldn't start an RFC as just a thought experiment, that's what a normal discussion is for. SnowFire (talk) 05:15, 3 March 2024 (UTC)[reply]
  23. Oppose: Not causing any harm, and is a nice bit of encouragement for editors. ARandomName123 (talk)Ping me! 02:46, 3 March 2024 (UTC)[reply]
  24. Oppose If my GA/FA articles didn't get the topicon, I rather doubt I'd have even known they existed, or felt compelled to get my articles to that status. The badge is useful to readers, and a great inducement for editors. CaptainEek Edits Ho Cap'n!⚓ 03:26, 3 March 2024 (UTC)[reply]
  25. Oppose, mostly per voorts. We should show more of this, not less; readers deserve to know if an article has passed some quality gate. On the topic of substandard GA/FAs, yes they exist, no we shouldn't let perfect be the enemy of good. ~ A412 talk! 04:24, 3 March 2024 (UTC)[reply]
  26. Oppose. This does not really seem like a good idea to me; if there's a bunch of crappy GAs we do not need to address topicons to deal with them. jp×g🗯️ 06:07, 3 March 2024 (UTC)[reply]
  27. Oppose. I would prefer we go in the opposite direction and make the icons more visible and more intuitive. Readers will not know which one is more "trusted". —Femke 🐦 (talk) 07:48, 3 March 2024 (UTC)[reply]
  28. Oppose - Nothing wrong in letting readers know which articles are trusted and have underwent community review. The Herald (Benison) (talk) 09:14, 3 March 2024 (UTC)[reply]

Neutral (remove GA & FA topicons)

  • I suspect that the vast majority of our readers pay absolutely no attention to article ratings and their associated topicons. However, because I don’t think they harm the project in any way… I am neutral on the question. Blueboar (talk) 13:16, 2 March 2024 (UTC)[reply]
  • I don't feel strong enough to sit on either side of this discussion. There are genuine grounds for concern about quality control and the ad hoc nature of the review process. It does seem that the topicons are very much inside baseball, so to speak. Nevertheless, despite the extreme example highlighted above (for which I have direct experience) I still think indicating some kind of independent review has taken place is worthwhile, no matter how limited in nature...I might have an easier time supporting this proposal if an alternative was being proposed. Regards, --Goldsztajn (talk) 01:36, 3 March 2024 (UTC)[reply]

Discussion (remove GA & FA topicons)

Barkeep49, as far as I know, we have no evidence that ordinary readers have any idea that those topicons exist or what they mean. WhatamIdoing (talk) 03:42, 2 March 2024 (UTC)[reply]

That's probably true. But that's a reason to improve them, not remove them. Sdkb talk 07:04, 2 March 2024 (UTC)[reply]
This 2022 study might interest you, unless you're already familiar with it :) Shells-shells (talk) 07:32, 2 March 2024 (UTC)[reply]
We having no evidence for something doesn't necessarily mean it isn't true. Readers curious to find out the meaning of the icon would hover over it - it says "This is a featured article. Click here for more information". The click leads to WP:FA which begins with "Featured articles are considered to be some of the best articles Wikipedia has to offer". – SD0001 (talk) 07:54, 2 March 2024 (UTC)[reply]
The vast majority of readers don't see these anyways because they are not displayed in mobile view. Moxy- 17:18, 2 March 2024 (UTC)[reply]
We can actually figure out how many people click these. I've created Wikipedia:Good articles* and Wikipedia:Featured articles* and changed the links in the template accordingly, so after a month or so we should have good data on how many clicks these get. Elli (talk | contribs) 17:36, 2 March 2024 (UTC)[reply]
Great work....thank you! Moxy- 20:13, 2 March 2024 (UTC)[reply]
Yes, that's a good idea. WhatamIdoing (talk) 02:32, 3 March 2024 (UTC)[reply]
I agree with Skdb. Best, Barkeep49 (talk) 08:16, 2 March 2024 (UTC)[reply]
I've nothing against the topicons; I'd be happy to keep them just because they're useful to experienced editors, a nice reward for hard work, and traditional for the site. However, I don't think we should be making this decision on the grounds that we speculate that they're useful to non-editing readers, when
  • we don't know that they're useful,
  • we have a limited amount of evidence suggesting that they're not (or that the utility is very limited), and
  • we know that most readers don't see them because 66% of page views are on the mobile site.
A month from now we will know whether those topicons get clicked on at any significant rate. WhatamIdoing (talk) 02:57, 3 March 2024 (UTC)[reply]
I have occasionally told people who have questions about whether/when Wikipedia articles are reliable to look for the topicons. —Compassionate727 (T·C) 15:38, 2 March 2024 (UTC)[reply]
Question: how often are ratings/topicons reevaluated and lowered due to subsequent crappy edits? Blueboar (talk) 01:53, 3 March 2024 (UTC)[reply]
There's WP:FAR and WP:GAR. Galobtter (talk) 01:57, 3 March 2024 (UTC)[reply]

If we are going to remove an icon, I would hide the protection icons from logged out users (I don't see the benefit - they are anyways shown a "view source" button instead of "edit source" if they can't edit the article). That truly is inside baseball unless you actively try to edit an article. Galobtter (talk) 02:01, 3 March 2024 (UTC)[reply]

Proposal for Integrating University Knowledge into Wikipedia

Hello! I share with you this proposal, it is still not very mature, I would appreciate ideas and suggestions to carry it out. Any opinion is welcome. Thanks

The aim of this proposal is to compile and share all academic content from universities on Wikipedia. This involves adding the syllabi of all subjects from all university degrees to the platform, providing free and open access to university knowledge for anyone or any artificial intelligence.

Implementation:

1. Acquisition and Digitalization of Notes:

  • Students are encouraged to digitize their notes and publish them under the CC BY SA license for inclusion in Wikipedia.
  • Participation from students can be promoted through annual awards for the best notes in each degree, whether in the form of monetary incentives, meal vouchers, or transportation grants. It is crucial to avoid plagiarism and respect copyright.
  • Collaboration with student delegations and the involvement of professors in this task are encouraged.

2. Uploading Content to Wikimedia Commons:

  • Students can upload their notes to the Wikimedia Commons repository with their full name, which enhances their visibility on Google and improves their curriculum vitae.

3. Distribution of Content on Wikipedia:

  • The notes are reviewed and understood, and the information is distributed across related Wikipedia articles.
  • To achieve this, two options can be considered:
  1. Hiring specialized editors.
  2. Requesting the collaboration of Wikipedia volunteers, possibly establishing a Wikiproject dedicated to organizing tasks and coordinating content contributions.

This proposal aims to enrich Wikipedia's content with verified and accessible academic knowledge, benefiting students, researchers, and learning enthusiasts worldwide.

In commons there are already uploaded notes for several subjects, see Lecture Notes Uni4all (talk) 18:09, 2 March 2024 (UTC)[reply]

See Wikipedia:What Wikipedia is not. Students notes are (or should be) original works. Wikipedia is an encyclopaedia, which only contains articles summarising material from already published reliable sources. Whether Wikiversity might accept such content, I don't know: you could try asking there. AndyTheGrump (talk) 18:32, 2 March 2024 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=1211627472"