These are the closed discussions from Phase 1 of the 2024 RfC review. Any new comments will be reverted.
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.
Should the requests for adminship process be placed under community sanctions (GS)? theleekycauldron (talk • she/her) 20:05, 14 February 2024 (UTC)
Extended content
|
---|
Survey (proposal 1)[edit]
Discussion (proposal 1)[edit]
|
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.
Following the passage of this RfC, for 5 Requests for Adminship (RFAs) which are not closed as SNOW or NOTNOW (or for six months, whichever happens first), RfAs will last 10 days. For the first 3 days (72 hours) no "Support", "Oppose", or "Neutral" comments/!votes may be made. Optional questions may still be asked and answered, and general comments may still be left. After 3 days, "Support", "Oppose", and "Neutral" !votes may be left for the remaining 7 days (same length as an RfA is now). This RfC does not change other RfA procedures/rules. 17:49, 17 February 2024 (UTC)
Extended content
|
---|
Support (proposal 3)[edit]
Oppose (proposal 3)[edit]
Neutral (proposal 3)[edit]
Discussion (proposal 3)[edit]
|
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.
Note I have just added an alternative, proposing a 2+5-day RfA trial instead of the 3+7-day trial originally proposed. Usedtobecool ☎️ 03:00, 20 February 2024 (UTC)
Pinging people who had commented/!voted already: @Barkeep49, Isaacl, Aaron Liu, Schazmjd, QuicoleJR, JPxG, Ahecht, Enos733, RoySmith, Lepricavark, Seraphimblade, S Marshall, SportingFlyer, NightWolf1223, Mach61, Lightburst, Thebiguglyalien, HouseBlaster, Relativity, Theleekycauldron, SilkTork, 0xDeadbeef, Rhododendrites, Leijurv, Femke, Bilorv, Retswerb, Kusma, Firefly, Serial Number 54129, Szmenderowiecki, Cremastra, AirshipJungleman29, Schierbecker, Voorts, WereSpielChequers, Compassionate727, Ixtal, WaltCip, Bruxton, Soni, MarioGom, Lulfas, Stanistani, Mackensen, and RunningTiger123: Usedtobecool ☎️ 03:00, 20 February 2024 (UTC) Also, @North8000, Novem Linguae, Lightoil, Lee Vilenski, Yngvadottir, Vanamonde93, Wbm1058, Galobtter, FOARP, Andrew Davidson, Tryptofish, Asilvering, Sideswipe9th, Hey man im josh, Fastily, and Schazjmd: Usedtobecool ☎️ 03:08, 20 February 2024 (UTC)
note: this was originally a subsection of the above section. I've moved it out here to match the format of the rest of this RfC :) theleekycauldron (talk • she/her) 08:15, 20 February 2024 (UTC)
Extended content
|
---|
Support (proposal 3b)[edit]
Oppose (proposal 3b)[edit]
|
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.
Following the trial of the discussion-first RfA (provided the proposal is enacted), a second trial of threaded-discussion RfA will run for six months or 5 Requests for Adminship (RFAs) which are not closed as SNOW or NOTNOW, whichever happens sooner. A RfC to then be set up to see if elements of either or both trials should be made permanent. In the no threaded-discussion RfA trial, the rules and procedures are to be followed normally, except that, other than 'Crats, nobody is allowed to comment below another user's vote or comment. Each user, including the candidate, may address issues or respond to other comments either after their own vote comment, or by creating their own sub-section in the General comments area. SilkTork (talk) 11:33, 18 February 2024 (UTC)
Extended content
|
---|
Support (proposal 4)[edit]
Oppose (proposal 4)[edit]
Neutral (proposal 4)[edit]
General discussion (proposal 4)[edit]
The Spanish Wikipedia does something similar: votes can only have a short comment (15 words max), and all questions to the candidate and extended discussion happen on the talk page. I am still undecided on its effectiveness (after all, there was only one successful RFA in all of 2023), but it's a point to consider, and I have certainly noticed that the discussion focuses more on the candidate than the voters. –FlyingAce✈hello 16:02, 18 February 2024 (UTC) Let's say that, in my own comment in an RfA of this sort, I want to say something about what another editor has said. If I understand the proposal correctly, I would say that within my own comment, as opposed to saying it in a threaded reply to the other editor. If I think about how this format has worked at WP:AE, where it is also used, it often leads to walls of text that end up being limited when admins enforce a word limit, but it doesn't reduce the back-and-forth sniping. At ArbCom, the format works better because, in part, editors are required to address their comments to Arbs or clerks, not one another, which would not be workable at RfA. Also, both ArbCom and AE use individual sections for each editor, whereas there would have to be a hundred-plus sections if we were to do actual sections at RfA. --Tryptofish (talk) 22:05, 18 February 2024 (UTC)
Seems to me these proposals are all too complicated. The principle should be to discuss the candidate first and then vote after the discussion -- not during the discussion. A sequence of events might be: (1) A nomination and seconds of the candidate to become an administrator followed by a statement by the candidate in which they tell us why they should be an administrator (with a maximum length of, say, 500 words). (2) Discussion of the candidate for, say, 5 days. Commentators may present pro or con evidence in favor of the candidate. "Evidence" is the key word here. You can't just say I don't like this candidate because they were mean to me; you have to present specific examples of said incivility or mistakes. Nor can you just say that the candidate is a good person; you have to present specific examples of what they have done that was good. The candidate and other people may respond, if they wish to address any of the comments. (3) Vote, for say 3 days. Support or oppose only. No comments allowed during the vote. What that system would do would be to ensure that people have more information about the candidate before the vote begins. It would also encourage the candidate to participate directly in the discussion about their candidacy. Smallchief (talk) 00:14, 19 February 2024 (UTC) I get the concerns about organization. I'm bothered by the arguments that it should be harder to oppose an RfA or that we should maintain a chilling effect on potential opposers. Thebiguglyalien (talk) 17:47, 20 February 2024 (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.
Following the passage of this proposal, candidates will have the option to include a header between Support and Oppose that will read Support adminship for a year. When closing the RfA, bureaucrats are to grant a year-long term of adminship only when there is no consensus to make a candidate an admin indefinitely, but the combined strength of both support sections does achieve consensus. After this has been tested on five RfAs that are not closed as SNOW or NOTNOW – or six months, whichever is sooner – this trial will end. No candidate may use this option twice.
Extended content
|
---|
Support (proposal 5)[edit]
Oppose (proposal 5)[edit]
Discussion (proposal 5)[edit]
|
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.
Following the passage of this RfC the position of "Provisional Admin" will be created, to be selected by sortition at monthly intervals.
Provisional admins serve for a period of one year. During this year they may perform any activity a full admin performs, with the exception of enforcing discretionary sanctions or participating as an admin at WP:AE. In addition, full admins are permitted to revert the actions of provisional admins even when they would otherwise be forbidden from doing so by WP:WHEEL.
A provisional admin may at any point elect to go through WP:RfA; should they pass the process they will be permanently granted full adminship. Should they fail their provisional adminship will be revoked.
Provisional adminship may also be revoked at any time by a consensus of full admins at WP:AN, or by WP:ARBCOM.
Provisional admins are selected by sortition, with an editor who meets the following criteria being drawn once a month by the bureaucrats:
Following the passage of this RfC ArbCom may, as a one-time action, unilaterally alter these criteria before the process goes into effect. Future modifications to these criteria would need to be done through standard processes.[a]
Prior to the drawn editor being announced, the bureaucrats shall inform ArbCom of the editors identity. ArbCom may, if they deem it necessary, silently veto the editor, in which case a new drawing shall occur.
A drawn editor may decline provisional adminship, in which case a new drawing shall occur. 10:54, 20 February 2024 (UTC)
Extended content
|
---|
Support (Proposal 6)[edit]
Oppose (Proposal 6)[edit]
Discussion (Proposal 6)[edit]
Notes (Proposal 6)[edit]
|
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.
Proposal: If there is more than 60% support at RfA after three days from the start of voting and at least three admins willing to mentor an incoming admin, then the editor can get trial adminship. As a trial admin, they will get to participate in administrator activities and demonstrate that they have the technical expertise and understanding of policy to keep the tools. Trial adminship could last (extend the RfA) for up to three months (or some other arbitrary maximum), but can be as short as 3-14 days, depending on the level of community support and the finding of consensus by bureaucrats after the initial 7-day period; if there is no consensus above the passing mark but no major objections then a trial might be appropriate (added on 00:43, 23 February 2024 (UTC)). If a bureaucrat closes an RfA as "unsuccessful", if the candidate withdraws, if community support drops below 50%, or if the number of mentoring admins drops below 3, the trial ends as unsuccessful. On the other hand, if a bureaucrat closes an RfA as "successful" the trial ends with promotion to full-time adminship. Reverts of trial administrative actions by mentors would not count as wheel-warring, and reverts of trial administrative actions clearly not in policy does not count either. Awesome Aasim 21:47, 22 February 2024 (UTC)
Extended content
|
---|
Support (Proposal 6b)[edit]
Oppose (Proposal 6b)[edit]
Neutral (Proposal 6b)[edit]
Discussion (Proposal 6b)[edit]
Most mentorships I have seen on English Wikipedia (*) have been very hands off: the mentor waited for questions to be asked, and often seemed to be answering them in a detached manner, without looking into details of the specific situation. I think for this proposal to be effective, the expectations of admin mentorship need to be set more clearly, and it would help if we knew if there were any people willing to meet those expectations. (*) Note I am not referring to mentorships in the sense of the new user mentor feature that was deployed in recent years. isaacl (talk) 00:01, 24 February 2024 (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.
Following the trial of the discussion-first RfA (provided the proposal is enacted), a second trial will run for six months or 5 Requests for Adminship (RFAs) which are not closed as SNOW or NOTNOW, whichever happens sooner. During the trial, the main RfA page will consist exclusively of a numbered "support" and "oppose" section. The only thing participants will be allowed to type in those sections is their signature. If a candidate receives 65% of the vote, they are automatically given adminship, and there will be no bureaucrat chats. The talk page of the RfA may be used for any relevant discussion. 00:52, 21 February 2024 (UTC)
Extended content
|
---|
Support (proposal 8)[edit]
Oppose (proposal 8)[edit]
General discussion (proposal 8)[edit]I'm not sure what you mean by candidates automatically getting adminship when they get 65%. If the first voter votes support, that would be 100%. Would there be some minimum threshold of votes? I was going to propose a straight vote like this myself seeing as we don't seem to be ready to implement SecurePoll on a large scale just yet, but this part is tripping me up. Perhaps it would be better to just stick with the established method of counting votes after a specified end time. Pinguinn 🐧 00:58, 21 February 2024 (UTC)
I'm confused by this proposal, especially when you say
|
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.
Require all support or oppose comments to also add unique diffs relevant to, and/or supportive of, their comments.
You can still say "also per so-n-so", but you still have to provide unique diffs of your own first.
If you support or oppose a candidate, you should be able to show why. If they are ready for adminship, this should be an easy thing to do. - jc37 05:43, 21 February 2024 (UTC)
Extended content
|
---|
Support (proposal 9)[edit]
Oppose (proposal 9)[edit]
General discussion (proposal 9)[edit] |
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.
Identifying vandals and spammers is easy, that's why we hand out rollback like candy. Blocking for incivility and pretty much any block involving goodfaith editors is difficult, and we need to vet candidates for that right very seriously. Uncontentious blocks of IPs and newbies for vandalism are the vast majority of the blocks we currently only have admins to issue. So it would be logical to create a new userright with the block/unblock button and also view deleted. This block/unblock button would only work on IPs and editors who are not yet extended confirmed. Admins would still have the full block and unblock power as at present.
Extended content
|
---|
Support (proposal 10)[edit]
Oppose (proposal 10)[edit]
General discussion (proposal 10)[edit]If this was a group of: block/blockemail/unblock; I think I could support this unbundling (presuming that the separated bundle is grandfathered/added to all current admins). But "view deleted", (even just the history) brings along issues that I would rather see as part of a discussion closer's package of user-rights, than merely someone who is helping out by blocking users due to behavioural issues. Not opposing yet, because I think through discussion this could become a workable proposal. - jc37 08:46, 22 February 2024 (UTC)
Regarding implementation feasibility reality checks: getting an idea if something is technically feasible, or if it has inevitable side effects for users is helpful to avoid raising people's hopes. The proposed one-time sorting mechanism per reader that was proposed for the arbitration committee election candidates page could not be implemented without incurring either a page loading cost or back-end server cost that was disproportionate for the amount of use it would get. Modifying SecurePoll doesn't have the same type of constraints that applies for most of the code underlying Wikipedia—as long as the old version is still available if needed to access any archived data, it doesn't matter if the user interface or implementation radically changes. Adding a new capability for, say, blocking specific users can be overlaid on top of existing capabilities, so it too is technically feasible (not to minimize the number of use case scenarios that would have to be examined and tested, nor the implementation cost, though). The community ought to remain aware, though, that the more development effort required, the longer it may be until a feature is implemented. Personally I feel the community should still support capabilities it desires even if they require new development, but at the same time, understand that there is no guarantee on when the required work might be scheduled and delivered. isaacl (talk) 17:34, 22 February 2024 (UTC)
I agree with Xaosflux that in the interim we can define in policy how a selected administrator can make use of their assigned privileges. isaacl (talk) 18:04, 22 February 2024 (UTC)
Would WMF legal have issues with this? Snowmanonahoe (talk · contribs · typos) 17:08, 23 February 2024 (UTC)
One very big pro I can see to this, if there are severe limits to what they are allowed to do as a sysop-lite (with serious consequences if they step out of bounds), is it would give us insight as to how potential admins would use the toolset, we could weed out the heavy-handed ones before they have the opportunity to do things like block all Spectrum Business customers in the state of Hawaii because a few IPs on the /16 range out of ephebiphobia (this is a reference to an actual schoolblock I saw but am not going to invest the time to hunt down a link to it; it would have to look absolutely ridiculous to try to edit from a law firm or a medical office and see that you're blocked as being a school because a few schools in Hawaii use Spectrum Business). PCHS-NJROTC (Messages)Have a blessed day. 22:36, 26 February 2024 (UTC) An idea I had after reading some of the discussion above, is maybe do this the other way around and have semi-protection unbundled instead of blocking. Preventing IPs from editing a single page for a day or a week will have a much lower chance of innocent users getting caught up in it than blocking specific IPs from editing everything. If the vandal registers or moves to a different page, then we'll have the paper trail for an admin to properly block. --~ฅ(ↀωↀ=)neko-channyan 19:44, 27 February 2024 (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.
Much of the angst and disagreement at RFA isn't really about the candidate, it is about the criteria for adminship. Hence the critique of RFA as it being like taking your driving test whilst driving a minibus full of examiners who are arguing with each other about the criteria for the test. This also causes uncertainty among potential candidates as to what the criteria is. Part of the problem of RFA as opposed to Rollback, Autopatroller or other userrights is that we don't have defined criteria for adminship that potential candidates can look at. Some of those criteria, 12 months activity, no blocks in the last month, at least 3,000 edits and some experience could be set by consensus in individual RFCs per criteria.
Extended content
|
---|
Support (proposal 11)[edit]Oppose (proposal 11)[edit]
General discussion (proposal 11)[edit]
|
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.
RfA has a discretionary zone as part of its "not a vote" tradition. At some point (when RfAs had become rare), individual bureaucrats no longer wanted to exercise this discretion so crat chats were born, leading to additional days of bureaucrat scrutiny of the voters' arguments. This was a nice idea when it started, but now the community anticipates the crat chats. This means that during voting, people are inclined to make more and more lengthy arguments to ensure their vote is counted, further increasing the contentiousness of the discussion and the stress for the candidate. A simple hard pass/fail boundary would help to calm things down instead of inflaming things further like the anticipation of crat chats.
Extended content
|
---|
Support (proposal 12)[edit]
Oppose (proposal 12)[edit]
General discussion (proposal 12)[edit]Very few RFAs are anywhere near the discretionary zone, if people are being clearer in their RFA !Votes maybe that's about them wanting to have others pay attention to their !votes. Also there was one crat chat last year and maybe two the year before. The numbers are too few to justify the assertion that every RFA that ends in the discretionary zone is expected to go to a crat chat. For example, I assume that if there is an RFA just inside the discretionary zone, but clearly outside if you downweight the weak supports and opposes, I could close that uncontentiously. Equally if an RFA was in freefall due to something happening at the start of day 6, and the RFA had dropped from >99% to clearly in the discretionary zone, I could close as unsuccessful without people calling for a cratchat. ϢereSpielChequers 09:29, 22 February 2024 (UTC)
How does this proposal differ from proposal 8 on making the process a straight vote? isaacl (talk) 17:57, 22 February 2024 (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.
Basically the same rationale as proposal 12: bureaucrat chats rarely produce a result contrary to the numeric result of a 7-day RFA discussion, thus they needlessly elevate the tension of an already-stressful process. In my analysis of RFA statistics, a review of the discretionary ranges showed that, since 2009, RFAs ending with a numeric result below 70% nearly always fail, despite having expanded the discretionary range down to 65% in 2015. This suggests that bureaucrat chats aren't meaningful in determining consensus. Thus I propose that we eliminate bureaucrat chats and replace with a discretionary relisting period. If after 7 days an RFA carries a numeric result between 70% - 75%, it is automatically relisted for an additional 7 days. If the result remains below 75% after one relist then the RFA fails. Ivanvector (Talk/Edits) 15:39, 28 February 2024 (UTC)
Extended content
|
---|
Support (proposal 12b)[edit]
Oppose (proposal 12b)[edit]
General discussion (proposal 12b)[edit] |
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.
I think we should consider the idea of having the community appoint CUs and OSs in a similar process that RFAs are run by. I think in this way, the community has more of a say in who is most qualified for these positions. Interstellarity (talk) 01:22, 25 February 2024 (UTC)
Extended content
|
---|
Support (proposal 15)[edit]
Oppose (proposal 15)[edit]
General discussion (proposal 15)[edit]I feel like this is out of scope for RfA reform. Aaron Liu (talk) 01:25, 25 February 2024 (UTC) I agree that this proposal isn't within the area of RfA and ought to be made separately. (Note it would require amendment to the arbitration policy.) isaacl (talk) 01:29, 25 February 2024 (UTC)
Every non-checkuser and non-oversighter being elected to ArbCom is a community-appointed checkuser and oversighter. There could be a process that is separate from ArbCom seats, but we should at least not pretend that all checkusers and oversighters got their privileges from ArbCom rather than the community. ~ ToBeFree (talk) 12:17, 25 February 2024 (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.
As described in the previous proposal, administrators are only subject to ARBCOM once they are given administrator permissions. There is no means to remove permissions for administrators who have lost the trust of the community unless they have committed egregious or ban-worthy offenses.
If this proposal passes, administrators will be required to pass a new RfA after a certain number of years to confirm that they still have the trust of the community and need for the tools. The number of years will be decided by the community, either in this proposal (if there is strong consensus for a specific number) or in a follow up discussion. Administrators who do not initiate a new RfA will have their administrator permissions expire in good standing with the option to reapply at a later time. This will replace the current inactivity rules for administrators. Current administrators will not be immediately subject to reconfirmation if they have served longer than X years. If several administrators must be reconfirmed in a short period, reconfirmations may be staggered at bureaucrat discretion to allow sufficient time for review.
Supporters of this proposal may condition their support on a minimum or maximum number of years they would be willing to support. As with the previous proposal, the benefit would be stronger accountability for administrators who have lost the trust of the community. It would also simplify the current inactivity rules. The potential drawback is that it would make administrators less likely to take necessary but controversial actions, though it would allow time to pass before an RfA due to its scheduled nature, preventing kneejerk reactions. This drawback could be further mitigated through means such as requiring only a simple majority to reconfirm. Thebiguglyalien (talk) 03:48, 27 February 2024 (UTC)
Extended content
|
---|
Support (Proposal 16b)[edit]
Oppose (Proposal 16b)[edit]
Neutral (Proposal 16b)[edit]
Discussion (Proposal 16b)[edit]
|
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.
Any extended confirmed user may begin a recall discussion at WP:AN. They must inform the administrator being discussed and must explicitly state that the discussion is to initiate a Reconfirmation RfA (WP:RRfA). Following a minimum period of seven days and a minimum !voter turnout of at least 20 users, any uninvolved bureaucrat or arbitrator may close the discussion. Any user may comment in the discussion, but only !votes by extended confirmed users will be considered by the closer. Should the minimum turnout not be reached, the discussion should be closed. An admin may have no more than one AN thread for recall opened in a three month timeframe.
Should consensus be found in favor of desysopping them, the user in question must be notified via their talk page by the closer. The user will have one month to initiate a RRfA. Like a typical RfA, an RRfA would be listed at the WP:RfA page, appear on watchlists, and be listed at WP:CENT. They may have one or more nominators or opt to self-nom, just as in a typical RfA. During this time, they may continue to use any tools included in the administrator user group.
Should they elect not to hold an RRfA, their administrator permissions will be removed. If, at a later date, they wish to regain their administrative tools, they must run through an RfA with the typical thresholds (75% automatic and 65% 'crat chat at the time of this writing). Should they choose to participate in an RRfA, it will run with lower confirmation thresholds than a normal RfA (65% for an automatic pass and 55% for a 'crat chat). Should the RRfA fail, a bureaucrat will desysop them.
An admin may not go through an RRfA until at least one year after the conclusion of their previous RRfA or RfA. Sincerely, Novo TapeMy Talk Page 17:17, 29 February 2024 (UTC)
Extended content
|
---|
Support (Proposal 16d)[edit]
Oppose (Proposal 16d)[edit]
Neutral (Proposal 16d)[edit]Discussion (Proposal 16d)[edit]
|
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.
Partly the same motivation in 16e above, and in some of the other proposals to narrow or eliminate the discretion zone and cratchats - bureaucrats retain their permissions indefinitely, with no means for the community to remove them unless there's misconduct severe enough for arbcom to become involved; and the current cadre of bureaucrats are nearly all ancients, with only one of the 18 having registered after 2010, and a few who have almost no interaction with the community besides participating in one or two cratchats a year.
Unlike 16b, there's few enough bureaucrats that we can schedule re-rfbs without overwhelming the process - a two-year term, for example, would average one new reconfirmation starting every 40 days. And unlike 16e, regularly-scheduled reconfirmations don't have the stigma recalls do, and severely limit the potential for retaliatory recalls following controversial-but-necessary actions.
This still has all the benefits of 16e, albeit slower, in that bureaucrats who act outside policy or against consensus can eventually be removed. It will also allow us to get new blood in the bureaucrat corps without risking making cratchats less of a pure consensus process and more of a vote (and there have already been a few that looked like the latter: discussion, then a poll, then closed according to the majority rather than trying to convince the holdouts). —Cryptic 20:12, 5 March 2024 (UTC)
Extended content
|
---|
Support (Proposal 16f)[edit]
Oppose (Proposal 16f)[edit]
Discussion (16f)[edit] |
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.
I am proposing to change RfA by removing ongoing voting during the week-long RfA process. During the RfA, users can either ask up to two questions of the candidate, or provide a statement in support or in opposition of the candidate's RfA, similar to a user statement at ArbCom. Threaded discussion could also take place. At the end of one week, the RfA is closed as a discussion, and then a user vote would take place through a secret ballot process. (A possible addition may be that the admin closing the discussion may judge that the RfA has no chance of succeeding before voting starts.) This takes the two proposals above and places the focus completely on the vetting process, which users can then read before casting their vote.
Basically, there are three types of RfAs: clear supports, clear fails, and edge cases. We struggle the most as a community with the edge cases. My belief is completely separating the voting from the discussion process will actually be less stressful for the candidate, who can use the week focus on simply answering questions about their work and their interest in the admin toolset instead of having to worry about whether consensus is breaking for or against them.
Addendum: per the discussion below, the intent here is to create a process which generates a discussion that users can use to cast a vote on a timeline of the candidate's choosing, similar to something you might receive from a political party or candidate before an election in a democratic political system.
Extended content
|
---|
Support (proposal 19)[edit]
Oppose (proposal 19)[edit]
Discussion (proposal 19)[edit] |
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.
One of the criticisms of RFA is that the whole process is public, anyone can see it. This deters some from running, especially if they edit under their own name.
If RFAs were only visible to accounts that were extended confirmed, then it becomes an internal process, only visible within the Wikipedia community. They don't publish recordings of job interviews and driving tests on the internet, why publish RFAs?
I appreciate this would require some IT work, but the WMF can afford to employ some programmers and I believe they want to make RFA less stressful. Once an account becomes extended confirmed they would be able to see RFA pages and take part.
I appreciate that this has similarities to the proposal to limit voting to extended confirmed accounts as a side effect, but some of the opposition to that was from people who saw no benefit.
The watchlist notice would also need changing so that it only promoted RFA to extended confirmed editors.
Extended content
|
---|
Support (proposal 20)[edit]
Oppose (proposal 20)[edit]
Neutral (proposal 20)[edit]
Discussion (proposal 20)[edit]
|
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.
One commonly cited trope at RfA is that "an oppose is worth as much as three supports". This may be a reason that individual opposes get so much badgering, from the basic underlying premise that their vote is effectively worth more than yours.
Currently, an RfA requires 75% support (ie: support / support + oppose) to be usually considered successful, and 65% support to be under consideration by bureaucrats.
This proposal would reduce the thresholds to 66% and 50% respectively.
In other words, a candidate simply has to get more people supporting than opposing to be considered appropriate for adminship, and can be generally considered suitable at two-thirds majority support.
This could be considered the "Holy Grail" clause from a line in Monty Python and the Holy Grail ... "but all the decisions of that officer have to be ratified at a special bi-weekly meeting by a simple majority, in the case of purely internal affairs, or by a two-thirds majority, in the case of ...." Or, if you prefer, "strange women lying in ponds distributing swords is no basis for determining adminship".
The most recent RfA this might have made a difference is Wikipedia:Requests for adminship/Tails Wx, which might have persuaded them to continue the RfA instead of withdrawing. (Note, I opposed at that RfA). Ritchie333 (talk) (cont) 11:54, 28 February 2024 (UTC)
Extended content
|
---|
Support (proposal 21)[edit]
Oppose (proposal 21)[edit]
Discussion (proposal 21)[edit]It would be interesting to see more examples of RfAs that would have gone another way, although this is quite difficult due to the small number of RfAs these days. I don't think there are too many that would have changed
There are very few RfAs that have ever ended between 50 - 65%, simply because the candidate withdraws and bails out by that point, possibly also quitting the project at the same time. As an aside, somebody I can't stand managed to get elected US President on 46% of the vote, so 50% is far less controversial than you might think. Ritchie333 (talk) (cont) 14:25, 28 February 2024 (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.
Lower the discretionary range from 65–75% to 60–70%.
Extended content
|
---|
Support (proposal 21b)[edit]
Oppose (proposal 21b)[edit]
Discussion (proposal 21b)[edit] |
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 people that we really need are the capable "I'm willing to serve" people rather than the "I want this" folks. RFA has an "I want this" atmosphere / basis, a basis and environment that the "willing to serve" folks are often unwilling to go into. Also, it puts the crowd and conversations at RFA into a "you are asking for this, you'll need to fight/grovel/beg for it" mode. Changing the name to "Nominations For Adminship" would shift the psychological ground in all of these areas.North8000 (talk) 15:29, 29 February 2024 (UTC)
Extended content
|
---|
Support (Proposal #22)[edit]
Oppose (Proposal #22)[edit]
Neutral (Proposal #22)[edit]
Discussion (Proposal #22)[edit] |
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.
I'm resurfacing an idea I advanced in 2021 [3]. Namely, all Admins are on probation for the first six months of their tenure. During this period, the Admin will be subject to a compulsory binding recall process using a to-be-determined formula if such a recall process is initiated. If the administrator is not recalled within 180 days, the probation is lifted and the current status quo with respect to recall processes (voluntary) resumes.
This would significantly lower the stakes of RfA and make RfA less of a life-or-death struggle. Chetsford (talk) 03:08, 1 March 2024 (UTC); edited 16:48, 1 March 2024 (UTC)
Extended content
|
---|
Support (Proposal #23)[edit]
Oppose (Proposal #23)[edit]
Neutral (Proposal #23)[edit]
Discussion (Proposal #23)[edit]
|
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.
Close to 100% of functional large organizations have promotions given by a boss, often with discussion/approval of other bosses and/or the bosses boss etc. (I would suppose). Close to 0% percent have promotions have promotions given by public discussion vetting by all the employees (with no veto power by the boss(es)).
Most of these organizations by far exist to make profit. Making profit is very much enhanced if your internal organization, and the procedures for maintaining it, work well. If the latter method worked well, it would tend to increase profits. Therefore you would see it used in a non-negligible number of functional large organizations, which number would tend to increase over time. That is how it tends to work with large organizations in our system, period.
"Doing what basically every other large successful organization in the free world does" is certainly something to look at closely, n'est-ce pas? Sure we're different -- nonprofit, with article content crowd sourced to volunteers, which works very well, altho crowd-sourced management doesn't seem to -- but I'm sure Goodwill Industries or the Red Cross and so on use a basically similar paradigm. We are an encyclopedia publishing house. We are not the Hog Farm or the Oneida Community. The public lemon-squeezing adoration/flagellation system has got to go. It is horrible, cruel sometimes, and not working that well. When you deselect for sensitive people, you are going to get insensitive people. We have enough of these already in the admin corps and its not getting better.
Howevvvver...we don't have bosses. Well, not exactly, but the admin corps does a number of boss like things -- firing people, and a number of others. They're kinda-sorta the bosses. And (important!) They are supposed to be the best of our best -- vetted as being the most experienced, honest, intelligent, thoughtful, and so on. Who better to decide who they want to promote into their ranks.
Also important -- politics is everywhere (including here of course) and politics is the art of the possible. The admin corps might go for this, big time. There are a number or proposals that are just not going to fly. The admin corps is made of humans, and I don't think are ever going to allow admin recall even if they themselves are grandfathered in, and some of these other also, and at the margins they have ways to pretty much make this stick. And significant enthusiasm on the part of the admin corps would be a huge boost for this proposal. Some people do tend to follow those they consider to be our best and brightest, and some people tend to follow leaders.
The admin corps would go for it I believe because would give the admin corps more power. Who doesn't like that. Also more work, sure, but the work could be mostly given to a small group of admins (there would be plenty volunteers), with whatever oversight from the corpse general that they like. The could all vet on their Discord server or mailing list or whatever they use; all this'd be up to them.
Optional: the admin corps could also be empowered to remove members. Let's not consider that right now, we've got enough to ponder with just what I've laid out here. Herostratus (talk) 21:03, 3 March 2024 (UTC)
Extended content
|
---|
Support (Proposal #26)[edit]Oppose (Proposal #26)[edit]
Neutral (Proposal #26)[edit]Discussion (Proposal #26)[edit]Obviously the downside here is, number one, they're going to tend to select their friends -- but then friends of (several) admins are mostly going to be good admins themselves I'd think. Number two, they're going to select for people who are like them, because of course. If the admin corps is mostly jerks and morons, they'll mostly select for jerks and morons. But they're not mostly jerks and morons, they're the best of our best, or are supposed to be. If they were mostly jerks and morons, we'd really want to burn down the whole structure and start anew. Herostratus (talk) 21:03, 3 March 2024 (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.
Provide a few paragraphs of respondent-guidance / advice on the RFA page. It would include things like the qualities needed for admin and advise evaluating and commenting on those. It would advise avoiding some of the common problems that have been occurring. Including problems inherent to a crowd responding/discussing North8000 (talk) 21:59, 5 March 2024 (UTC)
Extended content
|
---|
Support (Proposal 29)[edit]
Oppose (Proposal 29)[edit]
Discussion (Proposal 29)[edit]Wikipedia:Requests for adminship § Expressing opinions has a link to Wikipedia:Advice for RfA voters. As it was largely written by Kudpung, it reflects his perspective on commenting on RfAs. Nonetheless it does contain a lot of advice on what commenters should be doing and looking for. isaacl (talk) 01:32, 6 March 2024 (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.
Emphasize that just granting the tools does not mean that they will be blocking experienced editors tomorrow. In reality, most newer admins start in safer areas and evolve into the rougher high impact areas like blocking experienced editors at WP:ANI and similar high tension high impact blocking areas. But WP:RFA sort of assumes that they will be doing this tomorrow and sets a very grueling standard accordingly. The WP:Administrators page gives some very weak guidance to this effect. The proposal is to strengthen the guidance there along these lines as well as developing this as more of a public expectation. So newer admins (and RFA) can start where it really is "No big deal" and then grow into the areas where it really is a Big Deal. North8000 (talk) 22:10, 5 March 2024 (UTC)
Extended content
|
---|
Support (Proposal 30)[edit]
Oppose (Proposal 30)[edit]
Discussion (Proposal 30)[edit]I'm not sure there's any specific process or procedure that needs to be altered for this that would require a consensus to proceed. If the proposal is to alter the Requests for adminship page, the RfA voters advice page, or other pages to provide more guidance for RfA commenters, then I think that can be worked out via discussions on the appropriate talk pages. isaacl (talk) 01:38, 6 March 2024 (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 RfA model of segregating and tallying !voter commentary is demonstrably conducive to group think and piling on whereas the AfD model, for example, is much more discussion oriented and demanding of respondents to individually reach and own the opinions they publish. While it will be more difficult to assess consensus, I believe it will result in far less toxicity, overall.--John Cline (talk) 10:17, 6 March 2024 (UTC)
Extended content
|
---|
Support (Proposal #31)[edit]
Oppose (Proposal #31)[edit]
Discussion (Proposal #31)[edit]With the bot-generated count of viewpoints still present, I don't think this would have much effect. Even if the bot summary were removed, I don't think there's consensus to prevent someone from mentioning and updating the count elsewhere. isaacl (talk) 15:22, 6 March 2024 (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.
RfA remains a seperate process. Additionally, any editor who reaches a set of milestones (account age, edit count, block-free period, et cetera, numbers and details TBD) receives a friendly message on their talk page, offering adminship. If they accept they get the mop. If they mess up, the ordinary 4-level warning system applies. 4th warning, admin assesses situation, mop kept or removed. No admin action logged for a year, mop removed. This offer is once-off. — Preceding unsigned comment added by Pgallert (talk • contribs) 19:24, 7 March 2024 (UTC)
Extended content
|
---|
Support (proposal 32)[edit]
Oppose (proposal 32)[edit]
Discussion (proposal 32)[edit]I don't want to oppose without discussing this first, Would this be discretionary, as in, an admin comes up and offers it, or would it be an automatic offer? I'd oppose an automatic offer, since, theoretically, there's long time editors who contribute to the project excellently but may not be the best candidate for admin. A good outcome if an un-mop-worthy editor were to get it would be they wind up biting someone. The worst case scenario would be that editor abuses their mop and winds up geting indef'd DarmaniLink (talk) 19:49, 7 March 2024 (UTC) Probably needs proposal # 32b. Reach out to people who met the criteria, offer to nominate them for regular RFA. North8000 (talk) 20:58, 7 March 2024 (UTC)
All those editors that self-admit to "shouldn't be admin", should be. Actually, these are our best choice, far, far better than those who believe they should be admin. We have admins that are not the best candidates for admin. We have admins that make mistakes. We have admins that bite. That is normal, and the site is still operational. What is broken is RfA, that's why we need a back door into adminship. (by OP) --Pgallert (talk) 06:10, 8 March 2024 (UTC) |