User:Sven Manguard/Failed RfA Advice

Well that didn't go exactly as planned...

Well, you've reached this cheery little page of mine. If you were sent a link to this message, that probably means that you just got through an unsuccessful RfA. Don't take it personally. The statistics show that in recent years, a third to a half of all RfAs are unsuccessful. Plenty of good editors are unsuccessful, especially on their first attempts at RfA.

Wikipedians, as a community, are an eclectic and occasionally savage bunch, and RfA is one of their favorite playgrounds. You might be a perfectly ideal editor, but the community has decided that you are not ready for the tools. It could be for any number of reasons. Some of them, like content concerns and immaturity, are worked at over time. Others, like AN/I threads and blocks, remain sticking points for a very, very long time.

The key to a successful second RfA is twofold. First, you must demonstrate that the concerns raised in your first RfA have been sufficiently addressed. Second, you must not get yourself in any additional trouble and raise more concerns. History clearly shows that if you don't address the concerns raised from your first RfA, chances are high that you will be absolutely slaughtered on the second run around, especially if your second try is less than six months after the first. Your RfA might have failed, but that doesn't mean that the feedback you received wasn't important.

In the mean time, I'll give you exactly what the community is (or at least should be) looking for.

1. Go to Wikipedia:Administrators' reading list and read up on all the pages in the sections "Should already know", "Content policies", "Copyright", and "Controversy". Also read the first four pages in "Deletion."

   On second thought, you probably should read the whole thing cover to cover at least once, and make sure you re-read the ones in those sections a few days before running, just to make sure your information is fresh.

2. Go and demonstrate your new-found knowledge by participating in AfD, the various other fDs, and possibly AN/I, AN/EW, and the Help Desk.

   Careful on AN/I, as it has the habit of bringing the worst out of people. It feeds on drama and incivility. You can gain a lot of respect and trust by resolving issues that come up there, so long as you act civilly, neutrally, and know how and when to cite policy. However if all you ever bring to the discussions is hot air, you'll become part of the problem, and that will lose you trust and respect. In short, pick your battles; not even the admins participate in every single discussion there.

3. A tour of vandalism fighting is a mark of pride among the community, and dealing with vandalism is necessary duty that most if not all admins will end up heavily involved in. Demonstrate your ability to recognize what is and is not vandalism by spending some time in the trenches. Twinkle, Huggle, and Igloo will make it less tedious. Note though that while vandalism fighting is worth doing, it should not be all you do.

   Everyone, and I mean everyone, makes mistakes occasionally when fighting vandalism. The key to fighting vandalism effectively and in uncontroversially is not just to minimize the mistakes, which is important, but also to deal with those mistakes effectively. Trust your gut. If you think you might have made a mistake, double check your work. If someone posts a message asking you to justify a decision, or outright telling you that you made a mistake (some will tell you more civilly than others), do your due diligence and figure out what happened. If you catch your own mistakes, fix them, and clean up any assorted damage (warning messages, AIAV reports, etc.) as soon as possible. Never be afraid to apologize when you screw up.

   Finally, if you're making more than one mistake an hour, or more than one mistake in roughly 50 to 100 reverts, you need to put down the tools and do it by hand for a while, or stop and do something else entirely. Some people just are not cut out for vandalism fighting, and recognizing deficiencies is important. People will respect you more if you avoid vandalism fighting than if you do it, but do it poorly.

4. As important as 1, 2, and 3 are, the modern RfA will almost always fail if there is no content creation to go along with the vandalism fighting. Do constructive editing: Make an article or two, join a WikiProject, (or several projects), work on article promotions (GA, FA, and FL), or do a little bit of copy editing. Heck, do all four if you want. If actual content creation is too time consuming, or if you can't think of anything that isn't already covered, you can facilitate content creation at AfC. Find something that unequivocally adds content and value to the project, and then set out and do it.

   Other avenues include Featured Pictures, the Signpost, and various Help Desks. If you're good with prose, the Guild of Copy Editors could certainly use you. If you are a photographer, an image editor, or a digital artist, there is plenty of work in those fields that would also be useful. If you have a good voice, Spoken Wikipedia is one of those understaffed little corners of the project that can have a big impact. If you know copyright law, there is always a need for you at SCV, CCI, NFCR, and MCQ. If you're good with code, head over to Bot Requests and see what needs programming, or find some other tasks that could use automated assistance and write up programs for those tasks. Remember to always get approval for the bots before you start them up. Finally, if you want to help tackle backlogs of grunt work, there is the perpetually running Great Backlog Drive. These areas might not be content creation, but they tend to be grouped seperately from AfD and vandalism fighting, (remember that diversity in work is good), and they are highly respected fields.

5. Follow the RfA nominations of others, whether you vote or not, to see what the community standards are. You can see what is being looked for without throwing your name in the hat. I've also linked to a few essays in the Other Thoughts section, which includes a few very good criteria pages.
6. Never, never, never, be afraid to ask for help, advice, or a friendly review by other respected editors. The worst thing they can do is say no, but if they accept, their advice and guidance will be helpful. I will, to the best of my ability, help you if you ask me to, and many editors would do the same.
7. Don't get yourself blocked. It really hurts your chances. That means avoiding edit wars and vandalism. It's not hard to avoid being blocked, but I figured I'd mention it anyways.
8. Finally, spend at least six months, though preferably nine or twelve months, doing the above before throwing your name in the hat again. If you follow this guideline I can't see why you won't be successful the next time around.

Best of luck, see you around. Sven Manguard Wha?

P.S. I would think it goes without saying, but you can't do any of these things if you walk off in a huff because the RfA failed. Take a few days off if you need to, but don't quit just because your RfA wasn't successful. You're here because you enjoy being here, don't let any of this change that.

Other Thoughts and Thoughts by Others

For other opinions on RfA, I recommend the following essays:

• Kudpung's Advice for RfA candidates, an overview of community expectations and a set of recommendations for candidate behavior during RfAs. The essay is large, but formatted well, and hits just about all the points that are worth mentioning. A good place to start.

For a sampling of published support criteria, I recommend the following:

• Swarm's Criteria - Solid, easy to understand, middle of the road list of criteria.
• PeterSymonds' Criteria - A less numbers focused and more actions focused list of criteria.

While several users have publicized their criteria for assessment, these two are both especially well composed and from especially well respected editors. They're also both ubiquitous to the RfA process.

I happen to agree with both of these criteria. Where Swarm and PeterSymonds differ, mainly on lengths of time, I fall somewhere between the two. I tend to look for nine months of active editing, less than Swarm's twelve and more than PeterSymonds' six. My view on blocks is also different from both of theirs, but since blocks can be for a number of reasons I won't tie myself to any one number. That all aside I reiterate that I personally agree with both of those documents.

That being said, since everyone has their own standard, most users don't publish their standards, and even the best constructed standards are only one part of what should be a thorough case by case evaluation, don't take these as anything more than the well written guidelines that they are. Much like following the steps I've laid out in my essay above won't automatically guarantee a successful next request, (and blowing my essay off entirely won't automatically guarantee a failure), don't think that meeting or not meeting either or both of these criteria will set anything in stone. I linked to these pages so that you'd be able to see what goes though peoples' heads when they comment at RfAs.

Once again, I wish you luck.