From Wikipedia, the free encyclopedia

This is a guide for how to nominate candidates at Requests for Adminship. This list is not complete or exhaustive, and there is no obligation for nominators to follow it if they think that skipping some or all of the steps would be beneficial. It merely represents what its authors consider to be best practice.

Finding potential candidates

The first step is to find potential candidates. There is no exact science to this, and some great candidates can be found in unexpected places. However, here are some suggestions of where to look.

  • Use your personal experience. If you are a long-term contributor, you will have interacted with many dozens or even hundreds of editors. Experienced editors who made a good impression on you are likely to be good candidates for adminship.
  • Ask around. Editors who you have a relationship with may be able to point you towards some editors that they think highly of in their personal experiences. This can be particularly effective in offwiki venues related to editing, such as a meetup, Discord server, or Signal group.
  • Wikipedia:Requests for adminship/Optional RfA candidate poll is a place potential candidates can identify themselves and can also be a good place to practice doing preliminary checks and editor review. The poll's archives can also reveal candidates who might pass RfA now.
  • Wikipedia:List of administrator hopefuls. Editors are automatically added to this list if they use the {{ User wikipedia/Administrator someday}} userbox. This list is good for finding candidates who have the desire to run, but editors on it may be inexperienced, inactive, or otherwise unsuited to run. Some editors also are skeptical of people who use these boxes.
  • Wikipedia:List of Wikipedians by featured article nominations. Editors on this have proved that they can create quality content, which a lot of people look for in adminship candidates. However, many editors on the list are already admins, may not want to run for adminship, or may be inactive or blocked, etc. Relatedly you may choose to watch Featured Article nominations and/or good article nominations to see if there are any active regulars who are not administrators.
  • Wikipedia:List of Wikipedians by number of edits. This gives you a very rough idea of the amount of experience a contributor has, although most of the edits of editors at the top end of the list are semi-automated. It also handily lists all the users' user rights.
  • Wikipedia:List of Wikipedians by article count. This shows our most prolific article creators, another good test of content creation prowess. However, beware of editors that create many one-sentence stubs or poorly referenced articles, as this is generally frowned upon.
  • Review recent reports at administrative venues such as AfD, AIV, or RFPP to find active contributors who make reports with a high accuracy rate.
  • Select a group of people with a particular user right. For example, List of editors with the "New Page Reviewer" permission, sorted by most recent user. Anyone with this right has already been assessed to have a basic understanding of deletion policies, which are essential for adminship.
  • Fork and run a Quarry query such as this one. You can adjust or delete lines to change the criteria.

Preliminary checks

Once you have found a candidate, you need to make sure that there are no obvious obstacles to them running. You can check their:

  • Blocks. Recent blocks will be a large concern for many editors. Sometimes users have mistaken blocks in their block logs, and these should not carry any weight at all. If practical, look at the user's talk page archives to see if an unblock request was filed. Use your judgement – for example a five year old block for edit-warring with a successful unblock request of "I'm sorry, I was edit warring. I will not look at the page again." should not carry much weight.
  • Recent activity to make sure they're currently editing.
  • Desire to run. Some users may display userboxes such as {{ User wikipedia/Anti-Administrator}}, or may otherwise make it clear that they do not want to be considered for adminship, while others might note the opposite.

Editor review

Once you have finished the preliminary checks, it is time to start checking your potential candidate's contributions in depth.

Edit counts

  • Look at their XTools edit counter. This provides you a great snapshot of the editor and provides areas to check further. From here you can see their:
    • Total edits. The quality of a candidate's edits matters more than their quantity, but even so, users with a lower edit count may face opposition. As of late April 2022, there have only been 2 successful RfAs since 2017 for an editor with fewer than 10,000 edits.
    • Length of service. A good rule of thumb is 12 months of continuous editing, with some editors preferring 18–24 months. Sometimes less than 12 months of continuous editing will be OK for editors who have been regularly active over long periods of time (5+ years). If you see a candidate who is great except for this, it can still be worthwhile to contact them because if they are interested you could prepare to run when they've reached the 12 month mark.
    • Which namespaces editors use. Typically successful candidates will have a plurality of edits to article space (mainspace), while also having contributions to a project space such as Wikipedia or Template. Successful RfA candidates tend to have the highest number of individual edits on articles they have created or otherwise spent time working on – an editor with a small number of edits over lots of articles may attract numerous "lack of content creation" opposes.
    • Top edited pages with-in each namespace. This can give you an idea of places to check further. For instance if they have a lot of edits to Wikipedia:Administrator intervention against vandalism have their reports been accepted? [1] What kind of contributions have they made to their most frequently edited article and what is its current assessment (with Good or Featured being best)?
    • Total numbers of pages created (including deletions) and edits deleted.
  • Check the editor's user page. Frequently you can learn about them as a person and editor. Things to pay attention to include their user boxes and topicons: do they have any good or featured content? Do they indicate an interest in a certain project or wikitask?
  • Check for temperament concerns. If a user is sometimes rude or edit wars it can sink an RfA very fast. It's better to check for this thoroughly before nomination, as these kinds of concerns can cause contentious RfAs that are highly stressful for candidates. A good way to check this is to look through the editor's user talk archives and by searching at WP:ANI. If you find some less-than-friendly conversations there, then this aspect of their contributions is worth checking over a long period of their user talk and in other discussion spaces.

Candidate types

By this point you hopefully have a general idea of what kind of candidate they will be. Successful candidates frequently will fall into one, or more, of the following categories:

  • Content creators: This is someone who has worked hard to create content. They will frequently have a number of new articles in sufficient depth (i.e. they're not just creating lots of stubs), having a number of DYKs, Good Articles, and Featured Articles/Lists and who has shown some interest in the administrative side of Wikipedia in at least one area (for instance Articles for Deletion).
  • Vandal fighters: This is someone who has worked hard to keep vandals at bay. They will frequently have a high number of edits, with a number of them being semi-automated via scripts like Twinkle, Huggle, or RedWarn. They will normally have a significant number of edits to places like Wikipedia:Administrator intervention against vandalism, Wikipedia:Requests for page protection, and Wikipedia:Usernames for administrator attention. Editors who only revert vandalism and have not done any in-depth/significant content creation of their own have traditionally had a difficult time passing RfA.
  • Technical editors: This is someone who works on the technical side of Wikipedia. They will frequently have a number of edits in Template space, may have written user scripts, or run bots. They may have a significant number of edits at Wikipedia:Bots/Requests for approval.
  • Project editors: These are editors who are interested in the "behind the scenes" working of Wikipedia. They may focus on a particular area, such closing discussions, on a particular noticeboard, or who work on a particular task (e.g. New Page Patrol or Articles for Deletion). Traditionally it has been hardest for this kind of editor to pass RfA if they do not fit one of the other categories.

Specifics

For the next level of review you will want to give some attention to all areas, but pay particular attention to the areas that most overlap with the categories above.

  • Check for content contributions. Candidates without significant content contributions frequently have a hard time at RfA, so it makes sense to check for these early. Users often list their content contributions on their user pages, so check there for featured articles, good articles, or DYKs. You can also check the list of new articles the user has created.
  • Check for work in administrative areas. This will frequently involve using the edit history for either the editor or the page. There are also some tools available to help in this analysis:
    • Check AfD participation with the AfD statistics tool and the AfD closure statistics tool. Spot check the AfD debates to check the candidate's comments are of substance and not "me too" pile-ons. Also check debates where the candidate's vote didn't match the result. Was the candidate civil and polite to those disagreeing with them? Did they cite appropriate policies and guidelines? It is also worthwhile to check just their nominations in the same way. If the candidate is interested in working deletion, a good AfD record is essential to pass RfA. A rule of thumb for this kind of person is to have participated in at least 50 debates and matched consensus at least 80% of the time.
    • Check the user's CSD log and PROD log, if they exist, and see if they have made any recent bad nominations. Bad nominations can mean both nominations that were declined and nominations that were accepted but shouldn't have been (certain types of CSD, such as WP:A7, can be particularly controversial). User:Ritchie333/badspeedies.py is a Pywikibot script that can be used to list any Twinkle-style CSD tags on pages that have never been deleted.
    • AfC Review will let you examine their work at Articles for Creation.
  • Review their user talk. Pay particular attention to how they handle new users and criticisms. Are those criticisms part of a pattern? How long ago was the criticism? Does the user respond to criticism promptly and politely, or ignore it and hope it goes away? With new users do they show a willingness to help and explain? Have they received discretionary sanctions notices? If so, look at how they have acted on talk pages in those areas. Traditionally RFA voters like an editor who can keep their cool in heated areas.

It can also be helpful to consult other editors, particularly editors who have experience as (co-)nominators, for their opinions.

Asking the candidate

At some point after the basic checks, you should ask the candidate if they are willing to run. You can ask a candidate on their talk page, which can let others see or send them an email to offer more confidential feedback. It is a good idea to ask them early, as a good editor review takes a significant amount of time. If they are not willing to run, your time would be better spent elsewhere. To do this tactfully you can ask them something like, "Are you interested in running for adminship? I think you would be a good candidate, and if you like I can look through your edits and nominate you if I don't find any problems."

Some editors may need more persuasion than the above approach before accepting your offer. RfA can be a very stressful process, and it is not uncommon for editors to want to have a strong vote of confidence from their nominator before throwing their hat into the ring. In this case it might be worth doing a more detailed review first so that you can say with conviction that you think they are ready to run. Whether you think this would be worth doing is down to your judgement. Do not be surprised or disappointed if many (most!) editors turn you down no matter how qualified you think they are to run.

If you do find any problems that mean you are not willing to nominate, you can let them know tactfully by email. You may also discuss doing a nomination in the future. Many potential problems at RfA can be solved with 3–6 months of productive editing. For instance, if the candidate doesn't have enough content contribution you could suggest doing a GA, or if you observe trouble with a certain kind of CSD you could suggest the editor get more experience tagging with that CSD.

Preparing a nomination

After an editor agrees to accept a nomination, it is best to begin email communication with the candidate. You can discuss with the candidate if you should find another editor to serve as a co-nominator, or even in certain situations as the nominator. A co-nominator can be particularly useful if there is a candidate category that the nominator cannot speak to or cannot speak to credibly; for example, it may be hard for someone who doesn't understand templates to be the only nominator for a technical editor. Having more than one co-nominator is usually unnecessary and that person could often be more helpful as an enthusiastic supporter.

To write a really good nomination statement, you need to find the user's best contributions so that you can highlight them. Returning to the user page is the first stop for this, as editors will often list their editing interests or their best contributions there. You can also find useful hints through the list of most-edited pages in the counter tool, or by looking through their user talk archives to find out what they have collaborated with others on. There are many areas where users can make significant contributions that might go unnoticed, such as the help desk, the Teahouse, OTRS, dispute resolution, copyright cleanup, etc. If you can find things like this, it will make your nomination that much stronger.

It may be helpful to ask the candidate to answer the standard 3 questions before writing a nomination statement, in order to highlight or emphasize certain areas. Offering feedback on the standard 3 questions can also be helpful feedback for the candidate. Reviewing questions from recent RfAs to get a sense of what might be asked is another helpful practice. Finally, it is helpful to have a plan for any issues discovered during the editor review, or pointed out by the candidate. For some issues, it is best addressed in a nominator's statement, while other times the candidate will merely want to be ready to answer any questions if someone should ask them.

You will want to discuss when to run the RfA. You will want to make sure to do it at a time that the candidate has enough time, particularly in the first two days, to answer questions. As discussed above, sometimes you may want to wait to do a nomination so that more time elapses between a problem and the attempted RfA. Normally a nominator should do the technical aspects, such as creating the RfA page and transcluding. This way if something goes wrong, it is not held against the candidate.

During the RfA

During the RfA, the nominator is there to offer support and feedback to the candidate. Sometimes a candidate will want to get help with an answer to a specific question before responding on-wiki, to ensure they don't inadvertently shoot themselves in the foot.

Candidates sometimes will also need a place to let off steam or get support because of how stressful RfA can be. The vast majority of RfAs will have editors opposing, even for very successful nominations. This may be a minority view, concern over one area of contributions or a personal criteria (eg: "Oppose – no GAs"). There are likely to be comments both you and the candidate disagree with, and it is vitally important to resist any temptation to rebuke any opposition, as it can derail an RfA. Experience shows that if an oppose is questionable or without merit, it will be rebuked by an uninvolved editor anyway.

During a difficult RfA, it can be helpful for the nominator to offer an opinion about whether the candidate should continue or withdraw. Withdrawing too early is a mistake, but done at the right time, it can help preserve the candidate's chances at RfA in the future, or ensure that a productive editor doesn't become discouraged by further negative feedback.

Notes

  1. ^ To spot-check AIV reports, use XTools' "Top edits" feature to sample diffs, then move forward to see if the edit led to a block or a rebuke.
From Wikipedia, the free encyclopedia

This is a guide for how to nominate candidates at Requests for Adminship. This list is not complete or exhaustive, and there is no obligation for nominators to follow it if they think that skipping some or all of the steps would be beneficial. It merely represents what its authors consider to be best practice.

Finding potential candidates

The first step is to find potential candidates. There is no exact science to this, and some great candidates can be found in unexpected places. However, here are some suggestions of where to look.

  • Use your personal experience. If you are a long-term contributor, you will have interacted with many dozens or even hundreds of editors. Experienced editors who made a good impression on you are likely to be good candidates for adminship.
  • Ask around. Editors who you have a relationship with may be able to point you towards some editors that they think highly of in their personal experiences. This can be particularly effective in offwiki venues related to editing, such as a meetup, Discord server, or Signal group.
  • Wikipedia:Requests for adminship/Optional RfA candidate poll is a place potential candidates can identify themselves and can also be a good place to practice doing preliminary checks and editor review. The poll's archives can also reveal candidates who might pass RfA now.
  • Wikipedia:List of administrator hopefuls. Editors are automatically added to this list if they use the {{ User wikipedia/Administrator someday}} userbox. This list is good for finding candidates who have the desire to run, but editors on it may be inexperienced, inactive, or otherwise unsuited to run. Some editors also are skeptical of people who use these boxes.
  • Wikipedia:List of Wikipedians by featured article nominations. Editors on this have proved that they can create quality content, which a lot of people look for in adminship candidates. However, many editors on the list are already admins, may not want to run for adminship, or may be inactive or blocked, etc. Relatedly you may choose to watch Featured Article nominations and/or good article nominations to see if there are any active regulars who are not administrators.
  • Wikipedia:List of Wikipedians by number of edits. This gives you a very rough idea of the amount of experience a contributor has, although most of the edits of editors at the top end of the list are semi-automated. It also handily lists all the users' user rights.
  • Wikipedia:List of Wikipedians by article count. This shows our most prolific article creators, another good test of content creation prowess. However, beware of editors that create many one-sentence stubs or poorly referenced articles, as this is generally frowned upon.
  • Review recent reports at administrative venues such as AfD, AIV, or RFPP to find active contributors who make reports with a high accuracy rate.
  • Select a group of people with a particular user right. For example, List of editors with the "New Page Reviewer" permission, sorted by most recent user. Anyone with this right has already been assessed to have a basic understanding of deletion policies, which are essential for adminship.
  • Fork and run a Quarry query such as this one. You can adjust or delete lines to change the criteria.

Preliminary checks

Once you have found a candidate, you need to make sure that there are no obvious obstacles to them running. You can check their:

  • Blocks. Recent blocks will be a large concern for many editors. Sometimes users have mistaken blocks in their block logs, and these should not carry any weight at all. If practical, look at the user's talk page archives to see if an unblock request was filed. Use your judgement – for example a five year old block for edit-warring with a successful unblock request of "I'm sorry, I was edit warring. I will not look at the page again." should not carry much weight.
  • Recent activity to make sure they're currently editing.
  • Desire to run. Some users may display userboxes such as {{ User wikipedia/Anti-Administrator}}, or may otherwise make it clear that they do not want to be considered for adminship, while others might note the opposite.

Editor review

Once you have finished the preliminary checks, it is time to start checking your potential candidate's contributions in depth.

Edit counts

  • Look at their XTools edit counter. This provides you a great snapshot of the editor and provides areas to check further. From here you can see their:
    • Total edits. The quality of a candidate's edits matters more than their quantity, but even so, users with a lower edit count may face opposition. As of late April 2022, there have only been 2 successful RfAs since 2017 for an editor with fewer than 10,000 edits.
    • Length of service. A good rule of thumb is 12 months of continuous editing, with some editors preferring 18–24 months. Sometimes less than 12 months of continuous editing will be OK for editors who have been regularly active over long periods of time (5+ years). If you see a candidate who is great except for this, it can still be worthwhile to contact them because if they are interested you could prepare to run when they've reached the 12 month mark.
    • Which namespaces editors use. Typically successful candidates will have a plurality of edits to article space (mainspace), while also having contributions to a project space such as Wikipedia or Template. Successful RfA candidates tend to have the highest number of individual edits on articles they have created or otherwise spent time working on – an editor with a small number of edits over lots of articles may attract numerous "lack of content creation" opposes.
    • Top edited pages with-in each namespace. This can give you an idea of places to check further. For instance if they have a lot of edits to Wikipedia:Administrator intervention against vandalism have their reports been accepted? [1] What kind of contributions have they made to their most frequently edited article and what is its current assessment (with Good or Featured being best)?
    • Total numbers of pages created (including deletions) and edits deleted.
  • Check the editor's user page. Frequently you can learn about them as a person and editor. Things to pay attention to include their user boxes and topicons: do they have any good or featured content? Do they indicate an interest in a certain project or wikitask?
  • Check for temperament concerns. If a user is sometimes rude or edit wars it can sink an RfA very fast. It's better to check for this thoroughly before nomination, as these kinds of concerns can cause contentious RfAs that are highly stressful for candidates. A good way to check this is to look through the editor's user talk archives and by searching at WP:ANI. If you find some less-than-friendly conversations there, then this aspect of their contributions is worth checking over a long period of their user talk and in other discussion spaces.

Candidate types

By this point you hopefully have a general idea of what kind of candidate they will be. Successful candidates frequently will fall into one, or more, of the following categories:

  • Content creators: This is someone who has worked hard to create content. They will frequently have a number of new articles in sufficient depth (i.e. they're not just creating lots of stubs), having a number of DYKs, Good Articles, and Featured Articles/Lists and who has shown some interest in the administrative side of Wikipedia in at least one area (for instance Articles for Deletion).
  • Vandal fighters: This is someone who has worked hard to keep vandals at bay. They will frequently have a high number of edits, with a number of them being semi-automated via scripts like Twinkle, Huggle, or RedWarn. They will normally have a significant number of edits to places like Wikipedia:Administrator intervention against vandalism, Wikipedia:Requests for page protection, and Wikipedia:Usernames for administrator attention. Editors who only revert vandalism and have not done any in-depth/significant content creation of their own have traditionally had a difficult time passing RfA.
  • Technical editors: This is someone who works on the technical side of Wikipedia. They will frequently have a number of edits in Template space, may have written user scripts, or run bots. They may have a significant number of edits at Wikipedia:Bots/Requests for approval.
  • Project editors: These are editors who are interested in the "behind the scenes" working of Wikipedia. They may focus on a particular area, such closing discussions, on a particular noticeboard, or who work on a particular task (e.g. New Page Patrol or Articles for Deletion). Traditionally it has been hardest for this kind of editor to pass RfA if they do not fit one of the other categories.

Specifics

For the next level of review you will want to give some attention to all areas, but pay particular attention to the areas that most overlap with the categories above.

  • Check for content contributions. Candidates without significant content contributions frequently have a hard time at RfA, so it makes sense to check for these early. Users often list their content contributions on their user pages, so check there for featured articles, good articles, or DYKs. You can also check the list of new articles the user has created.
  • Check for work in administrative areas. This will frequently involve using the edit history for either the editor or the page. There are also some tools available to help in this analysis:
    • Check AfD participation with the AfD statistics tool and the AfD closure statistics tool. Spot check the AfD debates to check the candidate's comments are of substance and not "me too" pile-ons. Also check debates where the candidate's vote didn't match the result. Was the candidate civil and polite to those disagreeing with them? Did they cite appropriate policies and guidelines? It is also worthwhile to check just their nominations in the same way. If the candidate is interested in working deletion, a good AfD record is essential to pass RfA. A rule of thumb for this kind of person is to have participated in at least 50 debates and matched consensus at least 80% of the time.
    • Check the user's CSD log and PROD log, if they exist, and see if they have made any recent bad nominations. Bad nominations can mean both nominations that were declined and nominations that were accepted but shouldn't have been (certain types of CSD, such as WP:A7, can be particularly controversial). User:Ritchie333/badspeedies.py is a Pywikibot script that can be used to list any Twinkle-style CSD tags on pages that have never been deleted.
    • AfC Review will let you examine their work at Articles for Creation.
  • Review their user talk. Pay particular attention to how they handle new users and criticisms. Are those criticisms part of a pattern? How long ago was the criticism? Does the user respond to criticism promptly and politely, or ignore it and hope it goes away? With new users do they show a willingness to help and explain? Have they received discretionary sanctions notices? If so, look at how they have acted on talk pages in those areas. Traditionally RFA voters like an editor who can keep their cool in heated areas.

It can also be helpful to consult other editors, particularly editors who have experience as (co-)nominators, for their opinions.

Asking the candidate

At some point after the basic checks, you should ask the candidate if they are willing to run. You can ask a candidate on their talk page, which can let others see or send them an email to offer more confidential feedback. It is a good idea to ask them early, as a good editor review takes a significant amount of time. If they are not willing to run, your time would be better spent elsewhere. To do this tactfully you can ask them something like, "Are you interested in running for adminship? I think you would be a good candidate, and if you like I can look through your edits and nominate you if I don't find any problems."

Some editors may need more persuasion than the above approach before accepting your offer. RfA can be a very stressful process, and it is not uncommon for editors to want to have a strong vote of confidence from their nominator before throwing their hat into the ring. In this case it might be worth doing a more detailed review first so that you can say with conviction that you think they are ready to run. Whether you think this would be worth doing is down to your judgement. Do not be surprised or disappointed if many (most!) editors turn you down no matter how qualified you think they are to run.

If you do find any problems that mean you are not willing to nominate, you can let them know tactfully by email. You may also discuss doing a nomination in the future. Many potential problems at RfA can be solved with 3–6 months of productive editing. For instance, if the candidate doesn't have enough content contribution you could suggest doing a GA, or if you observe trouble with a certain kind of CSD you could suggest the editor get more experience tagging with that CSD.

Preparing a nomination

After an editor agrees to accept a nomination, it is best to begin email communication with the candidate. You can discuss with the candidate if you should find another editor to serve as a co-nominator, or even in certain situations as the nominator. A co-nominator can be particularly useful if there is a candidate category that the nominator cannot speak to or cannot speak to credibly; for example, it may be hard for someone who doesn't understand templates to be the only nominator for a technical editor. Having more than one co-nominator is usually unnecessary and that person could often be more helpful as an enthusiastic supporter.

To write a really good nomination statement, you need to find the user's best contributions so that you can highlight them. Returning to the user page is the first stop for this, as editors will often list their editing interests or their best contributions there. You can also find useful hints through the list of most-edited pages in the counter tool, or by looking through their user talk archives to find out what they have collaborated with others on. There are many areas where users can make significant contributions that might go unnoticed, such as the help desk, the Teahouse, OTRS, dispute resolution, copyright cleanup, etc. If you can find things like this, it will make your nomination that much stronger.

It may be helpful to ask the candidate to answer the standard 3 questions before writing a nomination statement, in order to highlight or emphasize certain areas. Offering feedback on the standard 3 questions can also be helpful feedback for the candidate. Reviewing questions from recent RfAs to get a sense of what might be asked is another helpful practice. Finally, it is helpful to have a plan for any issues discovered during the editor review, or pointed out by the candidate. For some issues, it is best addressed in a nominator's statement, while other times the candidate will merely want to be ready to answer any questions if someone should ask them.

You will want to discuss when to run the RfA. You will want to make sure to do it at a time that the candidate has enough time, particularly in the first two days, to answer questions. As discussed above, sometimes you may want to wait to do a nomination so that more time elapses between a problem and the attempted RfA. Normally a nominator should do the technical aspects, such as creating the RfA page and transcluding. This way if something goes wrong, it is not held against the candidate.

During the RfA

During the RfA, the nominator is there to offer support and feedback to the candidate. Sometimes a candidate will want to get help with an answer to a specific question before responding on-wiki, to ensure they don't inadvertently shoot themselves in the foot.

Candidates sometimes will also need a place to let off steam or get support because of how stressful RfA can be. The vast majority of RfAs will have editors opposing, even for very successful nominations. This may be a minority view, concern over one area of contributions or a personal criteria (eg: "Oppose – no GAs"). There are likely to be comments both you and the candidate disagree with, and it is vitally important to resist any temptation to rebuke any opposition, as it can derail an RfA. Experience shows that if an oppose is questionable or without merit, it will be rebuked by an uninvolved editor anyway.

During a difficult RfA, it can be helpful for the nominator to offer an opinion about whether the candidate should continue or withdraw. Withdrawing too early is a mistake, but done at the right time, it can help preserve the candidate's chances at RfA in the future, or ensure that a productive editor doesn't become discouraged by further negative feedback.

Notes

  1. ^ To spot-check AIV reports, use XTools' "Top edits" feature to sample diffs, then move forward to see if the edit led to a block or a rebuke.

Videos

Youtube | Vimeo | Bing

Websites

Google | Yahoo | Bing

Encyclopedia

Google | Yahoo | Bing

Facebook