Guild Wars Wiki talk:Requests for adminship/Archive 2007

Formatting and reconfirmation

Nice work on this proposal Rezyk, I am quite happy with most of it, but there are 2 points I dislike:

• Formatting: Policies should never regulate formatting. Having templates to help with formatting is ok, but they are integral in this policy (i.e. an editor can not create a RFA without it, because the policy does not state the information needed). They should not be. All importent requirements should be listed in the policy. This is especially true since we are here talking about a policy that most likely will be used by experienced editors, who need not rely on templates and would be able to create the page themselves.
• Reconfirmation: This step seems strange to me. I would understand it, if it was a regular "check" on sysops. In that case I'd list the conditions of entering one and simply state "in those cases a new RFA is started for an existing sysop". However it talks about reconfirmation directly after RFA, which for me looks like basically two RFAs back to back. --Xeeron 09:51, 12 June 2007 (UTC)

I reworded the reconfirmation section a bit; see what you think. I'll try to address your concern about formatting after figuring out the template. --Rezyk 16:00, 12 June 2007 (UTC)

Ok, I think I get what you intend the reconfirmation to be. I rewrote it a bit to have all conditions for starting reconfirmation completely in the bullet point list. --Xeeron 16:27, 12 June 2007 (UTC)

Okay, check the new revision regarding formatting. --Rezyk 21:29, 13 June 2007 (UTC)

Re-RFA

I'm referring to this particular condition: within the past 2 weeks (as a guideline, one should usually wait at least a month). If one should usually wait at least a month, why even bother mentioning 2 weeks? Or if 2 weeks is a long-enough wait, why bother mentioning one month? -- ab.er.rant 12:01, 12 June 2007 (UTC)

The idea is that one should usually wait at least a month, but might go down to 2 weeks if there's a good enough reason. (For example: Maybe there is someone that everyone obviously wants as a sysop, but who had to withdraw due to a sudden real life emergency.) There's no need to list all the exact good-enough reasons because abusing it frivolously risks earning more opposition within the RFA. Ideally though, these figures should represent how the community feels, so I ask all of you: How long should someone wait between failed RFAs to expect that you would not hold it against them at all for trying too often? How long should the bare minimum be to effectively auto-reject repeated tries? --Rezyk 16:29, 12 June 2007 (UTC)

I support 4 weeks as a bare minimum, with 12 weeks as the suggested wait. —Tanaric 14:55, 13 June 2007 (UTC)

I'd suggest a little rewording like: Someone with an unsuccessful RFA that closed less than 10 weeks ago (a minimum of 4 weeks on special circumstances). -- ab.er.rant 15:46, 13 June 2007 (UTC)

Resolving an RFA

Is it saying that we resolve an RFA by simply talking about candidate? No application, partial or otherwise, of GWW:ELECT? So... we just talk about a candidates eligibility and then after X number of days, a bureaucrat will come and analyze all the discussions and decide. Doesn't this seem rather ... simple compared to the election process for a bureaucrat? But anyways, if this is the case, then I would like to suggest 14 days of discussions - the total number of days of the GWW:ELECT's nomination + voting stages. -- ab.er.rant 15:57, 13 June 2007 (UTC)

Bureaucrats need a complicated process because their positions involve the application of their own subjective evaluation. Sysops only apply tools in the manner prescribed by policy. The sysop role is not a big deal, and there is no limit on the number of sysops. No election policy is needed. —Tanaric 16:59, 13 June 2007 (UTC)

I threw in a value of 7 days; feel free to disagree, anyone. I couldn't really see why it should be any longer than the election voting stage, which theoretically should require a lot more consideration. --Rezyk 19:22, 25 June 2007 (UTC)

Reconfirmation

if I read this correctly, there is no explanation on how a reconfirmation is done, just a list of things that initiate a reconfirmation. Would someone care to explain and also add thisto the article. -- (gem / talk) 23:45, 13 June 2007 (UTC)

I thought it fairly clear - "The reconfirmation process itself is simply another RFA for the sysop." MisterPepe talk 01:30, 14 June 2007 (UTC)

Lol, I can see it now. It was 4AM at the time and I was thinking whether I should post to ask or sleep first and reread the thing. Oh well... -- (gem / talk) 10:08, 14 June 2007 (UTC)

SysOps for Life

Rezyk asked me to read this. I'm still very, very opposed to any appointment "for life." I've made lengthier comments on this in other places, and I'll gladly link them when it's not 1:00 in the morning. ;) For now, I just want to beg for another consideration of the position that we ought not have a bunch of potentially inactive "Oh, I remember that guy" or "We don't want to recall her, she might get active again" or "They're not 'bad enough' to remove, so let them stay (out of respect for previous service or for other reasons" types of people. When you have major issues, or want to get forward movement, it's more easily and productively accomplished with a tighter, assuredly-active and committed group, imo. --Gaile 08:04, 15 June 2007 (UTC)

TBH, it's less of a big deal than you might think - due to the nature of the sysop position (as the way we have it defined here is far different from, say, GuildWiki's - see GWW:ADMIN), there's really no reason to limit the number of sysops. Hypothetically, we could have ~300 sysops and still promote a couple more. Likely? Of course not, but there's no reason why we couldn't. Sysops are effectively normal users with a couple extra tools under the current policy.

That being said, I think that this draft does a decent job of making it relatively simple to recall a sysop. See the "Reconfirmation" section. I think the way that that section is written is a pretty good job of dealing with this too - it allows for reconfirmation RfAs for sysops based on consensus, user support, sysop request, and ArbComm mandate - it's a very flexible little section. Really, if a sysop becomes inactive, it's not very hard at all to start up another RfA for them (though, once again, it doesn't really matter if we have a couple extra sysops that are less than active, as long as we have enough active ones) - of course, if the sysop in question is inactive, it's highly unlikely they'll be reconfirmed in the RfA.

Is it the same as a term limit? Of course not. But really, if the sysops are doing a good job, I don't really see a good reason to force them to undergo a new RfA just because their time ran out. While it would weed out inactive admins, it's easy enough in this version of the policy that it doesn't really matter, IMO.

As usual, my 2 MisterPepe talk 08:15, 15 June 2007 (UTC)

I think that sysops don't need a term length, although we could implement a system for automatically demoting inactive sysops. We could set a limit of 2-3 months after which a sysop is demoted if he stays inactive. -- (gem / talk) 09:14, 15 June 2007 (UTC)

Sounds like a great idea Gem, I could never understand why GWiki still had inactive SysOps, it looks messy. --Jamie 09:18, 15 June 2007 (UTC)

Just kick them back into reconfirmation rather than autodemoting, IMO MisterPepe talk 09:20, 15 June 2007 (UTC)

(conflict) Yea. Something that mentions that the reconfirmation will be carried out should an admin appear to have become relatively inactive for 2 months. Mentioning what is considered inactive is important I believe. A sysop that checks in once a month isn't really active enough to warrant being a sysop. -- ab.er.rant 09:22, 15 June 2007 (UTC)

Okay, a reconfirmation then. How about something like this as one bullet in the list of possible ways to start a reconfirmation: "the sysop in question is relatively inactive for 3 months."

This also brings up a small thing that needs to be noted in the article, an RfA and a reconfirmation must be accepted by the user so that an inactive user can't be made a sysop. -- (gem / talk) 11:34, 15 June 2007 (UTC)

I prefer not making activity requirements policy, and instead relying on the "user support" and "community consensus" clauses in the reconfirmation draft. If anybody notices a sysop has been inactive for a period, it can be handled on a case by case basis. For example, if Karlos says, "I just won the lottery, I'll be in Tahiti for the next six months," I don't think he should be automatically removed from his position because he can't answer a mandatory three-month reconfirmation proposal. That said, in that case, I would certainly support a reconfirmation a month after he returned, just to make sure he hadn't gotten too out of touch with us common peasants during his vacation. :) —Tanaric 12:57, 15 June 2007 (UTC)

Gaile, I'm not sure if this was apparent (I've edited the draft to make it clearer), but the "request for reconfirmation" process is intended as a sort of inevitable check -- it's just based on a measure of user support rather than time directly. For example: A user gets sysop'ed with ~20 supporters and a few opposers. Then it's generally a matter of waiting until there are ~20 accumulated supports for reconfirmation, which can represent a variety of opinions:

• people who do not or no longer trust that sysop to use the position responsibly
• support from those who prefer periodic reviews (depending on how long the sysophood has lasted)
• people who fully support that user as a sysop, but believe it is now questionable whether an RFA would pass
• people who feel that we've failed to meet the ideal of sysophood being No Big Deal, and want the sysop pool to be shaped differently
• whatever reason, really

Even if there were 10 times as many opposers to reconfirmation starting, it would still happen (under this policy draft) because opposition is not counted in the trigger condition. Also, any sysop who goes completely inactive forever would get desysop'ed after a reconfirmation trigger, because starting a new RFA requires their participation. Does this alleviate any of your concerns? --Rezyk 15:28, 16 June 2007 (UTC)

Thanks for your patience with my questions, Rezyk. Yes, the process you've outlined makes perfect sense. Except... well... there does not seem to be a mechanism for periodic reconfirmation. So an inactive SysOp could sit on board unless people proactively called for a reconfirmation, right?

Has the administrative board considered having a yearly reconfirmation? A periodic reconfirmation is mentioned, but not specifically called out by the proposal. I'd be very much behind an annual reconfirmation process. Has that been effective in other communities? What are the drawbacks? Thanks for helping me solidify my thoughts on this matter. --Gaile 08:07, 19 June 2007 (UTC)

I'm just against having any sort of Sword of Damocles (fine, that's not an entirely accurate example, but it's a really cool reference) hanging over our Sysops. It's really easy to start up a reconfirmation, and I don't really think that we have a need to force a periodic one on our active administators. IMO, it's a waste of time to have to go through periodic reconfirmations for sysops that are more or less sure to pass muster - if there isn't sufficient community concern to warrant a reconfirmation, they're pretty likely to pass the new RfA.

I just really don't see inactivity as a concern under the current draft. If there's no reason to regulate periodic reconfirmations or specific inactivity requirements (they don't really make sense, tbh - it may vary due to circumstances), then I'd rather we didn't. Anyone who really cares about periodic reconfirmations is welcome to add their support to/start a new reconfirmation. I like the way that Rezyk put it, personally - there just doesn't seem to be a need for a specific time limit. MisterPepe talk 08:37, 19 June 2007 (UTC)

Correct; you would need enough people to have requested reconfirmation for an inactive sysop. For a fully automatic periodic reconfirmation, the main drawback in my view is having to go through the extra process even if nobody feels a need for it. For almost all other wikis I've seen, sysophood has no formal community review process and they just rely on some bureaucrat/arbcomm/owner/etc keeping it in check when necessary. One notable exception is on meta.wikimedia, which demotes after a year of (relative) inactivity and polls once a year if there is opposition.

I've edited the draft into something that I hope is acceptable enough to both viewpoints here. The reconfirmation process is still not automatic, but anybody who wants can still trigger yearly reconfirmation. Thoughts, everybody? --Rezyk 19:14, 25 June 2007 (UTC)

Would it make sense to set a limit that no more than some given percentage of admins can be going through a reconfirmation process at any one time? I don't have a strong preference on what percentage is used ... 25%, 33%, or 50% all seem workable ones. That minimises the risk of total upheaval in the sysop group all at one time - unlikely to happen, but possible. Or do others feel that leaving that open so that a complete house cleaning could be done in case its ever needed for whatever reason? --- Barek (talk • contribs) - 03:54, 26 June 2007 (UTC)

I don't really seem why it would need to be limited. If there needs to be a total upheaval in the sysop group (though highly unlikely), why would we not put unfit sysops up for reconfirmation? I'd say leave it open. MisterPepe talk 05:02, 26 June 2007 (UTC)

Ready for implementation?

Are we ready to make this a policy? -- (gem / talk) 15:40, 25 June 2007 (UTC)

Not content, but presentation: The policy is currently suggesting editors to use non-working features (createbox). --Xeeron 17:33, 25 June 2007 (UTC)

The page does, at least, have instructions on how to do it the manual way. Think we can at least change this to proposed (rather than draft)? MisterPepe talk 18:56, 25 June 2007 (UTC)

I've cut out the createbox stuff for now. We still need to fill in some of the "?"s. --Rezyk 19:15, 25 June 2007 (UTC)

The ones you just popped in look fine to me. MisterPepe talk 19:18, 25 June 2007 (UTC)

Could somebody clarify this line: "In general, the line between successful and declined RFAs is at 75%". I think it means, "if a nominee has three times as much support as he does opposition, he is generally accepted as a sysop," but I'm not sure. —Tanaric 22:46, 26 June 2007 (UTC)

That was my intention. You think it needs a rewording? --Rezyk 22:55, 26 June 2007 (UTC)

Probably better to reword. -- ab.er.rant 01:02, 27 June 2007 (UTC)

Any more issues? -- ab.er.rant 14:52, 3 July 2007 (UTC)

I support this policy as written. —Tanaric 18:01, 3 July 2007 (UTC)

Ditto. MisterPepe talk 18:05, 3 July 2007 (UTC)

Support. --Xeeron 18:58, 3 July 2007 (UTC)

It seems that Gaile is okay with this version as well. --Rezyk 19:19, 3 July 2007 (UTC)

Seeing as tomorrow is an American holiday, let's give dissenters until Thursday evening to make themselves known before making this policy official —Tanaric 04:01, 4 July 2007 (UTC)

Bump to see if we can get any more comments on this before this evening (just in case people missed it) MisterPepe talk 18:59, 5 July 2007 (UTC)

Candidate Statements

Looking at the current RFAs, 6/7 candidates have expressed some confusion about candidate statements, instead preferring that people look at their contributions. It seemed to be the same with the last bureaucrat election as well. I'm just wondering what the rationale behind them is. As Xeeron put it, "if you are convinced only by my candidate statement, I'd likely not be a good sysop" -- AT(talk | contribs) 02:11, 9 July 2007 (UTC)

Hmmm, I dont fully understand what you are getting at, but even if a candidate statement might not convince you to vote for a candidate, it might convince you NOT to vote for a candidate. Furthermore, it might convince you if put together with the contributions of said person. So it is not without value. --Xeeron 21:21, 11 July 2007 (UTC)

Cheers for the reply. You did seem to understand what I was getting at - what the value of the candidate statement is. I hadn't thought of your second point (convincing people not to vote for someone) previously, which makes a lot of sense. -- AT(talk | contribs) 21:26, 11 July 2007 (UTC)

If nothing else, I think the statement portion has value in simply allowing the user in question to demonstrate that they're actively interested in the position, beyond a simple acceptance of a nomination. Even if the statement is simply that the user in question would like the focus to be on their contributions, it still shows that they've gone to the effort to say their piece. (Aiiane - talk - contribs) 21:30, 11 July 2007 (UTC)

Self Nominations

Self nominations allowed?--§ Eloc § 04:44, 9 July 2007 (UTC)

Yes you can nominate yourself Eloc, It says you can on the project page... -- Scourge 04:48, 9 July 2007 (UTC)

Edits to support/oppose

How many edits do you need to support/oppose a candidate? Indochine talk 17:51, 9 July 2007 (UTC)

There's no restriction currently in the policy. Go for it =P (You've also got somewhere around 100 non-user/guild namespace edits - you're probably allowed to vote in the BCrat elections as well) MisterPepe talk 18:03, 9 July 2007 (UTC)

Thanks, I just wanted to check before I voted. -- Indochine talk 18:04, 9 July 2007 (UTC)

Number of sysops

There has been a recent flood of new RfAs, most of them with highly supportive votes. Although I think it's good to have more sysops and I would normally support most of those users, I'm worried that suddenly promoting half a dozen new sysops would shake the balanced nature of this wiki quite a lot. I don't like it that the procedure listed on the RfA page seems to give us little choice on granting sysop status if the majority of the votes are positive. I would like some sort of limitations for granting multiple users the sysop status. What about a limit of 2-3 new sysops within a 2-4 week time period. -- (gem / talk) 12:41, 11 July 2007 (UTC)

It says "There is no inherent limit to the number of active sysops." in the policy. - BeX 12:43, 11 July 2007 (UTC)

I don't see a bad thing in an increase of the number of sysops. Most of the candidates are, let's face it, Wiki addicts *looks at Bex*. And that is a good thing. Fighting vandalism will become easier and quicker, though I might be out of a job when it comes to maintenance. :P — Gares 13:49, 11 July 2007 (UTC)

I didn't say that we should put a limit on the maximum amount of sysops. I suggested a limit on the amount of sysops made within a small time frame as making multiple new sysops within a really small time frame (a few days in this case) would most likely cause some unbalance in the wiki. -- (gem / talk) 15:16, 11 July 2007 (UTC)

That is a good point, imo. I know if I would get sysop tools I'm bound to make some mistakes over the first period (at least). If we are three new sysops one week, that is less mistakes than if we are 10 new sysops one week :P It's not about not trusting people or not wanting them as sysops. - anja 15:22, 11 July 2007 (UTC)

Agreed. I think all new sysops would kinda need some time to sort of "fit in" to the role, and would probably need some monitoring by the other sysops just to make sure they don't accidentally cross the lines. The policy says bureaucrats should resolve and close an RfA in about a week, but there's nothing that says that the nominee needs to be made a sysop straightaway. Adding in the little buffer period suggested by Gem doesn't really violate the policy... twisting it a little, yes, but violating, no :P -- ab.er.rant 15:32, 11 July 2007 (UTC)

You do have a point, we could just delay the process, but instead of 'twisting and bending' I would like to see this implemented as a change to the policy. -- (gem / talk) 15:39, 11 July 2007 (UTC)

(edit conflict) Perhaps lock RfA until for whatever reason the need is percieved for new sysops? For example, a large increase in vandalism, sysops going inacitve due to holidays or personal reasons or just so we can have someone on the wiki 24/7. If we made every good contributor a sysop then no doubt other users would be intimidated by the sheer number of them in proportion to other active users. And also, remember that sysophood shouldn't be based on mainspace contributions alone... stuff like policy discussions, vandalism reversion, willingness to help other users and other factors should take a larger part in the decision. The point of being a sysop is moderation and cleanup, if all they do is add content to the mainspace (which isn't a bad thing at all), then their position is more or less honorary, which isn't much good. --Santax (talk · contribs) 15:49, 11 July 2007 (UTC)

I also don't see anything wrong with having many sysops, the more the merrier (if we were able to get 99% of the wiki users to be sysops, it would be ideal, it'd mean that 99% of the users are trusted by the community). And don't worry too much about these initial high numbers of candidates, everyone was waiting for the RFA policy to be finalized, itching to get some new admins. It should calm down from here on. --Dirigible 16:16, 11 July 2007 (UTC)

Along the lines of what Ab.er.rant said, perhaps it could be added to the policy that a newly-chosen sysop's promotion (promotion isn't quite the right word, but it's what I'm using) may be delayed up to a few weeks (2 or 3?) from the close of voting if there are a large number of other new and pending sysop promotions ahead of them? - Tanetris 16:25, 11 July 2007 (UTC)

Something like that would be ideal. A may be delayed so that on times like this when we don't necessarily need more sysops we can give them time to get used to the sysop tools, and on times when we need more sysops we can give the tools immediately. -- (gem / talk) 16:47, 11 July 2007 (UTC)

I strongly prefer to not have any "may be delayed" clause in the policy, since it seems to be a perfect way of opening the policy for abuse to me. If there is a worry about having too many new sysops at once, I suggest that some of the new appointees volunteer to not use their sysop powers for X weeks/not have their accounts "sysop'd" for X weeks. I would be willing to do so, if chosen. --Xeeron 21:19, 11 July 2007 (UTC)

Remember that it's the bureaucrats who would be deciding on it and we've voted on trusting them. Well, I'm happy with any solution as long as we don't run into problems. :) -- (gem / talk) 21:45, 11 July 2007 (UTC)

That sort of potential abuse is why I included both having a definite maximum for the delay (I may not have been clear on this: In the policy, there should be an exact amount of time the delay can't be longer than, I just don't know what it should be exactly), and that condition being the only situation for the delay in the suggestion. Is there still a possibility some bureaucrat with a grudge could delay someones sysop-hood unfairly? Yes, but A: They are in that position specifically because we trust them to put community interests over personal ones, B: We do have processes when one of them breaks that trust, C: I can't imagine that the other bureaucrats wouldn't step in, and D: certainly if there was going to be abuse, it would be the "Bureaucrats are to use their discretion in gauging/interpreting the amount of support/opposition" part of the policy. - Tanetris 22:01, 11 July 2007 (UTC)

Grandfathered sysops

We have some sysops that do a great job on this wiki, but they still haven't been voted in by the community. I know that we've been planning to reconfirm all of the grandfathered sysops for some time now, but we've been waiting until this policy was ratified.
Anyway, I think it's probably time to start up some of those reconfirmations, though we might want to wait until Friday (a decent number of the current RfAs will end on Friday, allowing us to clear out the page somewhat.
Thoughts/concerns/snide remarks/death threats? MisterPepe talk 16:51, 11 July 2007 (UTC)

Agreed. -- (gem / talk) 16:53, 11 July 2007 (UTC)

There's a possibility (however slim) that some sysops will not be re-elected. I think we should wait a little longer, so that those sysops currently being considered can settle in before we might face any deficit. Perhaps I am being overly cautious, but those are my thoughts :) LordBiro 16:56, 11 July 2007 (UTC)

Good point, although this wont probably be a problem. I guess we can wait two three weeks. -- (gem / talk) 16:59, 11 July 2007 (UTC)

For grandfathered sysops the current policy requires a timeline to trigger for them to be put up for reconfirmation, but we haven't set one; can we do that now? I'm specifically thinking about the Karlos issue right now, and the fact that several users have called for his sysop rights to be removed; I think a reconfirmation at this point in time would be only fair. --Dirigible 14:24, 14 July 2007 (UTC)

I suggest we (as in, the community) just pick a date at which time every grandfathered sysop should be de-sysoped if not successfully reconfirmed. The sysops are already free to start up their own reconfirmation RFA at any time (like Tanaric has done). --Rezyk 15:24, 14 July 2007 (UTC)

I don't think the Karlos issue merits de-sysoptation - but I do agree that reconfirmations for all sitting sysops should be started soon. I see that Tanaric has already voluntarilly started his, and I plan to do the same for mine as well. --- Barek (talk • contribs) - 19:08, 14 July 2007 (UTC)

Well, looking between the resolved RFAs category, the current RFAs, and the sysop list (excluding bureaucrats), looks like the only grandfathered sysops left are Gares Redstorm, Karlos, Rainith, and Xasxas256 (please correct me if I'm wrong)... How bout we start RFAs for them once Barek's is done (unless they decide to go sooner)? It'd give a little time for tempers to calm about Karlos and the user page debate, so we can all take a more objective view at his track record, and just in case everyone fails (not gonna happen by the current votes, but who knows?), our sysop list doesn't drop too much in one or two days. - Tanetris 22:38, 14 July 2007 (UTC)

The above comment is becoming more and more irrelevant as time passes, but I stand by the core of it nonetheless. Anyone agree or have a differing idea? - Tanetris 23:01, 15 July 2007 (UTC)

By "start RFAs for them", do you mean: creating their RFA page and adding it to the list, without necessarily requiring their interaction? What if the grandfathered sysop is on vacation and returns to find a Failed RFA on record, where they didn't get any chance to write a candidate statement or respond to concerns? (We've already had one case of a user unhappy about their RFA being started.) This is why I suggest just picking a date to desysop anyone still on pure-grandfathered-status. It still effectively forces them to reconfirm to keep sysop status, but also shouldn't be a big deal if they don't (as long as they're given enough notice). --Rezyk 23:26, 15 July 2007 (UTC)

Yes, that is essentially what I meant, creating the RFA page and leaving a note on their talk page about it, along the lines of what's written under the reconfirmation heading, but you do raise a good point. There is currently nothing in the reconfirmation section about giving the sysop in question an opportunity to "defend him/herself" so to speak, and there probably should be. I certainly would be against starting a reconfirmation for anyone who was on vacation or otherwise away from wiki, be it a grandfathered sysop or a sysop whose status has been called into question. Is there a fair way to allow for this in the policy, without letting a misbehaving sysop postpone his/her reconfirmation indefinitely?

I'll mention, though it's a little moot now, that the reason I felt starting an RFA by a certain time rather than desysopping if they didn't start one by a certain time is that both methods have the same issue with notice and both allowed the sysop to start one sooner, but at least with an RFA in absentia, a vote is still given a chance. Certainly most of the grandfathered sysops haven't felt a need to make large candidate statements, relying instead on their record.

Of course, to the matter at hand, at this point I think I'll just go over to Rainith's talk page and point him to this discussion, see what he thinks about it, since he's the only one left. - Tanetris 17:03, 16 July 2007 (UTC)

Sorry to cause so much trouble. I'm very short of time today (even more so than usual) and if someone wants to throw up a re-confirmation page for me I'd appreciate it. I should be able to put a statement on there tomorrow or if no one wants to do start it, I'll try to do the whole thing tomorrow. --Rainith 21:15, 16 July 2007 (UTC)

RL always comes first. I put it yours up right before I'm about to take off. No worries. — Gares 21:28, 16 July 2007 (UTC)

The main method of reconfirmation for existing sysops (user support) was written with this in mind -- when it triggers, the RFA page is not to be automatically created, but a deadline of 2 weeks is given to the sysop to be successfully reconfirmed. If they don't start up (or give permission for someone to start up) their own RFA within one week, they should get desysoped at some point. Maybe they'll be away on vacation, miss this window, and thus be desysop'd...but this doesn't have to be a big deal, right? (Being desysop'd doesn't have to mean punishment for doing something wrong.) When they're back and ready, they just run through their RFA for a week. Fair enough? --Rezyk 21:56, 16 July 2007 (UTC)

Agreed with Rezyk. I think it makes perfect sense to desysop those sysops that aren't around at the moment don't respond to a reconfirmation within a certain perdiod. It shouldn't be a big deal to get their position back! LordBiro 22:09, 16 July 2007 (UTC)

(RI) Clearly I'm blind as I never saw the last sentence under the user support explanation. It does seem a reasonable enough protection for that case, and obviously voluntary reconfirmations aren't going to be an issue... I suppose it's just something we should keep in mind when community consensus or ArbComm decisions are involved rather than something that needs to be specifically written in? Good enough for me, anyway. And Rainith nicely resolves the original issue here, so let's all take a moment to be happy about that. :) - Tanetris 22:38, 16 July 2007 (UTC)

Time of RFAs

This is somewhat unfortunate since we started many RFAs now, but the timeframe of 1 week strikes me as too short now. I didn't see that problem earlier, but looking at the current RFAs, I cant help but feel that RFAs of people like me or Aiiane should run for longer, since the support is far from overwhelming (actually 2 opposing votes would mean that either RFA would lean towards reject, not accept, given the criterion of the policy). A longer timeframe, 2 weeks or even better 4, would let more people find the RFAs and we could be more confident that the candidate has been thoroughly checked. --Xeeron 22:24, 11 July 2007 (UTC)

Time isn't the problem, its that these pages are hidden(lost somewhere in the wiki), i didn't even knew there was something like this until i saw it in RC, maybe a warning on top of the wiki like with the bureaucrat election. ~ Kurd 22:27, 11 July 2007 (UTC)

Well, the reason the election has a sitenotice and the RfAs dont is because theoretically the RfAs are always ongoing (whenever there's at least one active) whereas elections occur over set timeframes. On the other hand, it couldn't hurt to add an additional sense to the current sitenotice saying something along the lines of "You might also wish to look at the current requests for adminship(linked)" or the like. (Aiiane - talk - contribs) 22:31, 11 July 2007 (UTC)

While not completely related, I'd like to mention that it's "not a simple tally" according to the policy. For example, a BCrat might weight the votes of established contributors more than those of say, someone who hasn't participated enough in the wiki to get around to making a userpage yet.

For example. Not that there are any votes like that...

Where was I? Oh, right. I'd also like to mention that reconfirmations are really easy to start under the current policy, so I'm not too worried about it. Right now, I'd much rather hurry this crop of sysops up, reconfirm the grandfathered sysops, and then see if there are any changes that we need to make. MisterPepe talk 22:38, 11 July 2007 (UTC)

Hurrying up is the last thing we want to do if there are people who want to take it more slowly. I for one support slowing the whole thing down in some way to prevent the problems that we might get with this whole mess. -- (gem / talk) 23:05, 11 July 2007 (UTC)

Ugh. Perhaps "hurry up" doesn't have the right connotations for what I was thinking.

I'm fine in general with the idea of slowing things down a bit, but I dislike the idea of changing policies on something mid-process. If we want to change it, then it'd make sense to have the changes apply to all future nominations, but it doesn't really make sense (to me) to swap out the rules mid-way.

And for the record? I'm pretty sure I'd be saying the same thing if I weren't one of the candidates affected =\ MisterPepe talk 23:21, 11 July 2007 (UTC)

Agree with Pumpkinman, Make Anja admin and then change the rules ~ Kurd 00:33, 12 July 2007 (UTC)

... Pumpkinman? MisterPepe talk 00:44, 12 July 2007 (UTC)

Dont tell me you have never met him, hes like the biggest,baddest,fastes,uber1337leetzorroxxer pumkin.~ Kurd 00:46, 12 July 2007 (UTC)

I have no problem with extending the RFA period, it seems sensible as a lot of people could quite easily miss it. Also I would agree that the grandfathered sysops should be reconfirmed, not that I think any of them would/should be "demoted" but it stops the possibility of any arguments occurring where a user complains that they never had a chance to agree that said person should be an admin. --Lemming64 01:25, 12 July 2007 (UTC)

Would it be ok to put a permanent link to the RfA page from the CP navbar? Might make it more visible. -- ab.er.rant 02:15, 12 July 2007 (UTC)

This revert

From the history, it seems to be very clear to me that Rein Of Terror wanted to nominate himself for RFA, which he is entirely entitled to. He failed to code it properly (which suggests to me that template creep and obsession with good looks has trumped user friendlyness on this page), but that is no reason to revert his nomination away. --Xeeron 12:51, 12 July 2007 (UTC)

I believe Aiiane left a message on his talk page about it at the time. - BeX 12:55, 12 July 2007 (UTC)

Yeh it is in his archive here User_talk:Rein_Of_Terror/Archive:July_2007 but he never replied to it. --Lemming64 12:58, 12 July 2007 (UTC)

He did reply, under the second RFA heading. - BeX 13:07, 12 July 2007 (UTC)

(edit conflict) He replied to it in the next edit on his talk page, but it does not seem that he ever managed to create the page. He first put his name down under pending nominations. There the description reads "When requesting adminship for yourself, this step is not necessary, but you could give your candidate statement here and request help in creating your RFA page if you want.". It seems to me that he intended to do that and needed help in creating the RFA page. --Xeeron 13:09, 12 July 2007 (UTC)

So lets create it then :) --Lemming64 13:13, 12 July 2007 (UTC)

Bex left a (new) message on his talk page, lets give him a day to respond. Though in principle, you are right, he already expressed his interest in a nomination, so even if he does not respond, we should create the RFA page eventually. --Xeeron 13:15, 12 July 2007 (UTC)

Well the fact that he accepted the removal might be taken as a withdrawal, but we should wait to see what he has to say first! - BeX 13:16, 12 July 2007 (UTC)

What about asking him first if he really wants to request an adminship? Maybe he has rethought his decision.. poke | talk 13:20, 12 July 2007 (UTC)

(edit) Oops, left my window too long open before I replied ^^ poke | talk 13:21, 12 July 2007 (UTC)

Since Rein Of Terror clearly stated he still intents to initiate a RFA, I created the page for him. --Xeeron 14:55, 12 July 2007 (UTC)

Despite everyone's good intentions, it seems that some confusion has complicated this issue. Rein of Terror is unhappy about his RFA being created.

I argue now that his RFA should be removed/deleted (not declined) on the basis that it was not properly created. Specifically, the Starting an RFA section of the policy states that RFAs should not be created for someone else, unless there is a clear acceptance in the "Pending nominations" section below. There was not ever any such acceptance within that section. Any objections? --Rezyk 16:43, 12 July 2007 (UTC)

I thought about that possibility before posting on Rein's talk page, but I'm not too sure about it because of this edit. The statement you quoted above goes on to say that "If it is an RFA for yourself, you should be logged in before starting". Doesn't Rein Of Terror adding that link pointing to his (nonexistent) RFA page count as starting the RFA himself? --Dirigible 17:08, 12 July 2007 (UTC)

Maybe. I'm more concerned about his candidate statement: "I do not want to be an admin!" =\ MisterPepe talk 17:51, 12 July 2007 (UTC)

Well, every candidate has the right to walk away at every point, so if Rein Of Terror now does not want to become an admin, the RFA should be closed. I'll stop trying to guess what he actually wants though. --Xeeron 18:00, 12 July 2007 (UTC)

I don't think the case for that is strong enough. We can discuss it further if anyone wants, but since he has added a candidate statement which would effectively withdraw his RFA anyways, I'll drop my argument. Closing his RFA now. --Rezyk 18:07, 12 July 2007 (UTC)

Already did =P MisterPepe talk 18:08, 12 July 2007 (UTC)

On a slightly different note, what do we do with the page after it's been removed from the list of current RfAs? There's nothing about it in the policy =\ Should it be linked somewhere, or should it just disappear into the aether? MisterPepe talk 18:12, 12 July 2007 (UTC)

Aaannnddd, that's the next section. Bugger hell. MisterPepe talk 18:13, 12 July 2007 (UTC)

Shortening this page?

Right now the main project page is loooooooong. Perhaps resolved RFA's and reconfirmations should be kept on an archive page to reduce the length? --Santax (talk · contribs) 18:07, 12 July 2007 (UTC)

I agree they shouldn't be kept on the main page. An archive page is one option...I'd even suggest categorizing them instead. --Rezyk 18:11, 12 July 2007 (UTC)

Hmm, archive page might not be so good either because the page can generally be moved/archived itself if another RFA is to take its place. Category:Wiki requests for adminship? --Rezyk 18:16, 12 July 2007 (UTC)

Category:Resolved requests for adminship imo, possibly with sub cats Category:Approved requests for adminship and Category:Failed requests for adminship MisterPepe talk 18:20, 12 July 2007 (UTC)

I've set up a large category tree under here. I was also thinking all RFA's and reconfirmations (active and resolved) could maybe have a show/hide button, default set to hide so the voter can browse the ones they choose to without having to scroll through the others, but unfortunately I lack the skills to create such a thing :P --Santax (talk · contribs) 18:52, 12 July 2007 (UTC)

Errr... why do the categories have apostrophes in them? Should it be Category:Resolved RFAs? Kinda like NPCs. But anyway, the show/hide thingy wasn't installed, so it's not possible. -- ab.er.rant 17:42, 13 July 2007 (UTC)

Because when pluralizing acronyms, you're supposed to add an apostrophe. It's one of those crazy little grammar rules that not many people know :P --Santax (talk · contribs) 17:45, 13 July 2007 (UTC)

Oh... does that mean it really should be NPC's? -- ab.er.rant 17:47, 13 July 2007 (UTC)

That's absolutely wrong. Check it out. —Tanaric 19:35, 13 July 2007 (UTC)

Tanaric is right. I think that I may have read that it's an American/British thing, but apostrophes should pretty much never be used for pluralisation by punctuation-conscious people. (Though sometimes I will with non-capital letters, but that's because "dotting the is and crossing the ts" just looks dumb. -- Dashface 05:26, 14 July 2007 (UTC)

It's just another one of those prolific errors that occurs when someone is confused. Happens a lot on the internet because we love to shorten everything. I'm guilty of doing it too at times, but I know that it is technically incorrect! Sometimes you just get lazy though. :P - BeX 05:29, 14 July 2007 (UTC)

Looks like there's some dispute within the grammar community. I'm just saying what I've been taught... --Santax (talk · contribs) 07:36, 14 July 2007 (UTC)

I don't know that pointing to an article section that is unverified and unreferenced was really the best idea. :P I think that section is referring to certain fields where simply adding an s to the end would cause confusion or errors (i.e. with file extensions) and to early uses of acronyms, in which case discussion could get very pointless very quickly, arguing whether those early uses were correct because they set precedent or incorrect because they didn't know what they were doing! In any case, I think it is a safe path that apostrophes should only be used to show possession because we are leaving out the periods in our acronyms - there isn't much reason to use just apostrophes to mark omissions of letters. - BeX 14:44, 14 July 2007 (UTC)

RFA order

I suggest that after Auron's and Lemming64's RFAs resolve, we switch the ordering of the List of current RFAs, such that newest RFAs go on the bottom of the list. It makes more sense to have the next-to-resolve RFA at the top of the list. Any objections? --Rezyk 10:07, 14 July 2007 (UTC)

Ok to me. -- (gem / talk) 10:14, 14 July 2007 (UTC)

I am indifferent. There are advantages to both, but I dont think it matters, so do whatever you prefer. --Xeeron 16:10, 14 July 2007 (UTC)

Agreed completely. —Tanaric 18:32, 14 July 2007 (UTC)

I'd prefer to see the newest RFA's at the top... people won't bother scrolling to the bottom to vote. Depends on your point of view, really... those who do the resolving would want them in chronological order, those voting would want them in reverse-chronological order. --Santax (talk · contribs) 15:19, 15 July 2007 (UTC)

What we really need is to find a way to include a DPL-generated list and let people choose according to their preference. :P (Aiiane - talk - contribs) 15:22, 15 July 2007 (UTC)

But..you don't have to put in your opinion while the RFA is the newest. =) You could even work on them starting from the oldest too. Actually, my reason for this is to mildly encourage candidates to stagger their RFAs evenly in time (by seeking to maximize the time their RFA sits at the top of the list). --Rezyk 00:42, 16 July 2007 (UTC)

List of resolved RfAs and results

I realised, mainly because of this comment that it's hard for people to know what results the RfAs get, especially if the RfA ends prematurely. I think we should put a list of recent resolved RfAs on the page. -- (gem / talk) 21:57, 15 July 2007 (UTC)

I agree, a short list giving results in the past week/fortnight/month or something would be useful. --Lemming64 01:05, 16 July 2007 (UTC)

Anyone against this? -- (gem / talk) 16:53, 16 July 2007 (UTC)

How about adding your suggestion to Guild Wars Wiki:Requests for adminship/Draft1? --Xeeron 17:04, 16 July 2007 (UTC)

Feel free to add it for me. -- (gem / talk) 20:21, 16 July 2007 (UTC)

Quick-start form

For a user's first RFA, you can enter the username here (with correct capitalization) to quick-start editing a new RFA page with everything filled out: <createbox> preload=Project:Requests for adminship/base template prefix=Guild Wars Wiki:Requests for adminship/ buttonlabel=Start RFA page width=50 </createbox> --Rezyk 06:08, 16 July 2007 (UTC)

That is super cool! LordBiro 08:18, 16 July 2007 (UTC)

Very nice... Of course you had to do it AFTER everyone finished nominating themselves for reconfirmation. :P --Karlos 08:33, 16 July 2007 (UTC)

Ah, that would have been handy! Rainith is going to absolutely love that, so nice of you to make it for him! --Xasxas256 09:03, 16 July 2007 (UTC)

I remember it took me several minutes and reading to set up a RFA page, so this is great. It should go on the main page and replace the overly complex way described there. --Xeeron 09:22, 16 July 2007 (UTC)

I created Guild Wars Wiki:Requests for adminship/Draft1 to update the main page. Does the create box also automatically add the candidate to the list? If so, step 3 in the draft needs to be removed, if not the template for doing so be added. --Xeeron 09:36, 16 July 2007 (UTC)

I notice that the box acts wierd if you type a name that matches an existing RFA..here's another version that doesn't act wierd (but is also not useful in that case). --Rezyk 20:43, 16 July 2007 (UTC) <createbox> preload=Project:Requests for adminship/base template default=Guild Wars Wiki:Requests for adminship/USERNAME buttonlabel=Start RFA page width=50 </createbox>

Requests for reconfirmation

I made a request for Lemming64's reconfirmation today. I feel like requests for reconfirmation are one of those things that people are hesitant to be the first to do, and that, once one is made, other similar requests are likely to follow. However, there's no way currently to see reconfirmation requests unless you happen to see it in recent changes. I propose adding a section to this page where we can maintain a list of the RfAs where reconfirmation requests made in the previous seven days. —Tanaric 00:27, 22 September 2007 (UTC)

Support. (Aiiane - talk - contribs) 01:50, 22 September 2007 (UTC)

If the request is made and unheeded for seven days, it just falls off the list? -Auron 01:52, 22 September 2007 (UTC)

Yes, but each individual person adding support for a reconfirmation would count as a request, thus, it's basically if no-one shows interest in it for 7 days it would drop off the list. The point of the list is to see where active drives for reconfirmation are, if we just want to know who could possibly be requested for reconfirmation, well, that's just the list of sysops. (Aiiane - talk - contribs) 02:02, 22 September 2007 (UTC)

Sounds fair. I support as well. -Auron 02:04, 22 September 2007 (UTC)

So if no one drives for the reconfirmation, the stays sysop or loses that?--§ Eloc § 02:34, 22 September 2007 (UTC)

Sysops are appointed for life unless they are actually brought up for reconfirmation (merely requesting reconfirmation doesn't mean they will be - see GWW:RFA) and don't pass a reconfirmation. So if no one drives for reconfirmation, the sysop's status is unaffected and they are still a sysop. (Aiiane - talk - contribs) 02:35, 22 September 2007 (UTC)

Alright, though so. So basically, the reconformation is like if you want to take down a sysop?--§ Eloc § 02:41, 22 September 2007 (UTC)

Reconfirmation is if you want to see if the user base still agrees that a user should be a sysop. It doesn't have to be negative, though the majority of people who would request reconfirmation for someone other than themselves would probably do so because they think such a person may no longer have community support. (Aiiane - talk - contribs) 02:44, 22 September 2007 (UTC)

By the way, requesting someone's reconfirmation does mean that they will be brought up for reconfirmation, it's just a matter of when. After one year has passed from the time the sysop got his admin bits, even one user supporting the reconfirmation is sufficient to start a new RFA (this was done in response to Gaile's worry about sysops being appointed for life, and I actually quite like it). --Dirigible 02:51, 22 September 2007 (UTC)

So we'd just have to wait ~11 months? Nice :P -Auron 02:55, 22 September 2007 (UTC)

At most. The more people request the reconfirmation, the sooner it will come. --Dirigible 02:58, 22 September 2007 (UTC)

It's not quite the same, but see the bottom section of Guild Wars Wiki:Requests for adminship/Draft1 for an automated list approach. --Rezyk 08:45, 22 September 2007 (UTC)

I was going to post something in my defence here, but I would guess anyone who is requesting this, has already made up their minds, in which case I will save it until such a time as I need to post a statement in a reconfirmation. --Lemming 16:50, 22 September 2007 (UTC)

I prefer a manual approach for a few reasons.

1. It ensures that every RfA on the list has actually been involved in a reconfirmation request.
2. It allows the 7-day time limit, ensuring that requesting a reconfirmation isn't a way to besmirch a sysop's reputation for a long period on a very visible policy article.
3. Since the list will require an edit to be kept up to date, it pings recent changes and people who watch RfA whenever a reconfirmation request is made.

—Tanaric 18:29, 22 September 2007 (UTC)

Is it not possible to include the RFC part of the RFA page on ths page for RFCs? --Xeeron 19:03, 22 September 2007 (UTC)

That makes it sound like one (or more) RFC's constitute somekind of vote before the reconfirmation has even been decided or set. This is not how this procedure is described on the page. --Lemming 19:17, 22 September 2007 (UTC)

There's no direct opposition to this idea, so I'm adding it to the policy. Lemming, it's been six days since your last reconfirmation request, so I'll add you to the list, to be removed in about 30 hours. —Tanaric 14:26, 27 September 2007 (UTC)

I have re-added to this. I may be late on seeing it but i feel a reconfirmation is definately needed here. --ChronicinabilitY 23:28, 7 October 2007 (UTC)

A small note on changing policies

Our policy regarding changes to policies states that proposed policy changes should be made public on Guild Wars Wiki:Policy. This policy change was not. To minimize hassle, I will put this change up there. If no opposition materialises, we can leave everything as is. However if people were not aware of this page, but voice opposition after being notified via GWW:POLICY, the change to the article will have to be reverted.

PS: I prefer the wording "have their most recent RfA listed here" to "should have their most recent RfA on this list." Should is not a great word to use on policies. --Xeeron 16:16, 27 September 2007 (UTC)

Re-think?

The RFA process has been hammered with claims of being a popularity contest and for being totally ineffective or unreliable. Does anyone actually have a good suggestion on how to rectify this? -- ab.er.rant 01:45, 27 September 2007 (UTC)

Is there a way to do hidden voting so people don't feel so afraid that people will hate them for voting a certain way?--§ Eloc § 01:49, 27 September 2007 (UTC)

Since wikis are based around the idea that everything needs to be documented, I guess this will be hard. Maybe there is some wiki-extension that does this (didn't wikipedia have something for their elections?). Of course, there is the BIG question of making sure that people only vote once. --Xeeron 08:50, 27 September 2007 (UTC)

I've only seen the claim that RfA produces bad GuildWiki-like sysops. I agree with that claim, but it's irrelevant, since our sysops are currently janitors. —Tanaric 14:23, 27 September 2007 (UTC)

We could try promoting more interesting and discussion-worthy candidate statements by putting together a list of questions they could answer. Stuff like How would the wiki benefit from you being a sysop? and How would the wiki be hindered from you being a sysop?. Although it might be better to start something like this up for bureaucrat seats first (or both). --Rezyk 14:51, 27 September 2007 (UTC)

I don't see how the current process has failed. Three worthy bureaucrats, and bunch of trustworthy janitors who don't abuse their wiki-powers. What's the problem?--Drekmonger 15:30, 27 September 2007 (UTC)

The problem is that, while many Admins that are elected are perfectly fine, there's aways the possibility that the system could be "corrupt" with people a) voting with sock puppets and b) people voting against a user because he/she got into an argument with them, even though the candidate is perfectly fine. In my opinion, the Q&A would be good, but I think a good solution would be for the candidate to submit the RfA, and for the admins, and only the admins, to discuss the candidate, their edits, etc., and then make a general decision as to appoint the candidate as an admin, or reject the candidate. Calor - talk 02:48, 28 September 2007 (UTC)

That might be even worse than the current system we have. By saying that it's the duty of admins to accept other admins, you're encouraging an elite group of users who give power to whoever they favor. It is the community who should decide, not just the people the community had earlier decided on. And sock puppets is an ever-present problem to all online communities, so that's not really the main issue. The primary complaint/weakness can be inferred by looking at the comments of the support and oppose votes. Some of them are clearly either ignorant votes or friendship votes. Someone you don't like isn't necessarily a bad admin, and someone you like isn't necessarily a good admin. Objective votes/decisions are what we need to strongly encourage. -- ab.er.rant 03:11, 28 September 2007 (UTC)

Agreed, that's the reason I've avoided voting on RFAs. -- Gordon Ecker 05:35, 28 September 2007 (UTC)

I can see two possible changes that might help:

• Introduce a contribution limit for voting like on the bcrat elections to avoid sockpuppets and friends of users who hate/love the candidate.
• Introduce a requirement of a comment which explains why the user opposes/supports. Something like "I like him" shouldn't be enough. -- (gem / talk)

The RfA process is bad because people have no idea what it's for. Admins, or sysops, are merely janitors on the wiki; thus, any given RfA is merely an open discussion on how well the candidate would perform as a janitor. Nothing more. Janitors don't have to be nice to be good, janitors don't have to be well-known to be good, janitors don't have to have held a certain number of jobs in the past (i.e., edit counts on the wiki); yet, these issues are brought up time and time again, just showing how clueless the general userbase is.
On GuildWiki, where sysops were given the ability to enforce policy the way they saw it, kindness/helpfulness/trustworthiness etc actually mattered; here, those things don't. People haven't been able to break away from the whole "RfAs give the candidate free reign over the wiki, thus we must discuss things that have nothing to do with their ability to delete/block/protect via a strict and specific policy" mindset. That's the biggest problem with RfAs... imo. -Auron 10:25, 28 September 2007 (UTC)

Which is why I asked why Gem's a bad choice for a janitor and all the mention of his "problems". Anyway, that's beside the point. So perhaps what an RfA should be is not to be voting. Just create and RfA, put in some candidate statement, and let people start a discussion on why a candidate is suitable or why a candidate is not suitable. Then have the bureaucrats gauge the response to the RfA, ignoring the plain "I support because I like to" comments, while giving perhaps slightly more weight to contributors who have been relatively active and has made an attempt to explain his/her support/opposition. -- ab.er.rant 10:50, 28 September 2007 (UTC)

A non-voting process might be a good idea too, but it needs to be refined a bit to work properly. -- (gem / talk) 17:46, 28 September 2007 (UTC)

Not that I oppose that suggestion, but much of that leeway is essentially already there: Bureaucrats are to use their discretion in gauging/interpreting the amount of support/opposition. Perhaps they are ignoring (or greatly discounting) unexplained supports/opposes. This also lets them exercise discretion in the case of likely sockpuppets. --Rezyk 20:57, 28 September 2007 (UTC)

The process should be formed so that the bcrats must consider the discussion and don't have the possibility to just close the case with nothing more than counting votes. Currently nothing in the system makes sure that the bcrats do more than count the votes and decide on that. -- (gem / talk) 21:40, 28 September 2007 (UTC)

Gem, I think we are that "nothing" - if there's a RfA in which an user believes the decision done by the bcrat(s) was not following the real consensus, I believe said user would be free to point so in the RfA's page and begin a discussion about it. I like the current way RfAs are done, given how we are (for now, at least) following the janitorial role - a sysop is important enough for us to learn how much support an user would have in that position, but not powerful enough for the process to be made really complicated (IMO). Most of the RfAs that have happened were clear regarding if the candidate had support or not; a discussion would have only made that process to be less fast and more bureaucratic, something that isn't needed, I think. In those cases in which there isn't a clear consensus, then I think going slower, with a more elaborated discussion, would be worth it - but that's already mentioned in the current rules about RfAs anyway. Erasculio 00:54, 29 September 2007 (UTC)

I don't think we can assume people are supporting any particular candidate when they have no idea what the RfA is about to begin with. -Auron 00:58, 29 September 2007 (UTC)

Sysops are given the ability to interpret and enforce policy over here as well. Furthermore, sysops routinely block vandals without explicit authorization from any specific policy (although the proposed blocking policy would restrict blocking). IMO the main difference is that bureaucrats have significantly more power over there, as the build wipe demonstrates. Sysops had more power, but that changed as policies expanded. -- Gordon Ecker 01:18, 29 September 2007 (UTC)

Detecting vandalism and blocking for it requires no real amount of higher-level thought. Is it vandalism? Yes -> Warning/Block. No -> don't block. And no, we aren't trusting our sysops to enforce policy as they interpret it; we're handing it to them word for word, and if they don't abide by that, they get in trouble. -Auron 03:03, 29 September 2007 (UTC)

But there's no policy. Vandals are blocked due to a combination of sysop discretion and an informal understanding among the community that vandalism should be punished with blocking. If a policy leaves room for interpretation, I am of the opinion that sysops, as the enforcers of policy, are authorized to interpret it. If the other editors have a problem with the way a policy is being interpreted, they can propose an amendment to leave less room for interpretation. If a sysop starts interpreting policy in an unreasonable or implausible way (i.e. "disagreeing with me is a personal attack"), it can be taken to the arbitration committee (and other sysops can use their discretion to undo the "rogue sysop"'s actions). -- Gordon Ecker 03:32, 29 September 2007 (UTC)

While there is no policy specifying exact measures, and I do think a GWW:No Vandalism would be useful for standarisation there, Vandalism is more or less defined as intentional violation of GWW:CONTENT, or in the case of userspace, GWW:USER. Upholding existing policy is a sysop job. Backsword 13:29, 29 September 2007 (UTC)

Somewhat off-topic reply to Gordon: the bureaucrats on GuildWiki have no inherent power. I assumed the right to builds wipe, but it had nothing to do with the bcrat role. Biro's a bureaucrat there only to make sure somebody was around to sysop/bot users when requested. He has never assumed the role that I did, because that role is not tied to bureaucrat status. If he assumes that role now, good on him, but it's got nothing to do with his bureaucrat status. —Tanaric 19:49, 29 September 2007 (UTC)

(Reset indent)

I'm strongly in favour of clear policies. -- Gordon Ecker 01:36, 30 September 2007 (UTC)

Not a Tally

Bureaucrats are to use their discretion in gauging/interpreting the amount of support/opposition.

Can anyone elaborate on this? Anon

It means bureaucrats get a say, and don't have to rely on just the number of votes. It stops people just getting their guild or friends to spam support votes, and means oppose/support votes with useless reasoning can be ignored. Lord of all tyria 17:59, 11 December 2007 (UTC)

Also consider the quote right before that passage: "In general, a successful RFA has at least 3 times as much support compared to opposition -- but it is not a simple tally". That means a RfAwith as many "Support" as "Oppose", or with one more "Support", is not necessarily considered to be a success. If it were just a voting, even one more "Support" would make it a successful RfA. Erasculio 18:35, 11 December 2007 (UTC)