Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
- Table of contents
- First discussion
- End of page
- New post
The proposals section of the village pump is used to offer specific changes for discussion. Before submitting:
- Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
- This page is for concrete, actionable proposals. Consider developing earlier-stage proposals at Village pump (idea lab).
- Proposed policy changes belong at Village pump (policy).
- Proposed speedy deletion criteria belong at Wikipedia talk:Criteria for speedy deletion.
- Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
- Proposed new wikis belong at meta:Proposals for new projects.
- Proposed new articles belong at Wikipedia:Requested articles.
- Discussions or proposals which warrant the attention or involvement of the Wikimedia Foundation belong at Wikipedia:Village pump (WMF).
- Software changes which have consensus should be filed at Phabricator.
Discussions are automatically archived after remaining inactive for nine days.
RfC: Bot to blank old IP talkpages
- The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
Should a bot be used to blank old IP talkpages which:
- Have not received any messages in the last 5 years
- The IP is not under active blocks (including range blocks)
- There have been no edits from the IP in the last 5 years
Pages that meet this criteria will be blanked and replaced with {{Blanked IP talk}}, which reads
—ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 04:31, 10 May 2022 (UTC)
- Background
There are millions of IP talkpages with vandalism warnings received since the earliest days of Wikipedia. Recent vandal warnings serve a useful purpose, but warnings from very long ago are detrimental as there is a high chance that the IP address would have shifted to different users. Stale warnings and other messages will confuse legitimate new editors editing from that IP seeing it apparently directed at them. Blanking the page and replacing it with {{Blanked IP talk}} template will avoid confusing legitimate editors, while still allowing access to potentially useful edit history.
Other benefits of this task will include uncluttering the Special:WhatLinksHere data for pages across all namespaces. Stale IP talkpages contains millions of links to articles, policy pages and their associated redirects, User pages, User talk pages, templates etc,. They will be cleaned up with this task.
This will involve the bot editing at least 1.5 million pages. If consensus is found for this proposal, I (or anyone else) can use a bot to implement it, subject to the normal WP:BAG approval from the Bot request for approval process.
Here are some sample edits: [1], [2], [3] —ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 08:22, 11 May 2022 (UTC)
Survey (iptalk blanker bot)
- Support, as proposer. I believe the criteria is a safe base for a bot to work from. We can discuss the bot's techincal implementation details, its handling of edge cases and see if any minor changes are necessary during the WP:BRFA process. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 08:37, 11 May 2022 (UTC)
- Support. I understand some concerns raised in the discussion, and think that we can proceed cautiously by having such a bot begin by focusing on very old IP talk pages (e.g., the IP has neither edited nor been blocked for over 12 years, and the page has not been touched in that time), and once those are done, evaluate any surprises and move the limit up a year, and proceed that way until we get to the five year range. BD2412 T 05:54, 12 May 2022 (UTC)
- Weak support I still have reservations over the matter, as I noted in the WP:VPIL discussion, but at least I have a sense that those reservations are also in the minds of the BotDevs and will be taken into account. --Jayron32 18:08, 13 May 2022 (UTC)
- Oppose Not worth it, especially given that IP masking is happening soon. * Pppery * it has begun... 18:13, 13 May 2022 (UTC)
- One does not simply get to roll out IP masking. Major changes like that take a long time to happen. Many things about it is still not clear and WMF has yet to give a timeframe for implementation. Even after IP masking is rolled out at some point, stale IP talkpages will continue to pose a maintenance burden. A substantial portion of the existing millions of Lint errors is because of IP talkpages. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 19:19, 13 May 2022 (UTC)
- Support - seems a reasonable approach and looks like it's being handled sensibly. Andrew Gray (talk) 17:43, 14 May 2022 (UTC)
- Support. I see no reason as to why decade old IP talk pages shouldn't be templated out automatically, saving much time and manual effort, I sometimes find in RecentChanges. —CX Zoom[he/him] (let's talk • {C•X}) 18:08, 14 May 2022 (UTC)
- Support. There is indeed too much of a maintenance burden with these old IP talk pages. Blanking them / Blanking with template will reduce this while also making the what links here a bit more useful again. --Gonnym (talk) 20:18, 14 May 2022 (UTC)
- Neutral I guess. Is this an actual problem, or a solution in search of a problem? I personally haven't experienced this as a problem for me. Maybe it's OK to see that there've been vandal warnings going back ten years, as this could indicate that it's like a static IP for a school, if being aware of that even matters... which probably not. I suppose it's more just clutter, and cleaning up clutter is OK too. Not important IMO, but perfectly OK to do if desired. Herostratus (talk) 22:29, 23 May 2022 (UTC)
Discussion (iptalk blanker bot)
- I think I still prefer a subst'd type version of that simple template, so as to not add over a million instances of a template out there (which drags along another template, which drags along a module, etc). — xaosflux Talk 10:40, 10 May 2022 (UTC)
- My preference for using a transcluded template is that if we have to change something due to future software changes (say the
{{FULLPAGENAMEE}}
magic word or some table markup), we can just update one page instead of having a bot go around changing substed uses. If the associated templates and modules are a concern, a compromise will be to hardcode {{Blanked IP talk}} to not use any other templates and modules. However note that every template and module used by {{Blanked IP talk}} is already used heavily enough to be under full protection. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 11:06, 10 May 2022 (UTC)- I have gone ahead and hardcoded most of the template, with no change in text. Previously it used 7 other templates and modules, now it uses only one. When reading this page from mobile, I realised the old template did not render in mobile due to it using
tmbox tmbox-notice
classes. Now it renders in mobile too. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 16:39, 15 May 2022 (UTC)
- I have gone ahead and hardcoded most of the template, with no change in text. Previously it used 7 other templates and modules, now it uses only one. When reading this page from mobile, I realised the old template did not render in mobile due to it using
- My preference for using a transcluded template is that if we have to change something due to future software changes (say the
- Question, what if the IP talk page hasn't received any actual warnings in 5 years, but their talk page got vandalized by another IP or a user before that 5 years happened, and no one noticed? Maybe the bot should look to see if there were any new warnings placed on the talk page in 5 years? ― Blaze WolfTalkBlaze Wolf#6545 14:13, 10 May 2022 (UTC)
- The idea is to remove all stale messages from inactive IP talkpages, not just warnings. This is why {{Blanked IP talk}} uses the word "messages" instead of "warnings". If the page has received any edits within the last 5 years, the bot will ignore it. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 14:48, 10 May 2022 (UTC)
FYI, there's {{Old IP warnings top}} and {{Old IP warnings bottom}} for IPs that are quite likely shared. Then again, shared IPs probably wouldn't go for five years without a talk page message. --I dream of horses (Contribs) (Talk) 20:52, 10 May 2022 (UTC)
- I use those templates regularly when I see lots of old warnings, and I think that it is a better solution han just blanking them out, but I also wonder if this whole idea will be moot if/when the WMF rolls out IP masking. Beeblebrox (talk) 21:10, 10 May 2022 (UTC)
- Might it make more sense to wait for IP masking, give it a year or so, then delete every IP talk page? They're not going to be used any more. And even for users with the "unmask IP" right, the old unused IP talk pages will be less and less useful as months go on, given the dynamic nature of most IPs. Suffusion of Yellow (talk) 21:23, 10 May 2022 (UTC)
- Deletion of things other than routine warnings risks deleting important information. Also, IP addresses aren't going away completely for a long while. Also, an old proposal thing maybe of interest: WP:OLDIP. -- zzuuzz (talk) 21:35, 10 May 2022 (UTC)
- Once masked identities are introduced, unregistered editors won't be looking at IP talk pages anymore but instead looking at their own talk pages. Thus the old IP talk pages won't have to be deleted to avoid confusion, and I think should be kept to preserve any discussions. isaacl (talk) 22:30, 10 May 2022 (UTC)
- That goes to the second reason for templating these pages. The discussions contain links—millions of links. Links to articles, links to disambiguation pages, links to user pages and user talk pages, links to Wikipedia policy pages. Cleaning up incoming links across multiple namespaces for pages that tend to accumulate bad links is burdened by the clutter of links to decade-old messages from long-abandoned IP talk pages. BD2412 T 23:26, 10 May 2022 (UTC)
- @BD2412 that sounds like an argument for clearing those pages - not really for why adding a million instances of a template is the best solution. — xaosflux Talk 23:32, 10 May 2022 (UTC)
- An intentionally templated page is immediately distinct from a page blanked for reasons unknown. IP editors sometimes blank the warnings they receive; in my experience, they never template them. I do agree, by the way, that these can not be deleted, as the edit history may contain useful information. BD2412 T 23:35, 10 May 2022 (UTC)
- @BD2412 that sounds like an argument for clearing those pages - not really for why adding a million instances of a template is the best solution. — xaosflux Talk 23:32, 10 May 2022 (UTC)
- That goes to the second reason for templating these pages. The discussions contain links—millions of links. Links to articles, links to disambiguation pages, links to user pages and user talk pages, links to Wikipedia policy pages. Cleaning up incoming links across multiple namespaces for pages that tend to accumulate bad links is burdened by the clutter of links to decade-old messages from long-abandoned IP talk pages. BD2412 T 23:26, 10 May 2022 (UTC)
- Might it make more sense to wait for IP masking, give it a year or so, then delete every IP talk page? They're not going to be used any more. And even for users with the "unmask IP" right, the old unused IP talk pages will be less and less useful as months go on, given the dynamic nature of most IPs. Suffusion of Yellow (talk) 21:23, 10 May 2022 (UTC)
- I'm pretty sure we won't need to keep most of those messages. When it comes to schools, there's actually a high chance that the IP address will remain assigned to the same organisation. We frequently block schools for five years because they've shown that they can be that static. They can even get re-blocked without any new talk page messages. I can see a situation where a school comes fresh off one of these blocks to a freshly blanked talk page. I don't think that's necessarily a problem, but I also don't think it's fully recognised by this proposal. In an ideal world, we'd probably want to check when a block was made or expired. -- zzuuzz (talk) 21:17, 10 May 2022 (UTC)
- The proposal would exclude blocked pages from templating, but could be expanded to exclude pages that have come off a block within, say, the past three or four years. Ultimately, the vast bulk of pages we are dealing with are IPs that have actually never been blocked, but received a warning or a caution once or twice many years ago, and were never used again. That is pure clutter. I would certainly not be opposed to developing a protocol which starts with the most decrepit pages, and works up from there in a relatively slow and methodical fashion. BD2412 T 23:30, 10 May 2022 (UTC)
- As BD2412 says (who have been doing this semi-automated for some time), the proposed criteria is enough for vast majority of IPs. I can set the bot to ignore pages having {{Schoolblock}} even when the IP is currently not blocked or check for block expiry date for pages having school block template. We can discuss these kind of cases and other technical implementation details when the BRFA is filed. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 02:53, 11 May 2022 (UTC)
But when... were IP addresses going away altogether?—Bagumba (talk) 11:58, 31 May 2022 (UTC)
- Won't the changeover to masked IP addresses make this task obsolete? Not sure it's worth it to edit millions of pages if the problem will be going away shortly. –Novem Linguae (talk) 10:18, 2 June 2022 (UTC)
- It will not be going away shortly. Beta testing for IP masking has only just begun since last week. Other large scale WMF initiavites like Reply links took 1 year to go from beta testing to full roll out. IP masking is a much more drastic change and will surely take much longer for full implementation. As discussed above, there are other benefits from this task, namely uncluttering WhatLinksHere and reducing Lint errors backlog, that will relevant post IP masking. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 11:37, 2 June 2022 (UTC)
Wikipedia has countless articles for which some text was added at some point, and then contested in some way not by being deleted, but by being hidden, often with a note (also hidden) explaining the reasoning for which the text was hidden (e.g., 'I don't think the source supports this' or 'this is off topic'). I find this to be a very bad practice, since this hidden text seems to be quickly forgotten about, and just stays on the page indefinitely. We also have metric tons of hidden links to deleted images, equally useless. I propose that we document all the pages that have blocks of text that were initially visible but were made hidden, and make a project of moving those from the articles to their talk pages for discussion. I think some of this can probably be done by a bot, but unfortunately only a small proportion, due to the potential for incorrectly moving appropriate uses of hidden text. However, it needs to be done, one way or another. BD2412 T 01:24, 14 May 2022 (UTC)
- I agree that it's clearly bad practice just to hide questionable text. As i recall, i used to remove it and put it on the talk page for discussion if i questioned some sentence(s); at some point i stopped, but perhaps i'll start again. How can we document such pages and text, BD2412? Is there some auto- or semi-automated way? If so, i'll happily take some of this on. Happy days ~ LindsayHello 08:05, 14 May 2022 (UTC)
- FYI here is a (somewhat slow) regex query that will give a random sample of mainspace articles with HTML comments. I checked 20 and counted 7 that seemed to contain removed text, with the other 13 being legitimate annotations/documentation. I don't see how any automated process could separate these two categories. Even if the content of the comment looks like wikitext, it might just be example syntax (you see this a lot in infoboxes - e.g.
| closed_date = <!-- {{End date|YYYY|MM|DD|df=y}} -->
). Colin M (talk) 15:54, 14 May 2022 (UTC) - I think some hidden text is useful in preventing certain good-faith edits that are a hindrance. As an example that I just came across, Alejandro Mayorkas has hidden text in the political party parameter of the infobox indicating that a source would be needed before people reflexively add the party of the president who nominated him. I do not understand why deleted images have been left in articles with hidden text, those should be removed. – Muboshgu (talk) 15:56, 14 May 2022 (UTC)
- I would support a proposal that would take the hidden test to the talk page and annotate with sufficient details e.g. comment date, commenting editor. Ktin (talk) 19:18, 14 May 2022 (UTC)
- I have some thoughts on these. First, I think the hidden text on removed images are there to remind people that there was an image there, and perhaps a new one could be added at that location, but I would be glad to see all of those messages flat-out deleted, and I think that could be done by a bot because they have a repeated format. Editors can see for themselves where an image would be useful in an article, and what good is the notice of removal after years have passed? As to the hidden text reflecting an editing dispute, that is more complicated, but I think that we can generate a list of most likely instances of text that should be removed. Something that has sat in the article for several years, is lengthier than typical example syntax, and contains Wiki links and formatting, would be a strong candidate to check first. BD2412 T 19:39, 14 May 2022 (UTC)
- A related anti-pattern is the unterminated or incorrectly terminated comment. This is picked up by report 5 in WP:WikiProject Check Wikipedia/List of errors, which currently lists 600 offenders. It does pick up the case when correctly terminated comments follow later, e.g.
<!-- Badly terminated comment > Smith is an [[actor]] who did some [[film]]s. <!-- Valid comment -->
, which quietly hides the intervening wikitext. Certes (talk) 19:56, 14 May 2022 (UTC)- Yes, I think we need to go after all of these issues. BD2412 T 23:51, 14 May 2022 (UTC)
- Yeah I agree with OP's points. My one caveat is that I personally have not seen this, at least not very much. That's just me tho. Yes move to talk page is correct fix IMO. Support a well-written bot or whatever else would help. Herostratus (talk) 22:24, 23 May 2022 (UTC)
- I just found this example today. The text in this case is a reference that purportedly has a broken link, which was hidden with a note saying that the link appears to broken. This hidden text had been sitting in the article for nine years (until today). I probably see more of this than the average editor because I sweep for ref tag errors, which include those in hidden text. BD2412 T 23:47, 27 May 2022 (UTC)
- Yeah I agree with OP's points. My one caveat is that I personally have not seen this, at least not very much. That's just me tho. Yes move to talk page is correct fix IMO. Support a well-written bot or whatever else would help. Herostratus (talk) 22:24, 23 May 2022 (UTC)
- Yes, I think we need to go after all of these issues. BD2412 T 23:51, 14 May 2022 (UTC)
- I don't recall having moved article text into html comments in recent years, but I don't see a reason why this should be considered a bad practice. After all, when you simply remove text, you're effectively hiding it in the page history, and when you move it to the talk page, you're hiding it from view of anyone except those looking at the talk. In fact, putting that text in an html comment makes it more visible to editors who engage with the relevant bits of the article. I don't think there's a need for any project here, and moving text out of (or into) html comments is best left to the regular, article-specific, editorial activity. – Uanfala (talk) 11:37, 31 May 2022 (UTC)
- If there is an issue with the text, it should be brought up in the talk page, not hidden in the article itself where no one will notice unless they edit the same exact section. This is extremely bad practice. Gonnym (talk) 11:53, 31 May 2022 (UTC)
- It seems that what you refer to as "extremely bad practice" is an instance of good targeting: a commented out passage will always reach the people it's aimed at: those editing the relevant section, whereas a talk page post may initially be better visible to a larger audience, but has less chance of getting noticed by the people it's intended for (I don't think many of us have the habit of systematically scouring the talk page and its archives before making an edit to an article). – Uanfala (talk) 12:21, 31 May 2022 (UTC)
- The article is not a place to discuss anything. If you comment text out, what will the next person do? Reply there? If you have concerns, bring it up in the talk page. Gonnym (talk) 12:26, 31 May 2022 (UTC)
- Of course that's not the place for threaded discussions. But if you use an html comment, you're not starting such a discussion: you're just flagging up an issue and leaving interested others the opportunity to resolve it (by e.g. uncommenting and correcting, or removing altogether). I'm not saying this is the best method, but it certainly has its uses. If we're going to start bulk moving commented out text to the talk page, the net result will be the substitution of one (at worst) small problem with another (likely bigger) one. – Uanfala (talk) 12:35, 31 May 2022 (UTC)
- @Uanfala: There are instances of blocks of text that have been hidden for ten or twelve years or more, apparently completely forgotten, while the rest of the article has likely completely changed around them. BD2412 T 01:11, 5 June 2022 (UTC)
- To the best of my knowledge, this has never been a standard, accepted practice for editing. On the occasions when I have seen it used I have simply removed the content, it's just clutter in the edit window at that point, and article histories are a thing for anyone who wants to see what an article used to say, but no longer does. Beeblebrox (talk) 02:47, 5 June 2022 (UTC)
- @Uanfala: There are instances of blocks of text that have been hidden for ten or twelve years or more, apparently completely forgotten, while the rest of the article has likely completely changed around them. BD2412 T 01:11, 5 June 2022 (UTC)
- Of course that's not the place for threaded discussions. But if you use an html comment, you're not starting such a discussion: you're just flagging up an issue and leaving interested others the opportunity to resolve it (by e.g. uncommenting and correcting, or removing altogether). I'm not saying this is the best method, but it certainly has its uses. If we're going to start bulk moving commented out text to the talk page, the net result will be the substitution of one (at worst) small problem with another (likely bigger) one. – Uanfala (talk) 12:35, 31 May 2022 (UTC)
- The article is not a place to discuss anything. If you comment text out, what will the next person do? Reply there? If you have concerns, bring it up in the talk page. Gonnym (talk) 12:26, 31 May 2022 (UTC)
- It seems that what you refer to as "extremely bad practice" is an instance of good targeting: a commented out passage will always reach the people it's aimed at: those editing the relevant section, whereas a talk page post may initially be better visible to a larger audience, but has less chance of getting noticed by the people it's intended for (I don't think many of us have the habit of systematically scouring the talk page and its archives before making an edit to an article). – Uanfala (talk) 12:21, 31 May 2022 (UTC)
- If there is an issue with the text, it should be brought up in the talk page, not hidden in the article itself where no one will notice unless they edit the same exact section. This is extremely bad practice. Gonnym (talk) 11:53, 31 May 2022 (UTC)
- A lot of hidden things are useful (comments about likely pitfalls, for example to warn people against linking a non-notable person to someone else with the same name). That kind of hidden text should stay there indefinitely (also, editnotices don't work everywhere, so hidden text must be used sometimes). I don't mind a cleanup project going through hidden text, but it needs a lot of human triage whether hidden text should (a) be removed outright (b) be put on the talk page or (c) stay there forever. —Kusma (talk) 12:47, 5 June 2022 (UTC)
- User:Δ has generated a report indicating the total volume of just those hidden text blocks that are over 1,000 characters. Although it is a bit difficult to parse, suffice to say that runs to about 40,000K. BD2412 T 06:03, 6 June 2022 (UTC)
- As to the points on standard practice using hidden text to leave notes in the article has been part of the cheatsheet for nearly a decade. I don't see a reason to remove these en masse, but a tracking category could be useful. - LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 16:18, 11 June 2022 (UTC)
- Beyond the sheer volume of instances, there is no consistency between them. There are instances of hidden text that I have seen where a few sentences or a few paragraphs are hidden without any note in the text or explanation in the edit summary, or where a note in the text is itself ambiguous or unhelpful. We have instances of that type and many others that have been sitting in article wikitext for over a decade. BD2412 T 18:42, 11 June 2022 (UTC)
- First step: sweep for hidden text and add a template to the talk page header that says "this article has hidden text", to alert editors. Then go through them and remove/move the text. We should also document in a PAG somewhere that hidden text should not be used as a way to communicate. Levivich 18:55, 11 June 2022 (UTC)
- A lot of my content space work has been in an area of history which spawned a number of pop culture artefacts, and as such I regularly see hidden text in the form of "please do not introduce additional information about this person's role in video games" or similar. See for example Lady Zhen#In popular culture. I think a hidden text edit notice exactly where a good faith editor is likely to introduce or change material against consensus is the most perfect way to communicate, rather than a years-old discussion centralised on a wikiproject or whatever. Good targeting, per users Uanfala and Kusma above. I don't think the practice necessarily needs to be discouraged in all cases. Folly Mox (talk) 19:02, 11 June 2022 (UTC)
- I think what we need to aim for is removing hidden content. If there is a sentence or a paragraph or a reference that is purely article content with a note questioning its validity or utility, that should not be kept hidden perpetually. BD2412 T 19:04, 11 June 2022 (UTC)
- Yes, hidden notes are a great way to highlight things where good faith editors are likely to make changes that aren't desired (not just because of consensus but also because something seems counter-intuitive for some reason, etc). However they should not be used to hide content - that should either be removed completely, moved to the talk page or tagged as appropriate to the situation. Sometimes noting what content has been removed (and why) can be useful but not the content itself. The trick is distinguishing the two. Thryduulf (talk) 19:29, 11 June 2022 (UTC)
- I think what we need to aim for is removing hidden content. If there is a sentence or a paragraph or a reference that is purely article content with a note questioning its validity or utility, that should not be kept hidden perpetually. BD2412 T 19:04, 11 June 2022 (UTC)
- A lot of my content space work has been in an area of history which spawned a number of pop culture artefacts, and as such I regularly see hidden text in the form of "please do not introduce additional information about this person's role in video games" or similar. See for example Lady Zhen#In popular culture. I think a hidden text edit notice exactly where a good faith editor is likely to introduce or change material against consensus is the most perfect way to communicate, rather than a years-old discussion centralised on a wikiproject or whatever. Good targeting, per users Uanfala and Kusma above. I don't think the practice necessarily needs to be discouraged in all cases. Folly Mox (talk) 19:02, 11 June 2022 (UTC)
Enabling the New Topic Tool by default
Should the new topic tool be enabled by default on English Wikipedia? {{u|Sdkb}} talk 21:33, 27 May 2022 (UTC)
Background
The WMF's editing team has been developing tools that aim to improve the functionality of talk pages for both newcomers and experienced editors under the umbrella of the talk pages project. A few months ago, we enabled their reply tool by default. The new topic tool is a similar tool for starting new sections on talk pages; you can preview it by clicking here and choosing "Add topic" at upper right, next to the history tab.
The editing team has informed us In light of the recent A/B test results showing the positive impact of the New Topic Tool, the Editing Team is in support of enabling it by default at all projects
, and has done so on 20 other projects, with it available here as a beta feature that can be turned on in your preferences. This RfC asks whether it should be enabled as a default-on feature, but with an opt-out option available to all logged-in editors in their preferences.
Survey (New Topic Tool)
- Yes. This tool is the logical complement to the reply tool, which we have been using very successfully for several months. It makes starting discussions easier for both newcomers (vital for our future) and experienced editors (essential for our present). The ease of opting out (both fully in your preferences, and on a case-by-case basis by just editing in source if you need to) limits the potential for harm. We've already been using it successfully at the Teahouse since March. It's not at 100% perfect functionality quite yet, but it's close, and it's certainly much better than the status quo. Enabling it now rather than once development is fully complete will provide us with a more meaningful window to give the developers feedback that they'll be able to address before they wrap up their initial development work. {{u|Sdkb}} talk 21:33, 27 May 2022 (UTC)
- Sure, why not. If it helps less-experienced users participate more (as the A/B results suggest), then that's probably worthwhile. Judging from Wikipedia:Talk pages project#Starting a new discussion, the big differences are the live preview (useful!) and the automatic signature (useful if "hyphen-hypen-space-tilde-tilde-tilde-tilde" hasn't already been permanently burned into your brain). Beyond that, the UX doesn't seem wildly different from the existing "+" setup, so there doesn't seem to be much to object to. -- Visviva (talk) 23:36, 27 May 2022 (UTC)
- Yes. A/B tests show positive benefit, it's fairly easy to enable, and helps new contributors. 🐶 EpicPupper (he/him | talk) 01:56, 28 May 2022 (UTC)
- Support, makes sense after the reply tool. ― Qwerfjkltalk 07:18, 28 May 2022 (UTC)
- Strong support I think it's a great and simple-to-learn tool. — Ixtal ( T / C ) ⁂ Join WP:FINANCE! 11:27, 28 May 2022 (UTC)
- Support There are bunch of userscripts that help to do the same though. AXONOV (talk) ⚑ 13:28, 28 May 2022 (UTC)
- Support An improvement over the raw wikitext form. – SD0001 (talk) 16:41, 28 May 2022 (UTC)
- Support I've found it to be an excellent counterpart to the reply tool. Sideswipe9th (talk) 15:25, 29 May 2022 (UTC)
- Support Nice improvement. MichaelMaggs (talk) 17:15, 30 May 2022 (UTC)
- Sure, why not? Go for it. --Jayron32 18:13, 31 May 2022 (UTC)
- Support: Useful tool. —CX Zoom[he/him] (let's talk • {C•X}) 18:53, 31 May 2022 (UTC)
- Support I've been using the tool and it's a great improvement. - LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 00:30, 1 June 2022 (UTC)
- Strong support Best discussion tool ever been made available to Mediawiki. Of course it should be available by-default. Lectrician1 (talk) 01:56, 2 June 2022 (UTC)
- Support. I have used it for some time, and I find it very convenient even as an experienced editor. MarioGom (talk) 11:04, 4 June 2022 (UTC)
Support It sign comments. TSOPar (talk) 13:53, 5 June 2022 (UTC)( Blocked sockpuppet) —CX Zoom[he/him] (let's talk • {C•X}) 07:15, 8 June 2022 (UTC)
- Support. It signs comments, it's nice for both new users and for me! SWinxy (talk) 16:19, 5 June 2022 (UTC)
- Support Works well for me. Galobtter (pingó mió) 06:34, 6 June 2022 (UTC)
- Support Will make adding a new topic consistent with the reply tool, no point having two different interfaces when you can have just one for a user to get used to for talk page comments. Terasail[✉️] 14:15, 7 June 2022 (UTC)
- Support - nice job to the Editing Team working on this, thanks for the improvement! Retswerb (talk) 03:35, 11 June 2022 (UTC)
Discussion (New Topic Tool)
Courtesy pings: PPelberg (WMF), Whatamidoing (WMF). Notified: WT:Usability, WT:Talk pages project. {{u|Sdkb}} talk 21:33, 27 May 2022 (UTC)
- hi y'all – on the topic of, "How will people who prefer the existing
section = new
workflow be able to turn off the New Topic Tool?"... - In addition to what @Sdkb mentioned above about you being able to disable the New Topic Tool within Special:Preferences, the tool offers peoples the ability to switch back to the existing
section = new
experience from directly within the tool as pictured here: PPelberg (WMF) (talk) 02:04, 28 May 2022 (UTC)
Please see this.[4] "What's going on with the times here? Bakkster Man posts at 12:29 am, Today (UTC+1) with many diffs. Next, in line, (visually) a post by Gimiv 8:40 pm, Yesterday (UTC+1) complaining about a report with no diffs. Last, a post by RandomCanadian at 11:50 pm, Yesterday (UTC+1).[reply] Why are times skipping around...23:29, 27 May 2022 (UTC), next 8:40 pm, Yesterday (UTC+1), next 11:50 pm, Yesterday (UTC+1). I have no connection with any of these editors, but it's very confusing, shouldn't our "software" organize this chronologically? Seems to make editors look as if they haven't read, or are mis-replying to posts." — Preceding unsigned comment added by Doug Weller (talk • contribs) 12:17, 28 May 2022 (UTC)
- I don't understand what you mean. That is not what I am seeing in that link; there isn't even a comment by Bakkster Man, and that is not how the timestamps look like for me. Can you include a screenshot of what you're seeing, and clarify what the problems are? (You can upload it to https://phabricator.wikimedia.org/file/upload/ if you don't want to clutter up Wikipedia.) Here's what the page looks like for me, and I don't see anything wrong: https://phabricator.wikimedia.org/F35185664. Matma Rex talk 21:43, 28 May 2022 (UTC)
- @Matma Rex please take a look at the whole thread.[5]. You've pointed to an earlier version. I can't fit it into a screen shot. Doug Weller talk 15:14, 29 May 2022 (UTC)
- Oh, actually you linked to an earlier version, that's why I also looked at the earlier version. I thought that was intentional.
- I am also still confused by the weird timestamps, I guess you're using some gadget to display them in your timezone and in different format? If it's showing some of them as "(UTC)" and others as "(UTC+1)", then that must be a bug in that tool. I have no idea what tool it is (it'd be slightly easier to guess if you shared a screnshot). You might find pages easier to read if you disable it, if that happens often.
- The non-chronological order is expected for me. As far as I know, only replies at the same indentation level are supposed to be in chronological order. When you reply with deeper indentation to a comment earlier in the discussion, by necessity the result can't be chronological (unless you put your reply at the bottom of the thread, instead of making it a directly reply). I found a good example of this in the documentation pages: Wikipedia:Indentation#Indentation examples (admittedly it took me a while to find it). Matma Rex talk 18:56, 30 May 2022 (UTC)
- @Matma Rex please take a look at the whole thread.[5]. You've pointed to an earlier version. I can't fit it into a screen shot. Doug Weller talk 15:14, 29 May 2022 (UTC)
- Does this still have the "feature" of hijacking the "create a page" process for brand new talk pages? — xaosflux Talk 14:33, 31 May 2022 (UTC)
- Yes, although I'm hoping that we'll add a way to disable that while keeping the tool enabled otherwise. I proposed that in T297990. Matma Rex talk 17:41, 31 May 2022 (UTC)
- [Update] The Editing Team is going to prioritize implementing what @Matma Rex mentioned above: a new setting that will enable people to decide for themselves whether they will immediately land in the source editor upon navigating to a talk page that has not yet been created or whether they will see the new empty state experience.
- We expect this new setting to be available in the next few weeks. PPelberg (WMF) (talk) 16:04, 2 June 2022 (UTC)
- @Xaosflux As of a few minutes ago, you can disable the "hijacking" of new talk pages in preferences at Special:Preferences#mw-prefsection-editing-discussion ("When I visit a discussion page that hasn't been created yet…"). Matma Rex talk 21:13, 7 June 2022 (UTC)
- Yes, although I'm hoping that we'll add a way to disable that while keeping the tool enabled otherwise. I proposed that in T297990. Matma Rex talk 17:41, 31 May 2022 (UTC)
Make Main Page responsive by replacing tables
PASSED | |
There is clear consensus to adopt the proposal. (non-admin closure) {{u|Sdkb}} talk 16:10, 11 June 2022 (UTC) |
- 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.
The Main Page in order to split the blue and green boxes into columns and to split Today's Featured Picture with its description text. Because tables are used, when the screen width of the page is small, the columns do not collapse to become one column on non-responsive skins like Vector. This is a proposal to switch the tables to use CSS flex so that they are responsive and do collapse. The resulting page and code can be viewed here.
Ping to those who participated in the original discussion: @Ravenpuff @Stephen @Izno @Xaosflux Lectrician1 (talk) 01:54, 2 June 2022 (UTC)
- I support this change. I have personally found the width listed (875px) to be a reasonable break point. --Izno (talk) 21:54, 2 June 2022 (UTC)
- Support (Isn't this a web standard by now?) Levivich 01:30, 3 June 2022 (UTC)
- Using tables for layout was obsolete a long time ago... But it's been a challenge to get a consensus to change. (The silver lining is that by now, all supported browsers support the latest CSS layout models.) isaacl (talk) 02:15, 3 June 2022 (UTC)
- As far as I can remember, every attempt to get rid of tables has been part of a larger attempt to change 37 different things on the Main Page all at once (if not from the beginning, then by having people say "well, while, we're doing this, let's do ____, too"). If this proposal is limited to JUST changing away from tables and making the final appearance as nearly identical as possible, it might succeed. --User:Khajidha (talk) (contributions) 11:56, 7 June 2022 (UTC)
- In recognition of the difficulty in getting support for new visible changes, there have been proposals to modernize the implementation without affecting content/design layout changes on regular width screens. The rise of users with narrow screens on mobile devices, though, has given a concrete reason to make such changes. See the discussions linked to by Izno. isaacl (talk) 15:48, 7 June 2022 (UTC)
- If it makes no visible difference on regular width screens and only does this very specific thing on narrow screens, I would support it. Just don't try to go into the "let's add today's featured portal over here, and a link to requests for adminship here, and a ZX Spectrum emulator over there, and a random number generator over here, and.....". --User:Khajidha (talk) (contributions) 19:00, 7 June 2022 (UTC)
- In recognition of the difficulty in getting support for new visible changes, there have been proposals to modernize the implementation without affecting content/design layout changes on regular width screens. The rise of users with narrow screens on mobile devices, though, has given a concrete reason to make such changes. See the discussions linked to by Izno. isaacl (talk) 15:48, 7 June 2022 (UTC)
- As far as I can remember, every attempt to get rid of tables has been part of a larger attempt to change 37 different things on the Main Page all at once (if not from the beginning, then by having people say "well, while, we're doing this, let's do ____, too"). If this proposal is limited to JUST changing away from tables and making the final appearance as nearly identical as possible, it might succeed. --User:Khajidha (talk) (contributions) 11:56, 7 June 2022 (UTC)
- Using tables for layout was obsolete a long time ago... But it's been a challenge to get a consensus to change. (The silver lining is that by now, all supported browsers support the latest CSS layout models.) isaacl (talk) 02:15, 3 June 2022 (UTC)
- Support, this makes a great deal of sense and we should expect and design the site to be viewed by users on screens of all sizes. Seraphimblade Talk to me 02:07, 3 June 2022 (UTC)
- I support having a responsive design that can adapt to different screen display widths. isaacl (talk) 02:15, 3 June 2022 (UTC)
- Support 🐶 EpicPupper (he/him | talk) 02:32, 3 June 2022 (UTC)
- Support responsive main page is brilliant. This should have been done eons ago. – SD0001 (talk) 12:02, 3 June 2022 (UTC)
- Support obviously MichaelMaggs (talk) 12:35, 3 June 2022 (UTC)
- Support, clear improvement for those who don't log in or can't use superior skins like Monobook. —Kusma (talk) 12:50, 5 June 2022 (UTC)
- It is ironic that an 18 year old skin is more responsive than the current default, at least in this regard. – Joe (talk) 16:55, 5 June 2022 (UTC)
- Regarding Vector particularly, this recent blog post by a WMF engineer may be of interest. Izno (talk) 00:40, 6 June 2022 (UTC)
- It is ironic that an 18 year old skin is more responsive than the current default, at least in this regard. – Joe (talk) 16:55, 5 June 2022 (UTC)
- Support, long time coming. Good usability is good. -- Visviva (talk) 16:33, 5 June 2022 (UTC)
- Support. Damn, really? I knew the main page was overdue a modernisation, but not 15 years overdue. And as a broader point, I don't think stylistic issues like this should be subject to local project consensus. We're encyclopaedia editors, not web developers or designers. The WMF and MW devs should have a free hand to make incremental upgrades to prominent pages like this. – Joe (talk) 16:44, 5 June 2022 (UTC)
- The main page design isn't fixed by the MediaWiki software, which makes sense given the wide variety of installations for which it can be used. While I agree it would be better to delegate implementation details to technical experts (be they volunteers or paid staff), for better or worse, there tends to be a feedback loop between implementation and visible design features, which I believe has fueled a reluctance of some vocal members of the community to agree to defer. isaacl (talk) 20:31, 5 June 2022 (UTC)
- I mean the implementation and what it looks like. All we should be concerned with is the content. – Joe (talk) 21:53, 5 June 2022 (UTC)
- Well, so far this discussion has been refreshingly free of "it's not broken for me, so why fix it" comments. Perhaps the increasing number of mobile device users has helped overcome community reticence to change. isaacl (talk) 22:12, 5 June 2022 (UTC)
- I mean the implementation and what it looks like. All we should be concerned with is the content. – Joe (talk) 21:53, 5 June 2022 (UTC)
- The reason this discussion is occurring is because there have been at least two attempts to add this main page responsive behavior for Vector without an active consensus and at least one user complaint. You can see the complaints in archives 192 and 198. Izno (talk) 00:37, 6 June 2022 (UTC)
- smh we've been discussing this for four years. This is how we end up being decades behind the rest of the web. Thank you, Lectrician1, for bringing this home. Levivich 03:47, 6 June 2022 (UTC)
- The main page design isn't fixed by the MediaWiki software, which makes sense given the wide variety of installations for which it can be used. While I agree it would be better to delegate implementation details to technical experts (be they volunteers or paid staff), for better or worse, there tends to be a feedback loop between implementation and visible design features, which I believe has fueled a reluctance of some vocal members of the community to agree to defer. isaacl (talk) 20:31, 5 June 2022 (UTC)
- Support a responsive design. Gonnym (talk) 17:07, 5 June 2022 (UTC)
- Support an update is clearly required. – robertsky (talk) 17:32, 5 June 2022 (UTC)
- Support - while I use Monobook exclusively (due to finding Vector butt-ugly) I'm always on board for making pages that newer editors/readers are very likely to see more readable. —Jéské Couriano v^_^v a little blue Bori 21:49, 5 June 2022 (UTC)
- Support. But, I've got a question. When I view the desktop version of Izno's sandbox on my phone, it's still in two-column mode. When I resize a window on my real desktop to the same width, it does the responsive thing and goes into single column mode. What's happening here? -- RoySmith (talk) 01:06, 6 June 2022 (UTC)
- @RoySmith are you viewing it using mobile frontend like most phones would use (en.m.wikipedia.org)? Are you setting your phone to use "desktop" mode, and if so - are you logged in and have a skin selected? The link above is good for seeing "Is how I look at the mainpage normally going to be OK" - but if you want to see a difference you really need to be using the only main condition it matters, legacy vector - such as loading the sanbox with this link. — xaosflux Talk 01:11, 6 June 2022 (UTC)
- Basically, the operating system resolution of smartphones is large enough these days such that the check for "greater than 875 px" returns true. The blog post I linked above in re to Joe explains some of it. There isn't really a way to fix that issue besides the change suggested in that blog post (I guess if you can find the 'zoom' button on your smartphone's browser, that would 'fix' it, but I'd have to look hard for the one on Firefox). Izno (talk) 01:56, 6 June 2022 (UTC)
- I'm not (by any means) an expert on CSS, but isn't that what using em instead of px is supposed to solve? -- RoySmith (talk) 03:00, 6 June 2022 (UTC)
- I am pretty sure not, since ems are still based on some relation to a root font-size. Your browser is the one that decides to display this size of text on mobile (Firefox does the same in Vector on mobile, so you're not alone). Either (mobile) browsers need to improve their understanding of the default appearance (or attempted appearance) of web pages (e.g. heuristics based on included CSS or something) or Vector needs to have the change suggested made. Izno (talk) 04:28, 6 June 2022 (UTC)
- But isn't the whole idea to make it relative to the font size? Instead of "go into 1-column mode on windows less than 875px", it's "go into 1-column mode on windows less than 70 typical character widths?" I tried it in User:RoySmith/Sandbox/MP2. Seems to do the right thing on both my desktop and my phone. -- RoySmith (talk) 13:34, 7 June 2022 (UTC)
- I've learned something. :D Safari < 15 is bugged when text zoomed, which is 4% of our views, but apparently Safari at some age is broken with px media queries also.
- I can take a look at this. Izno (talk) 01:45, 8 June 2022 (UTC)
- Ok, so your version doesn't work the way you think it does. All that happened is that you chose a wider (70em) break point. 55em, which is about 860px in Vector (and close to it in others), displays the same behavior as a breakpoint of 875px. Izno (talk) 02:09, 8 June 2022 (UTC)
- But isn't the whole idea to make it relative to the font size? Instead of "go into 1-column mode on windows less than 875px", it's "go into 1-column mode on windows less than 70 typical character widths?" I tried it in User:RoySmith/Sandbox/MP2. Seems to do the right thing on both my desktop and my phone. -- RoySmith (talk) 13:34, 7 June 2022 (UTC)
- I am pretty sure not, since ems are still based on some relation to a root font-size. Your browser is the one that decides to display this size of text on mobile (Firefox does the same in Vector on mobile, so you're not alone). Either (mobile) browsers need to improve their understanding of the default appearance (or attempted appearance) of web pages (e.g. heuristics based on included CSS or something) or Vector needs to have the change suggested made. Izno (talk) 04:28, 6 June 2022 (UTC)
- I'm not (by any means) an expert on CSS, but isn't that what using em instead of px is supposed to solve? -- RoySmith (talk) 03:00, 6 June 2022 (UTC)
- Support. Uncontroversial modernization. MarioGom (talk) 07:38, 10 June 2022 (UTC)
- Support - baby steps for the front page but progress is progress. Retswerb (talk) 03:38, 11 June 2022 (UTC)
Substitute int: messages
The {{int:filedesc}}
and {{int:license-header}}
belong on Commons which is a interlanguage wiki. I claim that they don't belong here on enwiki and requested they be substituted at WP:BOTREQ#Substitute messages but @Novem Linguae: wanted consensus so I post it here to get it.Jonteemil (talk) 16:03, 8 June 2022 (UTC)
- Yeap, just double checking. Any objections to subst-ing all these with a bot? There will be about 4000 pages affected in the File namespace. If no objections I will file a BRFA shortly. Thanks. –Novem Linguae (talk) 18:38, 8 June 2022 (UTC)
- No way. The
{{int:...}}
markup is a means for obtaining messages from the MediaWiki: namespace that are adjusted for the reader's language preference (int = internationalised). If you have never altered your language pref,{{int:filedesc}}
emits MediaWiki:Filedesc; if you have it set to de -Deutsch, you will see MediaWiki:Filedesc/de, and so on. Since it is dependent upon the reader's pref setting, any bot run will enforce the language setting of the bot. Why is this not at WP:VPR, anyway? --Redrose64 🌹 (talk) 19:41, 8 June 2022 (UTC)- Moved. –Novem Linguae (talk) 20:04, 8 June 2022 (UTC)
- I'm sorry, but I'd like to note that this is the English Wikipedia, not a multi-lingual wiki like Wikimedia Commons or Meta. 🐶 EpicPupper (he/him | talk) 20:24, 8 June 2022 (UTC)
- Sure, content and discussions should be in English, but that doesn't mean editors must use an English-language interface to edit English Wikipedia. isaacl (talk) 20:54, 8 June 2022 (UTC)
- We generally expect content in wikitext to be in English. I don't think any multi-language users should have any expectation that File space acts differently. Izno (talk) 21:43, 8 June 2022 (UTC)
- I agree that it wouldn't be in the minimal set of necessary features, and that users speaking other languages shouldn't expect it to be. Nonetheless, providing internationalization hooks and localization into other languages is a welcoming feature to offer, particularly for English Wikipedia which has a lot of editors that are non-native English speakers. isaacl (talk) 22:59, 8 June 2022 (UTC)
- We generally expect content in wikitext to be in English. I don't think any multi-language users should have any expectation that File space acts differently. Izno (talk) 21:43, 8 June 2022 (UTC)
- Sure, content and discussions should be in English, but that doesn't mean editors must use an English-language interface to edit English Wikipedia. isaacl (talk) 20:54, 8 June 2022 (UTC)
- On occasion, I post messages with an {{int}}-based invitation to read it in another language (
More languages
), and an invitation to translate it into another language (Please help translate to other languages.
). Ideally, these should show in the user's interface language (see in practice). The presumption is that there are users who may be more familiar with languages other than English. Does this proposal concern just the two mentioned examples, or all usages of int? Xeno (WMF) (talk) 23:19, 8 June 2022 (UTC) - If ain't broke, don't fix it. To the best of my understanding, the existence of
{{int: }}
messages isn't causing any harm, so no need to remove them. If there is a harm being done, I'm open to the idea of removing them. —CX Zoom[he/him] (let's talk • {C•X}) 08:10, 10 June 2022 (UTC) - Doesn't seem like this an issue, and is actually marginally helpful for readers with their interface languages set to anything other than English? — xaosflux Talk 10:06, 10 June 2022 (UTC)
- Oppose, has potential uses for people from other language Wikipedias looking at our images who can figure out more easily whether they are appropriate for re-use elsewhere. No actual harm has been demonstrated (bugs in bots should be fixed in their source code, not worked around in the whole wiki). —Kusma (talk) 11:16, 10 June 2022 (UTC)
Numbering system of archives
On May 14, I created a template protected edit request at Template talk:Archives, which would allow specifying the starting number for archives, including /Archive 0. The request was applied after two hours by User:Terasail.
On June 3 I opened another one, this time at Template talk:Talk header. Although the first request was fulfilled, this one was met with a lot more discussion regarding the appropriateness of /Archive 0 and whether or not the edit that would allow such a use should be applied. I believe a continuation of such discussion should continue into a more centralized discussion, since it was suggested that the consensus was to not make the edit at {{Talk header}}, and not whether a user should be able to number their archive as such.
In my opinion, I believe it is a reasonable request to allow /Archive 0, but the previous discussion at {{Talk header}} has also pointed out that starting from 0 can be confusing, unintuitive, and illogical. I totally agree that article talks should never have archives starting from zero, however,
Should we forbid numbering an archive as /Archive 0 in userspace?
- Yes.
- No, but the templates should not support them at all.
- No, but {{Talk header}} should not support it. {{Archives}} is fine.
- No, and the templates should support this use.
Pinging users at the previous discussion: @Paine Ellsworth, FlightTime, Bsherr, Mathglot, Shibbolethink, and Sdkb 0xDeadbeef 10:32, 9 June 2022 (UTC)
- 1, it can be confusing. 🐶 EpicPupper (he/him | talk) 21:24, 9 June 2022 (UTC)
3: I don't think that it should be forbidden to start archiving from 0 in userspace (Other namespaces should start at 1), if you ask me you can count how you like in userspace. I added it to {{Archives}} since it seemed reasonable to me and it is a supported feature for {{Archive list}}. Indexing from 0 is pretty standard for computing and it didn't really raise any concern for me. {{Archives}} and {{Talk header}} serve different purposes and while {{Talk header}} is less appropriate for user talk, {{Archives}} is perfectly appropriate and the template itself is designed to offer the most customizability and I think it should be kept with the option to set it to a custom value while it is probably best to not add it as a feature to {{Talk header}} Terasail[✉️] 11:40, 9 June 2022 (UTC)
- Is this not more for VPR/VPP than technical though? Terasail[✉️] 11:49, 9 June 2022 (UTC)
- I'm not sure. Feel free to move it. 0xDeadbeef 11:52, 9 June 2022 (UTC)
- Did you mean {{Talk header}}? 0xDeadbeef 11:53, 9 June 2022 (UTC)
- 4: I can see some reasonable use cases for "/Archive 0" and that in all talk namespaces. Sometimes I find an extant talk page with years old topics that no one responds to, that could've been much better dealt with at a parent talk page. So "let's redirect it to the parent talk page" is an obvious belief. But where do the existing topics go? One could just aggregate them all to "/Archive 0" of the parent talk page, if the parent talk page has already gotten an "/Archive 1" of its own. —CX Zoom[he/him] (let's talk • {C•X}) 13:37, 9 June 2022 (UTC)
- Further, specifying a starting number like "Archive 2020" is okay too (in user talk namespaces), considering that people like me like categorising topics according to year. But maybe we're only discussing about "Archive 0" thing? —CX Zoom[he/him] (let's talk • {C•X}) 13:42, 9 June 2022 (UTC)
- 3. In my recent work with article talk pages I found that there were a few valid applications for a 0th archive. There were a few instances where a merge of two articles resulted in editors creating an "/Archive 0", or archives that were "0.1, 0.2, 0.3" and so on, so as to accomodate the discussions on the merged article's talk page. However, imho these limited applications were very few and far between. Since the Talk header template is widely used on article talk pages, but used far less on user talk pages, #3, which allows editors to use the Archives template with the
|start=0
parameter, is sufficient. And there is also the ability to fork the Talk header template onto a user talk subpage, add the 0th archive facility and then transclude the subpage to one's user talk page. Just a thought. P.I. Ellsworth , ed. put'r there 14:45, 9 June 2022 (UTC)- @Paine Ellsworth, may I propose allowing setting the parameter only in the "User talk" namespace? We could detect if someone is using the parameter and error out when used in other namespaces. 0xDeadbeef 07:30, 11 June 2022 (UTC)
- That's a good question. I know that sensors can differentiate among namespaces like mainspace and userspace, however I'm not sure that they can differentiate one talk space from another. If they can, then I don't see why it couldn't work. Are you averse to putting the Talk header template on one of your user subpages and making it work that way? P.I. Ellsworth , ed. put'r there 08:15, 11 June 2022 (UTC)
- Maintaining a separate template creates too much burden. I don't intend to have a copy in my user subpage if it can be avoided as that would look like using Wikipedia as a web host to me. 0xDeadbeef 08:42, 11 June 2022 (UTC)
- Forgive me as I have no clue what kind of "burden" that would be. I don't use Talk header, however I do use other templates on subpages and transclude them to my talk page to customize their usage, so I guess it's just "different strokes for different folks". The only problem with forking a template to your userspace is that future improvements to the main template would be missed, and over time unless you keep up with it, the template in your userspace doesn't look the same as the main template. That can be a small problem I guess. P.I. Ellsworth , ed. put'r there 12:45, 11 June 2022 (UTC)
- Maintaining a separate template creates too much burden. I don't intend to have a copy in my user subpage if it can be avoided as that would look like using Wikipedia as a web host to me. 0xDeadbeef 08:42, 11 June 2022 (UTC)
- That's a good question. I know that sensors can differentiate among namespaces like mainspace and userspace, however I'm not sure that they can differentiate one talk space from another. If they can, then I don't see why it couldn't work. Are you averse to putting the Talk header template on one of your user subpages and making it work that way? P.I. Ellsworth , ed. put'r there 08:15, 11 June 2022 (UTC)
- @Paine Ellsworth, may I propose allowing setting the parameter only in the "User talk" namespace? We could detect if someone is using the parameter and error out when used in other namespaces. 0xDeadbeef 07:30, 11 June 2022 (UTC)
- No, people are free to manage their talk archives any way they like. If there is popular demand for templates helping with certain types of archive organisations, our templates should be adapted as necessary. —Kusma (talk) 15:22, 9 June 2022 (UTC)
- No, you can start from minus three if you want. Whether it's worth adapting templates to edge case user behavior is a separate question. Mathglot (talk) 19:42, 9 June 2022 (UTC)
- Wait, we are talking about userspace? As in one's talk page archives? I mean I archive my talk page myself by hand, and at one point I did number my archives as "1, 2, III, Delta, 6, Berlin". I have since grown up and now use a normal numbering system, but isn't that my business? If it's article talk pages you mean, I think that staring any sequence at zero is likely to throw people who aren't programmers? You don't often see "page 0" etc. Books use i, ii, iii before page 1 and maybe that could be used? Herostratus (talk) 21:23, 9 June 2022 (UTC)
- 4: User talk pages belong to the user, so they should for the most part do anything they want. Updating templates to support any starting value would not take that long, and it might as well be done. What would the harm be? Sungodtemple (talk) 00:52, 10 June 2022 (UTC)
- That "harm" might be determined by usage. The Talk header template is widely used on article talk pages, but I've only seldom seen it used on user talk pages. So to me it makes sense to not give that template 0th archive sensing capability. So again, either users can transclude the Archives template, which already has 0th archive sensing, or they can fork the Talk header template to their user talk subpage, give it 0th sensing, and then transclude the subpage to their talk page. No harm, no foul. P.I. Ellsworth , ed. put'r there 02:48, 10 June 2022 (UTC)
- Uhhhh as to the question of "Should we forbid numbering an archive as /Archive 0 in userspace", no - who cares They can call their archives whatever they want as long at it isn't blatantly disruptive or obviously trying to hide revision histories, if they want to use User_talk:X/Archive_Jan-Mar_1999, */Archive 0, or */Some_of_my_old_messages - I don't care. As far as the hidden question: should we maintain templates for edge cases? probably not. — xaosflux Talk 15:42, 11 June 2022 (UTC)
RFC: Shut down Wikipedia:Administrative action review
IAR Involved Close - no one wants this RfC. Those of us who think it was a bad idea are content to see if it actually takes off or if it dies. Those who thought it was a good idea don't want it marked historical yet and have an issue with the format of this RfC. The only thing everyone seems to agree on about this is that having an RfC about whether or not to mark it historical is something we don't need now. When all the interested parties agree this isn't a formal discussion worth having at this point; thats when you stop the discussion. I've already voted, so if anyone other than the IP who started this wants to revert me, go ahead, but my reading of the consensus is that there is nothing controversial about closing this now. TonyBallioni (talk) 19:52, 12 June 2022 (UTC) |
- 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.
Background (Administrative action review)
Wikipedia:Administrative action review (XRV) was created following Wikipedia:Requests for adminship/2021 review/Proposals#Passed: 6C Administrative action review. To start with, this board has nothing do with improving RFA, so many people who were not interested in RFA did not see the original proposal, as mentioned by User:Risker and User:TonyBallioni in the discussion section of the proposal. 6 months after creation and long discussions on the talk page later, the scope of this page is still unclear. It has hardly ever been used and still has "This is a newly created process and norms are still being established." on top. Many users have opined that XRV is a duplicate to WP:AN and its inactivity supports this notion. XRV has not received edits for the last 3 months except for test edits. There is nothing that XRV can do that cannot already be done at WP:AN with input from a wider audience. XRV is clearly a failed experiment and I propose that it be formally deprecated and marked as historical. There is already too much bureaucracy in wikipedia, pointing users to an unused and redundant process is unhelpful. 2409:4071:D9A:88D6:11AA:2ACF:EA4C:C433 (talk) 09:18, 11 June 2022 (UTC)
Support (Administrative action review)
- Support I don't think XRV has done anything to support its founding as a solution to improve RFA's; it's birth from this RfC predicted that
if it turns out to be useless it will naturally die
, and it so it has. — xaosflux Talk 11:49, 11 June 2022 (UTC) - Put me here if this RfC continues — it failed because it is duplicative and the only reason to use it is to prove a point that it is needed. That being said, I agree with Kudpung below that the better outcome would just be to let it wither away in obscurity, so I don't really oppose a procedural closure of this RfC. Actually think a procedural closure might do more to speed up the death of it since there will be less fighting over whether to save it or not. TonyBallioni (talk) 19:04, 12 June 2022 (UTC)
Oppose (Administrative action review)
- Oppose and malformed RFC The RFC is non-neutral. The "background" isn't background, it is arguments for a certain outcome. There is a good place for the process in Wikpedia. It needs to be tweaked. Less focused on "use of tools", more focused on actions (including/especially non-severe course corrections, and including mere mis-use of the imprimatur) of admins where fellow admins consider it impolite to intervene. North8000 (talk) 12:00, 11 June 2022 (UTC)
- If you think there is a good place for a process like that on Wikipedia, then I suggest your time would be much better spent getting consensus for a new venue with that explicit purpose, rather than trying to mould this one into a vision that is completely at odds with what some others want to see the place become. Thryduulf (talk) 12:13, 11 June 2022 (UTC)
- Oppose: My position is that AAR is a good idea and we should use it.—S Marshall T/C 12:14, 12 June 2022 (UTC)
- Procedural close, RFC consists entirely of argument.--WaltCip-(talk) 14:43, 12 June 2022 (UTC)
- Oppose: it is too soon to mark it as historical. — Bilorv (talk) 14:53, 12 June 2022 (UTC)
- Procedural close send this proposal through idea lab so that people can jointly work on it, then bring it back. Major issues with the proposal atm. Curbon7 (talk) 15:33, 12 June 2022 (UTC)
- Procedural close per the others and my (now reverted) closing statement. Levivich 16:13, 12 June 2022 (UTC)
Neutral (Administrative action review)
- (see also my extended comment in the discussion section) It's currently harmless in it's nominally experimental but practically completely inactive state. My preference is just to leave it like that until it completely fades into obscurity such that placing a historical tag is completely uncontroversial, but equally actively marking it deprecated now is not going to harm anyone or anything so I've got no reason to oppose that. Thryduulf (talk) 12:06, 11 June 2022 (UTC)
- (see my comment in the discussion section) For once I find myself concurring 100% with Thryduulf. Kudpung กุดผึ้ง (talk) 12:26, 11 June 2022 (UTC)
- I see no useful purpose in doing anything about it at this point, so find myself in agreement with Thryduulf and Kudpung for now. However I am open to logical reasoning and rational persuasion based on evidence. Cheers, · · · Peter Southwood (talk): 07:30, 12 June 2022 (UTC)
Discussion (Administrative action review)
- The "background" here is misleading and inaccurate and would be more appropriate as a comment. Yes, some people didn't think that XRV wasn't sufficiently related to RFA or too similar to AN. They're reasonable points, even if I disagree with them, but ultimately they had their say, along with those with other objections, and the RfC still found a comfortable consensus with something like 70 participants. After it was closed, we implemented the basic process proposed in the RfC and quickly started building momentum with some initial threads and a healthy set of discussions on how to refine the process. What happened then was that a small group of power users, unaccustomed to not getting their way, swooped down to try and delete the page, then when that failed, obstruct it by insisting we needed a second RfC confirming the first before it could be used, put tags on the page telling people not to use it, and most damagingly of all, remove all incoming links to it from other project pages. With that concerted attempt to smother the process before it got started, coming from the very people XRV was supposed to make more accountability to the community, it's not surprising that it became inactive shortly thereafter. So mark it as historical as a description of the current state of affairs if you like, but that doesn't change the fact that a) XRV had a strong consensus behind it which is now unrealised because of the objections of a small cohort and b) there remains a need for it, as seen by regular confusion about where the used of PERMs can be reviewed, and the continuing stream of ANI threads and ArbCom case requests about administrator misconduct that could have been resolved with early intervention at a less fraught venue. – Joe (talk) 10:47, 11 June 2022 (UTC)
- If you are going to give diffs of supposed obstructionism, it is only fair to those users that you ping them. Courtesy pings to users mentioned above @Spartaz, Jehochman, Bbb23, Floquenbeam, Beeblebrox, Thryduulf, Kudpung, and Isaacl: 2409:4071:4D0B:373:FC64:EA32:3697:9D16 (talk) 11:32, 11 June 2022 (UTC)
- ...I linked to talk page sections which dozens of users participated in. Why have you only notified the most vocal opponents of XRV? Not exactly a wonderful start if you're genuinely after a balanced discussion. Of course, even if there's a consensus to mark it as historical, we'll have to have a second on how to mark it as historical. – Joe (talk) 11:34, 11 June 2022 (UTC)
- If you are going to give diffs of supposed obstructionism, it is only fair to those users that you ping them. Courtesy pings to users mentioned above @Spartaz, Jehochman, Bbb23, Floquenbeam, Beeblebrox, Thryduulf, Kudpung, and Isaacl: 2409:4071:4D0B:373:FC64:EA32:3697:9D16 (talk) 11:32, 11 June 2022 (UTC)
- (responding to ping) It was clear from the RfC that developing something called XRV to do something related to reviewing (some subset of) actions by administrators and/or administrative actions (most but not all administrative actions are taken by administrators, most actions by administrators are not administrative actions) had consensus from those participating, which is not the same thing as implementing a less-than-half-formed venue with no clear agreement, even among proponents, regarding its purpose, scope or processes. When it became clear to me that it wasn't going to be easy to get agreement on any of the prerequisites for a functioning venue I decided I had better things to do with my life and the lack of activity suggests most others feel similarly. I don't really see the need to do anything with it other than let it naturally fade even further into obscurity. Thryduulf (talk) 12:10, 11 June 2022 (UTC)
- Joe Roe: Me? A power user? OMG! All I did was to state a few accurate facts here and here - simple generalisations about RfC proposals and noticeboard behaviour. That said, well,
"coming from the very people XRV was supposed to make more accountability to the community"
, I'm not even an admin, so it wouldn't affect me. XRV is dead, and you, dear IP hopping user, would probably have done better by letting sleeping dogs lie. Kudpung กุดผึ้ง (talk) 12:24, 11 June 2022 (UTC) - I have reverted an inappropriate closure by Levivich, who had cast a "Profanity-laced keep" for XRV. Clearly they are WP:INVOLVED here. To address comments about canvassing, the reason I pinged 7-8 users was because Joe Roe was specifically talking about them in the examples they gave (which included one direct diff). The RFC question of "Should Wikipedia:Administrative action review be depracted and marked as historical?" is neutral. In the background section I explained why I opened this RFC, obviously I wouldn't have opened it if I was opposed to shutting it down myself. I don't see what RFCBEFORE is required here, XRV is a completely inactive process, I only sought to make it a formality. And no I am not a "logged out OP", I am a long term IP user who never saw a reason to create an account. My ISP assigns very dynamic IPs, so my contributions are spread out over a broad range of IP addresses. 2409:4071:4D13:677B:E5E4:694E:766D:5EE0 (talk) 06:20, 12 June 2022 (UTC)
- The basic problem with AAR is that after the community reached consensus to create it, it got back-door deprecated by way of quibbles about process and scope. We clearly should have more structure around this than currently exists, because when an administrative action is disputed on AN, the thread can be closed after a random interval by a self-selected person, and that means that the actions are reviewed by whoever gets there first. This creates an incentive to rush to comment if you want to be heard, which in my view is clearly suboptimal. We should have fixed-duration discussions and holding them in a separate venue will help to archive them. DRV reaches better decisions with less drama than the AN does, and having a well thought out process is the reason why.—S Marshall T/C 12:12, 12 June 2022 (UTC)
back-door deprecated by way of quibbles about process and scope.
is an, interesting, way of framing the discussions that were attempting to determine whether there was consensus for the sort of process you desire or the sort of processes favoured by others. There was very clearly consensus for something, but given that all these months later there is still no consensus about what exactly that something was is rather telling. Thryduulf (talk) 14:28, 12 June 2022 (UTC)- The consensus was: A new process, Administrative Action Review (XRV) designed to review if an editor's specific use of an advanced permission, including the admin tools, is consistent with policy in a process similar to that of deletion review and move review. Thanks to all the editors who contributed (and are continuing to contribute) to the discussion of how to implement this proposal. Wording taken directly from the RfC close.—S Marshall T/C 15:41, 12 June 2022 (UTC)
- IIRC there was a collapsed box in the proposal that had further details. The consensus was quite specific. Levivich 16:12, 12 June 2022 (UTC)
- Yet, after months of discussion among editors acting in good faith, there is still no agreement on multiple open questions. This is rapidly heading towards rehashing those discussions, so I'll leave it here as you can read as well as I can and, unless anybody has anything new to bring to the table, there is no point in another few thousand words of no consensus. Thryduulf (talk) 16:17, 12 June 2022 (UTC)
- There were no "months of discussion". XRV was smothered in a matter of days and none of the discussion was constructive, only nonspecific objections to the process being "a mess" or "an embarrassment" or "not what the RfC said". We asked you and others repeatedly what those "multiple open questions" about the process were supposed to be, and never got an answer. It died because you (plural) insisted that the RfC consensus could not be implemented before some supposedly critical flaws were resolved, but you wouldn't tell us what those flaws were. – Joe (talk) 16:27, 12 June 2022 (UTC)
- I would put it less strongly than Joe Roe, but I do think the community consensus was clearer than most of our policies, Thryduulf. There was some real disagreement by people who wanted it to be something it wasn't, but the main problem was tactical failure to understand plain English.—S Marshall T/C 16:33, 12 June 2022 (UTC)
- I agree that what it was supposed to do seemed quite clear, but think that it has a failure to launch. — xaosflux Talk 16:39, 12 June 2022 (UTC)
- I wouldn't say failure to launch so much as it was shot down shortly after launch by people who opposed its launching. Joe summarized the details well above. Levivich 18:33, 12 June 2022 (UTC)
- It didn't help that one editor, who had very firm ideas how XRV should develop, made 25% of the talk page edits as well as 25% of the edits at XRV itself. They're now blocked for disruptive editing and checkuser-blocked, but many may have been too exhausted or frustrated by then. NebY (talk) 19:20, 12 June 2022 (UTC)
- That's a good point. It wasn't just those opposed to the idea who killed it; overenthusiastic supporters were equally to blame. It may be that, with the initial fervor dying down, cooler heads can now prevail and we can get it re-launched. Levivich 19:32, 12 June 2022 (UTC)
- I agree that what it was supposed to do seemed quite clear, but think that it has a failure to launch. — xaosflux Talk 16:39, 12 June 2022 (UTC)
- I would put it less strongly than Joe Roe, but I do think the community consensus was clearer than most of our policies, Thryduulf. There was some real disagreement by people who wanted it to be something it wasn't, but the main problem was tactical failure to understand plain English.—S Marshall T/C 16:33, 12 June 2022 (UTC)
- There were no "months of discussion". XRV was smothered in a matter of days and none of the discussion was constructive, only nonspecific objections to the process being "a mess" or "an embarrassment" or "not what the RfC said". We asked you and others repeatedly what those "multiple open questions" about the process were supposed to be, and never got an answer. It died because you (plural) insisted that the RfC consensus could not be implemented before some supposedly critical flaws were resolved, but you wouldn't tell us what those flaws were. – Joe (talk) 16:27, 12 June 2022 (UTC)
- Yet, after months of discussion among editors acting in good faith, there is still no agreement on multiple open questions. This is rapidly heading towards rehashing those discussions, so I'll leave it here as you can read as well as I can and, unless anybody has anything new to bring to the table, there is no point in another few thousand words of no consensus. Thryduulf (talk) 16:17, 12 June 2022 (UTC)
- IIRC there was a collapsed box in the proposal that had further details. The consensus was quite specific. Levivich 16:12, 12 June 2022 (UTC)
- The consensus was: A new process, Administrative Action Review (XRV) designed to review if an editor's specific use of an advanced permission, including the admin tools, is consistent with policy in a process similar to that of deletion review and move review. Thanks to all the editors who contributed (and are continuing to contribute) to the discussion of how to implement this proposal. Wording taken directly from the RfC close.—S Marshall T/C 15:41, 12 June 2022 (UTC)
- As I said before, mark it as an optional process and see if it helps solve problems (or if it tends to intensify them). Based on experiments we can then decide whether to make it permanent. Jehochman Talk 19:34, 12 June 2022 (UTC)
Update for the fully professional league to notable leagues
- The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
Hi. To clarify the sakes that can help enhance SIGCOV and GNG, I have proposed to update the following from the the title "fully professional leagues" to "notable leagues" in the area that the SIGCOV and GNG are to be respected, and to make the concerns addressed as to the list would be to inclusive in terms of notability.
I will look forward to hear your opinions, and have a peaceful day. Cheers. Ivan Milenin (talk) 03:08, 13 June 2022 (UTC)
Responses (football leagues)
- I've made a new section so the responses are readable. A few questions: (1) Can I ask why the proposal was not put to WP:FOOTBALL first, as this seems to be within that board's area of interest? (2) I note that WP:FPL is an archived/"historical" page that you have derived this from. Is this something that has been deprecated by the Football WP sub-group? (3) There seem to WP:FOOTBALL notability criteria already. What does this new proposal add? I.e. is this really needed? (4) What are the notability criteria used here? Do you have a list? (5) Why add defunct leagues? (6) Why mention since x year?
- (Continued) I do hate excessive guidelines as they prevent casual editors adding to knowledge. However if you wish to make a "notability list" then you need to ensure that you have criteria for it, as otherwise (eventually) either notability seems to get "captured" by a small group of editors, or alternatively descends into everyone thinking their hobby issue is notable enough to put on the list as there's no strict criteria. I hope these thoughts help in refining what you want to do. - Master Of Ninja (talk) 07:33, 13 June 2022 (UTC)
- @Master Of Ninja I would note that they have zero need to put the proposal to a wikiproject first - in fact, I would generally say that would be a negative for a content project as doing so would inherently prohibit any notability policy that those interested in football disagree with. I make no comment on the other questions. Nosebagbear (talk) 09:09, 13 June 2022 (UTC)
- @User:Nosebagbear - thanks for reply. It's interesting as I feel this cuts both ways. That slightly odd sub-project guidelines or conventions shouldn't necessarily overrider WP policies. - Master Of Ninja (talk) 13:08, 13 June 2022 (UTC)
- @Master Of Ninja I would note that they have zero need to put the proposal to a wikiproject first - in fact, I would generally say that would be a negative for a content project as doing so would inherently prohibit any notability policy that those interested in football disagree with. I make no comment on the other questions. Nosebagbear (talk) 09:09, 13 June 2022 (UTC)
- Why is this here? you already started a discussion in the appropriate place, Wikipedia talk:Notability (sports). Please do not split the discussion by having it in several places at once. —Kusma (talk) 11:42, 13 June 2022 (UTC)
- Good catch, although it seems the proposal is somewhat different but related. The noted discussion is here: Wikipedia talk:Notability (sports)#Proposal for association football (soccer). A user there already pointed to a previous discussion at Wikipedia:Village pump (policy)/Archive 173 § Notability guideline for association football on Wikipedia:Notablity (sports). As well as another related discussion at Wikipedia_talk:Notability_(sports)/Association_football. These seem quite related discussions to me so should be consolidated on one forum. Any similar discussions on other parts of WP should be consolidated to this. @User:Ivan Milenin - what's your thoughts on this? - Master Of Ninja (talk) 13:18, 13 June 2022 (UTC)
- @Master Of Ninja: I have read those comments. They appear to have been related, so, no problem with that. Proceed. Ivan Milenin (talk) 15:11, 13 June 2022 (UTC)
- Thanks User:Ivan Milenin. I see User:GiantSnowman and User:SMcCandlish have also made the same point in the section below. You should probably actually consolidate it on the other page (Wikipedia talk:Notability (sports)#Proposal for association football (soccer)) as that has more interest and discussion. I will (try and) close this discussion. If you have any other related discussions you should move to close them and point them to the main discussion page.
- Although note in future having a central discussion does not stop you from posting to other boards to tell others that a relevant discussion is occurring elsewhere - it just is better to have one page for discussion.
- I would also suggest in your proposal on Wikipedia talk:Notability (sports) that you update it and write some more background including links to the previous related discussion, and a summary of the outcomes, as linked on my previous reply above. This allows users dropping by to work out what has been discussed before, and to catch up more easily on progress so far. Otherwise it relied on User:Kusma pointing out to this page that there had been previous discussions. - Master Of Ninja (talk) 08:19, 14 June 2022 (UTC)
Keep discussion central
- This needs to be discussed at Wikipedia talk:Notability (sports)/Association football please. Having it in 3 separate locations is pointless. GiantSnowman 15:39, 13 June 2022 (UTC)
- Agreed. — SMcCandlish ☏ ¢ 😼 23:16, 13 June 2022 (UTC)
Discussion at RfA/RfB
Following on from Wikipedia talk:Requests for adminship#All discussion in general discussion, this RfC concerns those parts of the Wikipedia:Requests for adminship (RfA) and Requests for bureaucratship (RfB) processes that are normally placed below the RfA/RfB toolbox in the Discussion section. There are two proposals to consider:
- Anyone wishing to respond to any Support/Oppose/Neutral (if kept) statement should do so in the General comments section or on the talk page
- The neutral section will be eliminated at Requests for Adminship/Bureaucrat (only have Support and Oppose sections)
Barkeep49 (talk) 19:22, 13 June 2022 (UTC)
Background and details
In the most recent RfC on the topic of balance between voting and discussion at RfA, the community consensus was ...the bulk of opinions seem to be for keeping the balance as is with a slight skew towards making it more vote-like.
This RfC attempts to build-off of that consensus by concentrating discussion, including the comments that happen currently in the neutral section, in the "General comments" section and on the talk page thus making the support and neutral sections more vote-like. This RfC would not change current practice of people explaining their supports/opposes/neutrals, merely where replies to them would belong.
Comments specific to the candidate/RfX will go in the "General comments" section, while more general comments will go on the talk page. An example of how this would work can be found at this RfB where discussion about a particular oppose occurred in general comments while a broader discussion about hypotheticals was moved to the talk page. Topics would continue to be seperated with a dividing line in general comments and by headings on the talk page.
Poll (RFA/RFB discussion)
- Support both Our current status quo is a bad one, where on topic discussion about the candidate gets shunted to the talk page because of concerns about the tenor of discourse, while not actually doing much for that discourse because people still feel attacked by replies. By moving the comments to a general section, hopefully there will be a bit more remove (even if there are pings) and regardless when multiple people have similar concerns the discussion will be in one place rather than spread out over multiple opposes, something this recent RfA would have benefitted from. It also provides a standard (
Comments specific to the candidate/RfX will go in the "General comments" section, while more general comments will go on the talk page
on deciding which comments should be moved to the talk page. While I use Lee's RfB as an example of where this has worked, I would suggest it has also worked at Wugs' RfB where there was limited discussion about opposes compared to a more robust discussion in general comments. The neutral section at its best feels like it duplicates things that belong in general comments, where they should be considered by crats when determining consensus and considered by the community without tipping the balance towards or against the candidate, and at worst is needless signaling (i.e. "I intend to vote later") and since we're considering changes to increase that discussion I have paired the questions. Best, Barkeep49 (talk) 19:22, 13 June 2022 (UTC) - Support both per the nom almost verbatim. We might not have been able to reform RfA, but small changes like this might helpfully go a ways towards making the atmosphere and process of RfX slightly less adversarial. --WaltCip-(talk) 19:34, 13 June 2022 (UTC)
- Support both (I never understood the reason for having a
no-voteneutral section at all.) Schazjmd (talk) 19:53, 13 June 2022 (UTC) - support 1 only neutral section is required. "I will vote later" comments were discussed at WT:RFA. What if one finds a candidate who is excellent in some areas, and has zero experience in some other areas, and what if that voter gets torn between oppose vs support? They dont want to support because of lack of experience, but dont want to oppose as candidate is good, has clue, and solid contributions. I think neutral is necessary. We dont protect a page/article because of one inexperienced editor. Same should apply here. Crats can handle that. Rest of the norms for general comments should be kept as they are. If comments go off topic/RfX, any crat/uninvolved editor can move it to talkpage. —usernamekiran (talk) 19:59, 13 June 2022 (UTC)
- Oppose option 1. RFA can be counterintuitive already, and not being able to reply to a statement immediately below it, the way you would on a talkpage would make that worse. I think it would also make the RFA experience worse for candidates. Currently if someone !votes with an easily rebutted rationale it can be pointed out in the next paragraph - having the statement "I've checked the deleted edits, and yes it was an attack page. There may well be a notable academic of the same name, but that was a valid deletion" in a completely different section rather than in the next paragraph is not going to make RFA a better place. ϢereSpielChequers 20:30, 13 June 2022 (UTC)
- Oppose 1, Support 2. WereSpielChequers took the words right out of my mouth on option 1 -- demonstrably false claims in !votes need to be rebutted on the spot, not in a separate section down below. On option 2, I see absolutely no reason for someone who doesn't want to support, doesn't want to oppose, and doesn't want to leave a general comment to edit the page at all. !Voting at RFA is not mandatory, and no one's taking attendance. --Ahecht (TALK
PAGE) 20:36, 13 June 2022 (UTC) - I support both proposals. Consolidating discussion about a given concern will reduce repetitiveness and improve efficiency: additional supporting or refuting evidence can be done in one thread, instead of having to repeat it across multiple threads. For convenience, I also support a slight modification to the first proposal, where pointers can be added in response to a support/oppose statement that would refer to the relevant discussion threads. I think the comments currently made in the neutral section can be posted within a general discussion section without loss of effectiveness, and so support this as well. isaacl (talk) 20:52, 13 June 2022 (UTC)
- Support option 1 (we need to stop the way that discussions under a vote rationale tend to degenerate), but there should be a way to make factual corrections or perhaps a neutral "see discussion section for context". Also support merging "neutrals" into the general discussion. A lot of neutrals are either useless attention-seeking ("hey, I participated too!") or bring ammunition for the opposition that doesn't have to be sugarcoated as "neutral". —Kusma (talk) 21:14, 13 June 2022 (UTC)
- Support option 2, support 1 with changes I never understood why there is a neutral section and a general comment section. I generally support option 1, but with two caveats. First, self replies should alway be allowed. Second, I do agree there should be a way for an editor to signal there is discussion as Issacl mentions above. --Enos733 (talk) 21:45, 13 June 2022 (UTC)
- Oppose 1 per WereSpielChequers, et al. Support 2 as the Neutral section has never served a useful purpose. — SMcCandlish ☏ ¢ 😼 23:15, 13 June 2022 (UTC)
- Oppose both The "most recent RfC" was a war of attrition that cannot reasonably be interpreted as justification for these proposals. As stated above, if someone makes an incorrect claim in their vote, the problem needs to be corrected where the claim is made—not hidden in a large discussion 50KB further down the page. What is the problem with neutral? That section allows mild observations or reservations without recording a vote—it's fine. Johnuniq (talk) 23:53, 13 June 2022 (UTC)
- Strong oppose 2 Keep the neutrals. Maybe ill be back with an opinion on #1, but not yet. Happy Editing--IAmChaos 00:15, 14 June 2022 (UTC)
- Oppose 2 - RfX is a discussion, and one can add to the discussion without specifically supporting or opposing the candidate, I think that removing this will either dissuade people from contributing to the discussion at all or trying to shoe-horn themselves in to support/oppose as well so they 'get counted'. And I really don't want to see
*'''Weakest possible support because the neutral section is gone''' blah blah blah ~~~~
. — xaosflux Talk 00:21, 14 June 2022 (UTC)- The proposal you are opposing does not remove the option to participate in the discussion without supporting or opposing. —Kusma (talk) 05:31, 14 June 2022 (UTC)
- @Kusma I'm aware - but I think it may backfire because by not having a numbered entry, some people may not think they are "counted" like everyone else. — xaosflux Talk 15:32, 14 June 2022 (UTC)
- I don't think a person providing more clarity to crats on how their comments should be interpreted when deciding consensus is backfiring. Best, Barkeep49 (talk) 15:49, 14 June 2022 (UTC)
- @Barkeep49 I'm specifically talking about people who would have previously !voted "Neutral" who now would not be allowed to. Yes, they could just put general comments in the comments section, but I think some of them will feel they are not "counted" that way because everyone else gets an incrementing number with higher visibility towards the top of the page. — xaosflux Talk 00:08, 15 June 2022 (UTC)
- Given the number of statements in the support and oppose sections, I think the most prominent ones will be the first few, and the last few before an editor places their comment. Comments in the current "neutral" section have greater prominence only because there are a small number of them. It's unclear to me, though, that this prominence is inherently warranted: why should someone's comments get greater prominence just for appearing in one section versus another? Comments in the general discussion section also get greater prominence if there are only a few; they lose prominence as more comments are added, as they do in all the other sections. There isn't a good solution for that. isaacl (talk) 00:33, 15 June 2022 (UTC)
- Obviously we both know that this isn't how crats would read a discussion. But to the extent that it would be a fear among those who don't know better, I'm OK with it because it does send a signal about the intent of the person to the crats - that is there are mixed feelings that in the teeniest way tip towards oppose or tip towards support. As a believer in Wikipedia:Strong#What about "weak"? it seems like a legitimate way for the comments to get out there, while still having the same eventual effect on crats, as skilled diviners of consensus. Best, Barkeep49 (talk) 00:56, 15 June 2022 (UTC)
- @Barkeep49 I'm specifically talking about people who would have previously !voted "Neutral" who now would not be allowed to. Yes, they could just put general comments in the comments section, but I think some of them will feel they are not "counted" that way because everyone else gets an incrementing number with higher visibility towards the top of the page. — xaosflux Talk 00:08, 15 June 2022 (UTC)
- I don't think a person providing more clarity to crats on how their comments should be interpreted when deciding consensus is backfiring. Best, Barkeep49 (talk) 15:49, 14 June 2022 (UTC)
- @Kusma I'm aware - but I think it may backfire because by not having a numbered entry, some people may not think they are "counted" like everyone else. — xaosflux Talk 15:32, 14 June 2022 (UTC)
- The proposal you are opposing does not remove the option to participate in the discussion without supporting or opposing. —Kusma (talk) 05:31, 14 June 2022 (UTC)
- neutral Neutral votes do not hurt, and may express some useful point, but also don't help build an outcome. Graeme Bartlett (talk) 11:29, 14 June 2022 (UTC)
- Oppose both — I see really no benefit in building up new regulations like this one because of the WP:CREEP. I think we have to pay attention to a more serious problem here: many adminship proposals are turned down too early. They are rarely discussed. Wikipedia has many problems that are non-technical. Cheers AXONOV (talk) ⚑ 16:36, 14 June 2022 (UTC)
- And with oppose !votes like this, it's easy to see why. For some reason, it's impossible to get any meaningful changes pushed through in RFA or any other realm of Wikipedia because of a widespread impulse to avoid anything that might hint at "changing the rules", as evidenced in the failure of the RFA reform effort last year. One thing that can be guaranteed by standing pat is that nothing will get better. WaltCip-(talk) 16:42, 14 June 2022 (UTC)
- Support 1 Oppose 2 As long as people can reply to themselves then I support the first part of this proposal. Dr vulpes (💬 • 📝) 23:45, 14 June 2022 (UTC)
- Support both, and especially the second. If you are torn between support and oppose, you can leave a comment explaining your justification, and that might help others decide (or not). 🐶 EpicPupper (he/him | talk) 23:53, 14 June 2022 (UTC)
- Support 1, oppose 2 – Best to avoid staggering discussions across multiple sections or pages. The neutral section also helps for consolidation and offers a voice in the "main" thread for those who aren't comfortable supporting or opposing. ComplexRational (talk) 00:06, 15 June 2022 (UTC)
- Support 1, oppose 2 - I don't see enough justification to convince me neutral votes are harmful in some way and understand the value some editors see in stating their opinions through such a vote. Nonetheless, I think the first proposal is a good one. — Ixtal ( T / C ) ⁂ Join WP:FINANCE! 10:24, 15 June 2022 (UTC)
- Oppose both — concurring with WereSpielChequers and Johnuniq, being able to directly comment on a user's vote is extremely important, not only for explaining why the vote might be inappropriate, but also highlighting the issue for the next or following participants hovering over that section; ultimately, greatly influencing the the way the next editor votes. The drive-by voters, of whom there are an abundance these days, might not bother to scroll all the way down to read various comments, many of which are more about the process than the candidate. Probably few participants take the time for a serious read of threads removed to the talk page unless it is about a juicy scandal.
- Xaosflux's oppose of No.2 makes absolute sense.The 'neutral' section is also important because it is used and read by wavering voters. It is quite different from the quagmire of general chit-chat at the bottom of the page, and the neutrals could also be taken into consideration in a 'crat chat, or even by a single 'crat having a hard time reading a consensus in a close run RfA - it has happened but it would be suicide if I were to provide the diffs. (Sorry Barkeep49, I know you are hell bent on RfA reform - so was I for years, and still maintain that change is needed - but I think these 2 proposals are solutions looking for problems). Kudpung กุดผึ้ง (talk) 11:40, 15 June 2022 (UTC)
- Oppose 1. Unless we disallow discussion entirely (I hope not), the only thing shunting replies to a different section or the talk page does is make it harder to follow. Support 2. Having a special section for people to explain why they're sitting on the fence is the most Wikipedia thing ever. There is no difference between a neutral vote and a comment. – Joe (talk) 11:54, 15 June 2022 (UTC)
- Oppose 1. It would make it hard for the users to follow. Oppose 2: I agree with Xaosflux for the most part. --Baggaet (talk) 14:00, 15 June 2022 (UTC)
- Oppose 1. The problem with RFA is not people responding inline, it's people responding uncivilly. This will not fix the problem and, per others above, will introduce others. Thryduulf (talk) 14:19, 15 June 2022 (UTC)
- Support 1 Just a baby step towards what we need which is to organize a substantial, polite focused discussion (including participation by the nominee) in important areas of question. Mild oppose to #2 I was going to vote "neutral" on removing "neutral". :-) "Neutral" is a way to express actual sentiment and not remove participation by those who aren't in the other two choices. North8000 (talk) 14:37, 15 June 2022 (UTC)
- Support both - I wanted to wait until my RfB was over before making any comments here. I feel like I'm in a unique position having been through two RfXs in two years. My general thoughts are that the neutral option is very similar to just not voting at all. I get that sometimes a user may want to spoil a ballot - but that information would be the same in general comments.
- In my eyes, one of the bigger issues at RfA is badgering (or at least people being accused of it). Very few people strike their vote after having someone comment on it. Having the discussion over issues at a different place is helpful in my eyes. Having the discussion happen immediately after the !vote cast is quite combative, whilst a ping to a discussion thread would be a little bit more calm. I know I would feel like others were suggesting my comment was much less valid if I had a direct response than a ping to a discussion.
- That being said, discussions that happen, but aren't actually about the user in question (such as at the RfB, where there was some valid concern about security risks for having additional users with higher rights/2FA) are helpful, but shouldn't fill up the RfA page. These should be more more swiftly to the talk, or better to WT:RfA. My rfA had a valid discussion about the state of WP:GAN, but it's not helpful in discussing the candidate. Lee Vilenski (talk • contribs) 17:09, 15 June 2022 (UTC)
- Oppose 2: Neutral votes don't harm. No need to remove them. Someone might be great at one thing but not so much at the other. We may want to cast a neutral vote. Abstaining is not a solution, because someone else coming to the RfA may find the reasoning useful in deciding their vote. Maybe, of the points I raised, the "other thing" matters more to them. Because the candidate is not good at that "other thing", and my vote brought it to light, the voter now has a clearer picture and vote accordingly. That's what I do, keep reading every incoming vote (S/O/N) to ensure that I don't miss something. And ofcourse, when S/O ratio are in 'crat discretionary range, the crats may find something useful in the neutral section to base their final decision. Neutral on 1. —CX Zoom[he/him] (let's talk • {C•X}) 09:13, 16 June 2022 (UTC)
- As a 'crat that closes RfX's sometimes: I currently give more weight to a "Neutral, Leaning x" (though less weight than a "weak x" in the support/oppose sections) than just a comment in the general discussion area. The general discussion area is still relevant and important - especially if there are specific issues raised in the numbered section that get more resolved in expanded discussion. Most of this is only relevant in close-calls of course. — xaosflux Talk 10:00, 16 June 2022 (UTC)
- Oppose 1 per WereSpielChequers. Really don't care about 2, but it seems like a pointless change just for change's sake. Boing! said Zebedee (talk) 15:00, 16 June 2022 (UTC)
- Oppose 1 per WereSpielChequers; far better would be more active clerking or consistently removing to the talk page after two extra comments instead of it sometimes happening & sometimes not.. Oppose 2 because it's a solution looking for a problem, and because the Neutral section can be of use. Happy days ~ LindsayHello 13:15, 18 June 2022 (UTC)
- Endorse 1, oppose 2. The first option prevents users from bludgeoning another for their opinions. However, I believe the neutral page has its own utility, and should be kept (at least for bureaucratic consideration when closing an RfX). Thanks, NotReallySoroka (talk) 06:48, 19 June 2022 (UTC)
- Oppose 1 because of the occasional newbie RfA !vote that's like "XTools says that the candidate has 3,000 deleted edits, so they must have made 3,000 bad edits!" – for blatantly erroneous statements like these, I think it is important to keep the factual correction as close as possible. DanCherek (talk) 21:58, 19 June 2022 (UTC)
General comments
- Q: what does it mean by The neutral section will be eliminated at Requests for Adminship/Bureaucrat? It sounds like there would be only two sections: support, and oppose. Did I get it right? —usernamekiran (talk) 19:36, 13 June 2022 (UTC)
- Probably too late now, but might have been better to split this into 2 RFCs originally. It's hard to take the pulse of this and see what way this is trending without a very thorough read, due to the mixing of two questions. –Novem Linguae (talk) 01:48, 15 June 2022 (UTC)
- This may just be my pet peeve, and its not as bad as it used to be, but I always thought "placeholder" neutral votes are self-important nonsense. "I haven't taken the time to actually form an opinion, and I just wanted that noted for the record" is just noise. If nothing else we should ban/remove those. Beeblebrox (talk) 19:35, 16 June 2022 (UTC)
- Maybe Wikipedia:Advice for RfA_voters#Voting 'Neutral' should be updated with such advice. I believe the last few RfAs that have had these "neutrals" were appropriately admonished. Rgrds. --Bison X (talk) 21:10, 16 June 2022 (UTC)
- For reference, an earlier discussion can be found at Wikipedia talk:Requests for adminship/Archive 252 § Placeholder neutrals, which resulted in this edit to the edit notice for all requests for adminship (though not for requests for bureaucratship, which don't have any edit notices). isaacl (talk) 21:43, 16 June 2022 (UTC)
- Huh, I totally missed that previous discussion. Interesting. I think just removing them is still the right move, but if we remove the neutral section altogether that will obviously be a moot point, so I guess we'll wait and see what happens here first. Beeblebrox (talk) 21:52, 19 June 2022 (UTC)
- For reference, an earlier discussion can be found at Wikipedia talk:Requests for adminship/Archive 252 § Placeholder neutrals, which resulted in this edit to the edit notice for all requests for adminship (though not for requests for bureaucratship, which don't have any edit notices). isaacl (talk) 21:43, 16 June 2022 (UTC)
- Maybe Wikipedia:Advice for RfA_voters#Voting 'Neutral' should be updated with such advice. I believe the last few RfAs that have had these "neutrals" were appropriately admonished. Rgrds. --Bison X (talk) 21:10, 16 June 2022 (UTC)
Cite physical work
Why there is no one template for cite physical work like there is one cite web? There are three different Cite magazine, Cite encyclopedia and Cite book and probably more but maybe there is something universal? What if PDF file isn't a book, magazine or encyclopedia? Eurohunter (talk) 17:04, 16 June 2022 (UTC)
- Define what a "physical work" is here. Headbomb {t · c · p · b} 18:52, 16 June 2022 (UTC)
- I assume a wall covered in latin insults would be a physical work. ScottishFinnishRadish (talk) 18:55, 16 June 2022 (UTC)
- Are you thinking of citing something like the Orkhon inscriptions? Gråbergs Gråa Sång (talk) 19:00, 16 June 2022 (UTC)
- @Gråbergs Gråa Sång:, @Headbomb:,@ScottishFinnishRadish: Wrong translation. I mean every printed work such as magazine, encyclopedia, book etc. Eurohunter (talk) 19:22, 16 June 2022 (UTC)
- @Eurohunter If you cite a book you are holding in your hand, you use the same template, just don't add a weblink/url. Those are not mandatory, just practical when available. Gråbergs Gråa Sång (talk) 19:26, 16 June 2022 (UTC)
- @Gråbergs Gråa Sång: I mean if it not book or magazine. What then? Eurohunter (talk) 19:28, 16 June 2022 (UTC)
- Example? Gråbergs Gråa Sång (talk) 19:29, 16 June 2022 (UTC)
- @Gråbergs Gråa Sång: I mean if it not book or magazine. What then? Eurohunter (talk) 19:28, 16 June 2022 (UTC)
- @Eurohunter If you cite a book you are holding in your hand, you use the same template, just don't add a weblink/url. Those are not mandatory, just practical when available. Gråbergs Gråa Sång (talk) 19:26, 16 June 2022 (UTC)
- @Gråbergs Gråa Sång:, @Headbomb:,@ScottishFinnishRadish: Wrong translation. I mean every printed work such as magazine, encyclopedia, book etc. Eurohunter (talk) 19:22, 16 June 2022 (UTC)
{{Cite arXiv}} | arXiv preprints |
---|---|
{{Cite AV media}} | audio and visual media |
{{Cite AV media notes}} | AV media liner notes |
{{Cite bioRxiv}} | bioRxiv preprints |
{{Cite book}} | books and chapters |
{{Cite CiteSeerX}} | CiteSeerX papers |
{{Cite conference}} | conference papers |
{{Cite encyclopedia}} | edited collections |
{{Cite episode}} | radio or TV episodes |
{{Cite interview}} | interviews |
{{Cite journal}} | academic journals |
{{Cite magazine}} | magazines, periodicals |
{{Cite mailing list}} | public mailing lists |
{{Cite map}} | maps |
{{Cite news}} | news articles |
{{Cite newsgroup}} | online newsgroups |
{{Cite podcast}} | podcasts |
{{Cite press release}} | press releases |
{{Cite report}} | reports |
{{Cite serial}} | audio or video serials |
{{Cite sign}} | signs, plaques |
{{Cite speech}} | speeches |
{{Cite ssrn}} | SSRN papers |
{{Cite techreport}} | technical reports |
{{Cite thesis}} | theses |
{{Cite web}} | web sources not covered by the above |
See also | Specific-source templates Wrapper templates |
- There are plenty available - see box at right. Whilst all of them accept a
|url=
parameter, they are primarily for hardcopy sources, with the exception of{{cite AV media}}
,{{cite episode}}
,{{cite web}}
and one or two others. --Redrose64 🌹 (talk) 19:49, 16 June 2022 (UTC)- @Gråbergs Gråa Sång: @Redrose64: I mean their PDF versions so sometimes it's document which is not book or magazine - no one know what it exactly is so it need wider term than book or magazine. Eurohunter (talk) 19:50, 16 June 2022 (UTC)
- If the pdf is a scan of a book, just cite to the book. If it's an original pdf, I would think that you would cite the website it came from.--User:Khajidha (talk) (contributions) 21:02, 16 June 2022 (UTC)
- If there actually is a proposal in this section, it is hard to figure. The heading mentions "physical work" (presumably as opposed to a virtual work), but the OP mixes it up by mentioning pdf, a (virtual) file format. I was under the impression that the OP was asking for a catch-all {{cite xxx}} template for physical (real) works with no specific classification, similar to the way {{cite web}} may be used for some (virtual) online works, when such works cannot be otherwise classified. But the continuing references to pdf make me wonder. 50.75.226.250 (talk) 14:48, 17 June 2022 (UTC)
- @Gråbergs Gråa Sång: @Redrose64: I mean their PDF versions so sometimes it's document which is not book or magazine - no one know what it exactly is so it need wider term than book or magazine. Eurohunter (talk) 19:50, 16 June 2022 (UTC)
- There are plenty available - see box at right. Whilst all of them accept a
Temporarily lock an article
NBA 75th Anniversary Team clearly states: Statistics are correct through the end of the 2020–21 season, the season last completed before the list was announced. And also: which doesn't keep folks from adding Steph's and Steve Kerr's recent NBA title.
And since having an account on the wiki doens't induce reading skills, I suggest a hard lock for everyone until hte hype has died down.
No clue where this proposal should rightfully go, so please move it to the appropriate place, thanks. 2A02:810D:933F:E250:D8E0:E9C0:15CE:893D (talk) 09:50, 18 June 2022 (UTC)
- The right place is WP:RFPP, but you'd have to make the argument there that this problem disrupts the article so much atm that protection is needed. I see someone commented on this at Talk:NBA 75th Anniversary Team, that may have some effect. Gråbergs Gråa Sång (talk) 11:06, 18 June 2022 (UTC)
- Tack så mycket. Will do when I’m on my PC again. 2A02:810D:933F:E250:D942:55FA:23A0:689B (talk) 11:30, 18 June 2022 (UTC)
- Ingen orsak! Gråbergs Gråa Sång (talk) 13:45, 18 June 2022 (UTC)
- Tack så mycket. Will do when I’m on my PC again. 2A02:810D:933F:E250:D942:55FA:23A0:689B (talk) 11:30, 18 June 2022 (UTC)
Section can be archived. 2A02:810D:933F:E250:D02C:6B31:DA76:6D4B (talk) 15:56, 18 June 2022 (UTC)
- Sections are archived automatically by a bot, just wait a couple of days without editing the thread. Sungodtemple (talk) 16:28, 18 June 2022 (UTC)
Proposal to prohibit WikiProjects from ranking further articles as A-class
I would like to notify the Village Pump of a proposal to prohibit WikiProjects from ranking articles as A-class that was filed at MfD yesterday. — Ceso femmuin mbolgaig mbung, mellohi! (投稿) 18:55, 18 June 2022 (UTC)
Allow admins to grant PCR right?
NOTHING TO DO HERE | |
This is a proposal for what is (and always has been) the status quo for PCR grants. --Blablubbs (talk) 13:22, 19 June 2022 (UTC) |
- 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.
Currently, only bureaucrats may create new pending changes reviewers. I propose that this power be transferred to administrators, since the right is relatively less important (unlike, say, the power to grant new admins). Thanks. NotReallySoroka (talk) 06:42, 19 June 2022 (UTC)
- @NotReallySoroka: Er, I'm an admin with no superpowers - just the basic admin bundle plus autopatrolled. If I go to "User rights management" for any user (from a newly-registered account with zero edits, all the way up to Jimbo), I get the same two columns. The first, titled "Groups you cannot change" is greyed out - it has the following entries:
List of items
|
---|
|
- I could therefore remove the pending changes reviewer right from you, and restore it again. But I won't, because that is against WP:ADMIN#Expectations of adminship. I could also grant it to Jimbo, who apparently doesn't have it... --Redrose64 🌹 (talk) 09:28, 19 June 2022 (UTC)
- Redrose64, WP:JIMBOISNOTAHATSTAND /j. — Ixtal ( T / C ) ⁂ Join WP:FINANCE! 11:34, 19 June 2022 (UTC)
- @NotReallySoroka: see Special:ListGroupRights this is already in place. — xaosflux Talk 10:35, 19 June 2022 (UTC)