Jump to content

Wikipedia:Village pump (idea lab)

From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Xaosflux (talk | contribs) at 00:31, 29 April 2021 (→"Manually-vetted" usergroup: re). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts
The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, please note:

Before commenting, note:

  • This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
  • Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.

Discussions are automatically archived after remaining inactive for two weeks.

« Archives, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65

Trigger warnings

WP:SNOW close. – Finnusertop (talk ⋅ contribs) 06:11, 18 April 2021 (UTC) (non-admin closure)[reply]

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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

It would be nigh-impossible for Wikipedians, who may not share each others' societal or cultural norms, to agree on a comprehensive standard for what constitutes "triggering content". If the principle of least astonishment is properly followed, readers should generally come across offensive material only when it is expected (e.g. readers should anticipate articles on anatomy will contain images of sexual organs) and enhances their understanding of the topic, which would negate the need for warnings. There is also a general content disclaimer which explicitly warns readers that Wikipedia hosts objectionable content. (See also WP:NOTCENSORED). – Teratix ₵ 14:01, 25 January 2021 (UTC)[reply]
True. Perhaps a card with a link to the content disclaimer could be an idea? -LocalPunk (talk) 15:40, 25 January 2021 (UTC)[reply]
The problem is still which articles should have it, which is a highly subjective choice. —  HELLKNOWZ   ▎TALK 16:24, 25 January 2021 (UTC)[reply]
There'd probably have to be some sort of free-to-update list or something. -LocalPunk (talk) 19:19, 25 January 2021 (UTC)[reply]
@LocalPunk, I think you will want to read Trauma trigger. There might be some practical value in having a NSFW warning, but there is probably no benefit to a trigger warning. WhatamIdoing (talk) 02:35, 26 January 2021 (UTC)[reply]
I strongly disagree with the first paragraph of "In higher education". LocalPunk (talk) 11:35, 26 January 2021 (UTC)[reply]
It might be useful to differentiate between trauma trigger and thing that makes some people uncomfortable. For example, if you saw a person stabbed to death, then you might (or might not) develop long-term PTSD as a result. Your trauma trigger, however, is statistically unlikely to be "seeing people stabbed" or "reading about people being murdered". It's likely to be something like the metallic smell of blood, or the odd motion of the murderer's head, or the food that you had eaten just beforehand. Reading about crimes or watching a violent movie might be uncomfortable (or not; some traumatized people seek out horror films[1]), but it is unlikely to be an actual, bona fide trauma trigger.
There has been talk in the past about certain kinds of content filters. Nobody should have to look at a photo of someone gouging out another person's eye or dead bodies just because Special:Random will sometimes take you to pages related to mixed martial arts or war crimes. But actual trauma triggers, rather than things that make people feel uncomfortable, are probably few and far between on wiki, and warnings for true trauma triggers are probably neither possible (how is anyone supposed to know what your personal trigger is?) nor necessarily helpful. WhatamIdoing (talk) 03:35, 30 January 2021 (UTC)[reply]

The University is not engaged in making ideas safe for students. It is engaged in making students safe for ideas. Thus it permits the freest expression of views before students, trusting to their good sense in passing judgment on these views.

What if it's like one of the banners Wikimedia puts up on articles that need to be reviewed. Just a pale yellow warning "Common Trigger Warning" and editors and decide how specific that needs to be. — Preceding unsigned comment added by Totalart44 (talk • contribs) 06:05, 23 February 2021 (UTC)[reply]
  • I agree that there should be trigger warnings on things that everyone can agree on is triggering, like the holocaust or KKK. Starman2377 (talk) 16:25, 25 February 2021 (UTC)[reply]
    The problem is that we can't actually agree that those subjects are triggering. We can agree that they are uncomfortable. We can agree that they involve evil things. We can agree that one might wish to be careful about how one describes those to children. That is not actually the same thing as those subjects being coupled to any individual's PTSD-producing experience.
    Trauma trigger is "the Vietnam vet flinches when he hears a helicopter fly by". Trauma trigger is "mother collapses every time she hears her dead child's favorite Christmas song". A trauma trigger is not "reading about evil makes me uncomfortable". You're actually supposed to feel uncomfortable when you read about the Holocaust and the violent racist groups. Feeling uncomfortable when you encounter the evils of racism and genocide means you still have a functional conscience. WhatamIdoing (talk) 23:37, 2 March 2021 (UTC) You're right. Starman2377 (talk) 14:46, 25 March 2021 (UTC)[reply]
  • I don't think this should be dismissed out of hand - such warnings would not impact article content and would go a long way to making the website more accessible to some. As for what topics should be "warned" for, we could decide on that the same way we do anything else - through editor consensus. A standardized banner template with slot-in content warnings seems feasible and reasonable. BlackholeWA (talk) 23:51, 1 March 2021 (UTC)[reply]
  • Seriously, how about if someone creates a browser extension that searches a page for key words and phrases, does some kind of image search automagic, etc., before presenting it. Then it would work on everything, not just Wikipedia. And we can get out of the nannying business. EEng 06:42, 2 March 2021 (UTC)[reply]
  • I agree with WhatamIdoing's statement above. But, supposing that we could agree on a "trigger warning" banner and come up with a list of subject areas that the community agreed should display the banner, here's what I would expect to happen:
  1. Most readers would not see it (banner blindness).
  2. Word would get around that some articles have trigger warnings.
  3. People would complain when an article that bothered them personally in some way didn't have the warning.
  4. There would be demands for warnings on unmarked articles for a myriad of reasons (many patently ridiculous on purpose in the hopes of being denied so they can broadcast their fauxrage and get their 15 minutes), which, if we failed to comply, would result in accusations of bias or complicity or indifference to their suffering that would spread rapidly across social media to then be picked up by mainstream media who seem to welcome twitter mobs creating clickbait "news" for them.
I'm not convinced the lack of trigger warnings on articles is a problem, nor am I convinced there's a problem that would be solved by banners. Schazjmd (talk) 16:35, 2 March 2021 (UTC)[reply]
  • Oppose, regretfully. I am a person who generally benefits from content warnings; I have strong post-traumatic reactions to certain subjects, and so I find it useful to be prepared I am going to experience certain subjects before I experience them - especially in video content/etc, where it's much easier to be surprised by content. I am opposed to this proposal for two reasons: I do not generally have these problems on Wikipedia because this is an encyclopaedia, and article subjects are narrowly scoped enough that the lead generally already contains the information to allow me to nope out if I need to. Secondly, I don't think we are capable as a community of delivering effective content warnings with anywhere near enough consistency and empathy across the project for them to be anything more than a weak gesture. I would support more stringent policy on describing the content audiovisual media embedded in articles, because that has caught me out before. -- a they/them | argue | contribs 07:13, 3 March 2021 (UTC)[reply]
  • Oppose I have no idea what would even constitute a trigger warning. I think the introduction of an article should be enough for each user to decide if they personally wish to read the article. If the introduction says, for example, "The Holocaust, also known as the Shoah, was the genocide of European Jews during World War II. Between 1941 and 1945, Nazi Germany and its collaborators systematically murdered some six million Jews across German-occupied Europe, around two-thirds of Europe's Jewish population.", you can decide based on that information if you wish to continue reading. I believe triggers would be highly subjective. I don't see a point in adding a banner to a bunch of articles. jort⁹³|talk 00:04, 8 March 2021 (UTC)[reply]
  • Oppose - this is an encyclopedia. It covers the world in all its variety: good, bad, beautiful, ugly.... --Khajidha (talk) 11:40, 17 March 2021 (UTC)[reply]
  • Doesn't No disclaimers in articles cover this? On a semi-related note, though, I wonder if there'd be any benefit to showing new readers the disclaimers Wikipedia does have which they have to take an action on – i.e. clicking "Okay, continue" or "Cancel" so that they're properly informed about what sorts of things exist on Wikipedia before they enter. Then again, if this were shown to anyone without a cookie set, or something, it could become an annoyance. Maybe a link to the disclaimers could be prominently shown on the main page? Another problem with this sort of thing is you then get a "don't stuff beans up your nose" violation – as in, if we warn readers about what sort of objectionable stuff exists on the site, they then might try to seek it out, if they're curious youngsters or something. Well, anyway, there's my inane rambling quota fulfilled for the day. DesertPipeline (talk) 13:32, 19 March 2021 (UTC)[reply]
  • Oppose For some reason, the proposer believes that the average WP reader has only a few brain cells and cannot make inferences based on the names of articles that they will see graphic content. We can't pander this site to everyone. Putting trigger warnings on articles would only be obstructive to the 99% of readers who would not be triggered by the content of said article. Lettlerhello • contribs 22:07, 3 April 2021 (UTC)[reply]
  • Oppose page-level content warnings, but support the concept in general. We ought to have a disclaimer to readers somewhere on the site that Wikipedia is not censored and so they may come across content or images they may find offensive or may be inappropriate to display in (for example) a workplace, but I agree that we could never decide on universal criteria for what is offensive. Ivanvector's squirrel (trees/nuts) 13:39, 10 April 2021 (UTC)[reply]
    Is something like Wikipedia:Content disclaimer what you have in mind? — Goszei (talk) 18:12, 13 April 2021 (UTC)[reply]
  • @LocalPunk: you may want to take a look at Wikipedia:Perennial_proposals#Content_warnings.
  • Oppose. Why does truth and information need disclaimers? Why should be help discourage people from seeking those things? Life can be harsh and if a person cannot handle certain topics, why are they even searching for that information? It extremely childish to protect people from the harsh realities of history and life. We learn about some things *because* they are horrible and we don't want them to be repeated. We learn about some things to educate ourselves about the topic. The proposed templates are coddling. Jason Quinn (talk) 02:10, 18 April 2021 (UTC)[reply]
  • Oppose if some of our readers need trigger warnings this is not the way to do it. People who are triggered by rape, spiders, clowns or whatever can use searches and our category system to drive their own trigger warning systems. As different people are triggered by different things, it isn't our role to create some sort of general trigger warning system - just stick to the rule of least surprise. ϢereSpielChequers 05:09, 18 April 2021 (UTC)[reply]
  • Oppose. I'll point out the obvious - readers and editors have to consciously select the page they wish to view. If they choose Facial (sexual act) instead of Facial, they've made the decision to open that article. The article title is almost always sufficient to allow the prospective reader to decide whether or not they want to view the article. People need to take a bit of responsibility themselves. Risker (talk) 05:56, 18 April 2021 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Comma bot

I don't really know how bots work, but there is a grammar mistake (not too extreme) I see consistently. It's in a list of words, such as "One, two, three and four". It is supposed to be "One, two, three, and four". Again, I don't know how bots work/how to create one. Does anyone think this is a good idea? TheFirstVicar4 (talk) 15:21, 28 March 2021 (UTC)[reply]

Both forms are allowed by Wikipedia:Manual of Style#Serial commas. PrimeHunter (talk) 15:25, 28 March 2021 (UTC)[reply]
See also WP:CONTEXTBOT. This is not a task bots can do. —  HELLKNOWZ   ▎TALK 16:27, 28 March 2021 (UTC)[reply]
No!! Adding Oxford commas to existing articles would be a fine way to start a war — GhostInTheMachine talk to me 17:00, 28 March 2021 (UTC)[reply]
Alas, for the sake of peace, TheFirstVicar4, Wikipedia has to allow people to eat Grandma. Nosebagbear (talk) 10:29, 29 March 2021 (UTC)[reply]
I see where you're going, but it's too much work for too little overall benefit. As Hellknowz partially pointed out, even though it's just a comma you're working with, the way it's used can affect the clarity of the article, and this largely depends on the type of sentence it's being used in. Getting a bot to understand this will probably require a lot of volunteers' time, and in the end, there will almost always be false positives/negatives. As a general rule of thumb, I prefer most grammatical ambiguities to be picked up and corrected by human editors (and I also believe that's the status quo) - Lankyliver (talk) 00:55, 18 April 2021 (UTC)[reply]

Filter for special:random or the random article button

I feel like there should be some way to filter what pages you can be taken to by either using Special:Random or clicking on the Random Article button. I usually try and use it to find a random page and see if it needs any editing but often it takes me to a page on a topic I know nothing about or a page with very little information on a subject I don't know anything about. So maybe creating some kind of way for users to filter what kind of articles either of those will take them to or something else. I'd like to hear what you guys think about this idea. Blaze The Wolf | Proud Furry and Wikipedia Editor (talk) 20:00, 29 March 2021 (UTC)[reply]

I'd also like it if there was a "random" for all namespaces, or at least the major ones. 🐔 Chicdat  Bawk to me! 20:05, 29 March 2021 (UTC)[reply]
There is. See Wikipedia:Random. PrimeHunter (talk) 20:48, 29 March 2021 (UTC)[reply]

Including ethnic or religious heritage

When did Wikipedia become the enforcer of the Nuremberg Laws? I notice that people are constantly inserting information to identify subjects as being of Jewish descent, irrespective of whether that is relevant to the person's occupation (say, as a Rabbi or activist on behalf of Jewish causes.) Far, far less frequently is anyone else's religion mentioned. Protestants are never identified as Protestants, unless they are official members of a Protestant Church. Catholics are rarely identified as Catholics. But Jews are almost always identified as Jews.

I would recommend a policy of not including someone's ethnic or religious heritage unless that is directly related to their profession. — Preceding unsigned comment added by Wixifixer (talk • contribs) 20:30, 30 March 2021 (UTC)[reply]

@Wixifixer: I think this has to do with reliable sources noting these things more prominently in the case of those who are Jewish. In the western world, anyway, you'd see a similar thing for those who are Muslims, or those who are gay, or any other minority - it's not the default, so it's more worthy of note. Elli (talk | contribs) 01:57, 31 March 2021 (UTC)[reply]
@Wixifixer: You hint at a significant reason yourself: Jews are both considered an ethnic and religious group, an ethnoreligious group. Wikipedia:Manual of Style/Biography#Context says: "Ethnicity, religion, or sexuality should generally not be in the lead unless it is relevant to the subject's notability." If reliable sources often mention it then we usually don't omit it from the whole article. PrimeHunter (talk) 12:37, 31 March 2021 (UTC)[reply]
Maybe I'm reading too much into your comment, but since the discussion is about Jewish descent, it seems like you're implying people talk about having a homosexual ancestor as part of their identity.118.208.187.206 (talk) 06:21, 16 April 2021 (UTC)[reply]
I think you would find a very high proportion of the editors adding such information are themselves Jewish, so your implication is wrong. Johnbod (talk) 13:32, 31 March 2021 (UTC)[reply]


I don't know. In an earlier period, all those things would also have been true of Catholics--from the majority Protestant point of view. Catholics were not just regarded as a different religious group; most Protestants regarded them as at least an ethnic "other," if not a racial "other." In that world, too, "reliable sources" would have mentioned that one of their subjects was Italian/Irish/Catholic, because that fact would be "worthy of note." Now, tastes have changed. Catholics don't need to be noted as Catholics anymore. I haven't done the research to figure out why that changed. Maybe you guys know. But it's still the same phenomenon. And I just think it's time for us to be more sensitive to it. If many other Jews don't agree with me, that's fine. I think they're wrong. — Preceding unsigned comment added by Wixifixer (talk • contribs) 21:24, 31 March 2021 (UTC)[reply]

Getting a Wikipedia biography is usually a sign you are successful. I doubt Jews in general want it hidden that article subjects are Jews if they don't hide it themselves. PrimeHunter (talk) 21:52, 1 April 2021 (UTC)[reply]

well, by that logic, we would have to assume that Jews are the only ones who don't want their religious/ethnic identity hidden, while Episcopalians and Presbyterians DO want it hidden? Honestly, what are you talking about? 47.35.240.141 (talk) 16:34, 4 April 2021 (UTC)[reply]

What are YOU talking about? I have never in any way indicated that Episcopalians and Presbyterians want it hidden. The discussion is about Jews because that's what Wixifixer posted about. The reason we are more likely to mention whether somebody is Jewish is that it's also an ethnicity, and the reliable sources we use are more likely to mention it. PrimeHunter (talk) 19:43, 4 April 2021 (UTC)[reply]
This question has come up fairly often, so we might need to write an essay somewhere. What seems to throw people off is the combination of ethnicity and religion. If you feel like "Jewish" is primarily a religion, then it seems weird to say "He's Jewish" but not "She's Presbyterian". The difference, of course, is that the ethnic background of many Presbyterians is spelled "Scottish", not "Presbyterian". WhatamIdoing (talk) 01:47, 8 April 2021 (UTC)[reply]

Deserted WikiProjects around drinks – or anything? Merge, let be, or something else?

I have noticed that there are several WikiProjects and at least one task force revolving around some sort of beverage, WikiProject Spirits, WikiProject Wine and WikiProject Food and drink with task force Beverages that I know of, all of them inactive. It's a real pity as it looks like a lot of effort has been put into them. Perhaps they could be merged in some way. What happened to them? Is it this perhaps a general trend that WikiProjects fade away? How should Wikipedia handle that? --Mango från yttre rymden (talk) 23:59, 31 March 2021 (UTC)[reply]

@Mango från yttre rymden: some projects manage to provide context that helps editing – such as guidelines, coordinated reviews and a forum for discussion – and it's those projects that thrive. We've had even big projects fail, such as Wikipedia:WikiProject Culture, but it doesn't necessarily mean that editors will not be able to edit those topics effectively. If a project goes inactive, it's a good idea to link to a related project (see the Culture example). I suppose it would also be possible to revive Wikipedia:WikiProject Food and drink since it has a broad scope and thus many potentially interested editors. By the way, there is also a project on my favorite drink that is active: Wikipedia:WikiProject Beer. – Finnusertop (talk ⋅ contribs) 18:16, 1 April 2021 (UTC)[reply]
@Finnusertop: I wasn't implying that WikiProjects are indispensable. I'm just airing thoughts. I'm thinking that all those WikiProjects that revolve around the same wider subject, like food and drink, could be merged into WP Food and drink, that way is it more likely the projects(s) revive and the subject(s) get some more attention. The result could be worth more than the sum of it's parts, as more people are likely to join and engage if there are a few people in the same group, even though each person focus on different things, than if the same amount of people would be separated into one project each. Wine, beer and spirits could be task forces within WP Food and drink.
I have looked around a little, and I get the impression that WikiProjects sprung up like mushrooms at the early 2010s, presumably shortly after the concepts inception, but now have lost peoples interest and half of them are deserted. --Mango från yttre rymden (talk) 19:37, 4 April 2021 (UTC)[reply]
A Wikipedia:WikiProject is a group of people. Some groups form for time-limited tasks; others form indefinitely, but then sort of drift apart. That's okay. You are welcome to WP:REVIVE any WikiProject. You do that primarily by banding together with interested wiki-friends. Pages such as Wikipedia:WikiProject Directory/Description/WikiProject Food and drink will help you find interested editors.
Sometimes, two groups will voluntarily merge. This can be helpful, but it is never forced. WhatamIdoing (talk) 01:51, 8 April 2021 (UTC)[reply]
There are some Wikiprojects such as MilHist that are always active, but I think most will have flurries of activity in between longer periods of dormancy. But they still serve a role and are the relevant place for reports and source discussion re their subject area. ϢereSpielChequers 12:58, 16 April 2021 (UTC)[reply]

Adminship rights debundling

I would like to work on a proposal to debundle all rights that normal users can apply for from the administrative toolkit. I know auto patroller is an example, but I'm not sure what other rights are included in the administrative toolkit that normal users can also apply for. To add a little additional detail, I would like to propose that all user rights aside from the 3 core administrator rights ( Delete pages , block users, and protect pages), are no longer automatically given to administrators, and administrators have to apply for those user rights at the regular forum. ( The point of this is to enable taking away certain rights from administrators without requiring a formal Desysop by Arbcom) The main technical question is whether the ability for an administrator to grant themselves the newly unbundled user rights could be disabled while keeping the ability for admins to grant those rights to other users. I assume that this would probably take a formal RFC, and I am seeking a coauthor to help draft an official RFC proposal. Jackattack1597 (talk) 01:27, 1 April 2021 (UTC)[reply]

Can you see any situations where this would have been useful - eg rather than desysop, are there cases where taking away autopatrol from an admin would have been useful? Mostly when arbcom desysop I see it for admins offending some people, rather than creating problematic articles, or using rollback wrongly. Graeme Bartlett (talk) 03:48, 1 April 2021 (UTC)[reply]
I can't imagine a situation where an admin is trustworthy enough to block people, delete articles, view deleted material, and protect and unprotect pages, but could not be trusted with rights like rollback or autopatrolled. If they cannot be trusted with those, they certainly should not have the admin tools either. Seraphimblade Talk to me 05:02, 1 April 2021 (UTC)[reply]
If there are enough administrators that feel personally that their article creations should be independently patrolled, they could add themselves to a black list for a bot to unpatrol the articles (if DannyS712 is kind enough to repurpose it). The issue then becomes new page patrollers have to patrol pages admins create, when the vast majority are okay. You’ll unbundle it and find admins handing it back to each other because they are sick of patrolling fine pages. Yes, there is an application but hard cases make bad law.
Maybe there’s admins who never use rollback and could shed that right so as not to need a script to hide it. –xenotalk 05:17, 1 April 2021 (UTC)[reply]
Thanks for the ping. @Jackattack1597: "The main technical question is whether the ability for an administrator to grant themselves the newly unbundled user rights could be disabled while keeping the ability for admins to grant those rights to other users." as a matter of fact, it should be fairly easy to do - I wrote the code to do it in December 2019, see gerrit, but it hasn't merged yet because there wasn't a need for it - if enwiki decided to request this feature, it would likely be approved. The relevant phab task is phab:T44072. @Xeno: If any admin wants their articles to be unpatrolled automatically, I'd be happy to file a BRFA, should be fairly easy to code (ridiculously easy since the bot already unpatrols new pages by global rollbackers, so the logic is all there). DannyS712 (talk) 05:26, 1 April 2021 (UTC)[reply]
@Xeno: I requested a way for someone to have a session with less than all their access years ago in phab:T153454 - it hasn't taken off. This is currently available in the API, but not the WEBUI. — xaosflux Talk 13:23, 1 April 2021 (UTC)[reply]
Hmm, looks like I may have had an off-phab on that, since I'm not the author of that one (I think I was the wishlist author for it maybe?) - but same thing. — xaosflux Talk 13:25, 1 April 2021 (UTC)[reply]
  • This is never going to happen as written. Special:ListGroupRights shows the 63 permissions that sysops have. Also the current permission system doesn't allow for direct assignment of a permission, only a group - so they would need a group for each permission and that would overkill - and there is no way we are going to put the community through a "Request for globalblock-whitelist access" process for example. The partial blocks system may grow to allowing someone to be blocked against arbitrary actions, phab:T242541 has some more information on that. — xaosflux Talk 11:01, 1 April 2021 (UTC)[reply]
    • OK, so I re-read this focusing on the "can apply for" part. Keep in mind that noone gets rights still, they get groups. Still see issues, for example "event coordinators" get "no rate limit" and "add +confirmed to users", but you are proposing removing these from sysops and making them also be event coordinators to get them back? Sysops get "import" , but so do "transwiki importers" and "importers", so sysops would also have to apply for those? Making admins also be a member of a dozen other groups is quite cumbersome, we have role-based access controls for good reason. — xaosflux Talk 17:48, 2 April 2021 (UTC)[reply]
  • I firmly believe that unbundling admin rights is necessary but I also think that it has to be done in stages, rather than all at once. I would do this in the form of introducing new userright groups, for which regular users can apply, rather than taking any userrights away from admins. A good place to start seems to be creating a "vandalfighter" userright. I think it should include the ability to issue short blocks (up to 72 hours) to IP and non-autoconfirmed users engaged in vandalism and severe disruption and the ability to semi-protect pages for short periods (say up to a week). In my observations, the noticeboards such as RPP, AIV and 3RR are now frequently backlogged and it often takes hours to get action from an admin on a report there. But, unlike the admins, vandals don't take a break for hours. To give a specific example, several days ago I observed severe BLP disruption by a dynamic IP on an article on my watchlist, 2019 World Figure Skating Championships. I reported it to RPP,[3] but for several hours the report sat without action even though the article was getting clobbered. In the meantime, other users filed reports at 3RR Wikipedia:Administrators' noticeboard/3RRArchive430#User:117.111.0.0/19 reported by User:Jasper Deng (Result: Block, Semi) and ANI Wikipedia:Administrators' noticeboard/IncidentArchive1062#Urgent edit warring rangeblock needed, but again, nothing was happening. Eventually more than seven (!) hours after my initial RPP report, an admin was pinged directly and protected the page [4] and set a range-block for the dynamic IP. Yesterday, after the block and the semi protection expired, the disruption resumed. We were lucky this time that the same admin was online and responded to a ping quickly, since otherwise it would have again been several hours of chaos. This situation was ridiculous and I am certain that it is not an isolated case. Since we don't have enough admins to respond quickly to AIV and RPP reports, we need to give regular users the ability to do something. Nsk92 (talk) 12:13, 1 April 2021 (UTC)[reply]
    • We've looked at "mini-block" and "mini-protect" rights on multiple occasions just in the last 2 years. I think a case can be made, but we've failed to garner firm backing - there are issues that arise with either route. Nosebagbear (talk) 17:15, 2 April 2021 (UTC)[reply]
    A proposal for a "vandalfighter" user right was brought up in 2015 and failed to gain consensus. See Wikipedia:Village_pump_(proposals)/Archive_120#Proposed_user_right:_Vandal_fighter. --Ahecht (TALK
    PAGE    ) 03:35, 12 April 2021 (UTC)[reply]
  • I'm lost as to why this makes any sense. Give admin the three most important tools requiring the most trust, but make them ask for a whole bunch of other user rights? And also everything Xaosflux has said. You mention deleting pages as a right they would keep, but would they keep the ability to view deleted pages and to delete only specific revisions? They would still be able to protect pages, but would they retain the ability to edit through protection? None of this seems to have been considered before this was proposed. It is my personal opinion that we already have too many user groups. WP:PERM already experiences backlogs, sometimes fairly substantial ones. This would make that problem worse, much worse actually in that assigning permissions is not one of the three "core" abilities identified in the proposal. So would we need another new forum for requesting that ability? There might be an unbundling proposal I would support, but this is for sure not it. Beeblebrox (talk) 20:04, 2 April 2021 (UTC)[reply]
Sorry, I really don't think my original proposal was clear enough at all. Really, what I am trying to propose is that any permission that can be requested at WP:PERM is no longer automatically given to administrators, but it wouldn't affect any other permissions. Instead, administrators would need to request them at WP:PERM. If we were concerned about a backlog, I could propose an RFC on doing this for a few permissions at a time instead of all at once, to avoid a logjam of most active administrators requesting every perm back at WP:PERM at once. Also, to me the point of this is so that if an admin minorly misuses WP:PERMpermissions, the permissions in question can be removed without requiring a Desysop. I'm glad I was pointed to idea lab, because I definitely need to iron this out some more. Jackattack1597 (talk) 23:20, 2 April 2021 (UTC)[reply]
  • As far as the question of would we need a technical control to allow +sysop to give this to anyone except for themselves - why? If we don't want them to do that, just make a policy and block them if they violate. Such a technical control wouldn't prevent me from giving some flag to my own alt-account for example after all. — xaosflux Talk 21:02, 2 April 2021 (UTC)[reply]
Good point, on second thought I'll take the technical control out of the proposal, and just include a prohibition on self or alt perm granting in the RFC.Jackattack1597 (talk) 23:20, 2 April 2021 (UTC)[reply]
  • Per Beeblebrox. based on what Xaosflux said. The user rights system on Wikipedia is already highly granular and confusing to many who don't necessarily work in governance areas or are not involved in them until their creation is tagged for deletion, or they become a target for sanctions for some infringement or another. It would be interesting to define what actually constitute the 'core' rights of adminship. Traditionally blocking, deleting, and protecting may be perceived as the most important but as many admins focus on specific areas of their choice, they might not be the tools that are most often used by all admins - someone with some time on their hands might wish to do some data mining, the results of which could/should have been in the preamble of such an RfC (and might cast a different light on the proposal). While it may be possible to come up with reasons why autopatrolled for admins might need to be reviewed, they are rare. More rights mean more opportunities for hat-collecting, hence the En Wikipedia has probably reached the point where suggestions for further ideas for unbundling only serve for academic discussion, and they possibly fall under WP:SLOP. Kudpung กุดผึ้ง (talk) 23:55, 2 April 2021 (UTC)[reply]
  • I don't think we should be concentrating on taking away any userrights from admins, despite the currently pending arbitration request. However, I do believe that we should be thinking about creating new userrights that would allow regular users to perform parts of admin functions in areas where there is particularly urgent need and the shortage of admins is already acutely felt. In my observations, one area where the shortage of active admins is already acutely felt is vandal fighting. As I noted above, AIV and RPP are often backlogged for hours and even screaming for help at ANI doesn't necessarily produce a sufficiently fast response. That's why I suggested above creating a "vandal fighter" userright with the ability to issue short term blocks to non-autoconfirmed editors and to semi-protect pages for up to a week. Another such area is CfD. As it turns out, the persistent backlog there is so bad, that admins have a de-facto practice of allowing non-admins to perform NAC "delete" closures of CfD discussions, disregarding WP:NACD. So creating some kind of a userright (if technically possible) allowing regular editors to perform some low-level deletion functions, such as deleting expired PRODS and maybe deleting categories in non-controversial cases, plus possibly something else, would be useful. Nsk92 (talk) 00:34, 3 April 2021 (UTC)[reply]
    I would probably oppose any effort to unbundle the three "core admin rights" (delete, block, protect) per the rationale I wrote at WP:COREADMIN. It's true that AIV, RFPP, and other areas have been backlogged lately, but I see this as more of a short-term problem that can be solved by promoting two or three additional administrators who are specifically interested in those areas. A new user group would likely have unintended consequences and would be an ill-advised long-term solution to a short-term problem. Mz7 (talk) 01:58, 3 April 2021 (UTC)[reply]
    You are completely wrong. The arguments in WP:COREADMIN are abstract, but the problems I am talking about are concrete and practical that need addressing and are getting worse. And they are not "short-term", far from it. I have observed backlogs at RPP and AfD for a while and they have been quite chronic for at least over a year. As I said, things at CfD have gotten so bad that they now allow NAC "delete" closures in violation of WP:NACD. I haven't paid as close attention to AIV but I would bet good money that if one checks the data for the last year, we'd find that serious backlogs are persistent. All of these problems are only going to get worse if unadressed (just look at what's happening at Commons). The supply of new admins has slowed almost to nothing. At the same time we are losing quite a few admins due to retirements, inactivity, desysops, etc. At the same time WP as a project is getting more and more complicated. The number of admin tasks increases and the level of technical expertise required to perform them increases as well. Our current model of adminship is simply unsustainable and we are already seeing signs of things coming apart at the seams. Nsk92 (talk) 13:31, 3 April 2021 (UTC)[reply]
    I'm actually unopposed to the narrow proposal of allowing non-admins to close CfDs as "delete" if that would actually reduce a chronic backlog. In the past, I have supported such a strategy for WP:RFD, see [5]. Doing this would not require a technical change to the admin toolset, and any such close would eventually have to be reviewed by an administrator anyway when they go to press the "delete" button.
    On the issue of WP:AIV, I am an active admin there, and in my experience, whenever that page is filled with a backlog, it is not because there are a ton of urgent requests waiting for attention, but rather because editors have overfilled it with marginal reports that should really be declined as "not vandalism, take it to ANI", "user incorrectly or insufficiently warned", or "no edits since last warning". From a psychological perspective, it's harder to decline a report than to action the report because it requires taking a confrontational stand, which is why it might take longer for someone to actually say something (nowadays we even have a bot that clears stale AIV reports automatically). I'm not as much of a regular at WP:RFPP, but when I worked there a few weeks ago when there was a chronic backlog, it was the same thing: I declined the wide majority of the backlogged reports rather than taking action on them.
    What this tells me is that the truly urgent issues at AIV and RFPP—e.g. vandals who spam dozens of changes per minute on a variety of articles—already get dealt with quickly in the wide majority of cases, and it's the less urgent, more marginal reports that are the ones that form a backlog, the ones that wouldn't really benefit from non-administrator intervention anyway. Mz7 (talk) 16:11, 3 April 2021 (UTC)[reply]
    I think that admins' rights should stay as they are, unless anyone proposed automatically assigning edit filter manager to administrators, which I support. No unbundling, no debundling, our current number of administrators is too fragile. 🐔 Chicdat  Bawk to me! 10:08, 3 April 2021 (UTC)[reply]
  • At the moment, I would probably look favorably upon a proposal that would unbundle only autopatrolled, but allowing any administrator to self-grant to themselves without restriction, similar to edit filter manager. This would allow administrators who are not as experienced as others in content creation to get WP:NPP feedback on their article creations if they wish to do so. Other rights like rollback and page mover probably don't need to be unbundled. Mz7 (talk) 01:58, 3 April 2021 (UTC)[reply]
    @Mz7: not sure this is really needed - if an admin can't create a page that would pass basic new page patrol - they really shouldn't be creating pages - but if they just want feedback don't they now have the option to "unreview" the page to throw it back in to the queue? — xaosflux Talk 15:38, 3 April 2021 (UTC)[reply]
    I suppose that's fair. I guess it goes back to that contentious question at WP:RFA, which is whether considerable experience in content creation is needed to be an administrator. Currently, the guideline for granting autopatrolled to non-admins is prior creation of 25 valid articles, not including redirects or disambiguation pages. I know I didn't have 25 articles created when I did RfA (although I did have two GAs, but I know some admins who were promoted with much less). Mz7 (talk) 16:11, 3 April 2021 (UTC)[reply]
    @Mz7: that is a good guideline, but the primary component of patrolled new pages is that they aren't a CSD - which admins are expected to be able to recognize (i.e. that it doesn't violate "Wikipedia's criteria for inclusion, copyright violations, biography of living persons violations, conflicts of interest, and advertising.") If we are electing admins that really can't tell if a page is a violation of these policies we have a much bigger problem; not to mention that admins are also patrollers/reviewers themselves. — xaosflux Talk 20:08, 3 April 2021 (UTC)[reply]
    @Nosebagbear mentioned this point at WP:VPP recently. The problem is, I don't think he's correct. When he accepts an article at Wikipedia:Articles for creation, he's making an informed judgement about whether it has at least an 80% chance of surviving Wikipedia:Articles for deletion. He'd like a second or third person to go through the same assessment process. However:
    • Editors' subject-matter expertise varies wildly, so a second opinion may be worth less (or worthless).
    • He says that he's aiming for an 80% chance of the article surviving AFD, but exactly 0% of the 90 AFC drafts he's accepted have been deleted at AFD. Only three out of the 90 have been deleted. Two of the 90 articles were moved back to the draft namespace by someone else and were deleted as abandoned drafts (one of those subjects was moved to the draft namespace for non-notability reasons) and the third was deleted at the author's request. All three of those are eligible for a WP:REFUND.
    So I'm doubtful that we'd be getting any value out of a second opinion. In fact, maybe what we really need is to tell AFC folks that if none of the articles they accept end up at AFD, then that's a sign that their standards are too high. At any rate, what I conclude from this review is that if Nosebagbear accepts a draft at AFC, there is no point in asking another editor try to find a reason to delete it. WhatamIdoing (talk) 05:06, 6 April 2021 (UTC)[reply]
    AFC is not new page patrol. AFC assesses notability and tends to be strict, while NPP lets more stuff through with clean-up tags (while catching obvious speedy deletions). Following this, anyone competent enough to be an admin should have their pages survive NPP. Elli (talk | contribs) 10:05, 7 April 2021 (UTC)[reply]
    @Elli, well, that's what I think, too, but Nosebagbear is an admin, has a much lower deletion rate for the articles he accepts at AFC than he say's he's hoping to achieve, and he still wants the NPP folks to double-check his work. It doesn't seem like a good use of NPP's time to have them re-check the articles that he's already approved. WhatamIdoing (talk) 01:26, 8 April 2021 (UTC)[reply]
    @WhatamIdoing: well tbh, for admin-created articles I'm likely to approve them if they aren't blatant vandalism or whatever, since I trust that an admin would have an understanding of the notability policy. So it's not that big of a problem, more just pointless. Elli (talk | contribs) 01:56, 8 April 2021 (UTC)[reply]
    I agree that it's pointless. WhatamIdoing (talk) 02:11, 8 April 2021 (UTC)[reply]
    And that's really why I think rights de-bundling is pointless. Anyone trusted with blocking or page deleting should be trusted with stuff like article creation and rollback. If they've screwed up enough to merit not having those rights, they should not be an admin. Elli (talk | contribs) 02:22, 8 April 2021 (UTC)[reply]
  • Please see Wikipedia:Unbundling administrators' powers for some history. -- RoySmith (talk) 16:10, 3 April 2021 (UTC)[reply]
    Hmm, I seem to be listed on that page several times : ) - jc37 00:29, 18 April 2021 (UTC)[reply]
  • Remember our problem is not enough candidates running for adminship. Each time we unbundle part of the toolkit we remove another route to adminship, and once people become admins they often go on into other useful areas of adminship. I'm not aware of a specific right that could be unbundled in the way that rollback, file move and template editor were. We are now left with things that go together - like you can't set autopatroller without looking at someone's deleted edits. ϢereSpielChequers 13:10, 4 April 2021 (UTC)[reply]
  • I would strongly support this proposal, if it were a proposal. It does not come up often of course, but there have been instances of an administrator abusing a minor userright in a way which would normally be addressed by simply removing that one privilege, but because the user is an administrator the remedy is desysopping, which at present can only be done through a lengthy Arbcom case. If we kept the admin toolset to the userrights that are exclusive to admins, along with granting the usual non-admin userrights at the time of a successful RFA, then this is a lightweight change (other than for 'crats, who I'm sure can handle ticking a few extra boxes a few times a year, or it could be done by script) which also improves our processes. Ivanvector's squirrel (trees/nuts) 13:51, 10 April 2021 (UTC)[reply]
  • I share WSC's concern over unbundling. I support Mz7's statement that we should make autopatrol like edit filter. There is no way for an admin to unreview their own page creation so there is no easy way, for instance, that an admin could accept a marginal article at AfC and have a second editor review it as part of NPP (and since when is 80% the standard for that?). For this reason alone I support making autopatrol a flippable switch for admins. Barkeep49 (talk) 22:49, 17 April 2021 (UTC)[reply]
    @Barkeep49: I've opened phab:T280890 - can't see any reason they should be forbidden from un-reviewing the page. — xaosflux Talk 23:19, 21 April 2021 (UTC)[reply]
  • Let me repeat what I said before: Instead of taking away userrights from admins, we should be creating new userrights, enabling performing certain low level admin tasks, and making them available for regular users. We still need "full admins", but as Wikipedia is getting more and more complex and the incoming supply of regular editors is stagnating, we are not going to get a dramatic influx of RfA candidates. We should accept that as a given, start treating "full admins" more as crats, and start involving regular users in performing more of actual admin tasks. Nsk92 (talk) 00:11, 22 April 2021 (UTC)[reply]
    We do have regular users performing actual admin tasks which is how we have template editor and page mover (not to mention rollbacker which used to be the main reason someone did RfA). Historically unbundling has only made RfA harder to pass and I think it's plenty hard already. Best, Barkeep49 (talk) 01:54, 22 April 2021 (UTC)[reply]

Pronouns in Infoboxes

I believe that it could be useful to include a person's pronouns in the "infobox"/"biography" section that appears on the side specifically for people.

While this is a per-page thing, having this become standard across pages that refer to a person would be extremely helpful in having it implemented site-wide. — Preceding unsigned comment added by Itscrossboy (talk • contribs) 09:16, 5 April 2021 (UTC)[reply]

I don't believe so. The "they/them" crowd's pronouns are announced in their articles. If Wikipedia was like this: "John Doe was born in 2000. In 2010, he got a job. In 2020, she founded a pizza shop. In 2021, they expanded their menu." then that would be useful. But since it isn't, it isn't. 🐔 Chicdat  Bawk to me! 10:09, 5 April 2021 (UTC)[reply]
Off topic
@Chicdat: slightly off-topic, but in Special:Preferences#mw-prefsection-personal you can specify a language gender, this will be visible to other users using tools like popups, and may lead to you seeing "he" "his" etc more often. — xaosflux Talk 11:19, 5 April 2021 (UTC)[reply]
I have. Most users don't use popups though. 🐔 Chicdat  Bawk to me! 11:20, 5 April 2021 (UTC)[reply]
@Chicdat: hmm - yours isn't showing for me; when it's not showing I do tend to refer to people with singular they to try to be as unoffensive as possible. — xaosflux Talk 11:23, 5 April 2021 (UTC)[reply]
FWIW, Chicdat you are showing 'male' now. — xaosflux Talk 12:58, 5 April 2021 (UTC)[reply]
  • Oppose - It is actually very rare for notable people to publicly state their preferred pronouns, and even rarer for sources to comment upon that preference. Thus, we often won’t know what to put in this parameter.
The problem is that many of our editors (especially newer editors) think that we must fill in every parameter in an infobox... and to do so the editor will either guess, or use the pronouns that the editor assumes the subject will prefer (or worse, an editor will add a pronoun that the editor prefers) - and that would violate WP:No original research. In cases where we do know a bio-subject’s preference, we can simply use it in the text of the article - as is appropriate. Blueboar (talk) 12:25, 5 April 2021 (UTC)[reply]
  • I don't think this is a good idea, we are not wikidata - so putting every possible attribute about a person in a box isn't necessary. — xaosflux Talk 12:59, 5 April 2021 (UTC)[reply]
  • Oppose as unnecessary and likely to be a magnet for disruptive editing. ƒirefly ( t · c ) 13:17, 5 April 2021 (UTC)[reply]
  • Oppose due to it being an unnecessary addition, and a huge potential for edit-warring. JackFromReedsburg (talk | contribs) 19:42, 10 April 2021 (UTC)[reply]
  • Oppose Simple situations can just be used in the text. More complex or unusual uses will require explanation in the text, and will not be adequately covered in the infobox. This will not be a common thing to do at all. Having the parameter in the box will be almost always unhelpful and at the same time pushing a political point of view. Graeme Bartlett (talk) 20:52, 10 April 2021 (UTC)[reply]
  • Comment. The time for implementing this idea may come (and perhaps sooner than it may seem) but for now this proposal is probably premature. As noted above, relatively few people have made their pronoun preferences known and in even fewer cases we have WP:RS which indicate what those choices are. Where such information is available, it can be discussed in the main body of the article, and I believe that's already our standard practice. Creating a new infobox field now would likely invite a great deal of WP:OR and guesswork, and potential edit warring. Nsk92 (talk) 01:04, 24 April 2021 (UTC)[reply]
  • Oppose- Specifying pronouns is more of a "first person" thing: "Hi, I'm Taylor. My pronouns are she/her/hers." It helps because an individual rarely has cause to use gendered pronouns in a self-referential way and it signals to others what such pronouns to use when referring to that individual. But we are writing about the person and will be using the pronouns quite often. We don't need to "tell" the reader, when we can "show" them. Sure, a footnote might be useful or a note on the talk page explaining any instances that might be unexpected by the reader, but there is no reason to hit the reader over the head with this on every bio. --Khajidha (talk) 23:57, 24 April 2021 (UTC) PS - the example given above is just hypothetical, not a statement about myself.[reply]
  • Oppose - stating pronouns somewhere verifiable is not the norm and the encyclopedia covers this ground perfectly adequately through its choice of which pronouns to use in the articles themselves. If a person's gender identity is important to a biography, we put that in the body of the article, typically under "Personal life". › Mortee talk 00:02, 25 April 2021 (UTC)[reply]

How about making all requests for comments into subpages of the RfC page?

All AfD listings that are not jokes are as subpages of the main Wikipedia:Articles for deletion page. In that manner, I propose that all future Requests for Comments be mandatorily made subpages of Wikipedia:Requests for comment. I also propose that titling of future RfCs be standardised with the following format:

  • Wikipedia:Requests for comment/In re [page name] for RfCs that concern one page. (feel free to replace "in re" with words like "regarding", but its replacement should be standardised across the board).
  • Wikipedia:Requests for comment/[question] for RfCs on general matters that cannot be easily classified as only concerning a specific/specific pages.
  • Wikipedia:Requests for comment/[proposal] for proposals.

Ideally there could be an RfC template (yes, I know about Wikipedia:Requests for comment/Example formatting) that a user would sub into when making an RfC (c.f. {{afd2}} where the only things you have to do is to type your reasoning, the page name, and its category). A side benefit of standardisation is that it could open the door for WP:Twinkle to also cover RfCs (though this is not the main reason for my proposal). Thank you, DePlume (talk) 04:17, 8 April 2021 (UTC)[reply]

I don't see a problem this solves. Elli (talk | contribs) 05:27, 8 April 2021 (UTC)[reply]
Right now the RFCs are all over the spot. Some are in Articles' talk pages, another bunch as subpages of WP:RfC, and yet another bunch as subpages of various Project (not Project talk) pages. Making all of them subpages of WP:RfC will greatly enhance unity by having one instead of 100+ locations for them. --DePlume (talk) 05:34, 8 April 2021 (UTC)[reply]
DePlume I guess it just seems unnecessary given the variability in "officialness" or whatever of RfCs. Is a subpage really needed instead of a post at WP:RSN or whatever? Feels excessive. Elli (talk | contribs) 05:50, 8 April 2021 (UTC)[reply]
I am not asking for the RfCs to be posted twice. It is just once, like the AfD nominations. NotReallySoroka (talk) 01:16, 11 April 2021 (UTC)[reply]
I think there are some benefits, like having RfCs being found and created slightly faster with Twinkle support and there not being 15 pages for the same reason. I can see why it could be unessecary, but it could have moderate benefits. Arsonxists (talk) 14:58, 8 April 2021 (UTC)[reply]
  • There are benefits of holding RFCs about particular articles on article talk pages, such as having previous discussions and the article itself close at hand, but there are other RFCs that are not about particular articles, so they need to go elsewhere. As long as RFCs are registered and advertised at a central location I don't see any benefit to standardising where the discussion itself is held. I don't think we should be making decisions on the basis of what is easy to implement in Twinkle (does it go to the library to find good sources and add them to articles yet? If so I might consider using it) but anyway I don't see what would be too difficult about having it add the correct RFC headers wherever a discussion is held, if it is really too burdensome for people to do it themselves. Phil Bridger (talk) 15:25, 8 April 2021 (UTC)[reply]
    • Thank you, but Twinkle is merely a collateral benefit, not the main reason. DePlume (talk) 17:31, 8 April 2021 (UTC)[reply]
      • Then what is your main reason? I don't see one in your initial comment here, but merely an assertion that we should do this. Phil Bridger (talk) 17:54, 8 April 2021 (UTC)[reply]
        • Phil Bridger There are unity (prevents RfCs from being scattered all over Wikipedia), convenience (those who wish to reply to an RfC can easily find some to respond to), and standardised format, just to name a few. Sorry for replying this late, NotReallySoroka (talk) 01:15, 11 April 2021 (UTC)[reply]
          • We want AfD's to remain visible if the article and talk page is deleted, so they aren't held on the talk page. RfC's don't have that concern, and they aren't transcluded on pages like Wikipedia:Articles for deletion/Log/2021 April 11. I don't see sufficient reason to remove RfC's from the page they mostly concern. And whether to designate a discussion as an RfC is often an arbitrary decision. PrimeHunter (talk) 11:18, 12 April 2021 (UTC)[reply]
            • There is another reason it makes sense to put AfD's for all articles in one place even if it makes sense to put other RfCs about an article on that article's talk page: Established articles have followers who will be interested in RfCs about the article. A brand new article has no such followers; the people interested in whether the article should be deleted are the people who are interested in the scope of Wikipedia. Those people follow the AfD page. Bryan Henderson (giraffedata) (talk) 21:46, 24 April 2021 (UTC)[reply]
  • I see the point made, RFCs are all over the shop. Unless you have every area in your watch list, or spot it on the centralised discussion board, it would make sense to make it to centralise to one location. Davidstewartharvey (talk) 13:52, 12 April 2021 (UTC)[reply]
    • Current RfCs are listed at Wikipedia:Requests for comment/All. PrimeHunter (talk) 14:13, 12 April 2021 (UTC)[reply]
    • Having RfCs exist as subpages of one page will make them easier to search (from that point on), but I don't think it'll affect how easy it is to notice new RfCs. Using the bot-maintained page that lists all current RfCs would still be the best way. And it's a bit late to try to improve searching, since there is already a long history of requests in other locations that people would still have to search through. (I don't think it's worth the effort to move them and fix all links to them.) isaacl (talk) 15:08, 12 April 2021 (UTC)[reply]
      • As I said, whether to designate a discussion as an RfC is often an arbitrary decision. I think it's of limited value to make it easier to search old RfCs. PrimeHunter (talk) 15:35, 12 April 2021 (UTC)[reply]
        Yes, I read your comment. I apologize for not discussing the desirability of searching discussions not arbitrarily marked as a request for comment, which I think is important as well and so limits the value of being able to search one set of tagged discussions. isaacl (talk) 20:01, 12 April 2021 (UTC)[reply]
        I'm just trying to weigh the use cases for searchers. How often do I specifically search for RfC's about something? Never. How often do I search archives of a page for discussions which would normally belong there? Often. I think an "RfC space" will make the discussions harder to find, not easier, for the typical searcher. Maybe they get lucky and hit a notification about the RfC in the archives they search, but the chance is much better if the actual discussion is there. PrimeHunter (talk) 23:18, 12 April 2021 (UTC)[reply]
        I don't favour this proposal, for the reasons I specified (don't see how it helps people notice new RfCs or helps with searching given the current situation), but I didn't want to ignore a potential way of interpreting the proposer's viewpoint on the proposal's advantages. isaacl (talk) 23:30, 12 April 2021 (UTC)[reply]
I believe it is preferable to keep most RfCs, particular article RfCs, at the corresponding talk pages. That's where one can view discussions leading to a particular RfC, the relevant talk page archives, etc. However, I also think there is some benefit in having old RfCs searchable. An RfC is a formal, consensus determining, step in the dispute resolution process. Although the initial decision to label a particular discussion as an RfC is often arbitrary, the decisions reached in RfCs carry greater weight afterwards and their conclusions are viewed as more authoritative, compared to ordinary talk page discussions. So I think it might be worthwhile to get the bots to somehow index old RfCs in a systematic fashion after they are closed or expire. Nsk92 (talk) 23:58, 12 April 2021 (UTC)[reply]
I agree with @Nsk92 about keeping RFCs about the content for a single article at that article's talk page.
However, I would like to see the large volume of Wikipedia:Reliable sources/Perennial sources get moved off of Wikipedia:Reliable sources/Noticeboard, so that RSN can go back to being a reasonably sized and functional noticeboard. WhatamIdoing (talk) 02:21, 23 April 2021 (UTC)[reply]

Dark mode

Just noticed that XTools has switched to an all-black background. I really dig it. Are there any current efforts/pushes to add a dark mode to Wikipedia? Shouldn't be too difficult, right? ~ HAL333 01:44, 10 April 2021 (UTC)[reply]

@HAL333: it is actually very difficult - see many many open tasks related to that idea though. — xaosflux Talk 09:14, 10 April 2021 (UTC)[reply]
This has been implemented on the mobile version. Sungodtemple a tcg fan!!1!11!! (talk) 00:22, 11 April 2021 (UTC)[reply]
HAL333, Ugh, I hope not. Just wait until your eyes are a couple decades older and you need all the contrast you can get. -- RoySmith (talk) 23:25, 12 April 2021 (UTC)[reply]
@HAL333: There's something similar in your preferences (gadgets) that changes the text to green and the background to black, but I suspect that takes some getting used to. Sdrqaz (talk) 00:51, 20 April 2021 (UTC)[reply]
Oh wow. Just tried it and although it's easy on the eyes, I wish it weren't so garish. ~ HAL333 01:37, 20 April 2021 (UTC)[reply]
Looks like they've just released dark mode under "Testing and development", xaosflux and HAL333 (or maybe I've just missed it for ages). Doesn't look too bad. Sdrqaz (talk) 23:08, 22 April 2021 (UTC)[reply]
Sdrqaz, is Testing and Development in preferences as well? ~ HAL333 19:36, 23 April 2021 (UTC)[reply]
@HAL333: Yeah, it's near the bottom of the "gadgets" section (should be the penultimate one) of preferences. Sdrqaz (talk) 19:46, 23 April 2021 (UTC)[reply]
I just turned it on and OH GOD IT'S BLINDING ME the background is literally black and the text is white which makes it decidedly not easy on the eyes. Is there anyway to make the background dark gray instead? (Is this even the right place to post this?) ♔MEisSCAMMER(talk)(contribs) 22:04, 23 April 2021 (UTC)[reply]
@MEisSCAMMER and @Sdrqaz, this is being discussed at Wikipedia:Village_pump_(technical)#Proposal_for_a_dark-mode_gadget_addition_(before_Earth_Day_22_April?). I too find the blackness blinding, but only on certain devices. Comments would be welcome there. – SD0001 (talk) 08:43, 24 April 2021 (UTC)[reply]

New user 'problem'

This might be in the wrong place; feel free to move the discussion: Recently I've been seeing many new users get bitten by more experienced users, such as in this diff. In it, User:David notMD thought the user's edit was vandalismunconstructive, so they reverted, and now the new user is saying 'And this is now my really last edit in any article' about a word choice. Wikipedia is supposed to be an open place, but all too often at talk pages, RfCs, AfDs, etc. there is just a lot of harshness, if not intentional, that drives away even experienced users. Is there a way to make the Wiki more open?

Ideas:

1. Whenever someone signs up, guide them through a mandatory tutorial. This is hitting two birds with one stone: Vandals will be discouraged from creating socks, and new editors won't try something like editing a featured article too soon.

2. Make Wikipedia's policies and guidelines more accessible to new users. For example, upon creating an account, new users would be directed to a page which summarizes policies and isn't too long, so that they understand what to do and what not to do.

I'm sure doing this will help problems with vandals and subtle vandalism. Anyone have any other ideas about this? Sungodtemple a tcg fan!!1!11!! (talk) 00:39, 11 April 2021 (UTC)[reply]

  • I don't think anyone has a suggestion for a good "mandatory tutorial" or a short summary of all important policies. Requiring a "mandatory tutorial" certainly won't "make the Wiki more open". Many contributions from new users are not constructive and have to be reverted, no desire to be nice will change that. And your example is not as you describe; nobody said the initial edit was vandalism, and the editor who made it has been here over a year with over 500 edits. User:力 (power~enwiki, π, ν) 01:14, 11 April 2021 (UTC)[reply]
  • FYI - The editor was accusing me of vandalism for having reverted additions to "See also" at more than one article. I engaged the editor in discussions at the Talk pages of the articles in question and at Teahouse. Furthermore, V is not a new editor, having been actively editing since April 2019. David notMD (talk) 01:23, 11 April 2021 (UTC)[reply]
  • This doesn't look like any sort of problem at all. The new editor was told that there was a disagreement about their edit and that the article talk page was the place to discuss it. If the user then calls the disagreement vandalism and refuses to take advice about the appropriate place for discussion then that user is unsuited to be editing Wikipedia, which involves civil disagreement and discussion. It is better to be told that sooner rather than later. Phil Bridger (talk) 19:35, 11 April 2021 (UTC)[reply]
  • @Sungodtemple: There is the WP:HI for this purpose. In defense of David notMD I can say for sure that he didn't fail to WP:COMMUNICATE completely, he explained himself briefly here. On the other side his this contribution wasn't that friendly. Summarily I don't think the idea is worth pursuing it so I propose to close this discussion. (I also made a suggestion here in order to calm down everyone).--AXONOV (talk) ⚑ 15:37, 15 April 2021 (UTC)[reply]
  • I have a few ideas. Firstly, a "tutorial" already exists, or something similar to one. When new users create an account, an interface pops up recommending articles to edit, however, albeit with no mention of policy. WP:TFA is a good, currently maintained, detailed and easy-to-use longer "introduction". Also, there are already simplified versions of many WP policies, including WP:SMOS, HELP:PG, WP:SR, WP:8, WP:10SR, WP:SRI, etc.

Potential implementations relating to above:

  • Make the simplified rulesets more accessible and publicized, e.g. linking on Main Page.
  • Link to TFA in the already existing "introduction".
  • Add a short summary of policy to the already existing "introduction".

Input for my WP essay wanted

Hello, can anyone please give feedback on my essay, User:NotReallySoroka/No such redirect as "Dorian Fried", which speaks against creation of middle-and-last-name redirects without first name? Thank you, NotReallySoroka (talk) (formerly DePlume) 05:06, 17 April 2021 (UTC)[reply]

Dear User: NotReallySoroka, you may like to create this article, and if it is considered too embryonic to be in Wikipedia, it will get moved to the draft space. You can keep an eye on this and see whether it gets enough attention from other users to bring it up to the quality of a Wikipedia article. Regards, Rollo August (talk) 21:38, 25 April 2021 (UTC)[reply]

Rewording the Watchlist interface

Currently, when editors finish an edit and scroll down to the button strip, the dropdown next to "Watch this page" reads: "Permanent". I believe that this isn't an ideal wording, as it implies that you cannot remove an article in your watchlist. Instead, I think that it should be reworded to either Until I remove or Until I delete. Any thoughts on this? EpicPupper 21:03, 17 April 2021 (UTC)[reply]

The other options 1 week, 1 month, 3 months, 6 months can also be removed or changed earlier by the user. I think it's best to just continue briefly stating what happens without further action. Most users probably know or can guess that pages can be unwatched. "Until I remove/delete" can give the impression that the user is expected to remove it at some time. I guess most of the watched pages will never be removed. PrimeHunter (talk) 00:41, 18 April 2021 (UTC)[reply]

An idea to solve overcrowding and spagettization of articles by context specifications

One thing I'm being noting about wikipedia is the total lack of foot notes as would whatever printed encyclopaedia in my childhood.

This leads to over extense over complicated articles that zig-zag over a topic just to clarify an specific context on the topic with extra long paragrafs when. [1]

Not to talk about the complexity at the moment of editing an article where you want to state a point of view inside a focus that is totally twisted.

The most common examples but not only are the interminable cultural variants listings where a "some countries" [2] would help interleaving the article.[3] Not to mention [4]

Wikipedia should enforce a politic of foot noting articles and add a foot notes section to it's style.

I seem to know that there's already a very unpopular notes section at the wikipedia style but i think that is used for other purposes (mostly to add cites and quotes?).

I only lament if my idea is accepted that the facility for machine readability from external scripts will be lost and the grep of a lynx dump of wikipedia would only output a predicate footnote (eg, in Argentina, Brazil, and Uruguay) without subject (e, g. asado) but in turn my human eyes would preciate that so much. — Preceding unsigned comment added by Neurorebel (talk • contribs)

References

  1. ^ a simple foot note like this would suffice
  2. ^ followed by a footnote clarification
  3. ^ i already know that ref is not the right template for this but I dont remember the proper way to add notes
  4. ^ all the terminology and ethimological babble
Neurorebel, I don't understand what your idea is. Could you clarify? Also, it is already common practice to add notes for long lists like on Bill Nye the Science Guy#Format. Sungodtemple a tcg fan!!1!11!! (talk) 01:55, 18 April 2021 (UTC)[reply]
@Neurorebel: You are looking for {{efn}} and {{notelist}}. But I guess the question asked here is this: is something really relevant enough to be mentioned in article prose? If not, it can be mentioned in a footnote, like this: The New Year is celebrated in many countries.[a] – Finnusertop (talk ⋅ contribs) 06:21, 18 April 2021 (UTC)[reply]

Notes

  1. ^ Afghanistan, Albania, Algeria, Andorra, Angola, Antigua and Barbuda, Argentina, Armenia, Australia, Austria, Azerbaijan, The Bahamas, Bahrain, Bangladesh, Barbados, Belarus, Belgium, Belize, Benin, Bhutan, Bolivia, Bosnia and Herzegovina, Botswana, Brazil, Brunei, Bulgaria, Burkina Faso, Burundi, Cape Verde, Cambodia, Cameroon, Canada, Central African Republic, Chad, Chile, China, Colombia, Comoros, Democratic Republic of the Congo, Republic of the Congo, Costa Rica, Ivory Coast, Croatia, Cuba, Cyprus, Czech Republic, Denmark, Djibouti, Dominica, Dominican Republic, East Timor, Ecuador, Egypt, El Salvador, Equatorial Guinea, Eritrea, Estonia, Eswatini, Ethiopia, Fiji, Finland, France, Gabon, The Gambia, Georgia, Germany, Ghana, Greece, Grenada, Guatemala, Guinea, Guinea-Bissau, Guyana, Haiti, Honduras, Hungary, Iceland, India, Indonesia, Iran, Iraq, Ireland, Israel, Italy, Jamaica, Japan, Jordan, Kazakhstan, Kenya, Kiribati, North Korea, South Korea, Kosovo, Kuwait, Kyrgyzstan, Laos, Latvia, Lebanon, Lesotho, Liberia, Libya, Liechtenstein, Lithuania, Luxembourg, Madagascar, Malawi, Malaysia, Maldives, Mali, Malta, Marshall Islands, Mauritania, Mauritius, Mexico, Federated States of Micronesia, Moldova, Monaco, Mongolia, Montenegro, Morocco, Mozambique, Myanmar, Namibia, Nauru, Nepal, Netherlands, New Zealand, Nicaragua, Niger, Nigeria, North Macedonia, Norway, Oman, Pakistan, Palau, Panama, Papua New Guinea, Paraguay, Peru, Philippines, Poland, Portugal, Qatar, Romania, Russia, Rwanda, Saint Kitts and Nevis, Saint Lucia, Saint Vincent and the Grenadines, Samoa, San Marino, São Tomé and Príncipe, Saudi Arabia, Senegal, Serbia, Seychelles, Sierra Leone, Singapore, Slovakia, Slovenia, Solomon Islands, Somalia, South Africa, Spain, Sri Lanka, Sudan, South Sudan, Suriname, Sweden, Switzerland, Syria, Taiwan, Tajikistan, Tanzania, Thailand, Togo, Tonga, Trinidad and Tobago, Tunisia, Turkey, Turkmenistan, Tuvalu, Uganda, Ukraine, United Arab Emirates, United Kingdom, United States, Uruguay, Uzbekistan, Vanuatu, Vatican City, Venezuela, Vietnam, Yemen, Zambia, and Zimbabwe
Neurorebel, I feel like your footnote proposal will come off as more of a feature that facilitates "fun/trivial facts", which is not something prevalent within Wikipedia: information is either notable enough to be mentioned or not. Furthermore, underlying context should belong to the main article, and if it's too long, unnecessary details should be omitted. As for terminology that requires clarification, if it's not understandable by a native or proficient English speaker, then it's probably jargon and should be avoided (see the 2nd paragraph of the manual of style). Otherwise, readers can just do a dictionary lookup or infer the word's meaning from context. However, it is a promising idea, and there might be a way to change it so that it can be successfully enacted. Lankyliver (talk) 11:59, 18 April 2021 (UTC)[reply]
Neurorebel, we already have this functionality but there is no reason to make it mandatory; it all depends on the topic. The layout section of Wikipedia's Manual of Style defines explanatory footnotes as those that give information which is too detailed or awkward to be in the body of the article. The layout of how to do this is given there: the Notes section goes ahead of the References section. See Abu al-Faraj al-Isfahani for an article which makes extensive use of explanatory notes. Template:Efn has instructions on how to construct them. Notes can cite references themselves if needed as explained at Wikipedia:Nesting footnotes. StarryGrandma (talk) 22:44, 18 April 2021 (UTC)[reply]
@力: do you mean Help:HTML in wikitext? – Finnusertop (talk ⋅ contribs) 20:51, 20 April 2021 (UTC)[reply]
Kind of. Help:Wikitext explains "how does one use hypertext", but isn't a style guide on "how writing hypertext is different than writing in a physical diary". User:力 (power~enwiki, π, ν) 16:41, 22 April 2021 (UTC)[reply]
I think it's worth having footnotes be more obvious. I always use the {{NoteTag}} style for this reason. Other footnotes just look like citations -- that is, things the reader tunes out. Vaticidalprophet 09:51, 20 April 2021 (UTC)[reply]
  • Agree with User: Vaticidalprophet - Wikipedia does have a lot of footnotes, but these are largely reference citatiions. Personally, I would not be against having more footnotes if they are adding useful information to an article, but we would need to be carefully that they link with a different list to the reference citation list. Rollo August (talk) 21:47, 25 April 2021 (UTC)[reply]

Reconfirmation of Adminship (ROA) proposal

I am considering an RFC to add the following text to a new section on WP:ADMIN:

Reconfirmation of adminship (ROA) discussions are a voluntary re-confirmation process regarding whether administrators have community consensus to remain an administrator. ROA discussions are to be transcluded at Wikipedia:Requests for Adminship using the template {{tls|Reconfirmation of Adminship template}}. Any administrator may initiate a ROA discussion on their own adminship at any time. Like requests for adminship, a reconfirmation discussion is open 7 days during which editors may ask two questions each, and the discussion is closed by a bureaucrat. Unlike requests for adminship, the threshold for retaining administrator tools is 60% of participants, not counting neutrals, and margins between 50% and 60% should be evaluated by bureaucrats to determine whether consensus exists for continued access to the administrative toolkit. Administrators who withdraw from an open ROA or do not receive sufficient support will lose administrative privileges.

(text based on this diff; I believe Wugapodes and myself were the only editors but check that page for attribution)

A draft template can be found at Wikipedia:Requests for comment/Change to sysop activity requirements/Reconfirmation of Adminship template.

The discussion at Wikipedia:Requests for adminship/Harrias 2 (and, from several years before, Wikipedia:Requests for adminship/HJ Mitchell 3) should demonstrate why this policy is proposed. User:力 (power~enwiki, π, ν) 00:02, 20 April 2021 (UTC)[reply]

Other comments on ROA

  • Regarding the forum, I expect to start the thread as an RFC at Wikipedia talk:Administrators, with a link from the "Village Pump (policy)" page. User:力 (power~enwiki, π, ν) 00:02, 20 April 2021 (UTC)[reply]
  • Regarding the acronym, I prefer "ROA", but "RoA" may be preferred by other editors. User:力 (power~enwiki, π, ν) 00:02, 20 April 2021 (UTC)[reply]
  • There is no actually definition of what an ROA is. For example, could any administrator initiate a ROA discussion at any time about another administrator? — xaosflux Talk 00:18, 20 April 2021 (UTC)[reply]
    • I thought it was obvious that an ROA would be about the admin starting the discussion, but you're right, it does need to be stated. I also forgot the link to the draft template, fixing now. User:力 (power~enwiki, π, ν) 00:20, 20 April 2021 (UTC)[reply]
  • Isn't needed. If a particular admin really wanted to go through RfA again, they can get themselves desysop'ed and just run again. We don't need a separate process for this (unless this would provide a way for the community to remove admins, which it doesn't). This proposal needs more information on why it would be better than a re-RfA.JackFromReedsburg (talk | contribs) 01:03, 20 April 2021 (UTC)[reply]
  • I see no particular reason to encourage re-RfAs of current admins. The process strikes me as pretty self-indulgent -- not so much I'd oppose on principle as several people at Harrias 2 did, but enough to be a bit disreputable a practice. If you're doing it to follow a recall criteria, I don't see a good reason to give it a special name to...separate yourself from the riff-raff? Frankly, I'm unconvinced this isn't "oh shit we've had an empty Current RfAs box for two months, let's pump up those numbers by encouraging re-RfAs". Vaticidalprophet 01:07, 20 April 2021 (UTC)[reply]
    • I also find Harrias 2 to be, not at all a discussion about the need for such a process, but a discussion about how much the community didn't want one. That Neutral column wasn't just a couple throwaways as in an average RfA -- it was a strong statement on behalf of about a third of the participants that they were so troubled by the idea of setting a precedent in favour of these that they refused to support someone they considered worthy of the mop. Vaticidalprophet 01:11, 20 April 2021 (UTC)[reply]
  • At the moment I am struggling to see why anyone would choose to do this. Help me understand? Stifle (talk) 09:52, 20 April 2021 (UTC)[reply]
    • An admin who wishes to check whether there remains community confidence in their continued adminship. It's also a step towards a desysop proposal. The outcome of such RfAs would evidence exactly how much validity there is to claims that RfAs of existing admins will be filled with editors with gripes and grievances and thus fail (which causes desysop proposals to fail by virtue of 'need to protect admins who take tough actions'). It would take some very selfless admins willing to do this, though, so at minimum there should be evidence that there's a handful of admins that would even contemplate going through this. ProcrastinatingReader (talk) 14:02, 20 April 2021 (UTC)[reply]
      • To the degree we need evidence, I'd offer two: one would be all the admins we have who have recall criteria and the other would be the 3-4 admins who volunteered to act as a trial on the rolling mandatory reconfirmations proposal that failed recently. Nosebagbear (talk) 14:04, 24 April 2021 (UTC)[reply]
    • I once done that on the Russian Wikipedia (and became the first admin there to go through the whole procedure) because a group of users became vocal criticizing me, and I was not sure whether I still have community support. I decided to stand reconfirmation and got over 90%, with 3 users opposing.--Ymblanter (talk) 18:58, 21 April 2021 (UTC)[reply]
  • This seems to add unnecessary complexity by creating something called an "ROA" with special guidelines. Simplify the proposal; just add a sentence saying (in more elegant words): Users with admin tools (or those eligible to regain admin tools at BN) may also open an RfA. Such an RfA will have adjusted thresholds for consensus <insert>. If this RfA fails, admin rights will be revoked. ProcrastinatingReader (talk) 14:06, 20 April 2021 (UTC)[reply]
  • This is fairly similar to @Thryduulf:'s proposal here and so I'd be inclined to support. I do think that it should note that candidates may not trigger one of these while there is an outstanding ARBCOM case request or case naming them as a party. I firmly support a clear demonstration that recall RfAs are permitted, and that failure to confirm consensus to be an admin is enforceable by removal of the userrights by the 'crats. Nosebagbear (talk) 20:35, 22 April 2021 (UTC)[reply]
  • Good idea. I would have supported a more ambitious proposal, but this one is a reasonable start. Apart from what PR wrote above, a reconfirmation RfA (even if overwhelmingly successful) would also let an admin get substantive systematic feedback about their admin work from the community as a whole. Sort of like a performance review. Nsk92 (talk) 22:24, 23 April 2021 (UTC)[reply]
  • Good idea, although I think it should be workshopped together with User:Nosebagbear/Draft RfC on Confirmation RfAs#Simpler proposal (i.e. combine the two proposals into one) to sort out the missing detail. Thryduulf (talk) 21:35, 24 April 2021 (UTC)[reply]

My "not search engine" essay

In my attempt to contribute to RfDs, I have decided to write another essay intended to say that we are not a search engine. How does the Community think of this? I believe it would be a good addition to WP:NOT. The essay is at WP:NOTSEARCHENGINE, NotReallySoroka (talk) (formerly DePlume) 03:05, 21 April 2021 (UTC)[reply]

I don't think this essay is accurate – after all, Wikipedia does have a search engine. True, it's not a general-purpose search engine like Google or Bing, but it is a search engine nonetheless. Wikipedia's primary purpose may be to be an online encyclopedia, but to fulfil this purpose we need to provide readers with an effective way to find desired information. – Teratix ₵ 04:38, 21 April 2021 (UTC)[reply]

Autopatrolled for extended confirmed users outside of article-space

Though not as prominently displayed, articles in all namespaces are subject to patrol. While patrolling in mainspace involved checking for notability, cleanup issues, etc - patrolling elsewhere is mainly just checking for obvious issues such as copyvios and attack pages. Given the vast number of pages created by experienced users outside of mainspace, patrolling these other namespaces isn't done often. To make this feature more useful, I'd propose automatically patrolling, ideally with a software feature, of pages created by extended-confirmed users outside of mainspace. Thoughts? Elli (talk | contribs) 01:55, 22 April 2021 (UTC)[reply]

Um... what? Ever heard of a user, Carlossuarez46, an administrator, abusing autopatrolled right by creating thousands of non-notable substubs? If anything, we should be more cautious about handing out autopatrolled after that recent case. So, no. 🐔 Chicdat  Bawk to me! 11:38, 22 April 2021 (UTC)[reply]
  • Support. The rationale for having projectspace pages subject to patrolling in the first place has always been fairly weak. The theoretical reason that one should watch for copyvio and attack pages there there sounds reasonable in the abstract, but in practice the overwhelming number of projectspace pages are either never patrolled at all or get patrolled accidentally, much later than they have been created. We should look for better ways of identifying highly problematic material in projectspace (e.g. trying to automate certain tasks and using bots creatively) rather than making all projectspace pages subject to patrol. The Carlossuarez46 case was an extremely isolated outlier even for mainspace and, AFAIK we've never had anything similar in projectspace with any user, admin or otherwise. I would support making all pages outside of mainspace not subject to patrol; but short of that, Elli's proposal is reasonable. Nsk92 (talk) 12:02, 22 April 2021 (UTC)[reply]
  • Oppose this particular implementation, but support in theory the idea of deprecating patrol for experienced users outside of reader-facing namespaces. EC is an automatic userright and easily gamed, and I fear we'll have LTA socks gaming EC and gaining this modified autopatrol right, creating and automatically patrolling pages we would otherwise reject in some obscure namespace, then moving them to article space where they will go undetected. Autopatrol should continue to be a userright only handed out based on a human review of an applicant's suitability. On the other hand I would support turning off patrol for NOINDEXed namespaces that are low-risk for abuse, perhaps along with adding a "this is not a Wikipedia article" banner in the software for those namespaces. Don't take my comments as a proposal, it needs work. Ivanvector's squirrel (trees/nuts) 13:12, 22 April 2021 (UTC)[reply]
    I think indexing is a good potential criterion for which pages require patrolling. {{u|Sdkb}} talk 05:36, 24 April 2021 (UTC)[reply]
  • Support the idea of this, still unsure of the correct implementation. User:PEIsquirrel brings up a concern about LTAs abusing this. The simplest solution is to have all pages moved to the mainspace require a review (unless the user has the true Autopatrolled right). I'm indifferent on banners saying "this is not a Wikipedia article". JackFromWisconsin (talk | contribs) 14:34, 22 April 2021 (UTC)[reply]
  • We shouldn't be !voting per the idea lab rules, and I'm unsure about the specific proposed implementation here, but I generally support trying to find a way to make patrolling of non-article pages more targeted. For copyvios, in particular, I wonder if that could be semi-automated—maybe only patrol pages that Earwig says have a high probability of violation? {{u|Sdkb}} talk 05:38, 24 April 2021 (UTC)[reply]
  • Support the idea, not sure with potential abuse mitigation. EpicPupper 21:58, 27 April 2021 (UTC)[reply]

Making wikipedia more graphic

Is it possible to add more images or videos in articles for a better experience and understanding of the content provided? — Preceding unsigned comment added by Souvick100Saha (talk • contribs) 09:11, 24 April 2021 (UTC)[reply]

Thumbs down icon Cabayi (talk) 10:10, 24 April 2021 (UTC)[reply]
Souvick100Saha, this is the Village Pump Idea Lab used for incubating proposals about all of Wikipedia. If you see particular articles that need more images, please be bold and add them. Thanks, EpicPupper 20:08, 24 April 2021 (UTC)[reply]

Charts (bar charts / histograms / ......) added to articles

On a page like "Canada"; I'm thinking of 1 chart showing Canada's land mass relative to other countries' land mass (Countries larger than Canada, and smaller than Canada; on either side of Canada.), another chart showing the length of Canada's coastline in relation to the lengths of other countries' coastlines, etc for all the numbers on the "Canada" page.

That's just 1 example; but eventually a "Pictorial-Pedia".

I can't decide whether; a link on the main page should open a separate page with the charts, or should each individual chart "pop-up" when pressing an icon beside the respective number ?

If a link on the main page for "Canada", opens to the pictorial page; should a map of Canada be the background, with the charts arranged on top ?

Maybe; this is beyond the scope / outside the realm, of Wikipedia ?


Maybe; someone else has implemented this idea, and I didn't see it.

I'm so new; to navigating a monstrosity, like Wikipedia.

And; I'll need a lot of "hand-holding", if I do go through with this. — Preceding unsigned comment added by I enjoy data (talk • contribs) 02:24, 26 April 2021 (UTC)[reply]

Encyclopedic articles are meant to give readers a general intro to subjects rather than display every single little bit of information possible (see WP:Wikipedia is not an indiscriminate collection of information). Sungodtemple a tcg fan!!1!11!! (talk) 15:23, 26 April 2021 (UTC)[reply]
Just checked... we do. See: List of countries by length of coastline. So again... rather than duplicate, just link. Blueboar (talk) 15:49, 26 April 2021 (UTC)[reply]

Portals?

Does anyone actually use portals? Before crossing the Rubicon and becoming an editor, I had never noticed them, let alone used them. An example of their disuse, Portal:Cars is viewed by less than 100 daily on average... Is there any way to make them more accessible and user-friendly or should they just be scrapped? ~ HAL333 21:34, 26 April 2021 (UTC)[reply]

  • Scrapped, except the top level ones linked on the main page, because virtually nobody uses them (based on page views). On the other hand, their existence does no harm. We have several million pages nobody reads, and portals make up less than one tenth of one percent of them. Levivich harass/hound 21:59, 26 April 2021 (UTC)[reply]
  • I went from a portal maintainer to a portal skeptic. The idea that they are either alternative thematic Main Pages or reader facing facets of WikiProjects both failed. Readers simply don't use them the way we wanted them to. Readers hardly use them at all. There was a big RfC to deprecate portals a few years ago but that failed. The portal people have had time to come up with worthwhile ideas since then but portals are still the sad reminder of what all websites used to look like 20 years ago and why they are no longer like that. If another RfC was held in say a few years it would probably pass. – Finnusertop (talk ⋅ contribs) 22:08, 26 April 2021 (UTC)[reply]
  • Portals should be scrapped, except the very top level ones linked on the main page. Virtually no one uses them. The larger categories are helpful, but smaller portals often go unused after significant effort in making them. EpicPupper 21:46, 27 April 2021 (UTC)[reply]
  • Portal:Current events is used, but that can/should be moved to project space. Beyond that, I never use portals, but don't think they are so unused that removing the entire namespace is justified yet. User:力 (power~enwiki, π, ν) 19:28, 28 April 2021 (UTC)[reply]

Have the ability to search for pages without talk pages or talk pages without WikiProjects

I do not know if this is feasible or has already been done, but this seems like a great new feature. It can allow WikiProjects to more easily find pages that have not been tagged that are covered by the WikiProject. It would be a great maintenance tool. (Oinkers42) (talk) 15:51, 27 April 2021 (UTC)[reply]

I'd very much like to know this as well and would be more than happy to help with adding WikiProjects. I often run into articles, even some that have existed for years, that either don't have a talk page or have a talk page with zero WikiProject banners. – Finnusertop (talk ⋅ contribs) 16:22, 27 April 2021 (UTC)[reply]
You can try this Quarry query to get articles without talk pages a thousand at a time. There's also this query that I've used in the past that restricts it to pages tagged as unsourced. Let me know if there are any other restrictions that might be helpful.
Note that to regenerate the results for yourself you have to fork the query. Vahurzpu (talk) 17:08, 27 April 2021 (UTC)[reply]
This search looks for talk pages without WikiProject banners. Many of them are talk pages of redirects. PrimeHunter (talk) 17:18, 27 April 2021 (UTC)[reply]
PetScan can be used to search for pages with a particular template (e.g. an infobox) or in a category tree that don't have particular WikiProject Banner(s). This search find articles with {{Infobox mountain}} that don't have a banner for WikiProjects Mountains, Volcanoes, or British and Irish Hills. And this search finds articles in Category:Polyphenols and it's subcategories that don't have a banner for WikiProject Chemicals. Plantdrew (talk) 20:12, 27 April 2021 (UTC)[reply]

"Manually-vetted" usergroup

After seeing some recent discussions, it seems to me like there is a general community want for a userright/usergroup that's more trust than "extended confirmed", but less trusted than administrator. Generally, the concern is that extended confirmed can be gained automatically, with no human oversight.

Therefore, I would think that a usergroup "manually vetted" would make sense, and would be automatically assigned to any editors with "autopatrolled", "new page patroller", "page mover", or "template editor". This is because for granting those rights, a user should either have decent content contributions, or be well-trusted.

Following this, many pages with sysop protection could be dropped to this group instead, since any members have already been vetted for being productive contributors.

Thoughts? (please don't !vote, I'm not sure of the specifics here, I just think this could be potentially useful) Elli (talk | contribs) 19:22, 28 April 2021 (UTC)[reply]

I've generally disliked most attempts to create a formal 'inside circle'. This seems like the same. We don't need even more gatekeeping IMO. Also, overprotected full protections should be dropped anyway, as they're already not in compliance with WP:PP. ECP works fine as a set of requirements for basic competence and can be obtained automatically. If ECP editors are doing problematic things the accounts can be blocked. It's not exactly trivial to have multiple ECP socks lying around, as that does take an investment of time. That all being said, there is an equivalent concept to this on metawiki ('autopatrolled' is given out freely for this purpose), but that project is a different size and purpose. ProcrastinatingReader (talk) 19:27, 28 April 2021 (UTC)[reply]
They're not overprotected for now - but usually I'd think full protection in terms of edit warring, for example, could be dropped to this level, with the warning that any edit warring would immediately get the rights pulled. Elli (talk | contribs) 19:32, 28 April 2021 (UTC)[reply]
Not being a "content wiki" patrolling on metawiki applies everywhere, but yes we normally give it out liberally there to anyone that is around for a bit and is active on a content project. It has very little impact there except on actual patrolling and a couple of filters. — xaosflux Talk 19:35, 28 April 2021 (UTC)[reply]
Elli, perhaps the template editor protection level could be repurposed for this. Articles like Gay, Beer or McDonald's should probably not be moveable by extended confirmed, but restricting them to sysop seems overkill. An edit filter could be used to stop for example an autopatrolled user from moving templates, so moving templates would still require the user to be a template editor. — Alexis Jazz (talk or ping me) 21:25, 28 April 2021 (UTC)[reply]
@Alexis Jazz: I don't see how this would be appropriate - editing templates with hundreds of thousands of transclusions is a very different task from moving pages. Elli (talk | contribs) 21:59, 28 April 2021 (UTC)[reply]
Elli, not much would really change for those. Editing templates or modules with the manually-vetted protection level would still require a user to be a member of the template editor user group. There are currently 5 protection levels, increasing this may be met with resistance. It's just a clever way of optimizing the use of protection levels. Do more with what we have. — Alexis Jazz (talk or ping me) 22:05, 28 April 2021 (UTC)[reply]
@Alexis Jazz: the problem is that far more people would end up with the ability to edit such templates than should have it. It's the same reason we split out intadmin from admin, even though pretty much any admin can get the perm on request. Elli (talk | contribs) 22:32, 28 April 2021 (UTC)[reply]
Elli, no they wouldn't. Who do you believe would gain the ability to edit what are currently called template editor protected templates? — Alexis Jazz (talk or ping me) 22:47, 28 April 2021 (UTC)[reply]
@Alexis Jazz: my point is that your idea would either lead to a lot more people requesting template editor, or far fewer people getting the right than should have it. Elli (talk | contribs) 23:02, 28 April 2021 (UTC)[reply]
Elli, that's not what I meant. My idea would be to rename the "template editor" protection level to "manually vetted" or similar and in addition to template editors apply it to patrollers, page movers, etc. while using an edit filter to ensure only the template editor user group (not to be confused with the template editor protection level) can edit/move pages in the template: and module: namespaces at this protection level. — Alexis Jazz (talk or ping me) 23:09, 28 April 2021 (UTC)[reply]
@Alexis Jazz: ah, I see. Still not sure this is a good idea, there are some template-protected pages outside of the template: namespace (like User:AnomieBOT/TFDTemplateSubster). Also an edit filter is janky and you'd be better off just making another group. Elli (talk | contribs) 23:55, 28 April 2021 (UTC)[reply]
There seems to be two concerns here and I'm not sure how they connect. Right here, the concern seems to be that extended-confirmed is granted too freely. What abuses are we seeing from EC editors that we're trying to prevent? (Or, what right are we trying to grant to this new elevated group of editors?) In the one linked discussion, the concern seems to be that move-protection is overriding the page-mover permission, which does seem weird, but it seems like an argument about what "page mover" ought to mean. I don't see why it needs to involve a new permission. In either case, template editor permissions seem quite separate. › Mortee talk 00:07, 29 April 2021 (UTC)[reply]
@Mortee: so ECP - basically the Arbitration Committee invented a protection level out of thin air with any technical implementation, leaving it to the administrators to try to figure out how to manage it, thus eventually extended confirmed was born - the original purpose remains, however the community has additionally co-opted the group and permissions model to also provide what it is today - we can't strengthen the requirements without getting back to where we started: a means to enforce the arbcom device. — xaosflux Talk 00:19, 29 April 2021 (UTC)[reply]
Xaosflux I just haven't quite understood what's actually being asked for here. Are there powers being automatically granted to extended-confirmed users that shouldn't be (Generally, the concern is that extended confirmed can be gained automatically, with no human oversight)? If so what are they and what's the problem? Or, as with the linked discussion, is it rather that powers aren't being granted to people that should have them, in which case I guess the same questions apply. The way this was framed it sounds like there's a general concern about this, but I'm not yet clear what 'this' is, so I'm interested but a little lost. › Mortee talk 00:25, 29 April 2021 (UTC)[reply]
@Mortee: currently extendedconfirmed is granted automatically when your account is at least 30 days old and you have made your 500th edit. The usergroup currently does two things: it lets you edit pages that have extended confirmed protection and it lets you bypass ~5 abusefilters (notably the one that allows use of the content translation tool). We can't grant this "less freely" though, as the protection is about those arbcom requirements in many cases - which strictly only applies to people with under 500 edits and 30 days tenure. — xaosflux Talk 00:31, 29 April 2021 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(idea_lab)&oldid=1020423226"