Wikipedia:Village pump (idea lab)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Theleekycauldron (talk | contribs) at 23:14, 4 May 2022 (→‎A solution to the template graveyard of retired users: and removal). 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 
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, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56


Removing the requirement to specify NAC, and allowing non-admins to close AFD's as "delete"

Challenging closures already states that a close will rarely be changed by either the closing editor or a closure review if the complaint is that the closer is not an admin. Given this, requiring non-admins to specify that they are a non-admin when closing discussions is not helpful, and contributes to the perception of adminship being a seen as a big deal. I note also that many of the best closers are not admins, such as Paine Ellsworth for RM's, and Mhawk10 for RFC's.

The possible exception to this is WP:AN and WP:ANI, as given the nature of the board whether an admin closed a discussion may be relevant.

Similarly, I believe it may be beneficial to allow non-admins to close AFD's as "delete", with a new CSD criteria to support that. This would be similar to the current process for RM's, which allows non-admins to close RM's even if they are unable to implement the move themselves, and would not be a significant change from the current situation where non-admins can close discussions as redirect. BilledMammal (talk) 06:02, 3 April 2022 (UTC)[reply]

As far as I know, there is no formal requirement, and editors close discussions all the time without specifying if they are an administrator. Regarding closing deletion discussions as delete, it's a perennial question where the consensus to-date has been that it duplicates effort that the admin implementing the close would have to do in order to take responsibility for their actions. isaacl (talk) 06:27, 3 April 2022 (UTC)[reply]
There is a requirement to mark RM's that are closed by non admins, but you are right - it seems that is the only area where it is required. I didn't realize the deletion discussion was a perennial discussion (it's not listed at perennial proposals), but it seems that objection could be addressed by making the closure responsible for the deletion, with the admin who responds to the CSD only being engaged in non-controversial maintenance tasks. BilledMammal (talk) 07:32, 3 April 2022 (UTC)[reply]
Is there some XFD backlog that is beyond the capabilities of our current admins? --Redrose64 🌹 (talk) 07:39, 3 April 2022 (UTC)[reply]
It's not really a matter of questioning the capabilities of admins. It's just experienced non-admins who want to help whether or not there's a backlog, or it's about editors who want to gain more experience with an eye on becoming an admin someday. And it's about whether or not it's necesessary to declare oneself a non-admin when that's not really supposed to be much of an issue. P.I. Ellsworth - ed. put'r there 08:42, 3 April 2022 (UTC)[reply]
To-date, the response to that has been that administrators are the ones who face consequences for their use of administrative privileges. Also frequently proposed is a user group with permissions to delete pages who could close deletion discussions. So far, community consensus is that the abilities to delete, view deleted pages, and block users form a core set of privileges needed to make decisions involving these actions. isaacl (talk) 07:52, 3 April 2022 (UTC)[reply]
(edit conflict) Yes, that should be made clear. It is the closer who should be accountable for actions that result from the closure. My question, though never asked until now, has always been about the statement at Wikipedia:Non-admin closure that goes, For practical purposes, non-administrators should not take formal action in discussions whose outcome would require the use of administrator tools... – always wondered why? In all these years there has never been an instance where an admin has not helped me with edits, closures and with explanations when they were needed. There are always ways for non-admins to use the tools by getting admins to actually make the edits. That's an excellent way to learn the ropes here. While it is true that admins are always held responsible for their tool usage, it is ultimately the closer who is responsible for their closures and implementations, whether or not they actually have the tools. Thank you, BilledMammal, for bringing this up, because I doubt if I'm the only editor who would agree with this idea yet who wouldn't mention it until and unless someone else does. Guess it's the Wikignome in me. P.I. Ellsworth - ed. put'r there 08:01, 3 April 2022 (UTC)[reply]
First off, thank you for the ping and the compliment; I'm flattered by your description of me.
Getting to the substance: there's an RfC that happened around 2013 which ended with the conclusion that the sole reason for overturning a request for comment can never be summarily overturned on the basis that the closer was not an administrator. There's not obviously any WP:IAR exception (if a user wrote X, and X is without substantial flaw, then a then it doesn't matter whether or not that user has a mop). When there's a substantial flaw in the closing summary, the only thing in my mind that matters is the substance of the writing, not the technical privileges that the user has. Even a panel of three of the most experienced administrators on Wikipedia had a close of theirs overturned after non-admin S Marshall succesfully filed a close challenge. This is not to say that the median admin doesn't have a good understanding of policies and guidelines—the median admin is much more knowledgeable about them the average non-admin—but it's to say that sometimes the experienced non-admin can get it right even when a panel of admins get it wrong. It's also that closing RfCs can be hard, even very hard, because of the vast span of Wikipedia policies and how WP:CONLEVEL comes into play. S Marshall is exceptionally adept at closing RfC's (I would say moreso than the majority of admins) and is not representative of the typical user.
With respect to deletion, it's technically possible to create a new usergroup that has access to delete articles but not block people. The current guidance on deletions, per WP:NACD is that Non-administrators should limit their closes to outcomes they have the technical ability to implement; for example, non-admins should not close a discussion as delete, because only admins can delete pages. This seems reasonable to me, since letting people without the ability to delete pages close AfDs as delete would simply add onto the CSD backlog. This doesn't seem like the most time-efficient way to do things; having one editor close a deletion discussion and a second editor do the deletion seems inefficient to me. The question I think that's worth considering in the field of deletion is whether or not we, as a community, want to have a role that allows people to delete pages but not to block people nor perform other sensitive administrator tasks. And, if we do, the extent to which the community should vet these users before they are granted the role seems like a reasonable discussion to have. — Mhawk10 (talk) 07:43, 3 April 2022 (UTC)[reply]
Having two editors involved in editing happens all the time. Can't tell you how many edit requests I've made, how many technical page moves I've requested, it happens quite a lot. I see it as part of being an admin means using the tools to help other editors to make improvements. If efficiency is such a problem, then the solution would be to make every editor an admin so they don't have to bother others to get their editing done. And of course, that's not gonna happen. P.I. Ellsworth - ed. put'r there 08:12, 3 April 2022 (UTC)[reply]
I don't think that efficiency is the be-all-end-all, but from a segregation of duties perspective I don't see much of a benefit to having two separate people delete AfDs. In the current deletion workflow, an admin reads the AfD, makes a determination on consensus, and then actually deletes the page. There's even a nice script that lets people do this in one go. With two people, the non-admin reads the AfD and its comments, makes a determination of consensus, and then tags the relevant pages under CSD. A CSD-patrolling admin then comes along, reads the closure of the AfD to make sure it isn't insane, and then performs the deletion. There's a small benefit with the admin doing the whole thing in terms of total time used, since no work is really duplicated (although at the expense of a second set of eyes on the AfD closure).
The main thing that I think would come up is that deletion is one of the most fraught areas of the administrative side of the encyclopedia and the community (from my understanding) tends to want to vet people before they go around deleting articles wholesale in close-call scenarios. I also think that there would be less disruption (i.e. time and effort wasted from challenging bad closes) in the current process relative to one where Randy in Boise decided to close an AfD as delete where a merge or a "no consensus" was the appropriate outcome. And, as S Marshall points out below, there are some other systemic risks that would be amplified in the absence of a vetting process.
Having a role that allows a user to delete pages but doesn't allow them to block people seems to be tailored towards both direct workflow efficiency and preserving the existence of a thorough vetting process. The drawbacks I've heard for this idea are that this would lead to fewer administrators and that the vetting process could itself be inefficient (see: RFA disasters). — Mhawk10 (talk) 08:39, 3 April 2022 (UTC)[reply]
This isn't to say that the vetting process is perfect—it's not even perfect at stopping socks—but it's a risk reduction approach that is aimed at preventing bad people from getting advanced permissions. — Mhawk10 (talk) 08:44, 3 April 2022 (UTC)[reply]
All things considered, the vetting process does seem to work pretty well. In all these years I've only come across two admins who were "questionable", and I learned from them, too, anyway. And I think they learned some things, as well. The vast majority of admins (and probably all of 'em in this present moment) are knowledgable, helpful and trusted. Still though, I don't really understand how non-disclosure would help unscrupulous editors game the system. I don't see how an undisclosed non-admin who closes an AfD and slaps a SD on a page would in any way disrupt the system. One thing I DO understand is that there are some things we don't really want to talk about, because we don't want to give out any "bad ideas", so feel free to ignore that part of my response. My understanding of your and S. Marshall's ideas is not crucial to whether or not I love to edit Wikipedia. P.I. Ellsworth - ed. put'r there 09:01, 3 April 2022 (UTC)[reply]
In terms of there are some things we don't really want to talk about, because we don't want to give out any "bad ideas" I'm not really sure what this is supposed to convey except WP:BEANS, but I feel like I'm missing something. Anywho, my comment you appear to responding to focused on closing AfDs as delete rather than the question of how to handle RfC/RM disclosures. I generally think that the tag at the end of the closures serve little utility. The main thing that matters to me is whether or not the summary fails to accurately reflect the discussion and/or appropriately ascertain consensus in light of relevant policies. With respect to these, the closing summary should be able to speak for itself. The only time where the user themself matters is if they've made an involved close. — Mhawk10 (talk) 16:47, 3 April 2022 (UTC)[reply]
For deletion, while it would add the CSD backlog, I don't see it as an inefficient use of time; an admin confirming that an AFD has been closed as delete and deleting the article takes less time than determining consensus, closing the discussion, and deleting the article. BilledMammal (talk) 11:58, 3 April 2022 (UTC)[reply]
Guess the bottom line for me is, just because I'm a non-admin doesn't mean I can't get the job done. When I need the tools, I make a request for an admin's help. I make an edit request, or I slap an SD on a page after closing a deletion discussion. Of course the admin is going to check the deletion discussion to make sure it's proper, and that's expected. That's SOP. The vast majority of edits (thank goodness!) can be made by a non-admin without the help of an admin. And when necessary, a non-admin can, with the help of an admin, use the tools and make any edit on Wikipedia that's possible. As much as I don't mind declaring I'm a non-admin, I really don't see why it's necessary. P.I. Ellsworth - ed. put'r there 08:29, 3 April 2022 (UTC)[reply]
  • We have some comedians, on Wikipedia, who would love to take it on themselves to close discussions with their own alternative accounts. Don't remove the disclosure requirement. It would be easily gamed.—S Marshall T/C 08:34, 3 April 2022 (UTC)[reply]
    • I don't believe removing the requirement to disclose in RM's that the closer is not an admin will impact that. BilledMammal (talk) 11:58, 3 April 2022 (UTC)[reply]
No thank you. Admins being closers of AFD discussions especially is one of the core things that makes an admin an admin. casualdejekyll 12:45, 4 April 2022 (UTC)[reply]
Yes, I agree and I don't think anybody is trying to take these core functions away from the important things that admins do. Take a look for example at Wikipedia:Miscellany for deletion/Draft:2022 West bengal Municipal election; that's an MfD, and similar things happen at AfD as well. They really aren't something that admins need to spend time on when there are so many much more important and difficult decisions we trust them with. Point is, what difference did my disclosure that I'm a non-admin make? There might be some small advantage to it, and it's just not that big a deal either way, so why make it necessary to disclose it? If there's something I'm missing, I'd love to learn it! P.I. Ellsworth - ed. put'r there 17:48, 4 April 2022 (UTC)[reply]
This seems more like an WP:IAR scenario than a scenario that actually requires a changing of the rules. casualdejekyll 18:44, 11 April 2022 (UTC)[reply]
  • I'm not particularly keen on this. I've closed a few AFDs when the article had already been deleted and it's just a matter of cleanup, but I don't see the point of having people close AFDs as "delete" when they can't carry out the action. It simply creates a different backlog for admins to monitor. Mangoe (talk) 20:28, 4 April 2022 (UTC)[reply]
    It also doesn't save any work. I'm not going to delete a page just because somebody told me to. By the time I've analyzed enough of the AfD to convince myself that the NAC delete request is valid, I might as well have just closed it myself. -- RoySmith (talk) 22:08, 4 April 2022 (UTC)[reply]
    In some cases it saves work, as in those already mentioned. In other cases, while it doesn't save work, if it's done correctly then it doesn't make extra work for you. This has the benefit of helping an editor prepare to be an admin, or to just gain experience as a closer. If it is done incorrectly, then the benefit is an education for the closer. Admins are crucial to this project; it couldn't be done well without them. One of their important jobs that I've seen most admins take very seriously is to educate me when I've messed up. Such errors and corrections have made me a better editor, a better closer, a better non-admin. Where would we be if all educators took the stand, "I might as well have just closed it myself"? If you've not found any errors, then you can take a second to commend the non-admin closer, and if you did find something amiss, then you can take a minute to educate the closer. Where exactly is the downside? P.I. Ellsworth - ed. put'r there 05:09, 5 April 2022 (UTC)[reply]
    @Paine Ellsworth it does take longer than it would otherwise: in the same way that a DRV review takes me longer than an AfD review. I'd need to review the AfD and a close. Sometimes that's 20 seconds extra, but often significantly longer. Any AfD that I needed to revert the close on would take significantly longer than a minute. Much longer, for the double check any reverted action gets, then the time to undo and reclose, then the comments to the editor.
    Now you can still feel it's worthwhile, but please don't understate the downsides. Nosebagbear (talk) 19:29, 7 April 2022 (UTC)[reply]
    To editor Nosebagbear: thank you for this! I don't want to do that; don't want to understate the downsides. This is an education for me. I can't possibly know all there is to know about being an admin, never having actually been one. So thanks again. In your mind, with a closer's eye on such downsides, how do they compare with the upsides mentioned here? From my point of view the comparison does still favor the nom's idea, just not quite as favorably as before I read your words above. How do you think the ups compare with the downs? P.I. Ellsworth - ed. put'r there 22:56, 7 April 2022 (UTC)[reply]
  • Count me as one who thinks that non-admins should not close AFD discussions as delete - deciding on an action that they cannot implement. The person who makes the decision that an article should be deleted, and the person who actually deletes it, should be the same person, and should be someone who has been authorized by the community to make that decision. I agree with Roy Smith that by the time an admin has reviewed the "delete" recommendation and decided whether it is valid, they might just as well have been the primary closer. In any case, I don't see any real need for such a change. There does not appear to be a huge backlog of AfD discussions languishing for want of someone to close them, at least not where articles are concerned. Most discussions are closed on the same day they become eligible for closure, and the few that aren't are far too complex for a non-administrator to attempt. -- MelanieN (talk) 00:41, 8 April 2022 (UTC)[reply]
  • I agree with the above in that an AfD close as delete as a non-admin is redundant; currently it is not outright banned for a non-admin to close as delete, it is heavily discouraged, as Roy stated above it doesn't really alleviate administrator workload. The status quo works fine, considering the XfD backlog doesn't get full very often. Curbon7 (talk) 03:16, 8 April 2022 (UTC)[reply]
  • I have performed a couple of non-admin delete closures. What happened in those cases was that the article was deleted by an admin for copyvio. The non-admin close was therefore just a formality to close the AfD. Hawkeye7 (discuss) 05:44, 8 April 2022 (UTC)[reply]
Yes, in this case where the article has already been deleted, usually as a speedy delete for some reason or other, then anyone can close the discussion, with appropriate explanation that the article has already been deleted and why. As you say, it is a formality. The admin who deleted it may not even have been aware that there was an AfD. -- MelanieN (talk) 14:41, 8 April 2022 (UTC)[reply]
  • On the first half of this, there should not be any requirement to tag a closure by NAC. I'm not sure when that practice begun, but it's just silly; any experienced editor in good standing should be able to close most discussions, and shouldn't have to wear the badge of shame for not being an admin when closing it. On the second part, notice I said "most". This topic comes up every so often, and I still (as I have every time in the past) think that there's no practical reason for a non-admin to close a deletion discussion as delete if they can't actually delete the article. Closing as "keep" is fine; they don't have to do anything. For a purely pragmatic and workflow-related reason, if you can't enact the results, don't close the discussion. Any admin who would delete the article would need to read and assess the consensus anyways (best practice to make sure you're doing it for a good reason) and at that point, they can close it as well. It saves no one any work for a non-admin to close a discussion as delete and then fetch an admin to do the deleting. It's cumbersome and not helpful to anyone. This has nothing to do with trust, it's just a pragmatic issue that it isn't helpful. --Jayron32 14:49, 8 April 2022 (UTC)[reply]
  • It seems there may be a consensus for removing the first, but no consensus for the second.
I think an RFC will be needed for to implement the first, and I propose the following question: "Should all requirements for non-admin closers to state that they are not an admin in their closure, such as at WP:RMNAC, be removed?" BilledMammal (talk) 03:05, 23 April 2022 (UTC)[reply]

Equity considerations for notability

Background on my thinking: I've been thinking about this topic for months, informed by creating 200+ articles.

Background on the topic: The world favors certain demographics, and disfavors others. Race, gender, nationality, sexuality and most social factors make it easier for certain people to get noticed, to get media attention. I assume I don't need to provide citations and links and that we're all agreed that there is bias in Wikipedia that is replicating or mirroring the bias in the world.

To define the problem: Wikipedia seems to, for the most part, see itself as neutral. The world is unequal, it's not Wikipedia that is creating inequity, we're just reflecting it. There are exceptions, such as the Women in Red project that is making a great effort to reduce gender bias. But modern thinking on equity is that being neutral is to be part of the problem. It's not enough to be not biased, we need to work to be anti-biased.

A solution?: So here's my concept of an idea that I really want editors to critique and hopefully improve: there should be guidance that allows notability criteria to be considered through a lens of equity. For example if WP:ARTIST says that to be notable, an artist needs to be in the permanent collection of multiple museums, but the artist is an Aboriginal women in Australia, maybe we could consider that being in the permanent collection of one museum could be a fairer measure.

If WP:AUTHOR needs multiple reviews in journals, but the author is a woman in a country that rank in the worst 10% for gender equity, we might relax the rules for her.

These examples are both inspired by recent articles for discussion debates that I've been in where we're holding everyone to exactly the same standard, utterly blind to the much higher bar that many people face based on their sexuality, gender, race or luck of birth.

Is there a way we can introduce equity guidance for a fairer wikipedia?

This is my first proposal, so please be kind if I have erred in any way. CT55555 (talk) 12:46, 13 April 2022 (UTC)[reply]

  • So, there are three different issues here. 1) Ignore the SNGs. They are beyond worthless, and give little to no useful guidance on what should and shouldn't be created as a stand-alone articles. You've highlighted just one reason, but the problems with the various SNGs are legion, and beyond the scope of this discussion to get into. 2) WP:GNG is a better measure of when to create a stand-alone article. It says, in essence "We need high-quality source material from which we can research a subject in order to build an article". Let's take your aboriginal artist. Pretend Wikipedia doesn't exist for a second. Where can I learn about them, their works, and their life story? If the answer is "I've got a bunch of great texts for you to read from", then yes, you have the basis to create an article. If your answer is "Basically nowhere", then how do we build a Wikipedia article about that person? 3) You are essentially correct on the equity issues facing Wikipedia, but there are better ways to approach this than writing about subjects for which there is no source text to refer to when building a Wikipedia article. The equity and bias issues with regard to Wikipedia article creation is that lots of great underrepresented topics do have lots of source text we can go to. Those topics are ignored in favor of, say, the standard DWEM subjects we often focus on. My advice is, instead of seeking to lower Wikipedia's standards so we can include poorly referenced articles containing lots of text that we have no means of verifying, we should instead focus on seeking out subjects that we could already be building articles about, but are not. --Jayron32 14:19, 13 April 2022 (UTC)[reply]
    Trying to write articles about people without good source material is obviously a silly endeavor, because it would be difficult or impossible. I think the sort of logic I'm suggestion can only work with more shades of grey examples than someone with no body of works to draw upon. And I think my argument really is only applicable if we don't take your advice to ignore SNGs, because they do form the basis of many discussions/decisions at Articles for Deletion.
    So maybe an example where this could be useful is where an artist, for example, is mentioned a lot in good sources, mainstream media, or good books has lots of brief mentions about their poetry, book, film or play, but none are the depth of coverage we look for. So there is enough to make a profile, but it's pieced together from verifiable details. In that scenario at Articles for Deletion, the SNGs are the benchmarks and if someone has a piece of art in 1 or 2 national galleries, if someone's book is reviewed by 1 or 2 book reviewers, are the decision points on which articles get kept or deleted on.
    So if you and I could agree that SNGs are flawed but we should try to make them better, would this be an improvement to them, for this kind of scenario? CT55555 (talk) 14:38, 13 April 2022 (UTC)[reply]
    So, the situation is this with the GNG, notability, and AFDs. It has rarely happened where an article is written that is well-referenced to the proper sources, is of sufficient depth and length, and then gets nominated for deletion, and even less rarely does it actually get deleted. 99% of the time, the situation happens that a poorly referenced, stubby article about someone, like say your Aboriginal artist, gets nominated for deletion, and then people who think we should keep the article either a) have to scramble to find source material or b) level accusations of bad faith and bias against people who nominated it for deletion. Neither are particularly helpful ways to build the encyclopedia, and it all stems from building an article in the wrong order. First, gather the sources, then write the article while citing the sources the whole way. rarely, if ever, does anyone complain when that happens. --Jayron32 14:44, 13 April 2022 (UTC)[reply]
    Just for the record, none of these examples are about articles I have created. But I have been often been the person who scrambles to try to save articles. About bias, my reading of this is that all have bias, although I'd consider it counter-productive to point that out to an AfD nominator. Maybe I should make a proposal that points out the over/under representation of articles at AfD based on demographic data of biographical subjects :-)
    Anyway, although I think we're not agreeing on my main point, I do agree with your suggesting about just creating more articles about people on topics that are missing. I do welcome any examples of topics that you have to suggest. CT55555 (talk) 14:53, 13 April 2022 (UTC)[reply]
    I agree that equity is a major problem. What I don't agree is that the problem is solved by allowing the creation of substandard articles. We solve the problem by creating better articles about under-represented subjects. Letting articles slide on lower standards of referencing and verifiability is not useful, and would only exacerbate equity problems, not ameliorate them. --Jayron32 15:50, 13 April 2022 (UTC)[reply]
    I hadn't seen my idea thought that lens, but I take your point. I wonder if I'm looking in the wrong direction then and the answer is to incentivize or motivate others towards the creation of such articles. CT55555 (talk) 16:01, 13 April 2022 (UTC)[reply]
    Incentivizing the creation of articles is the realm of various Wikipedia-adjacent organizations. As just one really good example, we have Wikipedia:WikiProject Women in Red, a group that works towards correcting gender imbalance in Wikipedia by creating high-quality biographical articles about women. There are various other things like Wikimedia chapters that work locally to build up Wikipedia editors from local cultures; by increasing representation of editors at Wikipedia, we increase the number of articles these editors will be interested in writing on under-represented topics. There are various edit-a-thons that are organized to help improve articles from many (often under-represented) topics. Ultimately, insofar as the problem of under-representation in Wikipedia articles is one of culture at Wikipedia, and not of policy, then we can only fix the problem through solutions of a cultural nature, like the ones I listed here (among others). Policy by itself can't fix culture. My argument is that the policy is sound policy when our goal is to create a high-quality, well-referenced, verifiable encyclopedia. The fact that that the culture among the Wikipedia community undervalues certain topics is not fixed by changing that policy. It's fixed by adding additional culture around inclusion and expansion of access and deliberately correcting the imbalance within the sound policy. --Jayron32 16:16, 13 April 2022 (UTC)[reply]
    I am now wondering if you read all of my initial post... CT55555 (talk) 16:29, 13 April 2022 (UTC)[reply]
    I have read your post multiple times. What parts of my responses have made you feel misunderstood? --Jayron32 16:39, 13 April 2022 (UTC)[reply]
    When you told me about Women in Red when after starting post mentioned them. CT55555 (talk) 16:40, 13 April 2022 (UTC)[reply]
    Gotcha. Yes, we both agree they are a good example. Sorry that I reached for the same example you did. It is hard to find a better group, and perhaps that could serve as a model for starting other ones. I did not mean to give the impression that you had not already recognized them, but I clearly did do just that, and that is all on me. Sorry that I did that. I should not have. Regardless, I still stand by the rest of my post; culture and policy are different things, and at Wikipedia we have broken culture. Policy cannot fix broken culture, and the hard work of fixing culture requires a different tactic. --Jayron32 16:48, 13 April 2022 (UTC)[reply]
    By the way, Women in Red (which I am an proud and active member of), is producing biographical articles about women, using this month as an example, at rate of:
    5 per day (general, discounting upgrades), 0.5 per day (climate) 8 per day (via translation) and less than 0.5 per day (French overseas territories) Totaling about 14 articles per day.
    Of the 1.5 million biographies, 19% are about women. An equal world would mean about 765,000 biographical articles were about women, but only 285,000 are. We're 480,000 short.
    If Women in Red is our best fix, at the rate Women in Red produces articles, it will solve the problem in 93.9 years. That's assuming AfD stops nominating articles about woman at over double the rate it nominates men, despite the low representation of women on wikipedia, 41% of biographical articles about women nominated for deletion are about women.
    My hypothesis: we need to do a more, we need to move a faster. To me, a 94 year plan isn't good enough.
    Yes, culture beats policy, but culture changes as rules and standards are introduced. People didn't start wearing seatbelts until the law required them. We probably need to move the culture needle and the policy needle. CT55555 (talk) 21:03, 13 April 2022 (UTC)[reply]
    As you led off, we should never expect 50/50 balance on male/female articles, because we know historically the coverage of women was far less then men, and that we should not be trying to correct the ratio by including poor quality articles. We can improve the ratio but it will never get a where close to 50%. --Masem (t) 21:48, 13 April 2022 (UTC)[reply]
    Do you have a suggestions for how to get it higher than the status quo? CT55555 (talk) 21:52, 13 April 2022 (UTC)[reply]
    @CT55555 I would also just note that That's assuming AfD stops nominating articles about woman at over double the rate it nominates men, despite the low representation of women on wikipedia, 41% of biographical articles about women nominated for deletion are about women. is not sufficiently clear. Heavily due to the work of both WIR and those who act in a similar vein without being part of the org, of articles created per day, a majority are about women. AfDs are always more likely to be about newer articles.
    Thus while there may well be an issue on the AfD side, what we'd need to consider it is if you can determine and write the like for like comparisons. E.g, for articles made in the last year, how's do the creations/nominations/actual deletions stack up, and how does that change in the 2-3 year bracket, and 3+ year bracket. Nosebagbear (talk) 09:36, 19 April 2022 (UTC)[reply]
    I think the point is that, while articles on males are given the benefit of the doubt, and never make it to AFD, articles on women are much more likely to be scrutinized at an unreasonable level. The fact that 41% of the biographical articles at AFD are about women, and yet a much smaller number of newly created articles are about women, means that on the balance, the same quality article about a woman will end up at AFD more often than if it were about a man. We had a particularly nasty case a few years back where a nobel laureate's article was sitting at AFD while they were winning the Nobel Prize. And even afterwards, people were still trying to argue that wasn't a problem... C'mon now...--Jayron32 11:47, 19 April 2022 (UTC)[reply]
    Here is a link to a peer reviewed paper that analysed a large data set of AfD nominations and concluded that that AfD process is incorrectly used for women's biographies significantly more than men's.
    https://journals.sagepub.com/doi/10.1177/14614448211023772
    I found this at: https://en.wikipedia.org/wiki/Gender_bias_on_Wikipedia
    I think we're way past the point of debating if this is a problem and encourage you to join me in trying to imagine solutions. CT55555 (talk) 15:46, 19 April 2022 (UTC)[reply]
    Regarding that particular article, you might want to read Wikipedia:Wikipedia Signpost/2021-07-25/Recent research. Anomie 21:52, 19 April 2022 (UTC)[reply]
    If we were discussing an article, that response would considered a primary source, whereas mine was a published academic paper. So while I respect the points contained within it, I again plea that we move forward from the "is gender bias a problem" phase and into the "can we please work on solutions" phase. CT55555 (talk) 00:43, 20 April 2022 (UTC)[reply]
    Well, here's one idea for you, @CT55555: Many AFD nominations use Twinkle. Could we make Twinkle 'aware' of which articles are about women? If someone nominates a BLP about a woman, could Twinkle add an extra step/dialog box that says something like "Please make sure that you have done a proper WP:BEFORE search before sending this article to AFD"? (I don't know if it needs to have an explanation like "Articles about women are nominated for deletion about twice as often as articles about men, but they are less likely to be deleted.")
    My idea is that if there are an above-average level of nominations but a below-average level of deletions at AFD, then editors are sending some notable subjects to AFD. If we could encourage them to be a little more careful, we might get closer to the average (which means fewer articles at AFD, but a higher percentage of those articles being deleted). WhatamIdoing (talk) 07:04, 20 April 2022 (UTC)[reply]
    "Here's a paper" "That paper has already been looked at and received significant criticism" "But it's a published paper!" 🤷 Sure. People can get all sorts of crap published, especially in particular topic areas. Without better understanding of the actual parameters of the problem, I think we'll have trouble coming up with (non-politician's) solutions more specific than "interested editors should watch AfD to rescue articles they think can actually pass WP:N". But feel free to run with that one if you want. Anomie 11:24, 20 April 2022 (UTC)[reply]
    I would remind you that I am here asking people to suggest better solutions, soliciting critique, which seems quite different from the activities described in the politicians solutions article.
    Your quotes are not accurate and I request that you score them out. CT55555 (talk) 13:23, 20 April 2022 (UTC)[reply]
    Those "quotes" appear to represent a hypothetical dialog between two people, not the exact words said by anyone in reality.
    Of course, "received significant criticism" is not evidence of actual problems. Sometimes criticism looks more like the advice given in The Greasy Pole: "Some of the main conclusions have been questioned. (If they haven’t, question them yourself; then they have)." Even when a study isn't perfect, it can sometimes give us an approximate idea of reality. WhatamIdoing (talk) 18:24, 20 April 2022 (UTC)[reply]
    I took a quick look at the ration of male to female subjects of articles at Category:AfD debates (Biographical) right now. I was able to determine the value of the P21 property (sex or gender) in Wikidata of 185 of them. 47 are female, 138 male. This is a gross oversimplification of course, but it looks like articles about women are still nominated for AfD more frequently than those about men. Worth looking into how those ratios work out for only living people, recently created articles, etc. Anyone interested in working on that? Vexations (talk) 22:24, 19 April 2022 (UTC)[reply]
    ^I couldn't agree more with what Jayron32 has saved here. Mysterious Whisper (talk) 16:00, 13 April 2022 (UTC)[reply]
    I think that the bit about lots of brief mentions about their poetry, book, film or play, but none are the depth of coverage we look for. So there is enough to make a profile, but it's pieced together from verifiable details is one of the open questions with the GNG. If you have many short independent sources, but it all adds up to enough material to write a fair article, is that okay? Editors have different opinions, and we have never settled the question.
    Obviously, if you have a dozen sources, all of which contain only the fact that "Alice Expert is a cryptanalyst", then that's not enough to write a whole article about Alice. But if you have enough short sources to write a decent, non-stub article, then is it really a problem that one source provides "Alice Expert is a cryptanalyst" and the next source provides "Alice Expert wrote a book" and a third source provides the basis for "Alice Expert is an American", and so forth? Is it really necessary to have a single source providing significant coverage by itself? (WP:CORP claims it is.) WhatamIdoing (talk) 19:53, 13 April 2022 (UTC)[reply]
    To follow onto what Jayron said, remember that the Various SNG provide presumptions of notability. If an SNG allows for an article based on an artist having works displayed permanently in multiple galleries, we are still going to expect in time that secondary sources with significant coverage will be found and added...if they can't be found, we'll still end up deleting the article. So this means it would be reasonable to consider slight allowances of weaker SNG passage for underrepresented people, but with the understanding we still ultimately are looking for significant coverage too, which is applied equally to all topics. --Masem (t) 16:09, 13 April 2022 (UTC)[reply]
  • Have you reviewed WP:WHYN? The notability guidelines aren't just some arbitrary standard, they're the direct result of the nature of Wikipedia as an encyclopedia. Changing the notability guidelines won't make it suddenly possible to write an article without sources to base it on, or to put it another way, changing the words on the page at WP:N won't change the fundamental nature of notability on Wikipedia. The general notability guideline is descriptive, not prescriptive.
    You seem to understand that it's impossible to write a decent article about a subject that doesn't have at least a small body of source material which the article can be based on. In your response to Jayron32's comments, you speak of "shades of grey examples" where there are enough reliable secondary sources to write an article about a subject, but that subject somehow still doesn't pass the notability guidelines. I'm willing to believe, as you seem to, that this is a thing that happens, although I'm not convinced that it's a major problem or that your proposal idea is in any way a viable solution. Can you provide some examples of this, ie, subjects with complete and well-written articles, based on reliable secondary sources, getting deleted at AfD on notability grounds? If you can establish, with evidence, that this is a thing that happens, and that it often happens to subjects that are underrepresented, and that it's a major reason why those topics are underrepresented, then you'll have my full support in finding a solution. As of now, while we can (mostly) all agree that there is a problem here, it seems like a lot of questionable guesswork is being done in ascertaining the exact nature of the problem and in proposing solutions to it.
    I'll also add that it's usually possible to include information from reliable sources on topics that don't warrant a standalone article somewhere in the encyclopedia, as part of a larger article. That way, the information gets included and published for all to see, Wikipedia doesn't get littered with perpetually-incomplete stub articles, and the reader experience is improved, because they get complete and detailed articles rather than many disjointed tiny ones. Mysterious Whisper (talk) 15:33, 13 April 2022 (UTC)[reply]
    I thought this was the place to get a ball rolling and have other people build on it, suggest better ways. Have I misunderstood this space? CT55555 (talk) 15:41, 13 April 2022 (UTC)[reply]
    You're in the right place: you have a the makings of a proposal here, but it's not yet ready for WP:Village pump (proposals). I've given my feedback on your idea. Specifically, I think a proposal to change the notability guidelines will be much more likely to succeed, and accomplish something worthwhile, if its presented in relation to WP:WHYN. I think it would be more likely to succeed if you present a strong case based on verifiable evidence rather than speculation, and I've suggested one form that evidence might take. I have also suggested another way to accomplish some of your goals. I now feel as though this isn't going to go anywhere, however, so I'll cease my involvement. Good luck. Mysterious Whisper (talk) 16:00, 13 April 2022 (UTC)[reply]
    A body of evidence might take me a little while. If you are curious about the anecdotal story that was the trigger to me posting today:
    https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Jeannie_Pwerle CT55555 (talk) 21:53, 13 April 2022 (UTC)[reply]
    And another example https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Munira_Al-Fadhel CT55555 (talk) 05:39, 14 April 2022 (UTC)[reply]
    A third example https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Louise_Crisp_(2nd_nomination) CT55555 (talk) 05:41, 14 April 2022 (UTC)[reply]
I think you may be on to something. There are other measures of "notability" one might conceive of than the number of articles in newspapers that are "about" the subject. I think of that as "critical engagement by domain experts". For me, an artist's inclusion in a significant collection, is more important than a "profile" in Tatler, like something I just saw in an article: https://www.tatler.com/gallery/robyn-ward-exhibition-launch for example. Tatler knows fuck all about art, but the curators at the National Gallery of Australia are highly qualified professionals. We should consider their opinion more significant than that of a celebrity gossip writer. Another thing you could look at is how we consider interviews. We write often write them off as primary sources, but they can provide, and are sometimes the only source of important biographical details. Sometimes piecing together a biography from snippets and primary is possible, and common sense can prevail over blind application of guidelines. It's good those discussions can take place at AfD, and the outcome of those discussions should inform the guidelines that reflect practice, not the other way around. Vexations (talk) 16:54, 13 April 2022 (UTC)[reply]
  • I would like to see some discussion on how WP:RIGHTGREATWRONGS factors into all of this (both positively and negatively). Blueboar (talk) 12:21, 20 April 2022 (UTC)[reply]
    I see that guidance as directed towards editors making decisions about individual articles, not systemic issues. CT55555 (talk) 12:26, 20 April 2022 (UTC)[reply]
    The positive side of RGW is that the closer we bring our biographical article ratio to 1:1 male to female (roughly), the better. There's always going to be a systematic bias from how historical reporting has gone one that will limit that we will never reach 1:1 but we can do better than we do now. Negatively, we do not want to weaken notability to try to improve our equity ratios to a point that we have stubs and start-class articles on women that show no likely chance of improvement and were only created because one source mentioned the person's name with some iffy signs of being important. There's the ideal equity limit we would like to reach, and then there's going to be a practical one, the one that we know we can actually create encyclopedic-quality articles even if short simply due to that systematic bias from sourcing that we cannot change. --Masem (t) 12:39, 20 April 2022 (UTC)[reply]
Here's an idea: Improve participation at AfD. Here's a recent AfD I stumbled upon when looking at the list of women's biographies at AfD that I mentioned yesterday: Wikipedia:Articles for deletion/Shawna Hamic. I have no idea who this is, but one participant? One? Not even the creator of the article cared enough, or knew about the nomination to do anything about it. For starters, new contributors need to be told about watchlisting the pages they create. Then, they need to find a peer group that can help them either fix the article, and present valid arguments at AfD for keeping the article without being accused of canvassing. This too, might be something we'd want to look at a bit more closely. How many AfDs close as delete with minimal participation? Do we need to introduce a quorum? Vexations (talk) 14:51, 20 April 2022 (UTC)[reply]
OK, this is fantastic. Combined with the suggestions about some prompts about gender equity when nominating, perhaps something about doing a real WP:BEFORE this could be good. Thanks for this. CT55555 (talk) 14:56, 20 April 2022 (UTC)[reply]

Creating a mode for infoboxes (abstract/full)

Hi, an infobox is the source of structured data about a concept and is both for humans and machines (in semantic web). For humans, infoboxes should be as abstract as possible and convey only main information to render them to humans "at the first glance". And for machines, it should be as complete as possible, so that machines can answer semantic queries. These purposes seem contradictory. But I have an idea for infoboxes that makes them ideal both for humans and machines

I think the correct policy is: 1-Infobox of an article contains full data as complete as possible (that is for machines), 2-All infobox items are integrated with an additional property, that is, "only for machines"/"only for humans"/"for both" 3-Infobox of an article is shown in "for humans mode" in the default way, to be abstract enough, but it has the capability of changing its mode: i.e. a human can read full infobox data by changing its mode to "for machines mode". When an article is loaded, a full infobox is loaded too, but only some of its items are visible to humans (i.e., those with "only for humans" or "for both" property) at the default mode, but there is an option for viewing it in the "for machines mode".

This way an infobox is appropriate both for humans (convey only main information at first glance), and for machines (contain complete data to answer their queries in semantic web). Please discuss that idea. Thanks, Hooman Mallahzadeh (talk) 10:02, 14 April 2022 (UTC)[reply]

@Hooman Mallahzadeh, take a look at the information at Wikidata and Wikipedia:Wikidata. Wikidata is a database for such information and each Wikipedia article has an entry. Just click on Wikidata item in the menu at the left of the article. StarryGrandma (talk) 20:00, 14 April 2022 (UTC)[reply]
  • I have some quibbles about the premise to this question… while the way information is displayed in an infobox might make it easy for machines to scan and compile our information, that definitely is not the “purpose” of an infobox. I would disagree with saying that our infoboxes are intended to be “for machines”. Blueboar (talk) 21:27, 14 April 2022 (UTC)[reply]
An infobox is one source of structured data, but Wikidata usually provides it in a more machine-readable way, especially if you want to consider large numbers of articles (or even topics with no article on English Wikipedia). Tools such as SPARQL can query Wikidata efficiently to produce, for example, a list of German-speaking composers with an OBE. Certes (talk) 21:48, 14 April 2022 (UTC)[reply]
@Blueboar@Certes@StarryGrandma These semantics are metadata about that article data, and according to

These embedded semantics offer significant advantages such as reasoning over data and operating with heterogeneous data sources.

and

Specifications such as eRDF and RDFa allow arbitrary RDF data to be embedded in HTML pages.

Structured data should be «««embedded»»» within non-structured data, and ««not be redirected»» (e.g., from Wikidata). As I know Tim Berners Lee (the inventor of web) says "embed" metadata for machines within data for humans. Because this convention is not only for Wikipedia articles, but also for the total Web, to promote it to Web 3.0 or Semantic Web. Hooman Mallahzadeh (talk) 03:11, 15 April 2022 (UTC)[reply]
In addition, Wikidata item of an article is not always for a single concept. In current Wikipedia, some articles have more than one concept, e.g. Sine and cosine article. This way, "Wikidata metadata fetching" policy, should be for one of them either Sine or Cosine, and not both of them. But by infobox approach, we can create two infoboxes for each of these concepts, and show/hide one of them (or merge their "for humans" data into a a new infobox). Hooman Mallahzadeh (talk) 03:32, 15 April 2022 (UTC)[reply]
Wikidata solves that problem more simply, by having separate sine and cosine items. It also deals neatly with topics such as archaeologist, where the link to Wikipedia is a redirect to an article on a related topic. That article has no infobox and, if it did, it would describe the topic of archaeology, not of archaeologist. Certes (talk) 10:48, 15 April 2022 (UTC)[reply]
@Certes Does there exist a mechanism in Wikipedia to fetch Wikidata information and embed that data in a machine readable way (e.g., via "Web Ontology Language" (OWL)) in the articles written in different languages for the same concept? Hooman Mallahzadeh (talk) 11:01, 15 April 2022 (UTC)[reply]
Wikipedia:Wikidata#Infoboxes describes the current use in general, and Category:Infobox templates using Wikidata lists the relevant types of infobox. The code tends to be complex, calling subtemplates such as {{Wikidata entity link}} or Lua modules. However, the complexity is mainly aimed at display formatting; the pure data is easily accessible directly from Wikidata via tools such as SPARQL via the Wikidata Query Service (tutorial). Certes (talk) 11:15, 15 April 2022 (UTC)[reply]
@Certes Aside from embedding problem, do you agree with me that, till now, Wikipedia writers are not eager to fill Wikidata items? For example in Factorial Wikidata item, that is, https://www.wikidata.org/wiki/Q120976 there exists no item for «parity, date of invention, growth, approximation, its extensions, and related sequences and functions» that there exists in a unstructured way in the main article. We should use a mechanism to make users eager for filling these parts. Today these items are not filled, so we should alarm users fill these parts in Wikidata as complete as you can, to make the article machine readable.
Let me correct the above scenario, at each article, a machine readable infobox is shown from Wikidata to the user that some of its parts is not filled, and the users easily inspect them and make the machine readable infobox as fill as he can. That is we create a "machine infobox" different from "User infobox" that is hidden by default but users can view that, extract the information they need and fill empty parts, and possibly modify incorrect data. Hooman Mallahzadeh (talk) 11:49, 15 April 2022 (UTC)[reply]
Yes, Wikipedia writers are not eager to fill Wikidata items. But Wikipedia is not a database and, if it were, we wouldn't want to duplicate the information in every language with all the gaps and discrepancies. One way forward is to create a tool to scrape information from infoboxes of English and non-English wikipedias and add it to Wikidata with appropriate attribution. That way, Wikidata will be up to date for everyone, including any infobox designers who wish to draw on it for English Wikipedia. (Such a tool may already exist: this idea is unlikely to be original.) Certes (talk) 11:55, 15 April 2022 (UTC)[reply]
@Certes You are right, "Machine readable infobox" should have items with "label" and "data" parts. Label part is in English or is translated to other languages, but its data part should be some "id" or "url" (not in English).
If you agree with the benefits of creating a separate infobox for "machines" and embedding that machine readable infobox in articles of the same concept in different languages, please alert that to the developers, to implement that. Thanks, Hooman Mallahzadeh (talk) 12:05, 15 April 2022 (UTC)[reply]
@Blueboar@Certes@StarryGrandma As a conclusion, a sperate Machine readable infobox is created and added to all existing articles that its purpose is:

Convert «unstructured data» into «structured data» by that infobox, as much as you can.

Hooman Mallahzadeh (talk) 13:27, 15 April 2022 (UTC)[reply]
Meh. Adding a second infobox would just confuse our editors with no benefit for our readers. I don’t really care about the machines. Blueboar (talk) 13:35, 15 April 2022 (UTC)[reply]
@Blueboar No, it has many benefits for human readers. They know: "what parts of the infobox is free", and "what parts are wrong to modify that". Additionally a normal person (not a machine) may only want, for example, domain of the factorial function and nothing else, which exists only in the second infobox not the first infobox (after making it human readable by a simple process). Note that redirecting to Wikidata is a bad solution becasuse they are not in an infobox and is hard to read, also is not embedded to articles for machines, discussed above. Hooman Mallahzadeh (talk) 13:47, 15 April 2022 (UTC)[reply]
@Blueboar Note that second infobox is «hidden» by default, but the user can view that, so makes no confusion. Hooman Mallahzadeh (talk) 13:50, 15 April 2022 (UTC)[reply]
Um… The entire point of WP is that our editors can modify anything (as long as there is consensus to do so). This includes the information in infoboxes. Blueboar (talk) 14:09, 15 April 2022 (UTC)[reply]

Asides from d:Main there is also DBpedia which tries to structure Wikipedia infoboxes. Hope that helps ~ 🦝 Shushugah (he/him • talk) 20:07, 29 April 2022 (UTC)[reply]

Idea for account security and possible sock prevention

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.

Has there ever been an RfC or discussion to propose the following for new accounts:

  • A new account needs the following to be able to edit:
    • Needs to have a email address attached to it at all times
    • The aforementioned email address needs to be confirmed when added or changed
      • The email in the system stays as the previous email until the next/changed email is confirmed
  • An account's email cannot be changed while the account is subject to a block (to avoid abuse)

...ever been done? I have an idea formulating here, and this is what I have so far. Steel1943 (talk) 20:33, 18 April 2022 (UTC)[reply]

Why add barriers for registered users when we still allow unregistered editors? ~ ONUnicorn(Talk|Contribs)problem solving 20:47, 18 April 2022 (UTC)[reply]
Only one of the two can be controlled to provide accountability. And only one of the two can get user access levels, especially confirmed/autoconfirmed; it makes semi-protection all the more useful. Steel1943 (talk) 21:01, 18 April 2022 (UTC)[reply]
Interestingly there's a thread currently over at Wikipedia:Village pump (WMF) talking about how user data is toxic. I'm absolutely certain there have been several proposals for accounts to have a confirmed email address on this wiki, none of which I can find, but all of which obviously failed. What happens then, you set up a free email address for your account, then never check it again? -- zzuuzz (talk) 21:10, 18 April 2022 (UTC)[reply]
Well, the thing there is the idea of not being able to change the confirmed email address while blocked. That prevents a user, while blocked, to attach a new email account while blocked, causing a obviously passable, but somewhat annoying, barrier of having to create a new email account (if they don't have multiple) in order to sock as an editor with an account. I think I'll read over that discussion on the WMF VP page as well. (But hey, questions like this is why I brought this here instead of just throwing this on WP:VPPROP since I had a feeling there would be some really good rebuttals to this right off the bat.) Steel1943 (talk) 21:20, 18 April 2022 (UTC)[reply]
I think the point here is that it won't stop sockpuppetry. Email services such as protonmail don't even ask for a phone number. If I put myself in a sockpuppeter's shoes, I'd just create a random protonmail account, with which I'll open a Wikipedia account and start editing. You don't even need to remember the email password once a WP account is already created. Having them to connect to an email won't be stopping them from sockpuppetry for which they must already be putting in a good amount of effort. Meanwhile some good faith editors not willing to connect to an email id would get repelled away from creating an account, as they can already edit as IP. CX Zoom[he/him] (let's talkCL) 22:11, 18 April 2022 (UTC)[reply]
Yeah, it's not going to fully prevent socking, but rather make it a lot more inconvenient for sockmasters. It's kind of like a very strong deterrent. And in regards to "repelling good faith editors"; the idea here is to grandfather the current settings of every editor who already has an account prior to these types of changes being implemented. If they gamers grandfathered, editors without an email address could still edit without an email address, but if they ever wanted to add an email address, it would need to be confirmed, and then the editor would be subject to the non-grandfathered rules. And in regards to editors who edit as IPs socking: I'd imagine it's a lot easier to semi-protect an article than determine who's a sock. Steel1943 (talk) 23:13, 18 April 2022 (UTC)[reply]
Accounts are global, blocks are local - I wouldn't want a block on one of the hundreds of projects out there locking up me from ever updating my email address. — xaosflux Talk 23:39, 18 April 2022 (UTC)[reply]
@Xaosflux: "Accounts are global, blocks are local..." Yep, I think we're done here ... that's the nail in the coffin I forgot about. I'm proposing this on the wrong Wikimedia project page, so all of this is kind of moot. If only all blocks were global, this may have had a chance of making sense. Steel1943 (talk) 00:18, 19 April 2022 (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.

Bold list template

Hi there. I'm not sure if this is the right place for this but I'll post anyways. A few months ago, I created a template in my sandbox. It takes a list of items and creates a list where the terms are bolded, but not the commas, for example: foo, bar, or 123 . The idea being, this saves editors from having to type '''foo''', '''bar''' etc. during source editing, or having to manually precisely select each comma to unbold in visual editor. An example where the template would be used is in article leads, where bolded alternate names are given. I haven't moved it to template namespace because 1) I don't know whether the template would be useful, 2) I don't know if a way to do this already exists, and 3) I don't know if I've implemented it efficiently, since I'm not very familiar with template code. Asking for thoughts on the template. Thanks! — Mcguy15 (talk, contribs) 23:05, 20 April 2022 (UTC)[reply]

@Mcguy15 That could probably be implemented more efficiently with a few lines code in a Lua module (and it would work for an unlimited number of list entries), something like:
return { main = function(frame)
	args = {}
	for i, v in ipairs(frame.args) do table.insert(args, v)	end
	conj = "'''" .. (#args > 2 and ", " or " ") .. (args.conj or "or") .. " '''"
	return "'''"..mw.text.listToText(args, "''', '''", conj).."'''"
end }
The code can be simpler if you don't need it to produce Oxford commas. --Ahecht (TALK
PAGE
) 03:54, 23 April 2022 (UTC)[reply]
Wow, that's super cool, thanks! Definitely better than my bodged way of doing it. I'll try to see if I can figure out how add that to {{bold list}} later. — Mcguy15 (talk, contribs) 04:22, 23 April 2022 (UTC)[reply]
Hey, @Ahecht. I tried implementing the code on Module:Bold list and invoking it at Template:Bold list, but it doesn't seem to be working. Would you mind checking whether I implemented it incorrectly, or if it's a problem with the code? Thank you! — Mcguy15 (talk, contribs) 19:29, 25 April 2022 (UTC)[reply]
@Mcguy15 That module, as written, only works directly from an {{#invoke}} statement. If you want call it from a template instead, you have to change the frame.args to frame:getParent().args on line 4. --Ahecht (TALK
PAGE
) 20:19, 25 April 2022 (UTC)[reply]
Thank youMcguy15 (talk, contribs) 20:22, 25 April 2022 (UTC)[reply]
Oh! This was unarchived. I followed the advice of the person who archived this thread and created {{Bold list}}. — Mcguy15 (talk, contribs) 04:19, 23 April 2022 (UTC)[reply]

Improving ways for editors to indicate they are open to adminship

What are some ways we could improve the options available for editors to indicate they are open to going through an RfA? — Ixtal ⁂ (talk) 19:52, 21 April 2022 (UTC)[reply]

Change the name from RFA to VFA (Volunteers for Adminship). Like some other fields, the best candidates are characterized by "Willing to serve" rather than "I want it". North8000 (talk) 20:20, 21 April 2022 (UTC)[reply]
North8000 WOW! That's actually such a great idea I hadn't even considered it. I imagine people might be opposed to change just because it's not status quo but I think your suggestion makes a lot of sense. "Request" feels very uh can I pretty please have tools. — Ixtal ⁂ (talk) 22:06, 21 April 2022 (UTC)[reply]
That's a pretty brilliant reframing, North8000. Schazjmd (talk) 22:11, 21 April 2022 (UTC)[reply]
That renaming neatly moves the emphasis from gaining a privilege to taking on a duty, which might help to encourage good candidates. Certes (talk) 22:21, 21 April 2022 (UTC)[reply]
No thank you. Why? Well then we'd have to move all the current "Wikipedia:Requests for adminship/USERNAME" pages to "Wikipedia:Volunteers for adminship/USERNAME". And it isn't a problem worth solving. We were doing fine with RfA, we don't need to change it. We have promotional articles on this website, and here we're worrying about the name of a venue for discussion??? This just wastes time that could be used to like, improve the encyclopedia? If this was on the main proposals area this thing would be spammed with opposes, I bet you. Cranloa12n / talk / contribs / 00:28, 22 April 2022 (UTC)[reply]
CAT:RFA informs us that there have been roughly 5,000 RfAs throughout wikihistory, successful and unsuccessful. That's a lot for a single person to move around and maybe enough to just get a bot to do it, but hardly grounds for outrage on its own. Dr. Duh 🩺 (talk) 06:48, 22 April 2022 (UTC)[reply]
Per Dr. Duh. It's a matter of hours if done by a bot, which wouldn't waste anyone's time. From what I see in the latest draft of Administrators' newsletter, we are on track to losing 5 Admins to inactivity this month, and gaining only 1 new Admin. A net decrease of 4. So far in 2022, we've had a net loss of 4, 6 and 1 Admins per month. Back in the 2006–08 period there were an average of more than 1 RfA every day to replenish the ranks. Now it's about 2 every month. Administrators do a very important job in maintaining the project. *If* a name change or anything else has the potential to change the picture, we should seriously consider that. CX Zoom[he/him] (let's talkCL) 07:55, 22 April 2022 (UTC)[reply]
No. Rfa will not become better just because we decide to change its name. It will still be the same vetting, the same opposes and supports. Again, if it ain't broke, don't fix it. Cranloa12n / talk / contribs / 13:05, 22 April 2022 (UTC)[reply]
Well, will it be worse, Cranloa12n? — Ixtal ⁂ (talk) 13:09, 22 April 2022 (UTC)[reply]
No, but it's a pointless change. Cranloa12n / talk / contribs / 13:11, 22 April 2022 (UTC)[reply]
Cranloa12n if you wish to oppose a future proposal feel free to do so, but IL is to draft ideas and brainstorm. Not very useful to discourage editors from an idea because you don't see benefit nor harm from the idea in my opinion. — Ixtal ⁂ (talk) 13:39, 22 April 2022 (UTC)[reply]
There is nothing to draft here. The proposal to change the name is simply redundant. Cranloa12n / talk / contribs / 13:41, 22 April 2022 (UTC)[reply]
if it ain't broke, don't fix it General consensus for a few years now seems to be that it is indeed broken. Anomie 15:48, 23 April 2022 (UTC)[reply]
The process is broken, yes; but its name isn't the root cause of that breakage. --Redrose64 🌹 (talk) 18:44, 23 April 2022 (UTC)[reply]
User:Ahecht/Scripts/massmove could move them all in about 5 hours if you just pasted in the list and let it run. --Ahecht (TALK
PAGE
) 03:13, 23 April 2022 (UTC)[reply]
Half a Scorsese movie, Ahecht! :D — Ixtal ⁂ (talk) 09:02, 23 April 2022 (UTC)[reply]
There's nothing in the idea that requires retrofitting history or renaming everything that happened in the past. Schazjmd (talk) 15:42, 22 April 2022 (UTC)[reply]
@Cranloa12n Why would we have to move past RFAs? ~ ONUnicorn(Talk|Contribs)problem solving 20:20, 22 April 2022 (UTC)[reply]
It's hard to indicate you are open to an RfA without appearing to be a hat collector. I seem to recall one prominent editor had a list of things that would disqualify someone from being an admin, one of them was having a userbox such as {{User wikipedia/Administrator someday}} on their user page. --Ahecht (TALK
PAGE
) 22:22, 21 April 2022 (UTC)[reply]
VfA could be either of two things. It could answer Ixtal's question by being a better precursor to RfA than the userbox. Alternatively, it could be a rebranding of RfA, which might solve an important related problem. Certes (talk) 23:19, 21 April 2022 (UTC)[reply]
I like the idea of the whole process being rebranded. Even though it doesn't (of itself) change anything (yet) about how admin permissions are assigned, that one word difference in the name casts it in a different perspective. And maybe that different perspective might lead to more of us being more open to other improvements to the process. Schazjmd (talk) 23:34, 21 April 2022 (UTC)[reply]
In the dark ages, people who were ready for adminship could just self-nominate and pass RfA. —Kusma (talk) 07:02, 22 April 2022 (UTC)[reply]
Some editors are in the odd position that they could have passed RfA 5–10 years ago but, despite continuing to improve gradually, wouldn't now. I'd like to think that is due to increasing numbers of better-qualified candidates, but the admin count doesn't support that theory. Certes (talk) 20:06, 22 April 2022 (UTC)[reply]
My theory is that some highly qualified non-admins (who should probably be admins) subconsciously apply the "I am better than the candidate and I am not an admin" standard in the wrong way: instead of running for RfA, they make it hard for others to pass. —Kusma (talk) 08:41, 23 April 2022 (UTC)[reply]

The "unsolvable" no-new-admin problem could be solved easily by three relatively easy changes:

  • Something like that above that shifts the ground so that it makes it clear that volunteers are saying "I'm willing to serve" rather than "I want it"
  • Organize RFA/VFA discussions to shift discussions more towards reviewing for needed qualities rather than the random gauntlet that we have now
  • Strengthen the advice that is already weakly in admin guidance that it's expected that only more experienced admins should be doing the really heavy duty stuff like blocking experienced editors. Without that, the mop really IS a big deal and so reviewers place a very high bar accordingly.

North8000 (talk) 01:22, 22 April 2022 (UTC)[reply]

Given how hard we've been trying to fix RfA for a decade now, I feel like there's no way the fix is going to be easy. The main problem of RfA recruitment at the moment is not that editors are "willing to serve" but afraid of looking like they "want it"—rather, the problem is precisely that many qualified editors are not "willing to serve" in the first place because of the intense and stressful scrutiny you have to endure at RfA in order to serve. It seems like your second bullet point is trying to offer a solution to that, but at the moment, it's a little vague. The English Wikipedia currently has no official standards for what qualities are needed to be an administrator—RfA right now is mostly a free-for-all of editors applying their own views of what the necessary qualifications should be. Defining the necessary qualifications more rigorously does not strike me as an easy task—I suspect the RfC will result in no consensus, at best. Anyway, to answer the question presented by the thread, if you are interested in becoming an administrator, the best way to indicate that interest at the moment is to reach out to someone you trust on this list (either on their user talk page or by email) and start a conversation. Mz7 (talk) 08:28, 22 April 2022 (UTC)[reply]
Mz7 I wonder if you could also contact people in that list at random? It might be intimidating having to "pick" one (or a few) of the names on the list. ORCP has a similar vibe but also has some hat collector stigma (at least if you read some of the comments on leeky's recent RfA). — Ixtal ⁂ (talk) 11:13, 22 April 2022 (UTC)[reply]
@Ixtal: Hmm, yeah, I can definitely see how it can be a little intimidating. My recommendation would be to see if there's anyone on the list that you've had good interactions with—even if only once or twice. Alternatively, if you've never interacted with any of them, try to see if there's someone on the list that you've seen around and have a generally good impression of. I would also recommend reaching out over email. Messaging privately could make it easier for the person to provide more candid feedback, and even if they don't offer to nominate you now, this would put you on their radar for the future. Mz7 (talk) 00:41, 23 April 2022 (UTC)[reply]
Oh Mz7 I don't plan to run, hope my comments above didn't lead to that interpretation. I still have a few years of learning and improving to do, and adminship is not necessary for me to contribute productively. I know for me at least there's a few people in the list who I interact frequently with so I'd ask them, but other editors that are not as big of a metapedian as I am might be intimidated by all the big names. — Ixtal ⁂ (talk) 06:41, 23 April 2022 (UTC)[reply]
Mz7 All good points but IMO so are mine. BTW, I was not thinking of trying to define qualifications and turn RFA/VFA into an RFC. I was imagining a softer change. Just list some needed qualities and provide suggestions to comment on those overall. The real test case isn't recent RFA's which is mostly people who have 100% kept their head low their whole wiki-life. The real test case will be someone who has been experienced and active and has not kept their head low. If we ever get one..... North8000 (talk) 13:13, 22 April 2022 (UTC)[reply]
I disagree that recent successful candidates have kept their heads low their whole wiki-life. Looking at the last five successful candidates, I think that's somewhat fair for 2 of them - Colin and Modus. But Blablubbs is/was all over SPI, Firefly is/was an arbcom clerk, and Sdrqaz has never been shy about expressing their opinions. I am not sure what conclusion to draw from the "near unanimous support" or "withdraw" that we've seen in the last 8 or so months but I think it's a bit too glib to just say they've kept their heads low and that's what distinguishes them from those who didn't pass. FWIW, the idea of having formal qualities for admin was discussed a fair amount in WP:RFA2021 and ran into some real opposition I think you'd find that difficult to pass. The RFA/VFA piece is the most intriguing thought here but also feels like something that would have an impact at the margins, to the extent it actually does any change, in terms of how the reframe would impact voting.
If people want to change RfA, the idea of temporary adminship and admin elections both were closed at RFA2021 as having the chance to pass in a modified form. I hope someone would think about trying to get one of those ideas across the finish line. Best, Barkeep49 (talk) 01:05, 23 April 2022 (UTC)[reply]
That's not quite how I meant my post....my fault because it was too short to explain. But vaguely speaking, the more experienced that they are the more likely that they will encounter stuff at RFA that would discourage them from volunteering. North8000 (talk) 12:27, 24 April 2022 (UTC)[reply]
The proposal could put us in the strange editors make public their wish to be admins, but once they become admins you can't tell that they are unless you look through RfAs. Wakelamp d[@-@]b (talk) 09:18, 25 April 2022 (UTC)[reply]

In an alternate universe...

I just found myself wondering what would happen if all editors who met X number of edits and Y years here with a clean block log were automatically given the tools with the understanding that they were under no obligation to use them unless they wished to...but that if they wished to, it was incumbent on them to pursue how to do so appropriately...along with more of a 'guilty until proven innocent' approach regarding potential misuse of the tools, since something that's so freely given should be freely taken away if there's concerns. In other words, if someone opened an ANI case, an editor would lose access to the admin tools until the ANI case was resolved in their favor, or they'd lose the tools in the same way as they might be subjected to a block. In a nutshell, take the claim that adminship should be no big deal to perhaps its farthest extreme. I can't imagine this would ever happen, but I found it a compelling thought experiment. DonIago (talk) 17:55, 25 April 2022 (UTC)[reply]

Doniago, see Wikipedia:Perennial proposals#Automatically grant adminship to users with a certain number of edits or time editing. — Ixtal ⁂ (talk) 18:06, 25 April 2022 (UTC)[reply]
Fair enough! DonIago (talk) 18:10, 25 April 2022 (UTC)[reply]
That's actually not that far off from the VERY early days of Wikipedia. The first crop of admins were people who asked nicely. As long as you were relatively experienced, the process was much less involved than it is today. Given the relative growth in editorship, readership, and size of the 'pedia, that's understandable. --Jayron32 18:24, 25 April 2022 (UTC)[reply]
I do wonder what the real worst-case scenario would be if adminship was given out under those parameters. Yes, experienced editors can and do get into trouble all the time, which is why removing the tools would need to be simplified as well, but theoretically one would hope an editor with that level of experience would at least be making good-faith edits. Anyway, I doubt this kind of radical reworking will ever see the light of day (again). As a completely objective example (coughs), I have a clean block log, and I've been editing long enough that it's hard for me to believe that anyone would really think I'd abuse the tools if I had them. I think it's more a question of whether I'd ever use them for the kinds of editing I tend to focus on. DonIago (talk) 18:49, 25 April 2022 (UTC)[reply]
The yearly admin stats go back to Wikipedia:Successful requests for adminship/2003. In there, you will find many instances of "/0/0" in the tally column, indicating 100% support. But look closer - quite a few have less than 10 supports, one of them even has a tally of 1/0/0. It was so easy in those days. --Redrose64 🌹 (talk) 07:49, 26 April 2022 (UTC)[reply]
More to the point though...did those admins who passed so easily prove at least as competent as those who were subjected to more scrutiny? If the majority of people who would become admins via an automated process would be perfectly competent, then there's a reasonable argument as to why do we have an RfA process that's essentially gatekeeping and if anything making it more likely that those who are expressing an interest are those who "want it" (because you need to jump through the hoops to get the tools)? What's the goal of the RfA process? DonIago (talk) 13:23, 26 April 2022 (UTC)[reply]
I think that the intent and role is sound (review process to give someone the tools and the roles). But in it's current state, it also does harm. By the numbers, it has made defacto criteria for being an admin "got in a long time ago when it was painless and easy" North8000 (talk) 14:00, 26 April 2022 (UTC)[reply]
I wonder how it would impact Oppose !votes if it was explicit that one shouldn't be opposing based on single incidents or vague fears, but rather strong beliefs that someone as an admin would do a bad job, and that they needed to exhibit a clear pattern of problematic behavior. DonIago (talk) 14:41, 26 April 2022 (UTC)[reply]
It doesn't really matter. If 45% of the oppose votes are total bullshit, they still stand, and sink a candidate that would otherwise make a good admin. There is no mechanism for "making" people vote based on valid criteria. You can have one person vote "Oppose, the candidate smells funny" and then 100 other people chime in with "Oh, yes, I agree that they smell funny, I also oppose" and there's no reasonable mechanism to stop that. --Jayron32 14:47, 26 April 2022 (UTC)[reply]
Isn't the whole point of !voting supposed to be that arguments are discarded if they're baseless? If what you're saying is the case, then either someone isn't doing their job by discarding the meritless !votes, or the system really is very broken. DonIago (talk) 14:50, 26 April 2022 (UTC)[reply]
Yes, but in practice that only works for when there are only a few of such arguments. Repetition legitimizes, and when a large number of people oppose for a bullshit reason, it really doesn't matter if the reason is bullshit. It starts to look legitimate from the appearance of consensus on the matter. Unlike an AFD, where bad votes sometimes lead to the wrong results and we can do a quick re-run, a bad RFA can have an un-recoverable affect on the candidate's relationship with the Wikipedia community. A small number of people who have an axe to grind can sink an otherwise stellar candidacy, and the chances of that person never applying for RFA again, indeed of even leaving Wikipedia for the harassment are high. The issue with "not a vote" discussions is that, at the volume of commenting that happens at RFA, it basically is a vote. --Jayron32 14:57, 26 April 2022 (UTC)[reply]
If what you're saying is true (not to impugn your honesty!), then it sounds as though it either needs to be acknowledged that RfA is a vote, or the process needs to be rewritten/strengthened to bring it back to not being a vote. DonIago (talk) 15:03, 26 April 2022 (UTC)[reply]
It seems from my conversations with people that at this point it's already an open secret that it is a vote, but it is not entirely clear how much of a problem that is (see Arbcom elections for example for explicit votes that are very legitimate). — Ixtal ⁂ (talk) 15:05, 26 April 2022 (UTC)[reply]
Any time you present people with a binary option, like "support" or "oppose", it's a vote. We can pretend all we want that it isn't a vote, but once you make it an either/or issue, then it is a vote. We can say it is a weighted vote, where particularly good or bad rationales can swing the weight of the vote one way or the other, but it's a still a vote. One possibility is that you get rid of the "support/oppose" mechanism, and just require people to write their opinions out freely. However, if you got rid of the terminology, it's still "do I think this person should be an admin or shouldn't they", and you just make it harder for someone to assess whether the support is strong enough to grant someone the bit. I mean, look at any RFA. Most of the support votes are equivalent of "Yeah, they'd do a good job, give them the tools", which contains no real rationale for voting, it's just a restatement of the concept of support. But if someone gets 250 of those kind of votes, and like 3 highly detailed opposes, are you really saying that we want that RFA to fail? --Jayron32 15:55, 26 April 2022 (UTC)[reply]
I agree completely, Jayron32. That's why it kind of confuses me when editors really are serious about no-rationale opposes but have no issue with no-rationale supports. It's kind of strong-arming people into giving vague comments when it's just a vote. — Ixtal ⁂ (talk) 16:17, 26 April 2022 (UTC)[reply]
Well, the reason why no-context opposes tend to be ignored is that the vote is really "Can you think of a good reason why this person shouldn't be an admin?" If one cannot think of such a good reason, then they should get the bit. --Jayron32 16:21, 26 April 2022 (UTC)[reply]
Well if you cant articulate why you think they deserve the tools why give it to them, Jayron32? — Ixtal ⁂ (talk) 16:42, 26 April 2022 (UTC)[reply]
Did you even read the nomination??? The nominator literally wrote several paragraphs why the person deserves the tools, AND there are often co-nominators who also have laid out a convincing case why a person should get the admin bit. If I concur with the nomination, then it needs nothing more than my agreement that the nomination is sound. The case for giving them the tools has been made before I even gave my support. I don't need to repeat it, do I? Whereas a person who opposes the nomination without context doesn't have anything to cosign or endorse in the same way a support vote does. --Jayron32 17:12, 26 April 2022 (UTC)[reply]
Woah I hope I didn't sound passive-aggressive in my question above, Jayron32. — Ixtal ⁂ (talk) 17:29, 26 April 2022 (UTC)[reply]
You told me I needed to articulate a reason for my support in order for it to be valid. I was trying to explain to you why that wasn't always necessary. To repeat the extensive nomination statement that accompanies an RFA with every support vote is onerous and unnecessary. Whereas oppose votes don't have an similarly detailed rational to cosign. You told me I was doing something wrong because I didn't "articulate why you think they deserve the tools" (your words, not mine). I was flummoxed because such a statement would only be made by someone who clearly didn't know that RFA nominations are always accompanied by at least one, and often several, independent nominations that lay out that articulated reason. --Jayron32 17:33, 26 April 2022 (UTC)[reply]
I appreciate the explanation for why it isn't necessary to articulate supports, I was just surprised by the tone of the message. I didn't entirely understand why you implicitly believed there was no issue with blank supports and I'm glad you explained your perspective to me. I perhaps came off a bit weirdly in my question. — Ixtal ⁂ (talk) 17:50, 26 April 2022 (UTC)[reply]
Me as well. Sorry to have misread your tone. It is hard to interpret tone when reading text. Mea culpa. --Jayron32 11:18, 27 April 2022 (UTC)[reply]
Arguments are discarded if baseless when the discussion is assessed as a whole. Under current RfA procedure that does not happen unless bureaucrats get involved, AFAIK. — Ixtal ⁂ (talk) 15:04, 26 April 2022 (UTC)[reply]
Each commenter has the freedom to determine what factors they will consider to evaluate a candidate. With English Wikipedia's consensus-based decision-making traditions, one's viewpoint can only be considered meritless if there is a consensus. It's difficult to do this for most opinions, since they usually consider multiple factors. (In the past, I've proposed focusing the discussion on the individual pro and con arguments, so consensus could be found for or against each, but there hasn't been much support for this change.) isaacl (talk) 15:47, 26 April 2022 (UTC)[reply]

Ping specific user groups

Moved from WP:VPPR

Ping specific user groups, for example: @Administrators (pings a random administrator, in case administrator assistance is needed on a specific page) Viewer719/Contribs! 10:03, 22 April 2022 (UTC)[reply]

Pinging a random administrator won't necessarily help much. You might ping an administrator who isn't very active, for example, or somebody who doesn't work with that particular area. You'd be better off posting something on the admin noticeboard, posting something on a forum best suited to the topic (e.g. if you need a page moved then try WP:RM/TR), or using the recently active admins tool. Hut 8.5 11:53, 22 April 2022 (UTC)[reply]
Plus, there is already the {{adminhelp}} template to alert any admins monitoring that category. Regards SoWhy 12:09, 22 April 2022 (UTC)[reply]
I was recently thinking about the feasibility of a template that pings whoever's the most recently active admin, both from a technical perspective and a "is this a good idea" perspective. Nice that I stumbled over here at the time I did. For one, this is definitely the sort of thing that would require community approval - and probably moving User:Enterprisey/recently-active-opt-out.json to projectspace. For two, the current list uses API calls - Templates can really only work with stuff in the wikitext, though Modules do some ~other stuff~ which I can't comprehend even remotely.
All this is made moot by just.. going to the page and pinging the unlucky mop-wielder at the top? casualdejekyll 19:14, 22 April 2022 (UTC)[reply]
Sending an echo notification to a random user would almost always send to a completely inactive user. — xaosflux Talk 12:22, 22 April 2022 (UTC)[reply]
information Administrator note @Viewer719: I moved this from VPR to VPI as it isn't really an actionable proposal as is, and would get shut down there. The idea and other possible work arounds can be further disucssed here, maybe some other ideas will come up. You mentioned a specific technical process - but can you explain what it is you would want to accomplish? — xaosflux Talk 12:24, 22 April 2022 (UTC)[reply]
We already have some ping templates for certain groups of specialists (DYK admins or FA coordinators). —Kusma (talk) 12:29, 22 April 2022 (UTC)[reply]
See Special:PrefixIndex/Template:@ for examples. —Kusma (talk) 12:34, 22 April 2022 (UTC)[reply]

Help drafting a WP:RFA RfC

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.


Hi! I want to make an RfC suggesting that vote counts for ongoing requests not be displayed at Wikipedia:Requests for adminship as it influences editors before reading the nominations and questions, and similarly propose that the tally included at the top of every RfX be added below the Q&A of the candidate (as opposed to the top, as is currently done). How can I best word such an RfC? Should two RfCs be made rather than one, and if so should they happen concurrently? — Ixtal ⁂ (talk) 09:22, 23 April 2022 (UTC)[reply]

Page version of last RfA showing what I mean. — Ixtal ⁂ (talk) 09:24, 23 April 2022 (UTC)[reply]
Honestly, I don't see how this will accomplish much. People react to the content of other people's votes, not to where the tally is. If you want the tally to have no great effect, you need secret voting. —Kusma (talk) 09:34, 23 April 2022 (UTC)[reply]
I don't think it is some ground-shaking proposal that will completely change RfX, but I do think that it can have a strong subconscious influence on editors. Yes, editors will still be affected by the tally when they vote, but I think they should at least read the nomination and Q&A with as little influence from groupthink as we can. It's a small change, really. But I think it's a positive one that doesn't take much effort to implement so I want to get the community's opinion on this. I'd just like some help with wording the proposal before I bring it up ^u^ — Ixtal ⁂ (talk) 09:56, 23 April 2022 (UTC)[reply]
On the other hand, showing the vote totals helps respect editors' time. Often, I'll glance at an RFA, see that my input isn't needed, and save myself some time and effort. ScottishFinnishRadish (talk) 13:21, 23 April 2022 (UTC)[reply]
ScottishFinnishRadish by vote totals do you mean a count of all votes made or the current division of S/O/N? — Ixtal ⁂ (talk) 14:38, 23 April 2022 (UTC)[reply]
Both, as well as the time left in running. Ratio is important, as well as the total votes. I prefer to look towards the end to read both sets of arguments and see if I have anything constructive to add or say, which I normally don't. ScottishFinnishRadish (talk) 15:04, 23 April 2022 (UTC)[reply]
I don't think removing the "remaining time" is a good idea. Some editors are only on every few days and it will help them know if they have time to come back to it. — xaosflux Talk 15:21, 23 April 2022 (UTC)[reply]
I was talking only about the S/O/N counts, I don't see any way removing the time indicator being beneficial at all, XaosfluxIxtal ⁂ (talk) 16:04, 23 April 2022 (UTC)[reply]
Not sure this would achieve the subconscious effect you're looking for. Even if we remove the vote count from the top of the page, wouldn't editors be able to easily glean the vote count by looking at the numbered list of votes in each section? Even if we change the numbered lists to a bulleted list, for example, it still seems like it would be pretty easy to estimate the quantity of votes by looking at the sections. Mz7 (talk) 18:43, 23 April 2022 (UTC)[reply]
Yes but that would be after the nomination and Q&A. The information would be available, just not presented multiple times before you even read the nomination, Mz7. I'm not suggesting the information should be hidden or something, just that the first impression an editor gets of an RfX should be the nomination and the Q&A. Reading votes after having read the nom+Q&A seems better as you are not reading the Q&A having already partly made up your mind about the candidacy. — Ixtal ⁂ (talk) 20:01, 23 April 2022 (UTC)[reply]
My fear with RFA is that far too much weight is given to the nominations and the Q&A section already, and far too few editors actually check the candidate's contributions. Rather than removing the S/O/N numbers, why not just add an edit notice to the effect of "please don't vote in an RFA unless you've spent at least half an hour checking the candidate's edits". ϢereSpielChequers 21:21, 23 April 2022 (UTC)[reply]
WereSpielChequers that sounds like a great idea! :D I'm not sure "at least half an hour" is the exact wording that would be best in that case, but that's why IL exists — Ixtal ⁂ (talk) 21:28, 23 April 2022 (UTC)[reply]
Even that can be tough, depending on what editing people do. Someone could spend a half hour going through my edits and just see a couple hundred answered edit requests. That doesn't really show the articles I've created.
Maybe, rather than answering a bunch of questions, a candidate puts together a sizzle reel of diffs? ScottishFinnishRadish (talk) 22:52, 25 April 2022 (UTC)[reply]
"Sizzle reel"? I hadn't heard that before, SFR. — Ixtal ⁂ (talk) 22:54, 25 April 2022 (UTC)[reply]
Yeah, rather than someone digging through my answering 180 edit requests as "Not done," I'd rather give them a list of the things I do when I have the time. ScottishFinnishRadish (talk) 23:00, 25 April 2022 (UTC)[reply]
It's a public relations term; the sizzle of cooking food doesn't affect its flavour when being eaten, but looks enticing. isaacl (talk) 23:04, 25 April 2022 (UTC)[reply]
That's essentially what is being asked in the question on the candidate's best contributions to Wikipedia. isaacl (talk) 23:04, 25 April 2022 (UTC)[reply]
The biggest problem we currently have at RFA is that we don't have an agreed criteria for adminship, so potential candidates are in doubt as to whether or not they'd pass, often until they are ludicrously over qualified. Hence the pattern of the few successful RFAs being nearly unanimous supports. Agreeing that criteria, or rather getting a concensus that a particular de facto criteria exists, is nigh on impossible. Part of that is that we don't require consensus for a particular test such as too deletionist or too inclusionist, we don't even need 50%. It doesn't require 45% of the !voters to consider a particular position or candidate is too deletionist, too inclusionist, too tolerant of incivility or too much of a civility police position and an RFA tanks. Of course there is another solution, we have several experienced nominators who know how to assess whether a candidate is suitable and would have an acceptable deftness of touch with the delete and block buttons to pass RFA. But how do we persuade more community members to approach such nominators? ϢereSpielChequers 10:20, 24 April 2022 (UTC)[reply]
I agree completely. A big problem is that recent RfCs have the appearance of rearranging deckchairs on the Titanic. Take WP:RFA2021: it correctly identified a number of problems with RfA, but did almost nothing to rectify any of them. My feelings is that RfA will reach a tipping point at some point in the future, but until then nothing will be done that will make much of a difference. --Jules (Mrjulesd) 11:24, 24 April 2022 (UTC)[reply]
I appreciate other editors also brainstorming minor changes that could help improve RfX but I would appreciate if I could get some help drafting an RfC on my proposed idea. Remember that IL is not where one would vote on the idea, so please don't start dismissing it entirely. Just help me draft it :) We can discuss the other ideas at the same time, of course. — Ixtal ⁂ (talk) 13:22, 24 April 2022 (UTC)[reply]
I have started a discussion at Wikipedia_talk:Requests_for_adminship#RfC_on_display_of_vote_totals. — Ixtal ⁂ (talk) 22:43, 25 April 2022 (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.

Time Machine

I'm aware this would take enormous effort and time, but it would be a really cool and useful feature. Imagine selecting a time period or year, and all historical articles detailing people, places, or things that were in existence at the time, (perhaps excluding the 1950s onward), would reflect the current state of affairs in a country: Who is the current ruler, what territories were yielded/taken, etc. For example, I put in 984 A.D. I type in Richard I of Normandy. It returns something like this: "Richard I (28 August 932 – present), also known as Richard the Fearless, has served as the count of Rouen since 942." So on and so forth. Again, I realize this would be a monumental task, but I think it would be an invaluable research tool, simply to get an idea of the way things were at the time, rather than sifting through "Richard I (28 August 932 – 20 November 996), also known as Richard the Fearless (French: Richard Sans-Peur; Old Norse: Jarl Rikard), was the count of Rouen from 942 to 996.[1] Dudo of Saint-Quentin, whom Richard commissioned to write the "De moribus et actis primorum Normanniae ducum" (Latin, "On the Customs and Deeds of the First Dukes of Normandy"), called him a dux. However, this use of the word may have been in the context of Richard's renowned leadership in war, and not as a reference to a title of nobility.[2][3] Richard either introduced feudalism into Normandy or he greatly expanded it. By the end of his reign, the most important Norman landholders held their lands in feudal tenure.[4]" Please discuss. Lincoln1809 (talk) 00:08, 27 April 2022 (UTC)[reply]

It might be possible with a semantic wiki. -- GreenC 00:54, 27 April 2022 (UTC)[reply]
This sounds extremely fun, but would need to be somehow automated to be useful (so, another vote for the semantic wiki idea). Also, random but: if this is the kind of world you dream of, you might like playing the Europa Universalis games. Rileyzzz (talk) 23:58, 27 April 2022 (UTC)[reply]
Plenty of hunting accidents on ITN, I'd imagine, Rileyzzz! — Ixtal ⁂ (talk) 16:37, 28 April 2022 (UTC)[reply]
It might be possible with Abstract Wikipedia and Wikifunctions, but I doubt it would be their first priority. Certes (talk) 12:33, 28 April 2022 (UTC)[reply]

Easier to Understand User Guides

Hello!

I recently joined Wikipedia and if I'm honest, getting started has been a nightmare. A lot of this site relies on HTML/Sytax which is not user friendly. Additionally, all of the help pages are hard to reach and difficult to find. Many of them are not written in a way that is understandable to a new user. I think we could best amend this by introducing user guides formatted in visual way. This would be digestible to an individual accustom to the functionality of those sites. Perhaps video tutorials which show a user exactly how to create a new article or use a feature, an article written book-style that links to all avaliable help pages, and less reliance on HTML. I know this would take a ton of work but it would invite more users to Wikipedia without the hassle of googling each help page and digging to learn all of the terminology before entering. CherriGasoline (talk) 04:29, 27 April 2022 (UTC)[reply]

@CherriGasoline, see Help:Introduction for a newer tutorial on editing Wikipedia that includes the Visual Editor. Many of our welcome messages have not been updated yet and just link to using the WikiText editor. StarryGrandma (talk) 19:43, 27 April 2022 (UTC)[reply]

Improving WikiMarkup Editing Platform

Current Editing Interface

Editing played a major role in the formation of our Wikipedia, and it continues to, in the growth of it. People can edit Wikipedia in two ways: WikiMarkup or VisualEditor. Now, both have their pros and cons.


WikiMarkup Has:


- More features

- Professional editors are used to it

- It is a major part of WikiCulture


but


- It is a giant mess.

- It is intimidating to newbies

- It therefore makes an impression that Wikipedia is hard to edit, and scares away people with valuable information, who can contribute here.


But, that doesn't always need to mean that newbies have to hide in the shelter of VisualEditor, who now can only provide so much. If this Markup becomes more organised, less intimidating and makes a good impression among people (it is easy, but feels hard), I believe we will see more editors coming to contribute.

Unfriendly Notepad HTML

This also reminds me of HTML, during the early days of the internet. HTML was edited in a very unfriendly Notepad. Nothing is color coded, you can barely see where are the opening and closing tags, and things were a mess.


But then came the range of more comfortable editors. Notepad ++, and many more came with a new design, one that had light and dark modes, one where different tags were color coded, one where it told you where the opening and closing tags were, and most of all, corrected errors. (unclosed tags, etc.).


I propose the same for WikiMarkup.



Regards, Narutmaru . To contact me, visit my Talk Page. 09:42, 27 April 2022 (UTC) — Preceding unsigned comment added by Narutmaru (talkcontribs) [reply]

A very (crude) attempt at making a mock image.
Regards, Narutmaru . To contact me, visit my Talk Page. 09:55, 27 April 2022 (UTC) — Preceding unsigned comment added by Narutmaru (talkcontribs) [reply]
Narutmaru, I brought this up recently in a different thread which was also started by you, but you may have missed my response. What you're looking for is Wikitext editor syntax highlighting, which can be activated with the press of a single button.
On a different note, your signature seems to screw with the autosign bot, as demonstrated above. Probably shorten it somewhat to avoid this. Dr. Duh 🩺 (talk) 10:53, 27 April 2022 (UTC)[reply]
Is my signature ok now? Narutmaru(Talk) 11:23, 27 April 2022 (UTC) — Preceding unsigned comment added by Narutmaru (talkcontribs) [reply]
Narutmaru, still isn't, by the looks of it. I suspect the many superfluous spaces (every single one in this string: [[ User: Narutmaru |Narutmaru]][[ User talk: Narutmaru |(Talk)]]) may have something to do with it. You can either delete those, or just revert to the standard signature by blanking the "Signature" field in your account preferences. Dr. Duh 🩺 (talk) 11:58, 27 April 2022 (UTC)[reply]
@Narutmaru: Lose all of the spaces, except for the ones outside the links and the one in "User talk". --Redrose64 🌹 (talk) 21:37, 27 April 2022 (UTC)[reply]

Simple English Wikipedia.

m:Proposals for closing projects/Closure of Simple English Wikipedia (3). And the two proposals before it. They happened, they did not find consensus, but there were some good ideas in there.

One idea I had (or may have accidentally stolen, I don't know) is to add some sort of ambox or other notice to articles with simplewiki translations - similar to what Uncyclopedia does about us. (Yes, I did just unironically suggest we emulate Uncyclopedia for something.)

Thoughts? Is this even within the scope of Village Pump? casualdejekyll 00:37, 30 April 2022 (UTC)[reply]

Worth noting that LangCom said that they "certainly likes the idea of Simple English content being more accessible from English Wikipedia" but that it was a "matter for the communities to decide, not LangCom."
I don't know of any followup to that? casualdejekyll 00:49, 30 April 2022 (UTC)[reply]
For more context, I think this is the most recent proposal along these lines: Wikipedia:Village pump (proposals)/Archive 165 § New approaches to "Simple English Wikipedia". isaacl (talk) 01:00, 30 April 2022 (UTC)[reply]
A proposal which gained a good two or three opposes with almost everyone else supporting at least in concept - before magically fizzling out, as these things tend to do. Soumyabrata's merge idea also addresses most of the concerns but it would require consensus from simplewiki, which is unlikely to be attained from what I can gather. casualdejekyll 01:06, 30 April 2022 (UTC)[reply]

Redesigning the About page

Hello, I am currently working on redesigning our about page. I started a draft at User:Interstellarity/sandbox where we can improve on the page and was hoping to get some ideas on how to redesign the page. I welcome anyone to edit my sandbox to improve the page. Interstellarity (talk) 15:40, 30 April 2022 (UTC)[reply]

Hi, I was wondering if and when I'll get a response to this post. Interstellarity (talk) 15:57, 3 May 2022 (UTC)[reply]
To get the discussion started can you explain the background to this proposed change? What issues you see with the current page? BilledMammal (talk) 16:03, 3 May 2022 (UTC)[reply]
Hello @BilledMammal,
The current About page is too long. I would like to make it more user-friendly especially for newcomers since many newcomers aren't willing to read that long of a page. I would like to shorten it like many about pages you see online. Many of the sections can easily be explained using links. Interstellarity (talk) 17:14, 3 May 2022 (UTC)[reply]

Drafting of stand-alone page criteria for WP:NGEO, based on feedback at recent RfC

Hi! From the recent RfC at WP:VPP that I started, it seems to me editors would find it helpful for me to propose a specific criteria to be voted on. To draft this I'll need help from other editors as I've never really proposed notability policy changes before. Pinging editors previously involved in this discussion that were (IIRC) in favor of or willing to discuss changes: @Uncle G, Mhawk10, Theknightwho, Donald Albury, Redrose64, North8000, BilledMammal, and Aymatth2. Also pinging JPxG as someone whose work exemplifies why I think the notability of geographical features itself makes sense, and who can provide a useful perspective on taking geostubs to FA level articles.— Ixtal ( T / C ) Join WP:FINANCE! 00:24, 3 May 2022 (UTC)[reply]

@Jayron32: as they indicated interest in helping out here in their RfC vote. — Ixtal ( T / C ) Join WP:FINANCE! 00:26, 3 May 2022 (UTC)[reply]


Per WP:N:

A topic is presumed to merit an article if:
  1. It meets either the general notability guideline (GNG) below, or the criteria outlined in a subject-specific notability guideline (SNG) listed in the box on the right; and
  2. It is not excluded under the What Wikipedia is not policy.

The wisdom built into this is that things can be notable and still not be fit for their own article—provided that there is something about the article (or article subject) that runs afoul of WP:NOT. Unless we are to alter the core substance of what amounts to be Wikipedia's inclusion criteria (i.e. modifying point 1 or point 2)—which I am extremely hesitant to support—it might be wise to start thinking about common use cases where WP:NOT might apply to articles about geographic features (or if such use cases exist). — Mhawk10 (talk) 00:59, 3 May 2022 (UTC)[reply]

My concern is that we don't create articles that can never be expanded beyond (or much beyond) stub level. For example, while we may have names for a number of different streams in a river basin, it doesn't make sense to create a new article on every one of them, most we won't have more than 2-3 sentences to say. It would make more sense to just include all of these in one article on the main river or river basin in question. Similarly for unincorporated places in a township, county, or equivalent division, peaks in a mountain range, etc. etc. Information is actually easier to find in these ways; creating a new article on ever minor feature creates a fragmentation of text that can actually make it harder to follow. The criteria should always be "do we have enough reliably sourced text to create a decent-sized article about this subject". If so, do it. If not, then it should be included in a larger concept... --Jayron32 11:56, 3 May 2022 (UTC)[reply]
What is a good indicator for "enough"? Keep in mind that a wide range of things fall under NGEO, including villages, streams, and train stations. The "larger concept" seems a bit different between them, as well as how much information is needed for the article to be considered decently-sized. — Ixtal ( T / C ) Join WP:FINANCE! 12:09, 3 May 2022 (UTC)[reply]
I think one good metric for "reliably sourced text" is the number of and significant coverage in sources that are not databases. It is also true that This guideline specifically excludes maps and tables from consideration when establishing topic notability (emphasis my own, from NGEO) is almost never enforced, really. — Ixtal ( T / C ) Join WP:FINANCE! 12:13, 3 May 2022 (UTC)[reply]
It also excludes GNIS and GEONet ("WP:GNIS and GEONet Names Server do not satisfy the "legal recognition" requirement and are unreliable for "populated place" designation.") We should consider expanding that to include any database. As it stands, we have a lot of articles that do not meet the current GEOLAND requirements. If we want to tighten up the requirements for creating new articles about geographical features, I think we also need to clean out all the articles that do not, and likely never will, meet the minimum notability requirements. I did successfully prod Hasan, Florida last year. It was created in 2008 and had been edited 72 times, but when I prodded it, it consisted of the sole sentence, "Hasan, Florida is an unincorporated community in Alachua County, Florida, United States." The only source cited was hometownlocator.com. Yet, I spent considerable time searching unsuccessfully for any reliable source that mentioned it before I felt comfortable prodding it. I would be happy if we could make it a little easier to remove articles about places that are unlikely to ever meet the GNG. That would also help in preventing such articles from being created in the first place. - Donald Albury 13:37, 3 May 2022 (UTC) — Preceding unsigned comment added by Ixtal (talkcontribs) [reply]
It also excludes GNIS and GEONet ("WP:GNIS and GEONet Names Server do not satisfy the "legal recognition" requirement and are unreliable for "populated place" designation.") We should consider expanding that to include any database. As it stands, we have a lot of articles that do not meet the current GEOLAND requirements. If we want to tighten up the requirements for creating new articles about geographical features, I think we also need to clean out all the articles that do not, and likely never will, meet the minimum notability requirements. I did successfully prod Hasan, Florida last year. It was created in 2008 and had been edited 72 times, but when I prodded it, it consisted of the sole sentence, "Hasan, Florida is an unincorporated community in Alachua County, Florida, United States." The only source cited was hometownlocator.com. Yet, I spent considerable time searching unsuccessfully for any reliable source that mentioned it before I felt comfortable prodding it. I would be happy if we could make it a little easier to remove articles about places that are unlikely to ever meet the GNG. That would also help in preventing such articles from being created in the first place. - Donald Albury 14:02, 3 May 2022 (UTC)[reply]

The part that you are quoting is a top level statement of the entire wp:notability system. I don't think that you are proposing changing that. I thought that you were proposing tightening up the NGEO SNG a bit which I think would be a good thing. Sincerely, North8000 (talk) 13:11, 3 May 2022 (UTC)[reply]

North8000 what part am I quoting, or do you mean Mhawk10? — Ixtal ( T / C ) Join WP:FINANCE! 13:12, 3 May 2022 (UTC)[reply]
Thanks for the catch. I mistakenly thought that you wrote that so I struck that part of my comment. Sincerely,North8000 (talk) 14:16, 3 May 2022 (UTC)[reply]
North8000 tightening the notability criteria is something that could be explored, but I find it both unlikely to gain traction and be highly complicated to carry out. If you have any ideas, however, feel free to share :) — Ixtal ( T / C ) Join WP:FINANCE! 14:23, 3 May 2022 (UTC)[reply]
I thought that was what you are proposing developing/doing. If not, what do you have in mind? North8000 (talk) 14:28, 3 May 2022 (UTC)[reply]
North8000 the notability criteria in my mind is more of a theoretical ideal than a practical manual. The issue is not that we have many articles about villages, but rather that we have too many of them, cited too weakly (e.g. only to a single database), and too few editors to address that issue. Changing the notability guideline to something more strict is likely to be of detriment to our readers if it leads to mass AfDs of villages, but by encouraging merging information to parent articles (as NOPAGE does), we can reduce the unmanageable number of geostubs through a constructive rather than destructive method. Then, when an editor wants to expand the redirect into an article and has enough sources to do so, they do not have to pass through extra hoops. — Ixtal ( T / C ) Join WP:FINANCE! 14:51, 4 May 2022 (UTC)[reply]

The essence of this discussion seems to be whether we can provide guidelines on when notable geographical topics should have standalone pages and when they may be better part of a broader article. I suggest we should add a section to Wikipedia:NGEO:

== Whether to create standalone pages ==
As stated in WP:NOPAGE, "Sometimes, understanding [of a notable topic] is best achieved by presenting the material on a dedicated standalone page, but it is not required that we do so. There are other times when it is better to cover notable topics, that clearly should be included in Wikipedia, as part of a larger page about a broader topic, with more context." For example, a river may have several tributaries that are technically notable meet the notability criteria defined in WP:NGEO, but where there is little to be said about some of them. The article on the river may include a list of tributaries, and there may be standalone articles for some tributaries and redirect articles pointing to the list entries for other tributaries. A similar approach may be followed for hamlets in a municipality, shopping malls, railway stations and so on. This does not preclude expanding the redirects into standalone pages if more information comes to light, and also allows us to hold information on sub-topics that are relevant to the main topic but not notable in themselves.

Aymatth2 (talk) 15:26, 3 May 2022 (UTC)[reply]

What do you mean by "technically notable". GEOLAND does not automatically make all geographical features notable. It does say, Geographical features meeting Wikipedia's General notability guideline (GNG) are presumed, but not guaranteed, to be notable. Therefore, the notability of some geographical features (places, roadways, objects, etc.) may be called into question. Donald Albury 16:50, 3 May 2022 (UTC)[reply]
I have tweaked the wording to be more precise. This approach may help us avoid long discussions about geographical features where notability may be questioned. If there is not much sourced information, put what there is into the parent article, with a redirect to that article. Aymatth2 (talk) 17:46, 3 May 2022 (UTC)[reply]
Notability and whether a geographic feature should have a standalone article are only partially overlapping issues. In general, I would say that a geographic feature, even if it is presumed notable, should not have a standalone article until someone has found sufficient reliable sources to write more than a short stub. Geographic features for which sufficient reliable sources have not yet been found can almost always be mentioned constructively in a relevant higher level article. And yes, redirects to such mentions are cheap. Donald Albury 18:06, 3 May 2022 (UTC)[reply]
I dislike one-line stubs, but think it will be impossible to get agreement that they should be eliminated. The above proposed wording is probably as far as we can go. It legitimizes merging stubs into parent articles, but does not mandate it. Aymatth2 (talk) 18:32, 3 May 2022 (UTC)[reply]
That's kind of the best we can hope, and what I wished to encourage with my original proposal. — Ixtal ( T / C ) Join WP:FINANCE! 18:35, 3 May 2022 (UTC)[reply]
One thing in creating list pages to be aware of: There are going to be particular tributaries and municipalities that can't easily get lumpted into a notable list. WP:NGEO is something that relates to notability of particular features, while WP:NLIST requires lists to have coverage of a group as a whole. Any change to WP:NGEO that directs users to start making lists is going to need a parallel change in WP:NLIST to support it, unless the community desires to create a backdoor to deletion for geostubs through listification. I don't think anybody wants to see weird procedural loopholes created to delete valid content, so it might be wise to more deeply consider how changes to WP:NGEO would intersect with other guidelines before proceeding. — Mhawk10 (talk) 18:41, 3 May 2022 (UTC)[reply]
WP:NLIST is pretty fuzzy and really doesn't require coverage of a group as a whole.....it merely says that that is one way "in". Plus it takes work to even organize merge proposals and so I'm not fearing a deletions binge, especially with a "soft" change/addition. I'm not worried about as much about the current geostubs, I'm worried that the low bar used could allow 5 million more to get added. North8000 (talk) 19:00, 3 May 2022 (UTC)[reply]
One thing to remember about lists is that, per MOS:LIST, they do not need to be stand-alone. Many of the geographical topics that have been discussed (like tributaries, and also the oft-discussed boroughs) "belong to" an obvious parent article. The best practice might be to create lists as parts of parent articles until a given list reaches some length threshold, rather than defaulting to standalone lists.
As a separate issue, it is probably worth pointing to the potential strengths of annotated lists and searchable lists, in any guidance that is developed here. Newimpartial (talk) 19:07, 3 May 2022 (UTC)[reply]
I was thinking maybe Lake Rouge pointing to MacDonald River (Côte-Nord)#Lakes could be given as one example. Aymatth2 (talk) 19:12, 3 May 2022 (UTC)[reply]
I was thinking of Alachua County, Florida#Historic communities in Alachua County as an example of one way of incorporating topics of questionable notability in a parent article. Donald Albury 19:21, 3 May 2022 (UTC)[reply]

I like the idea. North8000 (talk) 17:02, 3 May 2022 (UTC)[reply]

  • I like Aymatth2's proposal above. I might also add something to the effect of

For topics which are not in-depth enough to merit a stand-alone article, some better ways to organize the information: 1) Include the information in a relevant related article, for example including a section on tributaries in the article on major rivers, and capturing relevant information on minor tributaries of that river in that section. 2) If the main article is too large already, or may be overwhelmed by such a section, then as another option, one could create a separate article titled "Tributaries of River Foo" and collect the information on various tributaries there. In general, this guidance favors collecting such information in fewer, but larger, articles rather than many tiny articles, and only splitting articles when the larger article becomes too long or too imbalanced. See Wikipedia:Summary style for more guidance on this style of writing.

As always, I am open to editing, changing, eviscerating, or ignoring my proposal as well. --Jayron32 12:34, 4 May 2022 (UTC)[reply]
I think we need to discuss how to provide guidance on when topics are not in-depth enough to merit a stand-alone article, without making it longer than people are willing to read. Donald Albury 12:48, 4 May 2022 (UTC)[reply]
Let.s not try to do too much. If we can extend the guideline to say that notable topics do not require stand-alone articles, but can be included in larger articles (with examples), that is progress. Then we can turn to the trickier questions of how small is too small and how large is too large. My guess is that many geo-stubs are very short indeed and can easily be merged into the natural parent without making the parent unwieldy, so these questions will often not arise. Aymatth2 (talk) 13:04, 4 May 2022 (UTC)[reply]
I agree with Aymatth2. In my opinion how we should expect this to go is to first get the NOPAGE section into NGEO, wait for a few months or half a year to see how it is being applied in practice, and then based on that draft guidance on sizes and whatnot. Like that the draft would be more descriptive than prescriptive, something I see as beneficial. — Ixtal ( T / C ) Join WP:FINANCE! 13:48, 4 May 2022 (UTC)[reply]
I disagree. Unclear guidance is exactly the sort of thing that consumes large volumes of editor time for things where there are no right answer. Rather than eating that cost every time there is a contentious geographical feature article merge or AfD, it is going to be a much better use of editor time if the guidelines are clear when they are proposed—biting the bullet and dealing with hard questions early is better than creating vague guidance that will inevitably lead to an increase in ANI threads and deletion reviews over what we have now. — Mhawk10 (talk) 13:54, 4 May 2022 (UTC)[reply]
The problem with specificity is that you invariably run into some variation of the Sorites paradox for defining proper length of articles. I mean Nile is a clearly long enough article about a river, and Fifteenmile Creek (Potomac River tributary) is clearly too short to be useful. How many words do I add to the Fifteenmile Creek article until it is acceptable? If it just crosses that line is it allowable as a stand-alone article? If someone comes along and edits it to remove 2-3 words must it now be merged? Editorial decisions do need to be made around necessarily fuzzy edges, and often depending on non-quantifiable standards, but that doesn't mean that there aren't articles which are clearly better served as being part of larger articles. --Jayron32 14:06, 4 May 2022 (UTC)[reply]
How about something like, If a preliminary search does not find at least two reliable sources that will support at least three or four sentences on a topic, then consider adding the topic as a section in a relevant article of larger scope. Donald Albury 14:20, 4 May 2022 (UTC)[reply]
I would hope we could do better than that. In particular, I think mentioning redirect creation - which has the potential to support the category system, highly relevant for geographical features - is worthwhile. It also seems to me that sortable lists and list articles should be explicitly mentioned as alternatives. Newimpartial (talk) 14:31, 4 May 2022 (UTC)[reply]
I think we need to avoid encouraging lists as an explicit alternative to articles; not all articles can be lists nor all lists be articles. In fact, I don't think that things like villages are equally or most useful to our readers as part of lists nor do I want to give that impression. For example, Pelliceira (parish) and Ibias (its parent administrative division, a municipality) show the limitations of lists without additional information or graphics. In this case the Spanish article provides a great idea: the use of maps and other graphics to allow the list information to be contextualized as part of the parent article. If we are going to mention lists, I really can support it if we explain how best to create these lists, even if its by creating a explanatory supplement on best practices regarding geographical lists. — Ixtal ( T / C ) Join WP:FINANCE! 14:44, 4 May 2022 (UTC)[reply]
Lists are not an alternative to articles; they are either a type of article or an element in a larger article. A sortable list - or for that matter, a "presorted list" based on a hierarchical structure, which is often available for geographical topics - does actually provide information to the reader with less "friction" than a text mention can provide. And there is nothing in a sortable list that inhibits annotation, either. As these comments imply, though, I entirely agree that we need to offer best practices for geographical lists (starting with the recommendation that short lists should typically be contained within the parent article, as well as advice about redirects and the categorization thereof. Newimpartial (talk) 15:02, 4 May 2022 (UTC)[reply]
An article may be nothing but a list, a list with a long preface, or just contain a few lists. The lists could be in tables, bulleted text, or with headings for each entry. The best choice depends on how much text and images each entry has, whether sortability would help and so on. A useful discussion seems out of scope for this proposal. Aymatth2 (talk) 15:23, 4 May 2022 (UTC)[reply]
In my first two sentences I meant the type of article and in the rest I meant all lists (both stand-alone list articles or elements within an article), Newimpartial. — Ixtal ( T / C ) Join WP:FINANCE! 18:02, 4 May 2022 (UTC)[reply]
The effect of requiring multiple independent RS will do little more than impose WP:GNG as a requirement for standalone GEO articles. If this is the intent, why not just propose to modify the existing text of NGEO? It seems far more straightforward and it would paint a clearer picture of what editors would be deciding on if this were to become a proposal. — Mhawk10 (talk) 14:52, 4 May 2022 (UTC)[reply]
I, for one, would oppose any such proposal, particularly if applied to populated places. Newimpartial (talk) 15:02, 4 May 2022 (UTC)[reply]
An article that says "Khryzk is a hamlet in Ruritania" followed by ten citations may be better merged into a parent. An article with two citations that says "Khryzk is a hamlet of about 50 people in Zaproz muncipality, Starzynck, Ruritania, on the Priztikh River. The main occupation is viticulture. The poet Stepan Khryskiv was born in this hamlet in 1843.", with a location map and a couple of interesting photographs, may not fit comfortably into a parent. I don't see how we can give rigorous rules for when stubs should be merged into parents. Aymatth2 (talk) 15:23, 4 May 2022 (UTC)[reply]
I am not saying that I would support such a proposal either, but I am saying that it is much more clear as to what the question is. — Mhawk10 (talk) 15:44, 4 May 2022 (UTC)[reply]
Why do we insist on creating stand-alone articles for which there is next to no verifiable information we can include in said article? If all we have to say can be summed up in a line or two of text, why do we need an entire page to contain that text? --Jayron32 15:56, 4 May 2022 (UTC)[reply]
What is so terrible about applying GNG to stand-alone articles about geographic features? What is so terrible about saying that stand-alone articles should be more than one- or two-sentence stubs? I also will note that my proposal was not a hard-and-fast rule, but rather would advise editors to consider adding topics to an existing article rather than creating a very short, poorly sourced, stub. Donald Albury 16:35, 4 May 2022 (UTC)[reply]

You seem to be conflating the GNG issue with the content issue. I think Aymatth2 is right about this: the question of how much encyclopaedic, reliably sourced information is available is more relevant to the standalone article decision than the number of GNG sources. Newimpartial (talk) 16:37, 4 May 2022 (UTC)[reply]

Your statement makes it seem like you don't understand GNG. When you say "the question of how much encyclopaedic, reliably sourced information is available is more relevant to the standalone article decision than the number of GNG sources.", GNG is literally about "how much encyclopaedic, reliably sourced information is available" That's 100 % GNG, but if we need to quote it to make it clear "A topic is presumed to be suitable for a stand-alone article or list when it has received significant coverage in reliable sources that are independent of the subject." Significant coverage means that there is enough verifiable text for us to build an encyclopedia article from. That's the point of GNG; if you can't create a long enough stand-alone article from the sources, then don't. Instead, find other ways to include the information. --Jayron32 16:54, 4 May 2022 (UTC)[reply]
No, I think I understand GNG pretty well (as one of the drafters who produced the text that was incorporated in WP:N as WP:SNG last year, I had to get to know GNG). I agree with you when you say that Significant coverage means that there is enough verifiable text for us to build an encyclopedia article from. But there is also a Bingo-card approach to GNG/SIGCOV, which is typically used to promote deletion of articles an editor wants deleted - by arguing that not enough of the sourcing is in depth, or that not enough of it is secondary, so that their aren't enough "GNG sources". My sense is that Donald Albury's original proposal for at least two reliable sources that will support at least three or four sentences on a topic would support this "ratcheting-up" approach in terms of dismissing sources and in terms of how much text is required. I took Aymatth2's point to be that it is the sourced information (and how well it fits into tabular format, etc.), not the number of sources, that should be the deciding factor in this context. While I don't think GNG discussions ought to devolve into nitpicking and source counting - I agree they are supposed to determine whether there is enough encyclopaedic information for an article - in reality they often do devolve into nitpicking. One of the purposes of SNGs like NGEO is to preempt that kind of nitpicking, so I wouldn't promote changes the main result of which would be to encourage it. Newimpartial (talk) 18:28, 4 May 2022 (UTC)[reply]
Would you say it was nitpicking when I tagged Dalkeith, Florida for not meeting GEOLAND? How about when Gulf Hammock, Florida was tagged for not meeting the GNG and being unsourced.? (Note that the latter tagging spurred me to find several sources and expand the article almost 6 times.) Exempting geographical features from GNG does not help improve the encyclopedia. Donald Albury 19:46, 4 May 2022 (UTC)[reply]
Exempting geographical features from GNG is already done in certain provisions of WP:GEOLAND; I did not understand the OP to be proposing to change that status. On the other hand, I haven't understood anyone in this discussion to suggest loosening any of the NGEO provisions around Notability. If you think the encyclopaedia would be "improved" through a radical overhaul of GEOLAND, I think that would involve starting a new discussion somewhere.
And of course people tagging articles that do not meet relevant criteria - like GEOLAND - or tagging (or better yet, improving) unsourced artickes, are not nitpicking. I am not suggesting that any participants in this discussion are engaged in nitpicking. What I have said is that proposed text like at least two reliable sources that will support at least three or four sentences on a topic would enable nitpicking: not as a goal, but as a predictable effect. I would therefore oppose any similar approach. Newimpartial (talk) 20:00, 4 May 2022 (UTC)[reply]

An attempt at a revised version is given below. This too long, but tries to cover some of the points made above. It is only concerned with notable topics under the present definition, and avoids the issue of how how big a stub should be to be kept stand-alone.

== Whether to create standalone pages ==

As stated in WP:NOPAGE, "Sometimes, understanding [of a notable topic] is best achieved by presenting the material on a dedicated standalone page, but it is not required that we do so. There are other times when it is better to cover notable topics, that clearly should be included in Wikipedia, as part of a larger page about a broader topic, with more context." For example, a river may have several tributaries that meet the notability criteria defined in WP:NGEO, but where there is little to be said about some of them. The article on the river may include a list of tributaries, and there may be standalone articles for some tributaries and redirect articles pointing to the list entries for other tributaries. A similar approach may be followed for hamlets in a municipality, shopping malls, railway stations and so on.

The target article may be a list-type article if the list is notable in itself or all the list entries are notable, or may be a list or sub-section within a broader article such as a river with a list of tributaries or a municipality with a list of communities. The list may be formatted as a sortable table, as bulleted text, as paragraphs or sub-sections depending on the type of content. Examples: MacDonald River (Côte-Nord)#Lakes and Alachua County, Florida#Historic communities in Alachua County.

Merging a short stub about a notable topic into a parent article will be often be uncontroversial, and may improve the reader experience if it presents the topic in a broader context. It should not be done if the resulting reader experience is significantly poorer, for example if it causes loss of relevant text, location maps or pictures. (But {{Location map+}} may be used to show a number of related locations on one map.) A merge does not preclude expanding the redirects into standalone pages if more information comes to light, and also allows us to hold information on sub-topics that are relevant to the main topic but not notable in themselves.

Aymatth2 (talk) 22:48, 4 May 2022 (UTC)[reply]

(undo | discuss | thank) next to all edits

We give users an easy way to revert edits in each article's history. Why not add the ability to quickly open a new discussion regarding an edit with a reference to it already included? Might help encourage the WP:BRD cycle. {{u|Gtoffoletto}}talk 19:25, 3 May 2022 (UTC)[reply]

This seems like an interesting idea. It might be technically a bit odd with respect to how we handle redirected talk pages in some of the non-article mainspaces, though this feels like something that can be pretty easily overcome. — Mhawk10 (talk) 19:32, 3 May 2022 (UTC)[reply]
I really like this idea. I think that the devs could implement this rather easily, and it would really help. The button simultaneously could do any number of things, such as starting a talk-page section, pinging or notifying the relevant user on their user talk page, etc. etc. If it was clearly visible next to every edit in both the diff view and article history view, it may encourage users to use the talk page rather than edit summaries for communication, and may cut down on revert wars. I dig it. --Jayron32 12:37, 4 May 2022 (UTC)[reply]
I like this too. Right now it is more "convenient" to hit the undo button and discuss using the edit summary, so making it easier to discuss edits, especially for new users would be great. Could be done as part of the whole mw:Extension:DiscussionTools thing. Galobtter (pingó mió) 20:21, 4 May 2022 (UTC)[reply]
I adore this idea as it encourages dialogue, something we need more of. — Ixtal ( T / C ) Join WP:FINANCE! 20:23, 4 May 2022 (UTC)[reply]

A solution to the template graveyard of retired users

The other day, I was reading Ritchie333's essay, Don't template the retirees. The essay rang true; I've seen it happen far too often for retired users. As Wikipedia's standards increase, and old articles and files don't make the cut, the talk pages of retired users contain Twinkle notification after Twinkle notification about images and articles being proposed and nomination for deletion.

I think that we should be able to place a box on the talk pages of users who haven't edited in, say, two years. It'd be a small box. If the box exists, instead of Twinkle leaving a large new message at every new PROD and XfD, it would simply add the nomination page to a bulleted list, maybe separated by category. Something like this:

{{Twinkle box|
 ;AfD
 * [[Wikipedia:Articles for deletion/Article 1]]
 * [[Wikipedia:Articles for deletion/Article 2]]
 ;CSD
 * [[Article 3]]
 }}

and so on. Users would still get a "you have a talk page message" notification, but the template graveyard would shrink significantly because closed nominations would be removed from the box. Thoughts, suggestions? theleekycauldron (talkcontribs) (she/they) 22:13, 4 May 2022 (UTC)[reply]

I think anyone templating Neelix (talk · contribs) probably needs to stop - all they're doing is filling up server disk space. Ritchie333 (talk) (cont) 22:47, 4 May 2022 (UTC)[reply]