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, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40


Let the community decide about major new features?

Now maybe I'm wrong and I just always miss it, but my impression is that the WMF would often develop features with minimal community input, minimal community testing, doesn't give the community any real chance to consider possible alternatives and proceeds to roll out the new feature. For example mw:Flow which was quite the faceplant, cross-wiki uploads plague Commons with numerous copyvios to this day due to a flawed design, DiscussionTools which takes up bandwidth even if you've disabled it, the VisualEditor which isn't universally loved and I don't expect a poll before the Vector 2022 skin which (in its current state at least) has upsides and downsides over Vector classic. Damn, almost forgot about IP masking! (are we still in the dark about what that's actually going to be like?) What I'm thinking is that the community should be informed well in advance and there should be some mechanism to ensure major new features will be backed by the community, or at least not hated. The community should have a chance to prepare for it (like updating tools/bots/help pages) and suggest changes or alternatives. For example with Flow, the community could have rejected it before it made a faceplant. While IP masking can't be rejected as the motive for that is legal, the community could propose implementation details/alternatives which do exist. And brace for its introduction, of course. I'm just brainstorming here, am I making any sense? Alexis Jazz (talk or ping me) 15:41, 10 March 2022 (UTC)[reply]

To shoot from the hip, whatever my thoughts on the rest of it, DiscussionTools is one of the single biggest improvements to the editor experience in the history of the project and the associated community outreach has been superb. Anyway, there's some information on ongoing projects on mediawikiwiki. I would say it could be updated/communicated more frequently, but perhaps it's already current. Enterprisey (talk!) 18:03, 10 March 2022 (UTC)[reply]
I don't know.. maybe like apply to work for the foundation ? —TheDJ (talkcontribs) 20:58, 10 March 2022 (UTC)[reply]
also, which part of the community ? different parts always show up to different steps and different projects and always have different opinoins and generally ppl leave out those without 'community' voice —TheDJ (talkcontribs) 21:01, 10 March 2022 (UTC)[reply]
TheDJ, work for the foundation, that sounds like wonderful idea. As for which part, well I was just brainstorming. I suppose if the WMF was more responsive to questions that community members are already asking and if developers didn't spend 90% of their community time on Phabricator (which is largely disconnected from the community at large) and in Flow discussions, we'd be halfway already. Alexis Jazz (talk or ping me) 03:46, 11 March 2022 (UTC)[reply]
As TheDJ alludes to, the community doesn't speak with one voice, plus design by large group conversation is often ineffective. On user-interface related features such as skins, there needs to be some liberty for new designs to be tried and tested, as learning from failure is important. I agree there ought to be a feedback loop, and in some cases, trials are appropriate. (I've not followed the progress, but I do know that suggestions were sought from the onset regarding IP masking, and most recently feedback was requested on different approaches.) Although focus groups shouldn't be the ultimate last word on design choices, as they're a small sample of opinion, it could be helpful for the WMF and the community to work together, at the start of the design cycle of a feature, on getting a suitable set of volunteers who could provide prolonged engagement during the development process. isaacl (talk) 21:36, 10 March 2022 (UTC)[reply]
Great idea. Like FRS but for WMF tech. Enterprisey (talk!) 00:40, 11 March 2022 (UTC)[reply]
I wasn't thinking of a notification service. I think for a given feature, the developers and community should agree upon types of users who could give useful feedback, and find volunteers who are willing to have ongoing discussions throughout the development process. This would allow the development team to have fast feedback cycles, enabling them to go through different options more rapidly. isaacl (talk) 00:49, 11 March 2022 (UTC)[reply]
The problem is that these people and more so their availability is highly unreliable. You can't plan around it, they don't answer fast enough, and they too are heavily biased. There have been plenty of WMF projects where WMF was nudged into a certain direction only to be recalled later by other volunteers. —TheDJ (talkcontribs) 09:09, 11 March 2022 (UTC)[reply]
Yes, I was going to say more on that aspect but omitted it for conciseness. There is of course no guarantee that any selected group would remain engaged; it can only be hoped that at any given opportunity, someone in the group will respond. As I mentioned, the received feedback should be considered carefully as one source of comments and not treated as absolute truth. isaacl (talk) 15:25, 11 March 2022 (UTC)[reply]
To echo what Enterprisey said, at least for DiscussionTools, the WMF has been soliciting feedback on the tool here on the various Village Pumps, at mw:Talk pages project/Replying, and in Tech News since early 2020. --Ahecht (TALK
PAGE
) 22:34, 10 March 2022 (UTC)[reply]
Ahecht, if DiscussionTools is the result of working closely with the community I may have been wrong. DiscussionTools is nice on the surface, if you don't care about features, customizability or resources. It's more convenient than source editing, but in some ways (philosophically, no idea if any code is shared) it's Flow in disguise, just not exposing the "structured" part of "structured discussions" to the end users (us), which some may actually consider to be a good thing. My main concerns with recent developments: DiscussionTools can't be disabled. (you can hide the links but not actually get rid of them) For IP masking several users asked on Wikipedia:Village pump (WMF)/Archive 4#How we will see unregistered users what we will see instead of IPs and similar and related questions on Wikipedia:Village pump (WMF)/Archive 4#New IP Masking implementation updates available also remained unanswered. Alexis Jazz (talk or ping me) 03:24, 11 March 2022 (UTC)[reply]
"you can hide the links but not actually get rid of them" This has more to do with the fact that we are going to more consistent Parser output for all users (less variance, hopefully one day, no variance) that with DiscussionTools. "what we will see instead of IPs" As far as I know that's exactly what they are figuring out right now, right ? —TheDJ (talkcontribs) 09:19, 11 March 2022 (UTC)[reply]
TheDJ, the kind of features that DiscussionTools adds can be accomplished with some very tiny extra HTML parser output instead of the massive bloat they implemented. From DiscussionTools that would be the data-mw-comment-end span tag. Their IDs are suboptimal but that's another matter, an ID is all you need in the HTML. IMHO the better solution is to actually fix signatures to become more machine readable, both in wikitext and when parsed, which would cause all required data to become part of the wikitext, and no parser adjustments would be needed. Somehow either nobody suggested this or they were ignored, either way, seems like a communication problem to me. And about IP masking, well, I don't know because the WMF developers don't have 2 minutes to state something like "the exact form of IDs for anons is not yet set in stone, the leading contender is X, we are also considering Y and Z" in a relevant WP:VPWMF discussion. @Certes: you keep better track of this than I do I think, please prove me wrong and tell me the WMF made a more informative statement since I last checked. Alexis Jazz (talk or ping me) 15:50, 11 March 2022 (UTC)[reply]
I've seen nothing but only really watch Wikipedia; there may be updates on Meta or MediaWiki. Masking doesn't seem to be happening quickly, so I'm hoping that it will prove infeasible and go away. Certes (talk) 18:31, 11 March 2022 (UTC)[reply]
Certes, you have (possibly unintentionally) demonstrated my point about the disconnect: I [...] only really watch Wikipedia. You are invested in Wikimedia, even knowledgeable about technical details and clearly interested in them, you're just not tuned into the channels the developers primarily use. You made three posts on Phabricator this year. Friction between developers and community would be expected when communication channels are not effective. Alexis Jazz (talk or ping me) 19:50, 11 March 2022 (UTC)[reply]
@Alexis Jazz: As you may have read in Tech News, the WMF just announced its intention to impose a session-based system. I suspect that it will be trivial to discard session information and start again with a clean slate, forcing us to ban unregistered editors and cut off our source of new contributors. Certes (talk) 22:44, 14 March 2022 (UTC)[reply]
I see they say "We do acknowledge that deleting a cookie is easier than switching an IP, of course, and do respect the effects it would have." I'd like to know how they respect the problems this will cause. Doug Weller talk 12:50, 15 March 2022 (UTC)[reply]
you can hide the links but not actually get rid of them – afaik, that's because at Wikipedia scale, "don't split the cache" is like "don't cross the streams". ⁓ Pelagicmessages ) 06:38, 17 March 2022 (UTC)[reply]
Pelagic, why is this crap in the cache to begin with? It shouldn't be! (I'm not saying the links shouldn't exist, but they shouldn't exist in cache) Alexis Jazz (talk or ping me) 23:40, 24 March 2022 (UTC)[reply]
I think you'll find that it's more complicated than that. AIUI anything and everything that is supposed to be in the HTML sent to an IP editor is supposed to exist in the cache. Having just one copy of each page in the cache is one of the reasons that the WMF does not have to hire thousands of engineers just to let people read. Running a site with this much traffic is not like running a little website, only with bigger numbers. Some rules of thumb just don't work when you extrapolate them to the level of half a billion page views every day.
(Anyone who really wants to know more might want to start reading at mw:Manual:Cache and wikitech:Caching overview.) Whatamidoing (WMF) (talk) 02:01, 25 March 2022 (UTC)[reply]
The reply tool is fantastic and was designed with lots of feedback from the community, I think it's a really good way of improving talk pages without changing the underlying wikitext structure. "It increases the size of the page slightly" is probably the most nit-picky feedback possible, anyone here could make a much larger change to the page size by adding a few images.
I don't think that the issue here is exclusively "the WMF doesn't get feedback", "the WMF gets the wrong feedback" is just as big of an issue. If you go and look at the original flow prototyping pages on meta/mediawiki I think the original focus group used to create the overall design consisted of 5 people who had never used a wiki before. Asking people who are (for want of a better word) completely ignorant about how consensus based wiki projects work to design one of it's most essential features is a recipe for disaster. The WMF seems to be so obsessed with recruiting new editors that they are willing to completely ignore the people who run the site on a day to day basis.
Final thought - they do seem to have gotten a lot better over the last few years (at least in terms of software development) and do seem to be making efforts to listen to the community, most of the big disasters were 5+ years ago. 192.76.8.70 (talk) 09:49, 11 March 2022 (UTC)[reply]
Images one could disable or load on click/hover/whatever. I know many people here probably don't care, but shouldn't we take those who don't have unlimited data and 10mbps+ broadband into consideration? Some people are still stuck on 1mbit/s ADSL (or worse) or pay per megabyte, even in developed countries. (granted there are people who have no access to the internet at all, some not even to clean drinking water, but that's another issue) Now if the additional HTML was actually necessary to achieve the goal, that would be a fair argument. But it isn't. The HTML (just the HTML, don't get me started on the API call) that gets added currently is about 95% bloat. Actually I'm rounding down from 95.3%, this is not a number I'm pulling out of thin air. (if anyone has doubts I can share my homework) So if this is the result of close collaboration with the community, I was dead wrong thinking community involvement would improve things. (either that or it would have been even worse without the community involvement) And while I don't know about all the disasters from 5+ years ago, I know that structured data and crosswiki uploads are an ongoing train wreck. And here's another thing that worries me: mw:Talk pages project states Some features may involve introducing new wikitext. Although, any changes to wikitext will be limited to those that enable new features that benefit contributors. Features like replying to specific comments or watchlisting particular discussions. This could align with what I'm doing, but given the current state and direction of DiscussionTools I'm sure they'll find a way to mess it up, maybe even break my efforts in the process. And this Google doc from phab:T273341#7539540 worries me even more. There's the wikitext, which is easily publicly accessible and can easily be copied/forked/analyzed/etc and there'll be a shadow ledger which won't be so easy to copy/fork but the dependency on it will just keep increasing. The WMF developers still want wikitext to be something it's not. They still want Flow. Maybe that's what the community told them during the collab sessions, in which case I guess I'd have to eat my humble pie. Alexis Jazz (talk or ping me) 19:33, 11 March 2022 (UTC)[reply]
"It increases the size of the page slightly" is probably the most nit-picky feedback possible, It certainly does. Examining the HTML that is served, I find that every single post has gained several hundred extra bytes, in the form of five extra <span>...</span> elements (one at the start of the post, the rest after the timestamp) and one <a>...</a> element (the reply link itself). This is present even if you have disabled the feature. --Redrose64 🌹 (talk) 22:10, 11 March 2022 (UTC)[reply]
As a point of fact, the [reply] tool was created as the result of the mw:Talk pages consultation 2019. During that five-month, multilingual, multi-wiki consultation, hundreds of editors shared their opinions about what should be built (and not built). @Alexis Jazz, I believe you were mostly editing at Commons then: c:Commons:Talk pages project 2019 was not especially well-attended despite multiple announcements and people linking to it in other discussions (e.g., [1][2][3]). Commons contributors mostly seemed to post at the central discussion rather than the project-specific page. The English Wikipedia's local page is at Wikipedia:Talk pages consultation 2019/Phase 1 and Wikipedia:Talk pages consultation 2019/Phase 2. Between the two discussions here at the English Wikipedia, I think we had something like 150 editors posting 900 comments – just in this one community. Overall, there were thousands of comments from at least 600 editors in at least 20 languages at more than 20 wikis. Since then, there have been dozens of discussions about specific details, at this wiki and also at other wikis. Multiple features inside the [reply] tool exist because volunteers asked for them after the project started, including the ability to add a custom edit summary and an extra button for adding the page to your watchlist. As for its success, I notice that SineBot has made fewer edits since this tool was deployed last Monday.
The visual editor, too, was requested by volunteers. The first request that I'm personally aware of was made in 2004 (i.e., before most of us here created our accounts). The decision to create a visual editor was taken during the original 2009–2010 strategy: process, which lasted more than one year and involved editors from around the globe. The idea of creating a visual editor was one of the most strongly supported proposals during those discussions. The visual editor was IMO deployed too soon, and they did not take my advice to deploy it at another wiki first (the English Wikipedia's articles have the most complex formatting, and therefore is IMO not the right place to begin deployment of any new article-editing tools), but these subsequent mistakes do not change the fact that this idea originated from volunteers. At this point, the visual editor is relatively popular, with half of newly registered editors choosing the visual editor for their first edits at this wiki (there's a far higher percentage at some other Wikipedias) and the visual editor being used approximately once for every two edits made in the 2010 wikitext editor here at the English Wikipedia. Even people who dislike the concept of a visual editor on principle would rather add, delete, or rearrange columns in a table by clicking three times in the visual editor than manually typing the wikitext code on each line of the table.
The original name for Flow was "LiquidThreads version 3". LiquidThreads was originally proposed by a volunteer, in response to the English Wikipedia's WikiProject Aircraft voting to hold their discussions off wiki. At that time, the WMF had zero staff. The first version was written by a volunteer. The conceptual shift from LiquidThreads version 2 (which is still used at Wikinews) to "Flow" (so named because it was meant to support a Workflow pattern built by local admins and tech volunteers, rather than being restricted to simple discussions) was the request to make it capable of handling Wikipedia:Articles for deletion and Wikipedia:Arbitration/Current (imagine a world in which ArbCom clerks didn't need to manually count the votes). IMO it never got far enough to show its real promise for managing workflows, but the goal was to extend existing, volunteer-conceived software to meet the needs of existing volunteers. Even in its limited discussion-only state, Flow has been popular in some communities (not, however, this one).
I would like to particularly encourage everyone here to offer the kind of "practical" feedback that Alexis suggests above. Yes, we're apparently stuck with some things, and other things are built because other communities requests them (or other parts of this community – the newcomers at the Teahouse probably benefits more from the auto-signing and auto-indenting [reply] tool than the regulars at VPT, after all). But I'm certain that, no matter which product is being discussed, that a clear articulation of needs and goals would be helpful and very much appreciated.
If you have any experience with writing a User story, then I've found that to be an effective model when talking to product managers. The idea is to say what you want to accomplish rather than how you want to accomplish it. To give an extreme, but hopefully illustrative, example, you want to write something like As a RecentChanges patroller, I want to know whether this new person is likely to speak English well, so I can share relevant advice (e.g., a link to WP:EMBASSY or a link to a help page written in the dominant language of their country) or As an admin calculating a block range, I need to know what IP range this vandal is using, so that I can block the correct range. What's not useful is As a RecentChanges patroller, I need to know the editor's IP address because that's how we've always done it. Goal-oriented stories sometimes result in magic buttons that say things like "☑︎ Block the nearby IPs, too". Whatamidoing (WMF) (talk) 19:08, 14 March 2022 (UTC)[reply]
Whatamidoing, I respect this deeper look into things. Some interesting stuff. As for the success of VE, in numbers I don't doubt it (and whatever is the default will gain market share anyway) but phab:T304303 should have never existed. Due to outstanding bugs that went unfixed for years (what's new?), Wikisource is saying "goodbye VE". Your text deserves a more useful response, but I'm still pondering where it all went (and goes) wrong. I think I'm slowly starting to see and getting some ideas. But that conversation can't be initiated by me (you'll have to ask for it), and VP idea lab might not be the ideal place for it, and it wouldn't be an easy conversation.. to put it mildly. Alexis Jazz (talk or ping me) 00:09, 25 March 2022 (UTC)[reply]
The Editing team never deployed the visual editor to any of the Wikisources precisely because of the difficulty of integrating it into ProofreadPage. It's still in Beta Features, opt-in only, for everyone. The integration was always going to be a volunteer-led project. If the volunteers there aren't keen on it, that's okay, too. The visual editor was designed for Wikipedia articles, not to be all things to all people. Whatamidoing (WMF) (talk) 01:52, 25 March 2022 (UTC)[reply]
I think the IP-masking reps have been making significant efforts to engage, but the change they're tasked with is fundamentally more distasteful to the communities than DiscussionTools, so they are stuck pushing it uphill. ⁓ Pelagicmessages ) 06:49, 17 March 2022 (UTC)[reply]
Pelagic, they tried to engage, but when questions are asked (like "what's it gonna look like?") in response to that the WMF goes quiet. Even if they have no answers yet, just saying that would help a lot. Alexis Jazz (talk or ping me) 22:23, 18 March 2022 (UTC)[reply]
I hear that the team is trying to set up a working version on one of the test wikis. My guess is that you can take a look at the first version in a few weeks. Since you'd need admin rights on the test wiki to see what the admins see, there'll probably be some sort of sign-up process. Watching their project page is probably the best way to keep track of when that happens. Whatamidoing (WMF) (talk) 21:30, 21 March 2022 (UTC)[reply]
Whatamidoing, I'm more interested in what I'll see as a user anyways. One of my scripts will need to be adjusted, but I can't do anything until I know what it'll be like. Alexis Jazz (talk or ping me) 23:44, 24 March 2022 (UTC)[reply]
I imagine the interface will be similar for both. You might want to sign up. Whatamidoing (WMF) (talk) 01:44, 25 March 2022 (UTC)[reply]
Whatamidoing, no interface. I separate users from IPs with a regular expression. This will no doubt break. Alexis Jazz (talk or ping me) 18:24, 25 March 2022 (UTC)[reply]

Proposed additions to the Main Page

The purpose of this RFC is determine what sections should be added and removed from the Main Page. I have identified a few features missing from the main page which would make Wikipedia more interactive. Other editors are welcome to add proposals here. Interstellarity (talk) 20:57, 19 March 2022 (UTC)[reply]

Proposal 1: Add links to the level 1 vital articles to replace portal links on the top right

This change would show that the purpose of the vital articles project is for readers and not editors.

Support
  1. Interstellarity (talk) 20:57, 19 March 2022 (UTC)[reply]
Oppose
  1. Oppose the WP:VA is more of a WikiProject than anything else. Whilst they are some of the most important articles, the VA list shouldn't be commented on from the main page. Best Wishes, Lee Vilenski (talkcontribs) 23:25, 19 March 2022 (UTC)[reply]
  2. Oppose. Not so quick. Community awareness is too low on WP:VA, there are oddities and niche perspectives. But consider. —SmokeyJoe (talk) 21:25, 22 March 2022 (UTC)[reply]
Neutral
Discussion

Proposal 2: Add a list of the most popular articles of the week

I'm always interested in what articles are popular every week and it might incentivize experienced editors to improve the articles.

Support
  1. Interstellarity (talk) 20:57, 19 March 2022 (UTC)[reply]
Oppose
  1. This sounds like a "trending" feature. Self-referential rankings like this don't belong in the mainspace. If you have it on the Main Page, I fear it will attract inexperienced editors, a spectrum of inept AGF edits and vandalism to the articles, and a lot more work for the experienced editors on presumably heavily-edited articles. – Reidgreg (talk) 22:50, 21 March 2022 (UTC)[reply]
  2. Oppose. Instead add a small discreet link to Wikipedia:Top 25 Report at the bottom of the In the news section. —SmokeyJoe (talk) 21:23, 22 March 2022 (UTC)[reply]
    had no idea this existed. Thank you for linking it. Star Mississippi 00:31, 25 March 2022 (UTC)[reply]
    Like with all things, the person who does it louder and later gets all the credit. [FBDB] casualdejekyll 07:47, 27 March 2022 (UTC)[reply]


Neutral
Discussion

Proposal 3: Add quizzes throughout the Main page

I think creating quizzes on Today's featured article, In the news, as well as Today's featured picture would be great because I like to test my knowledge to see what I know about the article.

Support
  1. Interstellarity (talk) 20:57, 19 March 2022 (UTC)[reply]
  2. YTKJ (talk) 18:45, 20 March 2022 (UTC) Yes, this sounds like a fun addition to Wikipedia.[reply]
Oppose
  1. User:力 (powera, π, ν) 23:18, 19 March 2022 (UTC)[reply]
  2. completely against the point of Wikipedia. Best Wishes, Lee Vilenski (talkcontribs) 23:21, 19 March 2022 (UTC)[reply]
  3. Oppose, per Lee. RudolfRed (talk) 20:24, 20 March 2022 (UTC)[reply]
  4. Oppose, per Lee.--User:Khajidha (talk) (contributions) 20:34, 20 March 2022 (UTC)[reply]
  5. Nah, but why nah? One, this would require some software work, and software developers are in short supply. If someone really wants to write a quiz extension lets see what it looks like first. If someone wants to write this as a javascript - lets see the example again. This would require volunteers to write and maintain questions and answers. Now, if some wikiproject really really wants to do this, and do it as a script, then maybe I'd be ok with it being an opt-in / onclick load gadget. But would want to see some proof of concepts on both the software and the process first. — xaosflux Talk 21:17, 20 March 2022 (UTC)[reply]
    A first iteration doesn't even need to be interactive: just have the questions and answers on separate pages. I agree before considering it for the main page, there should be a track record of the quiz creation process running regularly and smoothly. (I don't know if the Signpost is interested in a column like this; it could be a place to try it out.) isaacl (talk) 21:34, 20 March 2022 (UTC)[reply]
    The software already exists; see mw:Extension:Quiz. It's used at both Wikibooks and Wikiversity, and maybe other places. For the record, just because the software exists does not mean that it can be used on the largest wiki in the world. But if you wanted it (for any reason, not necessarily for this proposal), we could ask. Whatamidoing (WMF) (talk) 18:43, 21 March 2022 (UTC)[reply]
    Good to know there is an applicable extension. Personally I'd like see a consistent record of producing non-interactive quizzes and that there is an interested audience before requesting that an extension be installed. isaacl (talk) 23:20, 21 March 2022 (UTC)[reply]
Neutral
  1. I like the idea in general. Quizzes are fun, and add interest. Even the NY Times has a weekly news quiz. But before we can consider putting it on the front page, the idea should be tested somewhere else to see how well it works. -- RoySmith (talk) 18:54, 21 March 2022 (UTC)[reply]
  2. Quizes, yes. On the Main page, no. Link from the main page? Yes, trial it. —SmokeyJoe (talk) 21:27, 22 March 2022 (UTC)[reply]
Discussion

Proposal 4: Add Browse by category at the bottom of the Main Page so readers can look for a specific article without using the search engine

There will always be readers that are not quite sure what article they are looking for. Having basic categories like People, Science, Technology, and Society would make the user interface more usable rather than using the old-fashioned categories.

Support
  1. Interstellarity (talk) 21:02, 19 March 2022 (UTC)[reply]
Oppose
  1. I don't think throwing a reader at Category:People is going to be very useful. The category system is decent for finding related low-level topics, but not so much for browsing such broad categories such as those proposed. — xaosflux Talk 21:20, 20 March 2022 (UTC)[reply]
Neutral
Discussion

General discussion

Stubs and notability

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.

With all the vast discussion about stubs being "microstubs" or "permastubs", and all the arguments about whether they meet this NG or that NG, surely we should be seeking measurable standards that will reduce all the discussion and argument? The following is still only an idea, which is why I've come here instead of to the proposals page:

  1. Any new article must have a readable prose size (WP:RPS) of at least 500b (half a kilobyte) so that there will be around 100 words and maybe four of five lines of text. I think it is better to set a byte size limit instead of a word limit because of varying word lengths. Other content like short description, hatnotes, infobox, images, reflist, categories, stub notices, etc, are extraneous – RPS means the narrative (the readable prose) only.
  2. All content must be sourced per WP:V and WP:RS. Preferably with inline citations per WP:CITE but I wouldn't absolutely insist on that at the outset because stubs are often created by newbies who might struggle with CITE format.
  3. Unless a book source is used, there must be at least TWO reliable sources. With pre-internet subjects, a book might be the only source available and, unless there is reason to believe the book may be non-RS, it should be accepted as the sole source for the present. With post-internet subjects, I think it is fair to insist on two internet/newspaper sources if no book is available.
  4. If two internet sources are referenced and one them is a database, the other must be a non-database source such as a news site.
  5. The subject must meet the specific notability criteria (WP:SNG) set by the relevant project – e.g., WP:NFOOTY – and this criteria must set a recognisably HIGH standard of achievement. Using NFOOTY for example, playing in a Tier 1 international or in an FPL that is equivalent to the Premier League or the EFL; but not playing for non-league teams, or for reserve teams, or for youth teams, or in non-competitive matches, etc.
  6. If the subject does not meet any project's SNG, it must meet the wider definition of notability described in WP:GNG. This provides a safety net for notable subjects that are exceptional to project interest. As for why SNG should be considered ahead of GNG, the specific is more definable and demanding than the general and must therefore take priority. The caveat for the SNG is that it must set a recognisably high standard that has WP:CONSENSUS.
  7. Any stub that does not meet these conditions is subject to immediate WP:CSD which can be set by any experienced editor (say, anyone with 1,000-plus edits over a period of at least six months). This measure will provide an enormous time save at AfD.
  8. Any stub that meets the conditions as a new article must be expanded within twelve months of creation to at least 1 kb RPS with complete reliable sourcing, such that it earns class=start. If not, it can be taken to AfD for the community to decide if it should be retained as a stub. Some subjects can, of course, be highly notable but with very little to be said about them.

This idea would doubtlessly be a compromise solution if implemented. I can see where opposition might come from but I think anything which cuts back on all the arguments at AfD is definitely a way forward for us all. Happy to discuss. Please ping me if you want to ask me anything. Thanks for your time. No Great Shaker (talk) 16:20, 22 March 2022 (UTC)[reply]

Thank you for your feedback, WhatamIdoing. I take your points on board and I must agree with you. Btw, what you are doing is a good job. No Great Shaker (talk) 09:32, 23 March 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.

Future discussion on improving our management of geostubs

Hi! Repeatedly in discussions people raise the issue that the amount of permastubs about villages due to NGEO is not being handled in the best way possible. While WP is not a paper wikipedia, there are various concerns that having a large minority of articles be villages in third-world countries where our own sourcing bias (see Geographical bias on Wikipedia) prevents us from improving many of these articles or preventing misinformation due to very high ratios of articles to geo content patrollers (the Iranian Well issue comes to mind, for example, and I expect there to be other less absurdly flagrant content mistakes). On the other hand, there is no policy against the existence of stubs even in a permanent state. Additionally, I think we can all agree that having information on developing world villages is beneficial both to our readers and companies that use Wikipedia for their services. With the increased success of Wikidata (as much as we might not admit that very often here), this "loss of information" fear from altering how we manage these stubs seems less reasonable (but still valid). I wonder as well if redirecting impacts the accessibility of this information.

With all this in mind, I was wondering if y'all could help by giving your thoughts on the issue, including past discussions I am not aware of or ideas on how to fix the problem. A. C. SantacruzPlease ping me! 11:23, 23 March 2022 (UTC)[reply]

Geostubs break

A fair number of valid entries would be removed, but very little information would be lost. Aymatth2 (talk) 14:30, 27 March 2022 (UTC)[reply]
Deletion without manual review is basically never accepted. Also, how many articles do you think would be in such a list? I took at look at half a dozen articles about unincorporated communities (all in the US) just now, and all of them had been edited in the last 9 months. WhatamIdoing (talk) 21:24, 28 March 2022 (UTC)[reply]
I suppose the gnomish edits tend to obscure real activity. So how about we dropped the "last edit" criterion and PROD the articles? The idea is to clear away stubs that say only "Foo is a place in Finland". Don't know how many of those there are. Aymatth2 (talk) 12:04, 29 March 2022 (UTC)[reply]
Perhaps add "Is more than five year old". Aymatth2 (talk) 13:27, 29 March 2022 (UTC)[reply]

Proposal

Thank you all for your comments, they have been very instructive. I'll work on a proposal for the next few days to see if there is consensus to change some guidelines to deal with some of the problems identified in this thread. A. C. SantacruzPlease ping me! 12:24, 29 March 2022 (UTC)[reply]

What are the different types of geostubs, in terms of quantity and type of information? Has this ever been categorized formally? A. C. SantacruzPlease ping me! 09:22, 30 March 2022 (UTC)[reply]
Geostubs will all be indirectly in Category:Geography stubs. This PetScan query lists all articles in this category to a depth of 5, which probably is not deep enough, giving 682,896 results. It runs very slowly. Probably better to start at the country level, e.g. Category:France geography stubs, A query for France, 5 deep, at https://petscan.wmflabs.org/?psid=21772838, sorted by size gives 40,889 results, starting with the 260-byte Clément, French Guiana, which informs us that Clément is a town in French Guiana, and gives coordinates. OpenStreetMap has never heard of it and Google shows nothing but forest at the coordinates. Aymatth2 (talk) 13:33, 30 March 2022 (UTC)[reply]

Aguaxima, a plant growing in Brazil and on the islands of South America. This is all that we are told about it; and I would like to know for whom such descriptions are made. It cannot be for the natives of the countries concerned, who are likely to know more about the aguaxima than is contained in this description, and who do not need to learn that the aguaxima grows in their country. It is as if you said to a Frenchman that the pear tree is a tree that grows in France, in Germany, etc . It is not meant for us either, for what do we care that there is a tree in Brazil named aguaxima, if all we know about it is its name? What is the point of giving the name? It leaves the ignorant just as they were and teaches the rest of us nothing. If all the same I mention this plant here, along with several others that are described just as poorly, then it is out of consideration for certain readers who prefer to find nothing in a dictionary article or even to find something stupid than to find no article at all.

My study (which classified 277 of 1,000 articles as "geographic, broadly construed") was not that granular, but I did pick up some impressions from reviewing those 270. Also from my New Page Patrol work:

Also, because a deletion at AFD requires "proving a negative" that suitable sources don't exist, and an English speaking editor is typically unable to do that for an article when it's in a country where the primary media are Non-english and so borderline ones tend to stay....not just due to AFD results, but also due to editors never even taking them to AFD for that reason.

Again, I don't consider the maybe 200,000 or 500,000 current geostub articles to be a big problem. Geography is a very enclyclopedic topic. The big problem is that that could easily jump to 5,000,000.

(BTW, just to make sure my big "277" doesn't mislead, "broadly construed" included edge cases like facilities and planets.)

Sincerely, North8000 (talk) 13:45, 30 March 2022 (UTC)[reply]

For Category:United States geography stubs PetScan gives 130,527 results at 5 deep, 132,059 results at 7 deep, probably deep enough to get almost all of them, starting with the 261-byte Makaokahaʻi Point, a jutting headland on the south coast of the island of Kauai in the Hawaiian Islands. I do not know an efficient way to separate human geography stubs like villages, railway stations etc. from physical stubs like streams, hills etc. The United States has 4.25% of the total world population and 6.1% of world landmass. Perhaps it has 5% of world geography, giving 2,610,540 potential geostubs worldwide at the same level of coverage. But see Rivers of Lake County, California: there is potential to greatly increase the number of United States geostubs. We could be looking at over 20 million worldwide. Aymatth2 (talk) 14:46, 30 March 2022 (UTC)[reply]
Aymatth2 and North8000 I've done some initial research into the number of geostubs in proportion to geo articles for various countries at User:A. C. Santacruz/Research/Geostubs. The picture right now does not look very good... I'm not entirely sure how one would find the ratio of stubs per editor actively patrolling stubs for accuracy but I imagine it is unmanageably high based off this first impression. A. C. SantacruzPlease ping me! 14:34, 31 March 2022 (UTC)[reply]
@A. C. Santacruz: I thought the ratio of stubs to real articles was much worse than you have found, so in a sense this is encouraging. Short geo articles do not bother me if they are accurate and give some useful information. But I suspect that in some areas there are no editors checking the stubs at all. See Clément, French Guiana. Does this place exist? An editor could waste a fair amount of time before finding that the French government Géoportail does show something called Clément at those coordinates. They leave the stub, even though it is useless. Then a few years later another editor repeats the check... Aymatth2 (talk) 15:57, 31 March 2022 (UTC)[reply]
Yeah, the articles so far are from 3 very urbanized countries. I'll add India and Iran later, I expect those to be much worse. A. C. SantacruzPlease ping me! 16:10, 31 March 2022 (UTC)[reply]
North8000 that study sounds interesting, where can I read it? In terms of quantity of information I was wondering like, if someone had ever gotten some data on like, the distribution of article sizes within geostubs and the such. A. C. SantacruzPlease ping me! 14:42, 30 March 2022 (UTC)[reply]
@A. C. Santacruz: I have all of the data up at User:North8000/Display and am starting to add summaries etc. Sincerely, North8000 (talk) 14:49, 30 March 2022 (UTC)[reply]

?!

?! has no meaning behind it. or at least not for most people, for some people it means waiting for the end. what there waiting for the end of is unkown for now. should anyone find another meaning then that i would like to know what it is so please feel free to make changes or add to it. — Preceding unsigned comment added by Jevin clarin (talk • contribs) 03:48, 25 March 2022 (UTC)[reply]

I suspect you have posted this on the wrong page, and/or on the wrong website entirely. Whatever you are trying to say, it seems to have no relevance whatsoever to the stated purpose explained above. This is not a forum for vague comments about random punctuation marks, it's sole purpose is the discussion of ideas directly related to how Wikipedia creates and maintains content. AndyTheGrump (talk) 04:05, 25 March 2022 (UTC)[reply]
@Jevin clarin: Looks like your comments are possibly intended for Talk:Interrobang? ––FormalDude talk 04:43, 25 March 2022 (UTC)[reply]

Template for Old Style and New Style dates

There are many articles that use old style (O.S.) dates as opposed to new style (N.S.). I'm working on a few articles that use O.S., and I noticed that reliable sources often used one of the styles, or both. If exact dates are necessary, both O.S. and N.S. should be displayed using Template:OldStyleDate. However, if the dates aren't exact (years and months only), we enter a dilemma: months are also different with O.S./N.S. dates. For instance, if a certain event happened in October 27 (O.S.) but only "October" is displayed, readers and editors will be unsure as to whether the month is N.S. or O.S.; the date mentioned would be November 9 in new style, but, if an event happened in, say, October 10 (O.S.), it would still be October in N.S. (October 24). Using Template:OldStyleDate on each date only introduces clutter, and so is using explanatory footnotes of O.S./N.S. on each date, which WP:OSNS seems to allude to inciting in these circumstances. To resolve this issue, I thought of creating two templates akin to how "Template:Use dmy/mdy" works. My idea is "Template: Use O.S./N.S.". The latter templates, just like the former, should guarantee uniformity in articles that use either O.S. or N.S. instead of relying on messy explanatory footnotes and extensive use of the OldStyleDate template in events that occur prior to a calendar change. This idea is still in an embryonic state, and scrutiny is welcomed. Wretchskull (talk) 20:06, 27 March 2022 (UTC)[reply]

IPA Help passthrough

The (perceived) problem: Despite my best efforts, my brain refuses to memorize the IPA pronunciation symbols, so I often need to click through to the Help:IPA/English page (in a new tab) to figure out pronunciation. Flipping back and forth to decipher each symbol is both time-consuming and frustrating, especially with long or complex names.

Proposed solution: I propose that when clicking on an IPA pronunciation in an article, the original IPA from the article page should appear with the IPA help page, either as a highlighted static element near the top of the page, or a non-scrolling element that hovers above the page. This way, the symbols can be deciphered without having to jump back and forth between pages.

More technically, the original IPA could be passed as a urlencoded HTTP GET argument in the target URL, and the Help:IPA page could decide how best to display the source IPA (including any relevant localizations or user preferences). Although I've never looked at Wikipedia's code, it seems like it should be straightforward to automate the process of updating existing IPA->Help:IPA links to include the source IPA as an argument. — Preceding unsigned comment added by Quiescat (talk • contribs) 15:11, 28 March 2022 (UTC)[reply]

On desktop you can hover your mouse cursor over the transcription to see tooltips like "/ə/: 'a' in 'about'". You may also use Þjarkur's IPA popups script, which seems similar to what you suggest. Nardog (talk) 15:34, 28 March 2022 (UTC)[reply]
Thanks, I didn't know about the hover text! However, on a 4K monitor, trying to hover over a specific symbol is tricky at best (and, of course, it doesn't work on a touchscreen), I'm having some trouble getting the IPA popups script to work; I'll continue messing with it later. Thanks for the pointers. Quiescat (talk) 16:04, 28 March 2022 (UTC)[reply]
When I'm stuck, I copy and paste it to an external website that "speaks" the word for me. WhatamIdoing (talk) 21:26, 28 March 2022 (UTC)[reply]
There's a script that assists you in doing that as well FWIW (the site it relies on is pretty good too). Nardog (talk) 12:49, 29 March 2022 (UTC)[reply]

Leadership Development Working Group: Reminder to apply by 10 April 2022

You can find this message translated into additional languages on Meta-wiki.

Hello everyone,

The Community Development team at the Wikimedia Foundation is supporting the creation of a global, community-driven Leadership Development Working Group. The purpose of the working group is to advise leadership development work. Feedback was collected in February 2022 and a summary of the feedback is on Meta-wiki. The application period to join the Working Group is now open and is closing soon on April 10, 2022. Please review the information about the working group, share with community members who might be interested, and apply if you are interested.

Thank you,

From the Community Development team


Posting here following the original VPM announcement. I can see this working group functioning as a sustained idea lab of sorts.

The working group would benefit from the membership and participation of users who help generate and move ideas forward here. Xeno (WMF) (talk) 20:18, 29 March 2022 (UTC)[reply]

Portal:Yoga

Hi, I am very much active in sa.wikipedia. I want to request you all if you create Yoga portal, it will be a great job. If you make it here, I will try to make in sa.wiki also. Please help, if you can. Thanks.NehalDaveND (talk) 01:55, 1 April 2022 (UTC)[reply]

@NehalDaveND: Instead of creating a new Portal, I suggest you join the Yoga Wikiproject Wikipedia:WikiProject Yoga. RudolfRed (talk) 02:52, 1 April 2022 (UTC)[reply]
Thanks. I didn't aware about the project. I will try to do it in sa.wiki. Thanks again. NehalDaveND (talk) 02:22, 2 April 2022 (UTC)[reply]

Music genre discussion forum

I'd like a forum where you can post a song and have people discuss its genre. If this already exists, just link me to it. Wtoteqw (talk) 18:24, 2 April 2022 (UTC)[reply]

That would not be compatible with the policy at WP:NOTFORUM. - Donald Albury 18:54, 2 April 2022 (UTC)[reply]
@Wtoteqw: Because you posted this in other places as well, see WP:MULTI. --Redrose64 🌹 (talk) 19:02, 2 April 2022 (UTC)[reply]

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. Face-smile.svg 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. Face-smile.svg 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]
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]

Simple English Wikipedia

Simple wiki isn’t on the Wikipedia main page, and I don’t see it often in google searches. How is one supposed to find it?

(the proposal is adding it to the main page) – AssumeGoodWraith (talk | contribs) 03:07, 5 April 2022 (UTC)[reply]

It is not the job of English Wikipedia to promote any other language versions, even Simple English. The decision to link directly to other language versions of Wikipedia from the main page should be based on number of articles and number of page views. Cullen328 (talk) 03:18, 5 April 2022 (UTC)[reply]
If a reader wants to find the Simple English Wikipedia, then they surely can type "Simple English Wikipedia" into the Google (or Bing) search boxes, or type the same text into the English Wikipedia search box, which yields Simple English Wikipedia, an article with an external link. It isn't tough. Cullen328 (talk) 03:24, 5 April 2022 (UTC)[reply]
I don’t mean the people who know it exists. If someone could use simple wiki, but doesnt know it exists, where would they find it? – AssumeGoodWraith (talk | contribs) 04:51, 5 April 2022 (UTC)[reply]
I don’t know if this is the right place, but I meant wikipedia.org, not en.wikipedia.org. – AssumeGoodWraith (talk | contribs) 04:47, 5 April 2022 (UTC)[reply]
This is probably a better query for Meta. Curbon7 (talk) 06:07, 5 April 2022 (UTC)[reply]
@AssumeGoodWraith: It is in the Wikipedia main page, between Русский and Slovenčina. Where did you expect it to be? --Redrose64 🌹 (talk) 13:58, 5 April 2022 (UTC)[reply]
Any if @AssumeGoodWraith is talking about www.wikipedia.org - that is also limited to the biggest sites, and not something that the English Wikipedia manages. — xaosflux Talk 14:21, 5 April 2022 (UTC)[reply]
It's also in https://www.wikipedia.org/ provided that you click on Read Wikipedia in your language, it's under the 100 000+ articles heading between Română and Slovenščina. --Redrose64 🌹 (talk) 14:48, 5 April 2022 (UTC)[reply]