![]() | This page is currently inactive and is retained for historical reference. Either the page is no longer relevant or consensus on its purpose has become unclear. To revive discussion, seek broader input via a forum such as the village pump. |
Welcome to my proposal! My proposal focuses on making the RfA process comparatively smooth. It will mainly focus on "fixing the broken system". The new proposed process by me is divided into 3 phases.
First phase features a Pre-RfA process. Second, the regular RfA through which admins are selected currently. And the third, with a Post-RfA system to give an editor who barely doesn't reach consensus a chance of getting admin rights. Detailed explanation is stated below. Thanks!
Note: This is not entirely my own idea, but it is a mix of few ideas proposed by fellow editors at times which is modified by me and given the final shape. →TSU tp*
RfA-review committee
editA committee consisting of 10 selected trusted editors like Admins and Crates' will be formed which will perform the process of review of Pre-RfA submissions, Post-RfA and RfA work by editors. They would have term of 1 year and would be selected by voting process.
Phase 1: Pre-RfA review
editAccording to my proposal, there will be a RfA-review committee who will do the review work of the editor nominated. Editors who wish to become an admin will submit a nomination to the RfA-review committee. This review would be open for 3 days (maximum) in which the contributions by the editor would be discussed if the committee members have any doubt regarding the editor's contributions. The committee members would give their opinion and !vote oppose or support in this process. Here are the possible situations:
Success
editIf 7 or 6 (If 4 members have similar way of oppose) out of 10 members agree that the editor is ready for RfA, then the editor can start their RfA. In absence of few committee members, a rough consensus of minimum 70% will be needed by the editor to get through.
Failure
editIf 4 (If those 4 members have different way to oppose) out of 10 members agree that the editor is not yet ready for RfA, then the editor cannot start their RfA. In absence of few committee members, a rough consensus of maximum 60% will result in the editor failing their Pre-RfA review. Editors can re-try after addressing problems.
Phase 2: RfA
editEditors getting 7 or 6 (If 4 members have similar way of oppose) votes out of 10 or getting 70%+ rough consensus in Pre-RfA review are eligible for starting an RfA. According to the current process, editors with less then 75% are less likely to be granted rights.
Striking
editThis will give the members of RfA-review committee the power to strike off votes by few editors which are using an unfair rational or rationals that are totally blank and consists of just Support or Oppose.
Clear Success
editEditors getting 80% or more consensus are directly granted admin rights keeping the condition that opposes are not made due to issues raised in the RfA at the end. They don't require to go for Post-RfA review.
Success or no consensus
editEditors with consensus 75% or more are considered to be closed as successful. Less then 75% consensus at RfAs are closed as no consensus or sometimes passed and this can extend upto 70%. After this, editors still qualify for Post-RfA review.
Clear Failure
editRfAs getting less then 65-60%, will be closed as unsuccessful and they do not qualify for Post-RfA review. This would occur rarely as due to Pre-RfA this kind of failure almost gets eliminated
Phase 3: Post-RfA review
editAfter Pre-RfA review at RfA, if the editors have less consensus but enough to be granted rights or it is a "no consensus" situation, editors are given a chance to show their ability. Those editors are granted admin rights for trial of 3 days. During this, their admin-related-contributions are reviewed by the RfA-review committee and issues are raised if found any. At the end of trial, !voting process starts.
Editors getting 8 out of 10 votes or getting a rough consensus of 75% or more are granted the admin rights finally. Standards of Post-RfA review are kept high because of the reason that more opposes would occur only if admin work conducted by the editor is problematic or in error.
In the middle of the trial, if an editor abuses admin rights or fails to handle those properly and makes mistakes consistently, their rights will immediately be removed.
Disadvantages of current process
edit- Biggest problem, few editors feel that the process is broken.
- Recently, the number of RfAs have drastically declined and out of this very few have managed to pass.
- Few editors due to fear about failure of their RfA do not go for RfA thinking that they might not be eligible.
- If the RfA fails, then the editor comes to know about it in a hard way and this results in editors loosing hope and retiring or reducing their activity level.
- Too many WP:NOTNOW/WP:SNOW occur. This also results in newbies leaving to community
- RfAs with a rough consensus of 70%-77% are closed as "no consensus" as the ability of the editor cannot be determined or their work can't be trusted
- Many RfAs are withdrawn by editors because they fear that their RfA would be closed as unsuccessful as they have bad consensus.
Advantages of the proposal
edit- This new process doesn't completely, but till some extend fixes the broken system by creating wider chance and better scope for editors to become admin in a manner in which the community can trust the editors.
- Thus by having a Pre-Review, editors will get actual overview that where do they stand and the community gets a better way to decide weather to trust the user or not
- By this process, more editors would participate as this reduces the problem of fear-of-fiasco and thus the number of RfAs will increase
- In this, it will just be a review and the editor gets a chance to address their problems in some time and then try so that they can pass. This doesn't make the editor feel discouraged.
- An editor who is relatively new or not at all eligible for RfA, will not get a chance to start a RfA as the committee will guide the editor in the right direction and tell them the truth. This way the editor wont feel bad or discouraged but will be encouraged to do the right thing as a tag of failed RfA wont be added to their name.
- By having a Post-RfA review, editors having less consensus are given a chance to show their ability and if they are good at the work, admins are made. This eliminates the problem of RfAs which are closed as unsuccessful because of less participation or more off-admin related opposes or RfAs having little below the borderline consensus.
- Recently there have been many RfAs which were closed because of withdrawn. Such editors can get a chance to prove their potential in the Post-RfA process and thus eventually the number of editors passing RfA can increase.
- If this new process occurs, this reduces the heated up thing at the RfA thus, it will automatically result in more editors trying themselves.
- At the end of the day, we can finally increase the number of RfAs and thus more deserving editors can get admin rights.
Thanks
editThanks for taking out time and reading this. Please add you suggestions, comments, supports and opposes on the talk page. Happy editing! →TSU tp*