Wikipedia:Village pump (idea lab) Information

From Wikipedia
  Policy  Technical  Proposals  Idea lab  WMF  Miscellaneous 
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, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35

Trigger warnings

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

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

Clark Kerr, 1961 [2]

  • Someone should have warned me there'd be a Trigger warning discussion on this page before I visited it, because every time I see someone proposing trigger warnings I just want to cry. E Eng 21:34, 29 January 2021 (UTC)
    I think you're missing a ⸮ there, EEng. 4D4850 ( talk) 19:43, 15 February 2021 (UTC)
    What, you think I wasn't serious? E Eng 06:42, 2 March 2021 (UTC)
What if it's like one of the banners Wikimedia puts up on articles that need to be reviewed. Just a pale yellow warning "Common Trigger Warning" and editors and decide how specific that needs to be. — Preceding unsigned comment added by Totalart44 ( talkcontribs) 06:05, 23 February 2021 (UTC)
  • I agree that there should be trigger warnings on things that everyone can agree on is triggering, like the holocaust or KKK. Starman2377 ( talk) 16:25, 25 February 2021 (UTC)
    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)
  • I don't think this should be dismissed out of hand - such warnings would not impact article content and would go a long way to making the website more accessible to some. As for what topics should be "warned" for, we could decide on that the same way we do anything else - through editor consensus. A standardized banner template with slot-in content warnings seems feasible and reasonable. BlackholeWA ( talk) 23:51, 1 March 2021 (UTC)
  • Seriously, how about if someone creates a browser extension that searches a page for key words and phrases, does some kind of image search automagic, etc., before presenting it. Then it would work on everything, not just Wikipedia. And we can get out of the nannying business. E Eng 06:42, 2 March 2021 (UTC)
  • 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)
  • Yes, i think we should make a banner for triggering content. I know not everyone thinks that something is triggering. But what we should do is have discussions on pages if they should have a trigger warning or not. Starman2377 ( talk) 16:40, 2 March 2021 (UTC)
    So, what if someone is triggered by snakes. Or dogs. Or birds. Or spiders. Would we have to put trigger warnings on all of those pages too? Because some people are as frightened of those as other people are of violence. Where do we draw the line? We could easily end up with virtually every article having some sort of trigger warning. MeegsC ( talk) 17:23, 2 March 2021 (UTC)
    Phobia object ≠ trauma trigger. NSFW warning ≠ trigger warning. WhatamIdoing ( talk) 23:29, 2 March 2021 (UTC)
  • Incredible, and sad, that we are even discussing such a silly, infantilizing, idea. Of course, this is assuming text. Photos might be another issue. Rollo ( talk) 21:51, 2 March 2021 (UTC)
  • Although a trigger warning is much more serious than a spoiler warning, I think Wikipedia's experience with spoiler warnings is instructive here. I don't think it's a good idea, and would be subject to similar problems. ~ ONUnicorn( Talk| Contribs) problem solving 23:41, 2 March 2021 (UTC)
  • Oppose for text. Wikipedia isn't in the business of censoring text on this type of basis. An effort independent of Wikipedia, probably a browser toolbar, may be what you want to support. power~enwiki ( π, ν) 23:41, 2 March 2021 (UTC)
    Everyone keeps stealing my ideas -- see my earlier post. I feel triggered. E Eng 23:44, 2 March 2021 (UTC)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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. Lettler hellocontribs 22:07, 3 April 2021 (UTC)
  • 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)

I have an idea

My idea is that when you hover you're cursor over an image, You should be able to see a larger version of the image. A lot of the time, It takes awhile to load an image when you click on it. If this would be added, It would be a switchable setting. Starman2377 ( talk) 13:02, 25 March 2021 (UTC)

I like it. I already have Wikipedia:Tools/Navigation popups turned on. It's quite pleasant, and this feature would also make pictures more useful. Jim.henderson ( talk) 11:43, 28 March 2021 (UTC)
There's a browser extension for Chrome and Firefox called ImagePreviewer that does this. Fences& Windows 23:46, 3 April 2021 (UTC)

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)

Both forms are allowed by Wikipedia:Manual of Style#Serial commas. PrimeHunter ( talk) 15:25, 28 March 2021 (UTC)
See also WP:CONTEXTBOT. This is not a task bots can do. —   HELLKNOWZ   ▎ TALK 16:27, 28 March 2021 (UTC)
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)
Alas, for the sake of peace, TheFirstVicar4, Wikipedia has to allow people to eat Grandma. Nosebagbear ( talk) 10:29, 29 March 2021 (UTC)

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)

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)
There is. See Wikipedia:Random. PrimeHunter ( talk) 20:48, 29 March 2021 (UTC)

"Year in review" articles

I've noticed that different topics have different lead sections and different ways to put events, so I would like to make a proposal to fix them. I think this would be added to Wikipedia:Manual of Style/Lists.

PROPOSAL: Year in review articles are articles that review and summarize all of the events in the year.


The article should be the name of the year, then in, and then the topic it is referring to. For example, an article talking about politics in 2005 would be called 2005 in politics. The lead section should be just "Events from the year Year in review.", with no links in the lead. Everything should have a bullet point.



It should start with a section for the monarch and/or leader(s) of the place, titled Incumbents. Then it should have a section titled Events, with subsections for each month if and only if there is at least one event for each month. Only events with specific articles should be listed. For example,

  • 1 July – Sony releases a new brand of headphones.

should not go in the article (unless there is a specific article about its release), but

should go in the list.


After the lead, there should be a section called Works. Every work listed must have a separate article. Do not link to files. It should then include a list of Births, then Deaths in the year, in that order.

— Preceding unsigned comment added by -noah- ( talkcontribs) 22:43, 29 March 2021 (UTC)

"Year in review" discussion

@ -noah-: That sounds too rigid for many articles. For example, should 2020 in Burkina Faso have four one-line subsections for events by month? Or maybe less if we remove items with no article, which would leave 2010 in Burkina Faso essentially blank. Or maybe make 12 sections whether there are events or not like the ugly 1997 in Burkina Faso? If you want to work on years then you can join Wikipedia:WikiProject Years. PrimeHunter ( talk) 23:42, 29 March 2021 (UTC)
@ PrimeHunter:. Thanks for the feedback. Do you have any suggestions about what I could change it to? Noah 💬 13:08, 30 March 2021 (UTC)
@ -noah-: I'm not active in the area. Wikipedia talk:WikiProject Years seems a better place to discuss it. Note that Wikipedia:WikiProject Years#Scope links to Wikipedia:Timeline standards. Many year articles display Template:Year article header. PrimeHunter ( talk) 14:41, 30 March 2021 (UTC)
I think a way to fix this issue would be to only make articles like this if that year was fairly significant for the specific topic. So 2021 in Burkina Faso would only be made if something significant happened that year for Burkina Faso. Blaze The Wolf | Proud Furry and Wikipedia Editor ( talk) 18:08, 31 March 2021 (UTC)
Burkina Faso has 22 million people. People would be screaming about systemic bias if we deleted a whole year of the country "because nothing significant happened". The problem is that we haven't added much to those articles yet, probably mainly due to a shortage of editors from the country. PrimeHunter ( talk) 21:59, 1 April 2021 (UTC)
WikiProject Years, under whose purview this should fall under, doesn't seem to be very active currently. In any case, I think further development of such guidelines should probably be based on WP:Timeline standards, which already exists as a former guideline. More specifically, I would strongly oppose the proposed guidance that "The lead section should be just 'Events from the year YYYY.', with no links in the lead." This is in direct contravention of the manual of style. All lists, year lists included, should have a proper introduction as the lead section. That most of them don't is a current failure, not something to be advocated. -- Paul_012 ( talk) 15:28, 1 April 2021 (UTC)

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 ( talkcontribs) 20:30, 30 March 2021 (UTC)

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

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 ( talkcontribs) 21:24, 31 March 2021 (UTC)

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)

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? ( talk) 16:34, 4 April 2021 (UTC)

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

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)

@ 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 ( talkcontribs) 18:16, 1 April 2021 (UTC)
@ 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)
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)

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)

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)
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)
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. – xeno talk 05:17, 1 April 2021 (UTC)
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)
@ 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)
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)
  • 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)
    • 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)
  • 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: 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)
    • 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)
    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
    ) 03:35, 12 April 2021 (UTC)
  • 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)
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)
  • 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)
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)
  • 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)
  • 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)
    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)
    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)
    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)
    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)
  • 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)
    @ 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)
    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)
    @ 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)
    @ 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)
    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)
    @ 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)
    @ 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)
    I agree that it's pointless. WhatamIdoing ( talk) 02:11, 8 April 2021 (UTC)
    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)
  • Please see Wikipedia:Unbundling administrators' powers for some history. -- RoySmith (talk) 16:10, 3 April 2021 (UTC)
  • 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. Ϣere SpielChequers 13:10, 4 April 2021 (UTC)
  • 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)

Thank summary

Currently we can thank users. We thank them for a specific edit, or several. But what if we wanted to say why we were thanking the user? What if we wanted to add an additional comment? Similar to edit summaries, I think it would be nice if there were thank summaries. I've thanked a lot of users, and a lot of users have thanked me, but sometimes I'm wondering, what about the edit was so great? I know that thanks should be shorter than, say, barnstars, but these thank summaries would just be optional. 🐔  Chicdat  Bawk to me! 10:15, 3 April 2021 (UTC)

  • I have no comment on the merits of this issue, but I believe it would require developer time to implement. Dev time is a scarce resource, which I feel could be better spent elsewhere. ƒirefly ( t · c ) 10:59, 3 April 2021 (UTC)
  • My take... automated thank you messages are rather impersonal. I appreciate it when someone composes a more personalized message, and posts it on my user talk page. Much more meaningful to receive than an automated message. Blueboar ( talk) 11:39, 3 April 2021 (UTC)
  • Some users would use it for other things, e.g. harassing or canvassing. Would the summary be public or private? If it's private then should some user groups like administrators be able to see it? We value transparency. As long as we don't have private messaging (I know we have email), I don't think we should introduce a similar feature for an unimportant official purpose. If it's public then you may as well post to them or ping them somewhere. PrimeHunter ( talk) 11:42, 3 April 2021 (UTC)
    It would be public, viewable to other users (apart from the two, the performer and the receiver) through thanks logs. 🐔  Chicdat  Bawk to me! 12:41, 3 April 2021 (UTC)
  • Personal messages are always appreciated—please feel free to put a note on the user's talk page and let them know exactly what is so great about the edit in question! The thank you function works well as a way to give a quick indication of appreciation. In terms of cost-benefit ratio, I wouldn't want more effort spent enhancing it to replicate the functionality of editing a talk page. isaacl ( talk) 15:56, 3 April 2021 (UTC)

Creating Articles for Restoration

I have had this idea for a while now, and I have been considering that we could make Articles for Restoration to vote on whether an article that has been deleted should be restored, much like Articles for Deletion. There have also been some pages that I would support restoring such as List of people with autism spectrum disorders and New England Independence Campaign. I am not sure if this has been proposed before, though I feel like this should be implemented. Blubabluba9990 ( talk) 21:20, 3 April 2021 (UTC)

Note that Wikipedia:Requests for undeletion is meant for articles that were deleted via WP:PROD or after AfDs closed as WP:SOFTDELETE. Something like Wikipedia:Articles for deletion/New England Independence Campaign definitely won't qualify. Nsk92 ( talk) 22:40, 3 April 2021 (UTC)

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 ( talkcontribs) 09:16, 5 April 2021 (UTC)

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)
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)
I have. Most users don't use popups though. 🐔  Chicdat  Bawk to me! 11:20, 5 April 2021 (UTC)
@ 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)
FWIW, Chicdat you are showing 'male' now. — xaosflux Talk 12:58, 5 April 2021 (UTC)
  • 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)
  • 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)
  • Oppose as unnecessary and likely to be a magnet for disruptive editing. ƒirefly ( t · c ) 13:17, 5 April 2021 (UTC)
  • Oppose due to it being an unnecessary addition, and a huge potential for edit-warring. JackFromReedsburg ( talk | contribs) 19:42, 10 April 2021 (UTC)
  • 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)

Image use proposal

I'd like to deprecate the use of nude or sexually explicit photographs uploaded by anonymous single-purpose accounts. (This would include both Wikimedia accounts and accounts on other image hosting websites such as Flickr.) I'd appreciate any thoughts or advice on formulating an RfC. Cheers, gnu 57 15:06, 5 April 2021 (UTC)

@ Genericusername57: do you have any statistics as to the prevalence of this condition? Keep in mind that it should only be about local uploads here on the English Wikipedia as any uploads to Commons are outside the scope of enwiki RfC's. — xaosflux Talk 15:26, 5 April 2021 (UTC)
...and I don't see how we can police an unrelated site like Flickr. I know that this is the village pump for discussing vague ideas, but I still think that you should think about this a bit more before starting a discussion. I'm pretty sure that our policies and guidelines already prevent Wikipedia editors from including gratuitous nudity or sexually explicit content, but there are some articles where such content should be expected. Phil Bridger ( talk) 17:44, 5 April 2021 (UTC)
@ Xaosflux: Commons has no rule against hosting mugshots, but the English Wikipedia places limits on their use in biographies of living persons ( WP:MUG). I am proposing something similar: not that we somehow prevent Commons from hosting these photos, but rather that we stop using them to illustrate English Wikipedia articles. As far as statistics go, I'm not sure. Using Petscan to intersect the Commons categories "Human genitalia" and "Self-published work", then subtracting out various art and diagram categories and the "User categories" tree (most photographers with dedicated categories are non-anonymous) yields several thousand files, several hundred of which are in use on the English Wikipedia. Someone better at SQL than I am could probably use Quarry to figure out what percentage of the files in Commons category trees like "Nudity" and "Sex in humans" were uploaded by accounts with fewer than, say, 50 global edits.
@ Phil Bridger: The problem is that we have no way of verifying that the subjects consented to their photos being published on the internet. Commons and Flickr both let anyone with an anonymous throwaway account upload sexually explicit content. For illustrating English Wikipedia articles about human anatomy, medical conditions, social and artistic nudity, etc, there are plenty of high-quality, freely licensed images from reputable photographers and institutions. There's really no need to keep using sketchy amateur snapshots from anonymous randos. gnu 57 14:26, 6 April 2021 (UTC)
Disagree with doing this on enwiki - the proper place to make this decision is Commons (there, I do generally support deleting non-education nudity uploaded by new users). Elli ( talk | contribs) 09:57, 7 April 2021 (UTC)

Audio Summaries

It would be very helpful for many people who are illiterate (~14% of the world), blind, or can't understand the content of Wikipedia pages (simple English Wikipedia is, unfortunately, not heavily updated and contains few articles compared to Wikipedia) if there were short (~1-5 minute) audio summaries of pages at the top that can be listened to. The audio summaries would be created by any confirmed users and then "Audio Summary Reviewers" (new permission) would approve the summaries. I know there are audio recordings of some pages, but this is just a reading of the page as opposed to a summary; a summary would serve a separate, and arguably, more broad purpose. Thoughts? Ajshul  😃 02:01, 6 April 2021 (UTC)

What do you expect people to get from a short audio summary that they can't get from using text-to-speech tools on the first few paragraphs of an article? WhatamIdoing ( talk) 05:12, 6 April 2021 (UTC)
Illiterate people are mostly in countries that dont have great access to the internet. Which you need to access Wikipedia. The priority wouldn't be high, but this could work if enough people would volunteer. Just... dont expect it to happen anytime soon. Arsonxists ( talk) 14:05, 6 April 2021 (UTC)
I also think that for larger articles (for which I foresee this being the most useful), a 1-5 minute audio summary would be extremely helpful for those who can read but just want to gain some knowledge without having to pick through a large article. It can also be great for people who just want to learn something new for fun quickly while doing another task (similar to a short podcast). I also think that for some very long articles about very complex topics (mathematics, sciences, philosophical theories, etc.) if an audio recording with a summary can be provided, it would help a lot of people gain a deeper understanding. By no means do I think that if implemented, audio recordings will appear overnight on all articles, but by developing a framework for this to be possible, I think it would be incredibly helpful; further, with certain permissions needed for posting and reviewers needed to approve, I foresee few problems arising from this: only upsides. Ajshul  😃 17:04, 6 April 2021 (UTC)
That is, mostly better reasoning. Audio transcripts do exist already (solved the illiteracy problem), so I think a text based summary would work better. Also, I don't think that the permissions would be nessecary for a text based summary system and way too infuriating, as audio is way harder to make new versions of then text. Arsonxists ( talk) 18:32, 6 April 2021 (UTC)
I think a text based summary would work better that is what the MOS:LEAD is supposed to be... Elli ( talk | contribs) 22:44, 7 April 2021 (UTC)
Agreed, which is why I think audio would be best. An audio summary would allow people to learn about the subject without having to devote their entire attention to reading. As for the revisions, the audio would only cover a broad summary and not any extremely new or controversial information; similar to what is currently being done with Spoken Wikipedia. Ajshul  😃 22:41, 8 April 2021 (UTC)
Perhaps you can work with some people at Wikipedia:WikiProject Spoken Wikipedia on this idea. isaacl ( talk) 19:27, 6 April 2021 (UTC)
I don't see why a new permission would be necessary here. Elli ( talk | contribs) 09:56, 7 April 2021 (UTC)
This isn't even a problem (we have something called a "lead" that summarizes the content of the article, and readers can use TTS tools if they need help reading the lead. (Illiterate or blind people most likely aren't reading WP) Lettler hellocontribs 14:48, 10 April 2021 (UTC)
Lettler, blind people most likely aren't reading WP Blind people read and edit Wikipedia. They even have their own usergroup: Vexations ( talk) 16:02, 10 April 2021 (UTC)
I did not say that there were no blind people reading or editing WP. Either way, they are a minority of our readers and editors, so they most likely should just use an external TTS tool if they need help reading articles. Lettler hellocontribs 01:29, 11 April 2021 (UTC)

Watchlist/Notifications for specific sections

Please let me know if this is already a feature, but I think it would be incredibly helpful if a user could add a specific section of a talk page or other discussion-based page (like this one) to their watchlist. This would make it so they don't see notifications pertaining to different sections that they may not care much about. Ajshul  😃 02:12, 6 April 2021 (UTC)

@ Ajshul, please see Wikipedia:Talk pages project. WhatamIdoing ( talk) 05:12, 6 April 2021 (UTC)
This is a long-term wish list item, see phab:T2738 for more on it. — xaosflux Talk 14:29, 6 April 2021 (UTC)
@ Ajshul: This is being worked on as part of DiscussionTools, see phab:T263820. In the interim, User:Enterprisey/section-watchlist provides the same functionality as a user script. – SD0001 ( talk) 16:29, 6 April 2021 (UTC)
@ SD001 and @ Xaosflux – my apologies. I was not aware of these projects.

Obtaining BLP photographs from their subjects

Wikipedia articles about living people tend to have portrait pictures in the infobox that are rather low-quality compared to what one would expect on the internet in 2021, or in many cases no picture at all. I suppose this is due to the difficulty of finding a freely-licensed image given that Wikipedia lacks professional photographers. (The exception is government officials, who tend to have official portraits.) I wonder if any thought has been given to creating a streamlined way for subjects of BLP articles, or their representatives, to contribute a freely-licensed image to Wikipedia for use on their article, and then advertising this in some way. While some subjects are doubtless too busy to entertain such a request, given the ubiquity of Wikipedia in today's world I would be surprised if no BLP subjects were willing to contribute an improved picture for use on their article. CapitalSasha ~ talk 22:55, 7 April 2021 (UTC)

@ CapitalSasha: there is Wikipedia:A picture of you. I agree that the process should be improved. Elli ( talk | contribs) 23:16, 7 April 2021 (UTC)
Thanks, I wasn't aware of that page! I wonder if a dedicated email address could be set up, connected to OTRS somehow, so that all was required was to send an image attached to an email. That would be a lower barrier to entry. CapitalSasha ~ talk 00:41, 8 April 2021 (UTC)
@ CapitalSasha: that sounds like quite a good idea. Elli ( talk | contribs) 01:23, 8 April 2021 (UTC)
@ CapitalSasha and Elli: There actually is a dedicated email address set up and connected to OTRS: See Wikipedia:Contact us/Article subjects for the details. Given that it was so hard for people to find this, it's probably not being used to its full potential, but it is there. Vahurzpu ( talk) 01:04, 12 April 2021 (UTC)
@ Vahurzpu: thanks - I've added this to Wikipedia:A picture of you (see the section "By email"). Elli ( talk | contribs) 01:20, 12 April 2021 (UTC)
I didn't know until now that the page Wikipedia:A picture of you exists but it surprises me that the page doesn't mention the simplest way someone can provide a free picture of themselves. Many people maintain personal webpages and have photos of themselves posted there. They almost always own copyrights to those photos. All they need to do is post a note at their webpage saying that the copyright for a particular photo is being released under a suitable free license (like CC-by-sa 4.0), with the necessary basic info (where and when the photo was taken). Then any other Wikipedia editor can upload the photo to Commons or to Wikipedia directly. I think that's easier than asking BLP subjects to upload their photos to Commons or to e-mail something somewhere. Nsk92 ( talk) 01:40, 12 April 2021 (UTC)
@ Nsk92: feel free to update said page. It could certainly use some help. Elli ( talk | contribs) 02:03, 12 April 2021 (UTC)

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)

I don't see a problem this solves. Elli ( talk | contribs) 05:27, 8 April 2021 (UTC)
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)
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)
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)
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)
  • 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)
    • Thank you, but Twinkle is merely a collateral benefit, not the main reason. DePlume ( talk) 17:31, 8 April 2021 (UTC)
      • 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)
        • 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)
          • 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)
  • 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)
    • Current RfCs are listed at Wikipedia:Requests for comment/All. PrimeHunter ( talk) 14:13, 12 April 2021 (UTC)
    • 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)
      • 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)

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? ~ HAL 333 01:44, 10 April 2021 (UTC)

@ HAL333: it is actually very difficult - see many many open tasks related to that idea though. — xaosflux Talk 09:14, 10 April 2021 (UTC)
This has been implemented on the mobile version. Sungodtemple a tcg fan !! 1 ! 11 !! ( talk) 00:22, 11 April 2021 (UTC)

Identifying extra line breaks

One of the most common errors I see in stubs and similar pages is erroneous instances of double line breaks. Surely there's some way to automatically identify this and flag pages that might have the error for review? {{u| Sdkb}} talk 03:53, 10 April 2021 (UTC)

I think there's already a bot that does it. It might also be a built-in WP:AWB task. Ivanvector's squirrel ( trees/ nuts) 14:03, 10 April 2021 (UTC)

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?


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)

  • 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)
    • Well, looks like my principles and the Wiki's principles are conflicting here. I'd prefer improvement, but the Wiki prefers openness, likely because they don't want people complaining that Wiki editors are a vested community. Sungodtemple a tcg fan !! 1 ! 11 !! ( talk) 19:13, 11 April 2021 (UTC)

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)

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

WikiProjects that link to articles in their talkpage banners

This has been a minor annoyance to me, so I'm wondering if there's any opposition to this. Special:WantedPages is pretty much useless because talkpage banners, for example {{ WikiProject Northern Ireland}}, link to articles such as Shauna Gunn (which is, for the record, salted). Not only does this make WhatLinksHere of those pages useless, it makes WantedPages useless, as it mainly tracks what happens to be linked in WikiProject banners.

Additionally, this slows down loading (though small, it can add up) of any pages tagged with the banner, since it pulls in information that hardly anyone on that talkpage cares about.

Therefore, I would suggest that WikiProject banners are not allowed to include lists of tasks in them, and must instead only link to such lists. Elli ( talk | contribs) 20:57, 11 April 2021 (UTC)

@ Elli: I suggested that at Wikipedia talk:WikiProject Council/Archive 21#Proposal: Disallow transcluded to-do lists in 2015. There was support but also a suggestion of wider notification about the discussion. That wasn't done and the discussion died without action. I don't want to spend time on this now but others are welcome to use content from my post if they revive the issue. PrimeHunter ( talk) 22:21, 11 April 2021 (UTC)
@ PrimeHunter: seems like it gained support so... would an RfC be necessary, or simply asking the relevant WikiProjects? Elli ( talk | contribs) 22:23, 11 April 2021 (UTC)
@ Elli: An RfC may be best. It affects many other users than the WikiProjects which use the system. PrimeHunter ( talk) 22:36, 11 April 2021 (UTC)
@ PrimeHunter: ugh, that means I have to do writing :( I'll probably start one later this week, then Elli ( talk | contribs) 22:38, 11 April 2021 (UTC)