Guild Wars Wiki talk:Adminship/draft B

Archive

---

/Archive 1
/Archive 2

Documentation

With both this and DE's proposal we would end up with a body of nonwritten policy. And there's been no coherrent discussion on it. Well, perhaps, nonwritten is not right. Poorly documented, and that documentation spread out on various logs, talk pages and the admin noticeboard. In any case: policy that regulars nnow about and sysops enforce, but that other suesrs only find out about when they run into it.

As usual there are points that can be made both for and against. Some may be seen as either, depending on ones preference. A few I could think about is, for:

• Not knowing what one can get aeway with puts a chill on actions, meaning fewer disruptive edits to deal with.
• Avoids sysops having to go through a formallity, increasing flexibility and reducing the burden on sysops.
• Effectively gives regulars an advantage over other editors, a possitive if one follows a 'vision of the selct' line of thining.

Against:

• Not knowing what one can get aeway with puts a chill on actions, meaning less inovation and fewer initiativs in improving the wiki.
• Effectivly givs regulars an advantage over other editors, a negative if one follows the open community paradigm.
• Means any discussion about them will be equally spread out, making it harder to notice or follow. ANd perhaps leading to it taing place in location where others would prefer it didn't. (eg. noticeboard.)

Was hoping we could get a clear picture of what people are thining on this specific issue, since it seem to me to be the primary one, at least from how I read this page. Backsword 04:22, 5 April 2008 (UTC)

I see this is an issue that concern people deeply. Backsword 13:59, 7 April 2008 (UTC)

To be fair, at times I think it probably takes people a bit longer to fully digest/understand what you are saying, much less try to respond in a manner that is still clear if there was misinterpretation. =) --Rezyk 19:17, 7 April 2008 (UTC)

Better/centralized documentation regarding standards that are very commonly enforced by direct sysop blocking (e.g. don't vandalize) should revolve around the development of a widely-accepted blocking policy. Better documentation regarding policy that might be enforced through community editing (and sometimes arbitration) is general policy development. I see this proposal as not directly forwarding/obstructing either, but hopefully making both efforts a bit easier by clarifying the context behind them.

If not one of those, I guess that your points concern sacrificing preemptive transparency for sysop flexibility on less common block cases -- that we cannot prepare a list of precise blockable offenses that any new user can look at and easily abide by to edit safely. To me, the capability for such a precise and comprehensive list, excepting for arbitration, is worthwhile in the name of transparancy/openness/ease of integration for new users (and your list of cons). But I believe that would require certain changes from current policy and a shift to a much more user-centric culture (as opposed to admin-centric), both of which are beyond the immediate scope of the intention behind this rewording. We already have unwritten standards of blockable offenses developing; I don't see where we would fault this proposed change for such. --Rezyk 00:38, 8 April 2008 (UTC)

It should be mentioned that more flexibility/discretion and more "unwritten policy" are two sides of the same medal. You can not have one without the other. However it is worth pointing out that there is no law of precedent on the wiki. While precedent is surely taken into account, sysops are free to ignore it if they choose to.

To help users (and also sysops) stay "coordinated" in their actions without having to check tons of different pages, I strongly support a blocking guideline, which would serve as a guide to block length, while being flexible to change. --Xeeron 09:39, 8 April 2008 (UTC)

That can't be right. There is clearly a connection, but there is no identity. If that was so, nothing could be done about, as you imply. Bu the current proposal is already doing something about it, albeit in random cases. That would be impossible if you were right. Backsword 16:24, 10 April 2008 (UTC)

I think he probably did not mean an exact identity, but if you start from the "precise preemptive list" ideal then you cannot start one without the other (unless we are interpreting the terms in different ways). --Rezyk 20:51, 10 April 2008 (UTC)

The first time can't have been documented, for long at least, as that's the very point of flexibility, but any subsequent use could. Which reminds me. Backsword 22:00, 12 April 2008 (UTC)

Hmm, I wasn't making a distiction on how commonly the reason would apply for a block. Obviously, the more common it is, the more relevant the issue becomes, but I think the principle would remain the same in any case; either it's good thing, or it's not. I could only see an argument on the exceptionally rare cases. If something is likely to ever only happen once in the wiki's life, documentings it properly would be wasted time. But that's an excpetion, and also involves a case of predicting the future, which one can easily get wrong.

I agree that user edit enforced policies are outside the scope of this proposal, and since those would follow the current formal process, they would remain in the fully documented camp. Any change here would be an entirely seperate issue, this proposal being about admin initiatives, not user initiatives.

As for using a blocking policy, not yet existing, to document it, that seem odd to me. It's not mentioned anywhere in this proposal, I would expect a blocking policy to be about blocks (not what people are blocked for), and the document would have formal policy standing making use of it awkward, there would be no clear idea of whaen to update it and it would create yet another alternative admin noticeboard. Backsword 17:13, 10 April 2008 (UTC)

If every level of possible documentation had to go into a blocking policy, then it would be that awkward. Otherwise, it depends on the form of the blocking policy. A particular one might just cover the basics you expect and leave the visible standards up to a guideline or other places; you would not know until it is proposed.

It is not mentioned within this proposal because I don't see why that determination should need to be integrated to make this iteration of change acceptable (and it could easily make it less acceptable). Do you see some specific potential issue about the documentation that is generally worse than current policy/practice? If not, let's move forward now. --Rezyk 20:32, 10 April 2008 (UTC)

I do understand the frustration with having the main points delayed by what must seem like side issues. But I seriously think this is the time to deal with them. Not some possible future, that may not happen. A parallel can be made to the user page policy's section on talk pages, that was made in expectation of a talk page policy that never happen, and the pain that caused.

That's not very specific, which you specifically asked for. Well, I still object to having an effectivly random effect in a policy. An argument against can easily be made (Given a context, something is either good and should be done, or bad and shouldn't) but I've seen none in favour. That's how it's supposed to work, right, best argument wins?

Additionally, current proposal requiring documentation on every case. That seems needlessly effortful to me.

Shirly, documenting the first instance and then refering to that for subsequent cases would be enough. (eg. if someone blocks 5 IPs, possibly the same user using proxies, would have to write down the same reasons 5 times, if the documentation clause triggered.) Backsword 22:16, 12 April 2008 (UTC)

My concern is not whether this is the time to deal with whatever issue, but whether this is the proposal for it. It is not easy to make an argument for or against, because of the difficulty in understanding what aspect of the proposal you are looking for an argument about. In case I misinterpret yet again, please try to keep more specifics in the picture for now to make it clearer. It is not about "best argument wins".

I don't see the list of what is currently "specifically allowed by policy" as effectively random. Current policies exist alongside an admin policy that states that sysops can block accounts and IP addresses according to the rules of the Guild Wars Wiki policy, and I feel that the various mentions of administrative action have been evaluated in the context of making that sysop allowance solidly clear for those cases. In any case, if you feel the effect of this proposal might not be a reasonable direct translation of that old clause, just see if there's anything in other policies which you feel less comfortable with under the new rewording and take the rest of it as an okay change if you must. I added stuff aimed at clearing up potentially relevant semantics a bit. Regarding "documentation on every case", I feel the latest draft does not force any standard of repeating the reason for each case (though I didn't think it did before either). Does this make the proposal generally acceptable to you? --Rezyk 03:05, 15 April 2008 (UTC)

This is the proposal that causes it, so yes, I'd say it's the one to deal with it. That was exactly my point above.

What you meantion about current policy is absolutly right, and just the reason why it would be effectivly random. One doesn't block for someone doing something allowed by policy, one blocks in order to enforce it. Hence why they are written in terms of what is disallowed. We have no document like a 'bill or rights', nor have we needed one. Creating one, and rewriting all current policy in terms of what is allowed would be a massive undertaking.

As for redundant documentation, I still read no exception for already documented initiatives. Say a sysop blocks an IP for reason X, and an hour later another IP, also for X, perhaps the same user, perhaps not. Would they not be requirrent to ducument their reasons twice?

On a more constructive note; I could support these two solutions:

1. remove the entire documentation segment.
2. Replace "specifically allowed by policy" with 'for previously undocumented or rejected reasons', or some such.

Backsword 05:23, 16 April 2008 (UTC)

Say a sysop blocks an IP for reason X, and an hour later another IP, also for X, perhaps the same user, perhaps not. Yes, a clear reason must be provided both times. As annoying as it may be to have to write one into the reason-for-this-block field each time, it's something we should not slack off on. If this is a case of the sysop discretion log, the current draft makes no reference to requiring the reason there each time. If a sysop were to just add something like "also for IP xx.xx.xx.xx" to the previous notation in that case, I believe users would generally consider both actions noted. --Rezyk 06:57, 17 April 2008 (UTC)

Still not sure about my understanding of your argument, but I will take another guess. The word "allowed" was meant to refer to the sysop action, not the behavior of other users in general. In that context, your suggestion ("for previously undocumented or rejected reasons") would authorize deleting the Main Page for fun (previously undocumented reason), authorize blocking people for sarcasm (rejected), and drop authorization of blocking 1RR-violators (neither undocumented nor rejected). In any case, consider the reworded draft. --Rezyk 06:42, 17 April 2008 (UTC)

Yes, it would, at least for the first two. But so would your proposal. The difference is that they wouldn't have to use the log in your version.

For your third example, no they wouldn't be "authorized" to document it, but then, that's the point, there is no need, being as GWW:REVERT already does so. Backsword 07:40, 19 April 2008 (UTC)

Okay, another guess:

• All your arguments revolve around the existence of a distinction for what counts as "contradicting written policy" within the discretion clause.
• Your concerns do not directly involve the "As specifically noted in any written policy" case that falls outside the discretion clause. That part is basically fine and follows existing policies; no problem with #4 in the big table above.
• Your suggested solution above should really have instead said: Replace "contradicting written policy" with 'for previously undocumented or rejected reasons', or some such.

Is all this correct? --Rezyk 18:06, 19 April 2008 (UTC)

OK, I took some time to figure out what you were talking about. If I'm right, you didn't realise that I was quoting from your imediately preceding post, but instead thought I was quoting some unrelated part of the policy with similar wording, thus starting a new debate, rather than continuing about documentation.

If that's the case, then your above assumption would be right, at least in the ways that matter. Backsword 18:50, 19 April 2008 (UTC)

That is also basically correct. Actually it's more like all of my comments have been about struggling to isolate/clarify the issue rather than arguing a point. (And it's still not very clear to me.) --Rezyk 23:13, 20 April 2008 (UTC)

Among other changes, I've reworded "contradicting" into "disallowed". As I understand it, your argument about a "random effect" is largely based on policies tending toward identifying the disallowed rather than the allowed. I'd like to know how this new wording would fit in that regard. Not making an argument here; still seeking clarification. --Rezyk 03:13, 21 April 2008 (UTC)

Hmm, is this change meant to affect a difference in workings, or is it just a rewording? Have reread it, but can't tell.

As this has taken longer than I hoped, I've considered if it wouldn't be better to put up my own draft, but I've hessitated as it's such a minor change. Backsword 16:18, 23 April 2008 (UTC)

It could be taken as a difference in workings to those who read the 2 versions as reflecting a difference in workings. It could be taken as just a rewording to those who read the 2 versions as just a rewording. It is meant to seek clarification about your issue. Maybe you see the same issue with it (if so, please explain) or some new issue instead (if so, please explain) or something maybe-sort-of the same issue (if so, please explain) or you don't see any big problem with it (if so, please say so). --Rezyk 17:52, 23 April 2008 (UTC)

Well, I think policies should be clear enough that people can agree on what they're agreeing on. Otherwise, there's not really any policy there is concensus for. As I would read it, there's no change, but since uyou did the rewrite, I'd expect you to see it differently.

Just to be clear; I still don't see it making a distiction based on any reasoned argument; it's criteria still seem unrelated to the issue and thus effectivly random. Backsword 22:34, 27 April 2008 (UTC)

Yes, clarity. I wanted to make sure we were working towards clarity in the final wording standing on its own, though, so wanted to get your answer regardless of my "view of change". Perhaps I see the latest version as not really much of a change, but that stems from my different interpretation of previous versions and is thus not so relevant to how you should read it.

I propose that the trigger be based on cases where we have more explicitly restricted action in policy, not based on an absence of policy/discussion or implicit interpretations. The reasoning for this is that an explicit mention corresponds to us having purposely chosen to adopt a much higher level of "hey we don't want this to happen..!" for the case, which could be taken as decent enough justification for an extra logging action to heighten its visibility (in case it is to be challenged), despite the extra bureaucracy. --Rezyk 19:09, 29 April 2008 (UTC)

(Reset indent)

I think we are discussing different timeframes. I have been concerned with restrictions in past policies, which do not follow the reasoning you mention, and is basically incidental. You seem to be concerned about restrictions in future policies, written with the model proposed by this document in mind.

Even so, I still don't think it's good. 1. It would still interact wioth existing policy. 2. I don't see the justifications for desiring or rejecting centralised documentation changing at that point. 3. I think that if we write something explicitly prohibiting certain admin actions under this system,, essentially creating basic rights, we would only do so in a state informed of the workings of this policy. As such, we would do it to prevent sysop initiatives.

Aside, as I'm sure you've noted, feeling this is taking too much time, I've set up a draft of my own. Would appreciate your overview before I make it a proposal. Backsword 20:37, 29 April 2008 (UTC)

I'm concerned with both. 1. So go review the potential interactions and give me specifics on anything you are uncomfortable with. Other policy wordings might (or might not) have been written without this draft wording in mind, but the interactions are up for review right now so none of them would be effectively incidental/random afterwards (because this proposal is to be considered with those other policy wordings in effect!). 2. I don't see how whichever way is supposed to be causing/killing centralized documentation. 3. Maybe we would write some just to build a more clear and stable basis of agreement when warranted due to other issues (like fear of guidelines becoming effective law to be haggled over), while not wanting to prevent initiative for fear of loophole problems. Or maybe we won't. --Rezyk 22:58, 29 April 2008 (UTC)

As for 1&2: I'm primarilly concerned with the illogic of it all. There are reasons centralised documentation is good. There is reason it is bad. But none of them seems to start or end at the point designated by this proposal. Ass for 3, yes, that could happen, but if we are intentionally allowing it, then we are clearly not seeing it as an especially horrendous thing to do, which was the motivation you gave previously. Backsword 23:39, 2 May 2008 (UTC)

There is a strong correlation between an explicitly restricted archetype in written policy and us not wanting actions of that type to stand, but it is not absolute. This proposal has some basis in recognizing that correlation without relying on it as absolute.

I guess that you don't see the logic because (speculating) you take the whole/primary motivation of the note requirement as revolving around providing a simple collated reference to users for general understanding, and have been implicitly applying that meaning of "documentation" (which is fair but confusing because of other meanings). My drive behind the note requirement is based on trying to get the best consensus overall, and because it seems like a very reasonable consideration to make larger aspects (sysops potentially acting against policy) much more palatable to some. I expect that it makes things more palatable primarily by functioning as a notification/watchlist-pinging system that helps keep actual and potential restrictions more smoothly manageable and meaningful, rather than as "documentation" to promote general understanding. Makes sense?

The simple answer to your question below is that all else being equal, I think we would prefer to make criteria more transparent to all. But that simple answer is hardly ever relevant because "all else" is never equal and systems designed to fulfill that priority always involve compromising on other important aspects. This is not to imply that your proposal isn't good; draft E should get due consideration over whether its compromises are worthwhile. But it is more like "documentation reform", which I do not seek to incorporate in the scope of this draft B. I don't even intend/want the log to take on the role of primary documentation.

Btw: In draft E, I notice your wording leaves the Sysop Discretion Log note to be implicitly assumed to count as "documented". To me (and perhaps many others?), this is not so automatic; while it might technically meet some meaning of the word "documentation", I would only naturally refer to it as "noted" or "logged" . Hence much of my earlier misunderstanding. --Rezyk 21:28, 3 May 2008 (UTC)

I fundamentaly disagree about that correnlation. Such cases are rare and not related to especially stong concerns. Additionally, it's very asy to come up with cases that would be stronger concenrns, eg. blocking someone due to disliking their ethnicity.

As for your second point, I do think you have captured Gordon's issue, based on comments he made on E, and while the considerations you speculate being my issue are part of what I am thinking about, I'm also considering Gordon's issue and other points as well.

And yes, E is a case of "documentation reform" from B, but if one sees E asa baseline, it's B that's the reform document.

As for the log, that's just a solution I adopted from B. I'm not overly concern with formating or semantics. If you have another solution you think would work better, I'd be happy to hear it. Backsword 05:31, 7 May 2008 (UTC)

Against:

• Not knowing what one can get aeway with puts a chill on actions, meaning less inovation and fewer initiativs in improving the wiki.
• Effectivly givs regulars an advantage over other editors, a negative if one follows the open community paradigm."

Implementing "Assume Good Faith" as a guideline(policy?) would solve both of these. (Aiiane - talk - contribs) 20:41, 10 April 2008 (UTC)

Making GWW:AGF into a policy would work ofc, but it would also limit sysop initiativs to cases of clearly malicious users, a price I think many will find too high. Backsword 22:00, 12 April 2008 (UTC)

What are you talking about? Sysops are already effectively limited to such if they don't want to be crucified in an orgy of wikidrama. (Aiiane - talk - contribs) 05:33, 16 April 2008 (UTC)

True. But reducing said drama is a major motivation fo these proposals. Backsword 06:09, 16 April 2008 (UTC)

Removing the documentation clause would gut the deletion policy, allowing any sysop to speedily delete any article at any time for any reason. As for blocking, I think that allowing 1 day "general misconduct" blocks would be sufficient to deal with problem users until a bureaucrat can get on and issue an injunction. -- Gordon Ecker 06:32, 16 April 2008 (UTC)

This proposal allows that too. The difference is in that this proposal would require use of a centralised documentation if they did. The key differeance is that if their reasons are accepted, then sysops will continue to do it, and it will effectivly become a new speedy criteria. The question is if this criteria should be known to everyone, or only those that activly keep themself informed of such things, by following most discussions and reading the logs. Backsword 07:44, 19 April 2008 (UTC)

Opinion/status check 2

Updated, re-proposed.

• differences since previous proposal (several days ago)
• differences since first proposal (~10 days ago)
• For differences from current policy, refer to links at the top of the proposal page.
• Pending issues before acceptance: discussion over documentation aspect above (potentially)

Other than the documentation aspect being discussed, are there remaining/new issues? Is this policy update overall acceptable if that aspect turns out okay? --Rezyk 01:46, 9 April 2008 (UTC)

I'm happy with it. —Tanaric 01:49, 9 April 2008 (UTC)

Seems to be ok; I can't see any noticeable problems at the moment. -- Brains12 \ Talk 01:58, 9 April 2008 (UTC)

iawtc. -- ab.er.rant 02:54, 9 April 2008 (UTC)

Do you plan on getting this through during the current election? If so, the changed bureaucrat role may need to be clarified on the election page, or something else to make it clear that we are also electing a bureaucrat, sysop -- not just a bureaucrat as we knew it. -- Brains12 \ Talk 03:04, 9 April 2008 (UTC)

No plan on any specific time. Yeah, if it happens during the election, we should have a note like that. --Rezyk 03:16, 9 April 2008 (UTC)

This looks good to me. *Defiant Elements* +talk 03:42, 9 April 2008 (UTC)

*waves to camels* (iawtc) - anja 08:52, 9 April 2008 (UTC)

I still support this. --Xeeron 09:47, 9 April 2008 (UTC)

I like it :) poke | talk 11:35, 15 April 2008 (UTC)

One more for the road

I'd like clarification on an issue. This proposal puts enforcement under community purview. That's a break with tradition, as we've generally had it so that the community pickes it's values, and sysops then choose how to enforce it. And as such a step towars less flexibility in that issue. As there has been no debate on this, I'm left wondering if this is something people are silently supporting, or just haven't considered? Backsword 22:29, 12 April 2008 (UTC)

I prefer to avoid potential argument over having to pinpoint exactly what tradition is/was due to different interpretations. --Rezyk 03:05, 15 April 2008 (UTC)

...that's not really my point. I think people who's been around are pretty clear on how things have been, and that this is a departure from that. I have no strong preference one way or another.

What I didn't want to see is this coming up after the policy is in effect, with people claiming they were unaware and never in support. That's why this section is needed. Backsword 03:17, 16 April 2008 (UTC)

Reduced bureaucrat powers

I just noticed that, under this proposal, rogue bureaucrats could no longer be removed through the unanimous vote of other bureaucrats, and the arbitration committee would no longer be able to remove sysops. This seems to be unintentional, as the annotated diff list says that the sections were removed due to redundancy with the RFA and elections policies. -- Gordon Ecker 06:07, 15 April 2008 (UTC)

Even if its redundant, I'd rather have it said than not. Even if it's the same wording, it helps to cement policy. MiraLantis 06:16, 15 April 2008 (UTC)

"unanimous votes of the other bureaucrats" has always been in here, so not getting the problem there. For arbitration over sysophood, current policy just says that "their status may also be formally examined" by arbcomm, and I thought this to already be well covered by the note of arbitration within reconfirmation policy and the relatively open power of arbitration. But I don't mind trying to make this clearer here and have edited the draft. --Rezyk 16:30, 15 April 2008 (UTC)

You're right, I didn't notice that the "unanimous vote" clause was moved down. I still think that it should be explicitly mentioned either here or in the arbitration policy that sysop user rights can be suspended by injunctions. Otherwise, a sysop who goes rogue or has their account compromized could theoretically keep unblocking themselves, deleting pages and blocking people they don't like for hours until an arbitration comittee is formed (in practice, they'd probably get their powers stripped by a bureaucrat using a liberal interpretation of the "Injunctions are an extremely open-ended power with no immediate oversight." line, but I'd prefer an explicit mention, anyway, I'm bringing this up at Guild Wars Wiki talk:Arbitration policy). -- Gordon Ecker 23:33, 15 April 2008 (UTC)

Yes, maybe if it is made clear in this proposal and in Arbitration policy. (Thanks for pointing that out btw, I didnt notice it b4 :D) --Shadowphoenix 23:37, 15 April 2008 (UTC)

List of bureaucrats

I think that the list of bureaucrats should be moved off to a transcluded subpage to keep it out of the policy's edit history. -- Gordon Ecker 09:01, 19 April 2008 (UTC)

Sounds good. --Xeeron 11:14, 19 April 2008 (UTC)

Since it's basically a listing of terms, perhaps move it to the elections? Backsword 11:28, 19 April 2008 (UTC)

My Issues With This

Alright, I have to speak of my issues with the bcrat section. While I agree that bcrats should have some sort of sysop like powers, I don't think blocking should be one of them. I could see a bcrat being able to delete, undelete, protect, unprotect, etc. but I have a problem, with them being able to block user accounts. Bcrats are members of the ArbComm, which deals with user related problems and sysop actions. In order for the bcrats to be exclusive from the sysops, the right to block should not be allowed. Since ArbComm does not deal with content on the wiki, but instead user and administrators; we want to keep the ability to block seperate from ArbComms. (Fyi this may have came out all wrong, it is almost 4:00am here and I am abotu to fall over on my keyboard lol; but I hope you get what I am trying to say) --Shadowphoenix 07:17, 4 May 2008 (UTC)

Agreed. As it is right now, we already have problems with bcrats stepping back of their functions in order to avoid interest conflicts, just because they got too involved in discussions. If they are allowed to enforce everything sysops are, we could easily end with two or the three bcrats declining the review of a case because "they are involved" (ignoring any merit the case has). Unless they can prove that they can separate their functions as users/sysops/bcrats (which they have not until now), i don't think we should mix the use permission for administrative tools either.

To make it short, word it so bcrats keep their sysop status as it is today in order to avoid problems.--Fighterdoken 07:28, 4 May 2008 (UTC)

I haven't managed to find the time to actually peruse the forty two different drafts currently proposed, so I hadn't shared my opinion anywhere. But whenever I managed to find the current Adminship draft under debate, I planned to mention basically the same thing. In my opinion, Bureaucrats should not be involved in activities (namely blocks) which could negatively impact their future participation in ArbComms. They should be as uninvolved in user issues of all kinds as possible prior to accepting an ArbComm case so that there aren't any suspicions or accusations of bias. The best way to ensure this is to prohibit use of sysop powers on other users. (Though like Shadow, I'm not as concerned with protection or article deletion, if they want to be involved in it). — THARKUN 07:34, 4 May 2008 (UTC)

I recall there being a clause in some other admin draft -- bureaucrats should only use their sysop tools whenever a sysop isn't available or if the case doesn't require any interpretation, i.e. spam bots, link spammers, simple vandals. I wouldn't mind that; that said, I wouldn't overly mind them being full sysops. (by the way... how long has this draft been asking for responses? seems a little delayed to me for an opposition with an effect of this size) -- Brains12 \ Talk 14:43, 4 May 2008 (UTC)

"Although Bureaucrats are considered to be sysops (and are endowed with the powers thereof), in order to prevent conflicts of interest, they are expected to use those powers only when a sysop is unavailable and immediate action is necessary (eg. cases of rampant vandalism)." That's the line from I added to Guild Wars Wiki:Adminship/Draft 2008-02-06 essentially as a compromise between making them full sysops and leaving their status at it is now. That said, I support Bureaucrats being full sysops. *Defiant Elements* +talk 15:15, 4 May 2008 (UTC)

I think the idea is that the other 2 can handle it, tho' if one is the target and the second the blcoker one could get two abstains, I guess.

One solution would be the one DE has proposed. Another to expand the number of bcrats. How would you 3 feel about those? Backsword 05:18, 5 May 2008 (UTC)

Expanding the number could work, but in that instance we could remove the whole bureaucrat position, and assign it to current sysops on a case-by-case basis (we still would pick 3, but we would have a pool from where to work). In any case, i would still prefer the "can't do" option, instead of a "should not".--Fighterdoken 05:37, 5 May 2008 (UTC)

How about DE's propsal? (Can't 'cept in emergencies) Backsword 05:42, 5 May 2008 (UTC)

Answered above. I would still prefer to totally separate their functions but, if nothing else, i guess a limited to emergency-only use shouldn't be too much of a problem. In any case, note that some of the users who have ended facing a bureaucrat review were also the cause of "emergency cases".--Fighterdoken 05:46, 5 May 2008 (UTC)

I have one question (to those who prefer to keep them separate): Are you guys worried that bureaucrats would abstain, or that they wouldn't abstain? If it's the former, there is essentially nothing forcing two bureaucrats to abstain. If one bureaucrat already abstained, the remaining two, in principle, shouldn't. One important thing to note is that this call for bureaucrats to remain neutral and not directly involved in discussions essentially implies that I would be compromising my position to arbitrate should any of you here get pulled into arbcomm... since, as it is, I'm kinda "directly involved" in disagreement. Phrasing my question in another way, are you guys more worried about a bureaucrat's neutrality or a bureaucrat's refusal to participate? -- ab.er.rant 05:29, 6 May 2008 (UTC)

I would guess its a mix of both, I think there should be no blocking tools for bcrats because they have more of a chance to abstain (or in a rare case accept or decline or w/e when they shouldnt have) get what I am saying? --Shadowphoenix 05:37, 6 May 2008 (UTC)

I get it, but abstaining usually results from a prolonged debate or argument with a user, rather than block-related. As I mentioned, it implies that bureaucrats should abstain from discussions to minimise direct user involvement. In that case, in the elections, we should have nominated users who are not so active, especially in talk pages... so that they're less likely to be biased. From my point of view, blocking someone according to policy is going to be less bias-inducing than engaging in a heated argument with another user. Disallowing blocks is just not addressing the real issue - user contention. I would rather see something to the effect of advising bureaucrats to avoid getting directly involved in user disputes, and to have restraint on sysops tools to not go beyond what is specifically and unambiguously allowed. Saying I can't block a vandal won't stop a user from repeatedly harassing me and wailing on me for deleting his guild cape's image. -- ab.er.rant 10:22, 6 May 2008 (UTC)

Same as above, i am worried about both. I think we could end with no quorum for a case because of bureaucrats stepping back feeling they got too involved into something (which usually would be a good thing), and i also feel the affected user may feel a bureaucrat is not fit for judging him if he was already judged by the bureaucrat into a certain matter, thus ignoring any resolution taken (and we know users who want to grief find a way to do it regardless). Let's also remember that not every user agrees with what is written in the policies, or the interpretation we do about them, so usually the only "unambiguous act" which a bcrat could solve would be those done by gibberish bots (NPA is open to interpretation, human vandalism is open to interpretation, policy breaching may be open to interpretation, etc).

I don't really see how picking a silent bureaucrat could prevent this (even though forcing bcrats to be silent while on duty could prove to be useful). I do think we should try to at least limit any possibility of conflict with users that are already conflictives, and that will try to use any possible reason to justify their actions (i mean, users who end facing the bureaucrat team are not you common vandal anyways).--Fighterdoken 06:27, 7 May 2008 (UTC)

Proposal or Draft?

This is categorized and titled as a draft and yet it list here Guild_Wars_Wiki:Policy as a proposal. I did not delete from the proposed policies to allow for this draft to be changed to a policy proposal if that is the intent, although it states there that it has been proposed for a month. I'm hoping you realize that many people do not comment on drafts over policies that they do not believe need changing and this was just an editing oversite. Thus, please make this a proposal and categorize as such, or remove from the list of proposals. -- Inspired to ____ 17:28, 5 May 2008 (UTC)

Drafts are included and accepted in that section. Most of the policy changes under that are all drafted and not proposed. I don't agree with the drafts being removed from the list, since discussion while it is still a draft is very important. --Shadowphoenix 18:26, 5 May 2008 (UTC)

Actually I believe most are actually proposals. But, regardless if something is not actually a proposal but just a draft (for comment or because some people like making drafts) there is actually absolutely no reason for anyone to comment on them unless they feel a change should be made to the draft. And, I see it as devious to list a draft as a proposal in order to get input on it. However, this is not the appropriate place for this discussion, so lets continue it on the Policy page. -- Inspired to ____ 19:42, 5 May 2008 (UTC)

This was entirely my fault. I should have at least noted something there when shifting this back from proposed to draft. Sorry. --Rezyk 21:00, 5 May 2008 (UTC)

So... what caused it to shift back to draft? Which parts are incomplete? Or rather... maybe more appropriately, what exactly constitutes when something switches from draft to proposed? -- ab.er.rant 05:17, 6 May 2008 (UTC)

I reluctantly did so in an attempt to reach a better consensus, and have "re-proposed" now. I generally just treat switching between draft and non-draft as informally showing what stage to roughly take it as in terms of commenting/editing. --Rezyk 11:00, 7 May 2008 (UTC)

Changes

I proposed a new adminship draft here, and alot of the changes that are in their are minor and there as been a suggestion of possibly merging my draft with this draft. Maybe not all the changes but maybe some of the major changes that are placed in it, like allowing Bcrats to delete/undelete but not block and some other things in there. If you guys don't have a problem with it, i don't have a problem with it. I agree with DE that the changes are small and should be included into this proposal. --Shadowphoenix 21:39, 5 May 2008 (UTC)

This draft is completely different to yours. The only significant "similarity" is that bureaucrats are allowed a couple of the sysop tools. I fail to see any other. -- Brains12 \ Talk 21:43, 5 May 2008 (UTC)

It's not a question of small or large changes as far as I'm concerned. It's more that we have two non-mutually exclusive policies at the moment whose differences can be debated on a single talk page without necessitating the existence of two wholly separate policies. The two important changes which I feel like SP wants to see are A) longer bureaucrat terms and B) a restriction on exactly which tools a Bureaucrat can use. Those two changes can be discussed and possibly integrated into this policy proposal without weakening its overall integrity. @SP, if I'm wrong and you have some other changes that are more exclusive that you'd like to add, then nevermind. *Defiant Elements* +talk 21:46, 5 May 2008 (UTC)

Your right, but there is a little bit of a clause in mine that allows community discussion to demote a bcrat (if they find him/her not suitable for the role etc.). I would like that to be included as well, however I would not mind very much if it was not included --Shadowphoenix 21:48, 5 May 2008 (UTC)

How exactly would your "community discussion" work? You noted "community vote" in your proposal, but you neither noted how that would take place nor how the votes are to be interpreted. Does a successful community vote override the remaining two bureaucrats decision not to demote? That seems to imply a rather bleak possibility where the community managed to elect three bad bureaucrats. -- ab.er.rant 05:17, 6 May 2008 (UTC)

Did I put vote? Sorry it should say discussion; I would figure it would be formed on the RfA policy's talk page. Yes that may be a very, shall I say rare possibility; but I feel we should take care of it b4 it even has a chance of happening. --Shadowphoenix 05:32, 6 May 2008 (UTC)

So is this community consensus supposed to override the decision of the two remaining bureaucrats? I'm not sure whether I like it. I think I get where you're coming from, but I can't help feel that it sort of undermines the so-called final arbiter role of a bureaucrat. It's like "we elect you to arbitrate user issues, but if we don't like what you're doing, we'll pull you down immediately." instead of letting the term just run its course. I donno. I'll see what others think. -- ab.er.rant 10:22, 6 May 2008 (UTC)

I agree, you elect a bureaucrat for a reason. If we all can completely ignore the decision of at least one bureaucrat, there's no point of having a bureaucrat -- you may as well decide everything through community consensus. Because community consensus doesn't always "work", we elect bureaucrats. But if those bureaucrats can be completely ignored through the sometimes-non-working consensus... you see where I'm going with this. -- Brains12 \ Talk 15:18, 6 May 2008 (UTC)

Opinion/status check 3

Updated, re-proposed. Note: sysops that are also bureaucrats are not to execute blocks.

• differences since previous proposal version (~1 month ago)
• differences since second proposal version (~35 days ago)
• differences since first proposal version (~40 days ago)

I think most have some grasp of the difficulties of getting policy changed. With this proposal, I am not trying to create a fix-all nor meet individual consensuses on each detail. I'm following my guess at achieving the best consensus overall (especially on the main issue) while trying to keep everything clearer and acceptable to move forward with. I ask that people stick to considering it under that view -- even if you prefer some other change as a step forward instead, consider whether this is still acceptable as half-a-step first while continuing discussion on the issues that need more of it. In any case, I intend to not go back to hammering on this as a draft for a while at least.

Also please consider Backsword's above concerns regarding the documentation aspect. I aimed to keep this iteration relatively neutral on that (rather than setting or developing a new general documentation solution), but I can't say it's perfectly separate from it and maybe there is something there that you find objectionable enough compared to our current status.

Thoughts and opinions? Thanks. --Rezyk 10:46, 7 May 2008 (UTC)

I'm currently fine with it, as I have been since the first proposed version. I would prefer the compromise with letting bureaucrats block in trivial circumstances, but getting this far is a feat in itself. -- Brains12 \ Talk 14:30, 7 May 2008 (UTC)

I agree. Even if there are some minor kinks, getting this kind of ADMIN proposal passed in any form will be quite a triumph. *Defiant Elements* +talk 14:32, 7 May 2008 (UTC)

I don't see any troubles with this. Small steps are still steps :) - anja 16:11, 7 May 2008 (UTC)

Wait, wasn't "small steps are small"? Now seriously, i don't have mayor complains with the current proposal either. Maybe the only thing would be a cosmetic change, moving the line about "bcrats non-blocking" from the sysop section to the bcrat section, but otherwise looks fine (i specially like the SDL).--Fighterdoken 21:56, 7 May 2008 (UTC)

I think it's fine where it is, since they're just next to each other and there is this "bureaucrats are sysops" line; it should be pretty visible ;) I have no problems with this half-step either. -- ab.er.rant 03:49, 8 May 2008 (UTC)

(Reset indent) You know, I was thinking last night, maybe we could give bcrats the right to blovk IP's but not users. Since my problems were with ArbComm and blocking; and an ArbComm, as far as I know, can't be started for an IP. So hows about it? --Shadowphoenix 03:54, 8 May 2008 (UTC)

It's best to talk about this in the "My Issues With This" section above. Are you ok with this proposal as it is? -- ab.er.rant 03:58, 8 May 2008 (UTC)

Oh I wouldn't mind this proposal being implmented at all, I like it. I was just suggesting maybe adding that to it, but if it doesnt happen it is not a prob. :o) --Shadowphoenix 04:01, 8 May 2008 (UTC)

I'm not sure if its just a sign that I'm easily swayed in my opinion, or if Aberrant brings up points I hadn't thought of, or the gun Brains is pointing at me has an effect, but I'm perfectly fine with this. Just for the sake of smoother reading and clarity, I'd reword the first paragraph of selection process to be more similar to the current policy: The sysop selection (and reconfirmation) process is governed by the policy for requests for adminship. Sysop terms are unlimited, but can be ended via voluntary resignation, an arbitration ruling, or a failed request for reconfirmation. Sysop status is also granted temporarily during a term as bureaucrat. I feel its more clear but has no effective change in meaning. But I may well be overly .. something. Concerned with the flow of language. I don't know. Either way, +1 for consensus. — THARKUN 05:29, 8 May 2008 (UTC)

Not really a fair representation of my issue, as your verion divrges more from the current situation, but whatever.

Like the previous versions, this does a good deal of useful clean-up, as well as a few changes that I am agnostic about, so no oppose from me. --Xeeron 15:00, 8 May 2008 (UTC)

Example

You wanted an example earlier, and I just read GWW:DELETE. It conmtains prohibitions, as a list of four points. But as I see it, those are there to clarify what the speedy criterias do not mean, not because they are things we find especially bad.

Can you honestly maintain that deleting something that just barely fails to meet A1 is more controversial that just deleting the main page? (Gordon's earlier example). Backsword 05:33, 8 May 2008 (UTC)

You are correct, the deletion policy does not currently contain any explicit restrictions, only strong implicit restrictions, which would technically allow the main page to be deleted if this proposal was implemented (although it would definitely be noticed and overturned). I'm not thinking of sysop vandalism, and I'm not thinking of situations in which a sysop makes a good faith deletion which just barely meets the speedy deletion criteria. I'm thinking of a situation in which a sysop decides that something doesn't belong on the wiki, such as builds, historical content or pages for guilds without high ladder rankings, something like Wikipedia's cookie purge, but on a much smaller scale. As I explained on Guild Wars Wiki talk:Adminship/draft E, I believe that the discretion clause is intended for blocking, and authorizing sysops to act against explicit restrictions of policy would do nothing to serve that purpose, as our current body of policy contains no explicit restrictions on blocking, and any reasonable blocking policy would prevent exploitable loopholes by authorizing emergency and / or discretionary blocks. -- Gordon Ecker 08:00, 8 May 2008 (UTC)

I get the general feeling that we're not quite on the same page. None of these things are directly related to the documentation clause, and do not differ from B and E. I'll try to address this on E's talk. Backsword15:08, 11 May 2008 (UTC)~

The proposal doesn't insist/depend on it being more controversial. --Rezyk 17:07, 12 May 2008 (UTC)

It's the justification you have given. I've seen no other. Backsword 13:21, 13 May 2008 (UTC)

It's an oversimplification/misunderstanding of any meaning I've intended. Not sure if there is any remaining worthwhile way for me to try to get the reasoning across. --Rezyk 03:11, 21 May 2008 (UTC)

And if there are not 2?

I've read through a few of the Drafts, and it seems like this one is the most active, so I will pose the question here. I scanned the talk pages and archives and have not seen it addressed. There is a statement that the group of bureaucrats, as long as there are at least 2, form an arbitration committee. What if there are not two, or for some reason they must abstain from a case leaving only one or even none. Who then serves as the arbitrators?
Furthermore, if there are only two bureaucrats, it only take one vote to remove the other bureaucrat under this proposal, which could be easily countered by the first bureaucrat demanding the removal of the other. Whose vote counts? This is obviously a silly situation, but it brings up the point of how can bureaucrats be forcibly removed if there are only 2 serving currently. Mohnzh say what? 15:15, 13 May 2008 (UTC)

Regarding removal of bureaucrats, that is only in there for completeness. In case a bureaucrat ever needs to be removed, I think it will be very obvious who should be removed and who should not be removed through discussion taking place beforehand. --Xeeron 18:18, 13 May 2008 (UTC)

Mohnzh does bring up a good point about the 2 bcrats thing. So waht would we do in a situation like this? --Shadowphoenix 17:11, 16 May 2008 (UTC)

In the case of arbitration, there is none. Things can be solved in other ways. In the case of removal of bcrats, we turn to Anet if there's any trouble, since they will always have the "powers" to assign/remove user rights. They just don't use them atm. - anja 17:35, 16 May 2008 (UTC)

In this draft, it says that ANet may only be involved where explicitly stated. There role in bureaucrat removal is not explicitly stated. Therefore it ought to (easily) be included, if it is truly the case. Otherwise, a more detailed process ought to be outlined. Of course, one would hope that it would never be necessary. Mohnzh say what? 17:55, 16 May 2008 (UTC)

The thing is, the only time I feel this would be a problem is in extreme cases, where policy would not apply/be impractical anyway. Either, we can try to cover everything in a policy and be burdened with loopholes and mistakes forvever, or we can rely on some common sense and not be forced to follow policy word by word.
I did not say Anet should be involved in small matters or every other election. What I meant was not a community decision left to Anet, but a community decision carried out by Anet. Removing a bcrat, that doesn't want to remove him/herself already, is not a small matter, and frankly I think Anet would intervene no matter our policies. A rampaging bcrat can be quite bad for wiki. :P - anja 18:13, 16 May 2008 (UTC)

Consensus?

Checking: Is it fair to say that there is a consensus for this? --Rezyk 03:15, 21 May 2008 (UTC)

Obviously, I'd disagree. I haven't seen any support or reasoning supporting your documentation system. Would rather implement draft E, which includes everything people have supported, but not it. Backsword 05:10, 21 May 2008 (UTC)

Since B and E are actually pretty simmilar, both parts could check this link and maybe find a way to merge both drafts into a single proposal?. I mean, the wording for bcrat sysop power in E seems better, but also the wording for the discretion log on B is good...--Fighterdoken 05:39, 21 May 2008 (UTC)

Honestly Backsword, I haven't seen anyone else than you mentioning it, which to me indicates that no one else sees it as a problem. Also, I don't see what the difference is between B and E except wording. To me they say exactly the same. - anja 07:37, 21 May 2008 (UTC)

I share a similar confusion with Anja; the only difference between B and E to me seems to be wording. Both mention documentation of nonstandard actions. (Aiiane - talk - contribs) 07:44, 21 May 2008 (UTC)

There is one meaningful difference. Draft B requires the documantation of every incident in which sysop powers are used in a manner contrary to policy in the log. Draft E requires the documentation of every reason sysop power is used contrary to policy in the log, but does not require individual incidents to be documented, and contains some ambiguous phrasing. -- Gordon Ecker 08:22, 21 May 2008 (UTC)

There is also another difference. Draft B specifically states Bcrats as "sysops", allowing them to do all sysops do now (which is, IMHO, bad). Draft E states that bcrats, while still being sysops, are not to work as one unless "shit happends" (being quite conditional to it, as to avoid problems later when the bcrat has to do his job). That is actually a big difference when you take the time to analize it.(added) Also, draft B states that bcrats "shouldn't" block, while draft E doesn't deny the hability if needed. --Fighterdoken 08:34, 21 May 2008 (UTC)

Based on my interpretation of the discretion clause, in an emergency, a bureaucrat could still execute blocks as long as they put an entry in the discretion log, such as "blocked 10.0.0.0, 127.0.0.1, 172.16.0.0 and 192.168.0.0 for vandalism because no other sysops were available". I don't have any problem with toning down the restriction on blocking by bureaucrats, or merging in aspects of draft E other than the discretion clause. -- Gordon Ecker 09:02, 21 May 2008 (UTC)

Can we accept this first, then work out any documentation "problems" after? The majority (i.e. everyone except Backsword) seem to think B is better than E in terms of documentation. Why are we letting a couple of words delay this for so long? -- Brains12 \ talk 12:22, 21 May 2008 (UTC)

Hmmm I'd rather solve any problems that might exist with the documentation before implementing the policy. Assuming that everyone is ok with the added discretion, does anyone know a better way of documentation? If so, we should discuss that. --Xeeron 16:14, 21 May 2008 (UTC)

I'll copy and paste what I said on my talk page - "When the change is as little as how something is logged, and when it would be extremely rare for something needing logging, it slows down what would be a huge achievement in getting that policy accepted. The outlook on draft E has been apathetic so far, so I can't help thinking that it would be better to implement B and then work out the minute detail that is the logging of a rare occurrence." Also, considering the positive responses here, it seems that documentation isn't a problem for those of us who want to get something implemented and leave the "problem" until just after implementation. I doubt we'd get a case of going against policy in the few minutes of implementing it, so documentation would not be a problem; we'd have more than enough time to sort that out. In the meantime, shall we accept what we have already? -- Brains12 \ talk 16:20, 21 May 2008 (UTC)

Well you could do so by leaving that whole part out of the policy, but why not ask for any ideas for better documentation? If noone comes up with any that gain support, we are done. --Xeeron 16:37, 21 May 2008 (UTC)

I'd rather implement something which requires more documentation and then whittle it down from that, rather than implement something which requires no documentation and then struggle later to add it.

If anything, it'd be easier to simply document each occurance, rather than having to go through and find whether a similar action has been taken before - the "better safe than sorry" way of thought. Notes don't have to be detailed. (Aiiane - talk - contribs) 16:41, 21 May 2008 (UTC)

If you have any ideas that are better than the current version, say so now, no need to postphone that. If you don't, I fail to see the problem. --Xeeron 16:45, 21 May 2008 (UTC)

I think you misunderstood me, I was not stating that I have issues with the current version, but rather that I would prefer to implement draft B and scale back from there than to implement draft E and have to expand it. (Aiiane - talk - contribs) 17:17, 21 May 2008 (UTC)

I'd be willing to implement Aiianes version. My worry was that this would place an undue burden on sysops. And be a bit of a wasted effort, if it had already been well explained. But I guess we could make such a change later, when warranted. Backsword 07:47, 22 May 2008 (UTC)

First, I like that draft, but I have a question. "Additionally, sysops that are also bureaucrats are not to execute blocks." - I read this line that there are also bureaucrats, which are not sysops; whereas "Bureaucrats are sysops with [...]" says that bcrats are sysops as well. So how does this work? Do bcrats need to have an RfA to be allowed to use sysop actions (apart from blocking), or are they immediately allowed to do that when they become bcrat? poke | talk 15:20, 21 May 2008 (UTC)

Becoming a bureaucrat automatically gives one sysop status as well - "One also gets sysop status temporarily during a term as bureaucrat. " - it doesn't state another sysop selection method for bureaucrat promotions, other than being conditional on their bureaucrat status. If bureaucrats are sysops, but the sysop section says that bureaucrats can't block, then those bureaucrats .. well, they can't block. -- Brains12 \ talk 15:35, 21 May 2008 (UTC)

Ah, ok :) poke | talk 15:37, 21 May 2008 (UTC)

I'm in favor of adopting this and then working from there - for the most part, this draft appears to be stricter, so at worse we'll simply have to document non-policy actions in detail until or unless we come to an agreement on whether it's necessary in all cases. (Aiiane - talk - contribs) 16:11, 21 May 2008 (UTC)

(Edit conflict) "Bureaucrats are sysops with these additional powers and responsibilities" is not the clearest statement. It could easily be assumed to mean that to be a bureaucrat one had to already be a sysop. Assuming that's not what is meant, why not say "Bureaucrats have sysop status with these additional powers and responsibilities" to be clear that it is status and not actual technical selection requirements that are being stated. Or a separate note that non-sysops (temporarily) become sysops upon becoming a bureaucrat, like Brains alludes to even though it doesn't exist. Anyway, I don't really care what this policy says among anything I've seen except that the actual meaning is clear. -- Inspired to ____ 16:16, 21 May 2008 (UTC)

this wording tweak should fix your issue without any controversial changes. (Aiiane - talk - contribs) 16:21, 21 May 2008 (UTC)

Decided to give my 2 cents. I have been wondering for the past month why a policy tag has not been slapped on this yet, because 2 or 3 users do not agree with it? If I remember right the definition of consensus is "majority of opinion". It is obvious that "majority" many have an opinion to support this, yet it still has not been implemented. I really do not see much of a difference between Draft B and E, when I read it at first I wondered why it had been created in the first place; the small canges in Draft E could be easily implemented into Draft B, but I do not think that those chnages are a necessity. So I think that the policy has reached "majority of opinion" and should be implemented. --Shadowphoenix 17:31, 21 May 2008 (UTC)

"Majority opinion" is NOT the definition of consensus. If we meant majority, we'd say that. (Aiiane - talk - contribs) 17:36, 21 May 2008 (UTC)

[1], well it can also mean "general agreement", which has been reached as well kinda --Shadowphoenix 17:37, 21 May 2008 (UTC)

We don't operate off of strict dictionary definitions. See Wikipedia:Consensus for more details. (Aiiane - talk - contribs) 17:39, 21 May 2008 (UTC)

(reset indent) Before debating the merits of how to log controversial sysop discretionary actions, can I ask how the log is meant to be used? Is it a place for record precedents? Are precedents expected to be channeled back into policy? Is it a place for users to challenge sysop discretion? A place for sysops to notify or ask other sysops about their actions? My concern is that if we ask sysops to log too much, it essentially wastes their time. It's one more place they have to keep an eye and debate stuff. -- ab.er.rant 02:49, 22 May 2008 (UTC)

As far as i understand it, it's a place to locate non-policy covered events (or those who contradict policy), thus allowing the centralized discussion of the topic and deciding if there is consensus on it to incorporate to the current policy, if it is not needed (sysop discretion or common sense), or if such action is to be avoided to be taken in the future.--Fighterdoken 03:00, 22 May 2008 (UTC)

IMO the primary purpose should be to subject controversial actions to scrutiny, with a secondary purpose of tracking possible policy problems, such as loopholes and excessive restrictions. As for other actions outside of policy, IMO logging them should be voluntary, as it would be under this proposal. -- Gordon Ecker 23:38, 22 May 2008 (UTC)

Merge

I made E as a seperate draft as last time people seemed to prefer that. And I didn't want to step on Rezyk's proverbial toes by altering "his" draft. However as it has been suggested we merge, there are some other alterations I made to E that I'd like to know if people approve.

1. Some rewordings, prompted by various requests for clarification, from B and early versions of E. Esp regarding Bcrats as sysops.

2. Added "A clear reason is to be provided in the log." to bcrats using user rights. As a response to the drama with Bexor's desysoping.

3. Added "(as long as there are at least 2 others)." to the section where bcrats can remove another bcrat, so that in the situation of there only being 2 bcrats, neither can remove the other unilaterally.

Backsword 07:53, 22 May 2008 (UTC)

Going by those three points, I would agree to a merge - but only if it can be sorted out promptly. -- Brains12 \ talk 14:23, 22 May 2008 (UTC)

I don't think any of those alterations represents a serious deviation from the spirit of Draft B. Given that neither draft can be implemented until consensus has emerged on which to implement (which I honestly don't see happening in a prompt fashion) and given that, in my opinion, implementing one or the other is of the utmost importance -- I'm largely ambivalent as to which is implemented -- if, as Brains says they can be merged in a prompt fashion, then by all means merge them. *Defiant Elements* +talk 19:54, 22 May 2008 (UTC)

These are minor things and we could without them. I do think they are improvements. Backsword 08:50, 23 May 2008 (UTC)

If those are what you want to merge in, I'm fine with it, if it means we can pass this draft after the merge. (Aiiane - talk - contribs) 04:54, 23 May 2008 (UTC)

Finished?

What (if there are any) issues still remain with this proposal? As Backsword seemed to be the main opposer, and he has edited the draft page now, I want to check if someone else had an issue so we can avoid an "implement/revert" war :P - anja 16:10, 26 May 2008 (UTC)

[X] Implement already - [ ] change XY! - [ ] Admin..what? poke | talk 16:18, 26 May 2008 (UTC)

As said, I'm fine with it. As Rezyk was the main proponent of the earlier version, I'd like to hear from him before implementing. Backsword 16:28, 26 May 2008 (UTC)

Implementation reverted?

I would like to know why the implementation was reverted, and why so many changes were made to the wording. I personally don't approve of either.-- Wynthyst 17:09, 26 May 2008 (UTC)

I too feel that the new wording (particularly of the Sysop section) simply muddies the waters, and I truly don't understand what the reversion (of what amounts to an accepted proposal) accomplishes, particularly when these minor changes need not be cause to wait to implement this proposal. *Defiant Elements* +talk 17:11, 26 May 2008 (UTC)

Reading it through once more, I'm inclined to agree. There is no difference in them, really, but the former was alot clearer. - anja 17:18, 26 May 2008 (UTC)

Given all the recent changes one thing is clear: there was not consensus to implement yet. -- Inspired to ____ 19:10, 26 May 2008 (UTC)

No, that is absolutely not clear. To be honest, see Brains' comments on Backsword's talk page. All these changes appear to have revealed is that people were happy with Draft B the way it was (not surprising given that there was consensus on it!). I personally implemented Draft B after seeing that the community overwhelmingly supported it. The implementation stood for a day; indeed, no one even felt compelled to comment on it. Then, Backsword decided that he personally wasn't done with it and decided to unilaterally revert the implementation. That is absolutely not an indicator of a lack of consensus. Your argument assumes a causative relationship when the only one which exists is correlative. Yes, there is a correlation between the number of changes made to the document and the degree of consensus, but to assume that the consensus is dependent on the number of changes being nil is simply fallacious reasoning. *Defiant Elements* +talk 19:22, 26 May 2008 (UTC)

Let me be absolutely clear...I don't care whether the policy is the old way or the way it was changed to. But I do object to this sideways attempt to change consensus into "consensual compromise" or anything similar for a currently existing policy. There already is a policy and thus no need for anyone to compromise their beliefs on what the policy should be. A policy is made of a bunch of pieces. If there is consensus to change a piece to something else, then change it; if not, then don't. It is not useful to say I want to change this and you want to change that; and although neither of us wants to make the other change, let's compromise and change both. That's not the type of consensus I want to see in this wiki's policies. -- Inspired to ____ 19:41, 26 May 2008 (UTC)

That's the kind of thing already in this wiki's policies, whether you like it or not. Compromise is the only way, sometimes. Not everything can be supported by everyone. - anja 19:48, 26 May 2008 (UTC)

Eh? Sorry, but I cannot understand how you not see the consensus here..!? poke | talk 19:52, 26 May 2008 (UTC)

It's evident that you simply don't understand how policies are created or what consensus means. The very nature of consensus is compromise, especially on a wiki with people of differing opinions. Your response proves that. -- Brains12 \ talk 19:54, 26 May 2008 (UTC)

You're the one who seems willing to ignore that we already have a policy for which I would believe there was consensus. I specifically referred to making a change not to a new policy. There is a very big difference. The only reason to attempt to make a wholesale substitution of one policy for another is to attempt to get pieces for which consensus does not exist included by offer to give consensus for the rest in exchange. This is wrong and should not be happening. Change anything for which consensus exists and leave the rest alone. -- Inspired to ____ 20:07, 26 May 2008 (UTC)

Consensus over a year ago does not mean consensus today.

If I'm understanding you correctly, which I doubt, and you want to get rid of everything that doesn't have 100% agreement and that has not been part of a compromise, then by all means implement this.-- Brains12 \ talk 20:14, 26 May 2008 (UTC)

You are misunderstanding me. I do not doubt there was essentially consensus for this proposed change. There was not consensus to implement this policy proposal as it was just yet. There was an ongoing discussion on some minor wording changes. What the hell was Defiant's hurry to make the change rather then waiting for those things to be ironed out I'm not sure, but that is all that was wrong here. Finally, it's generally a good rule on a wiki that if someone reverts a change you made, there is not consensus for it. -- Inspired to ____ 20:46, 26 May 2008 (UTC)

Make your mind up - was there consensus on what Defiant implemented or not? You say "I do not doubt there was essentially consensus", then you say "There was not consensus" and "What the hell was Defiant's hurry to make the change" - Defiant IMPLEMENTED THE CONSENSUAL DRAFT. If you cannot understand that, and you cannot understand that it's "generally a good rule" to implement consensus, I refuse to discuss this with you any further. -- Brains12 \ talk 20:56, 26 May 2008 (UTC)

Further, I thought there was consensus for this: "Additionally, sysops that are also bureaucrats are not to execute blocks." If not, I would say we're not even close to implementing. -- Inspired to ____ 19:15, 26 May 2008 (UTC)

That was added by Backsword after implementation and reversion. -- Brains12 \ talk 19:54, 26 May 2008 (UTC)

This was removed, not added, by Backsword. It also was in the attempted implementation by Deviant that Backsword reverted. Finally, and most importantly, I absolutely to not agree with policy proposal if bureaucrats can block and will elaborate if necessary, but from the above discussion it is very clear that there was not consensus to remove this limitation. -- Inspired to ____ 23:00, 26 May 2008 (UTC)

I think I misread your first post, but our intentions were the same - I intended to say that Backsword allows bureaucrats to block, and I think you intended to say that the line limiting them was to stay. In either case, the limitation was removed. -- Brains12 \ talk 23:15, 26 May 2008 (UTC)

There was a difference between both drafts, B and E. One allowed bcrats to use their sysop tools with the exception of blocking (being explicit about it in the sysop section). The other allowed bcrats to use their sysop tools only if no sysop was available at the time to deal with it (including blocking). --Fighterdoken 23:21, 26 May 2008 (UTC)

I never paid any attention to "E" because there clearly wasn't consensus for it. Since this change did not include giving bureaucrats the right to block, I have not cared. Also, there was discussion above removing this limitation and it was rejected. Imo, the rest of this change is just about more work for sysops (documenting what they do) and bureaucrats (arbitrating over more blocks by sysops because they can now block outside of policy). How this implementation/revert suddenly leads to what I would consider the only significant change in this policy being made is unbelievable. -- Inspired to ____ 23:35, 26 May 2008 (UTC)

Discussing whether there was consensus or consensual compromise or nothing will not bring us any closer to implementing this policy (but has a great potential for exquisite wiki drama), so I suggest sticking to the facts and taking a look at the changes made since then. Let's not get derailed on the last meter. --Xeeron 19:53, 26 May 2008 (UTC)

Reimplement what was already implemented. Then discuss the changes that were made in spite of the existing consensus that was implemented - as many have said numerous times. -- Brains12 \ talk 20:00, 26 May 2008 (UTC)

Yeah, I honestly don't see what there is to discuss, period. We're talking about (on the whole) extremely minor differences (that everyone who has commented so far seems to have disliked) and which really have no bearing on whether or not the draft on which everyone essentially agreed should be (re)implemented. *Defiant Elements* +talk 20:04, 26 May 2008 (UTC)

I agree that the implementation should not have been reverted, and the changes to the wording after the reversion should not have been done without discussion. I totally disagree with Inspired, this draft had consensus from the community (it seems except for Backsword). This is how policy is changed, and not a "sideways attempt to change consensus".-- Wynthyst 20:19, 26 May 2008 (UTC)

I just noticed this entire section. What the heck are you all talking about? I was genuinely surprised when I saw D.E. marking this as implemented, because we had just suggested merging in a couple of changes from E and were discussing that in a section above so that we could implement it as acceptable to add after the merge. There was not a final consensus here when this was "implemented". We were getting close, but we weren't there yet. Please, please don't jump the gun and create things like this. (Aiiane - talk - contribs) 22:15, 26 May 2008 (UTC)

I very much agree with Aiiane (though I didnt really want to spell it out before, because I'd rather have the discussion focused on the policy, not the concept of consensus, but it seems to happen no matter my wishes, heh). The way to gather consensus on a wiki is, imho, either the "support chain" (asking for and getting many people to post their support in clear words) or the lack of disagreement (asking for and not getting, in a reasonable amount of time, any disagreement), ideally both happen simultaneously.

Trying to implement a policy that is still worked on is dangerous. Draft B has been around for 3 months now and looks very promising, so waiting another week will hurt noone (and the current activity shows that people are still actively searching for compromises, better wording, etc). --Xeeron 11:28, 27 May 2008 (UTC)

Xeeron, others, the bract elements were merged in after vaugly possitive comments above. Some by the same people who are now objecting to them....

I think them improvments, but not essntial, so if they're what stands between implementation and this, by all means, those offended by them should remove them. Backsword 04:49, 27 May 2008 (UTC)

Wording

Who defines what is "normally accepted"? The sysops? Concensus? People complaining? I just see alot of trouble rising from that wording, and I wouldn't act with that wording. I would rather ignore issues, since normally accepted is very wide and can be itnerpreted very differently, and acting on anything like that is doomed to cause drama. And I wouldn't feel supported by policy in any way to use discretion. That's why I changed it. - anja 22:21, 26 May 2008 (UTC)

"If going against what would normally be accepted as policy or going beyond usual sysop actions". As a rule of thumb, it would be "if it's not clearly explicited" as to avoid users wiki-lawyering the decision. It would pretty much be any action that is currently considerated "sysop discretion" (and in case of doubt, adding a new entry to the log can't really hurt, can it?).--Fighterdoken 22:31, 26 May 2008 (UTC)

Yea, I know I exaggerated a bit there, but I still feel it's really ambigous and seeing what you wrote, it basically says the same as before? - anja 22:33, 26 May 2008 (UTC)

It's meant to be ambiguous. The rule of thumb should be that if there's any doubt at all about whether it would be accepted, it should be noted. There's no specific metric that can explicitly determine that for every scenario. (Aiiane - talk - contribs) 22:35, 26 May 2008 (UTC)

Ah, I think I understand better where you are coming from now. I thought it was meant to explain the same thing in other words, not change the actual meaning. If it's meant to be ambigous, I guess you succeeded :) I don't like the wording, but I don't have a better suggestion, so if what it says now is what was accepted, fine. - anja 22:41, 26 May 2008 (UTC)

(Edit conflict x2) Well, a concrete answer would need to be giving examples case by case which would just fill this page up with unneded info i think). To put it simple: Any ban would need to go there (excluding bcrat injuction related, and maybe gibber-bots and sockpuppets bypassing a previous ban, since it appears to be concensus on them). Speedy deletion of articles not covered by policy. Reverts or removal of content into any namespace when the content is not covered by another policy explicitly forbidding its inclussion and... i think that is all. I actually think this can be resumed in "any ban", as to avoid another J.Kougar issue.--Fighterdoken 22:43, 26 May 2008 (UTC)

In short, everything they do? Lord Belar 22:48, 26 May 2008 (UTC)

No, there are plenty of things sysops do normally which are in policy. There are some blocks which are matter-of-course (vandals, sockpuppets, et cetera). The majority of deletions are considered matter-of-course. Speedy deletion of articles is normally covered by policy, so "speedy deletions not covered by policy" would only be in special cases. Reverting content isn't a sysop-specific action, I don't see why it'd need to be noted, except for potentially talk pages, due to policy explicitly forbidding that - but that's the point of this log anyways. I don't think it's valid generalizing that to "anything sysops do". (Aiiane - talk - contribs) 22:53, 26 May 2008 (UTC)

Fighterdoken, if that's the only issue, would it perhaps be a good ide'a to give them full sysop powers, but simply reqire them to stay away from any contoversy involving another bcrat? Just an idea, I'm really fine with any of the suggestions here. Backsword 04:51, 27 May 2008 (UTC)

Uh? Don't look at me, i am fine either way at this point, since both options seem to cover my previous concerns. Not sure other users up there, though :). --Fighterdoken 04:56, 27 May 2008 (UTC)

I added a slight bit to that section, limiting bureaucrats to blocking things that are unlikely to be challenged (specifically, those mandated directly by policy). I think that's a fair middle ground. (Aiiane - talk - contribs) 05:02, 27 May 2008 (UTC)

Not so. The reason that was brought up initially to prevent bureaucrats from blocking is not really whether or not it'll be challenged. It's that bureaucrats would then become directly involved in that particular situation with that particular user. And that in turn, if it comes to any arbitration, may cause a bias, intentional or otherwise. -- ab.er.rant 06:56, 27 May 2008 (UTC)

You can also become directly involved with an user in many ways not captured by a ban on blocking: Deleting said user's pet page, enforcing the user page policy on him, tons of different possibilities. Even if you insist on readding the block for bans, I would like the current wording to stay and include that bureaucrats should not use their sysops powers in cases that are likely to be controversial (and therefore potentially involve arbcom). --Xeeron 11:38, 27 May 2008 (UTC)

What is the point of "that are likely to be controversial" since it seems a good option for sysops to also try to avoid blocks that are likely to be controversial. As for the currently worded "potentially controversial reasons," by one interpretation it would mean they should never block; and by the other they can always block and will just be wrong if they block and it becomes controversial. Either way it makes no sense, especially when there exists no good reason for bureaucrats to block. And in response to those who say: what if no sysops are available, there are at most three bureaucrats compared to a much greater number of possible sysops. Thus, if their are not enough sysops, appoint more. And anyway, what if there are no bureaucrats or syops available? So what? If a block is called for, someone will do it when they are available. -- Inspired to ____ 14:10, 27 May 2008 (UTC)

The key difference is the bcrats have a seat on ArbComm and make the final choice as to user matters, sysops do not. Xeeron, I would say that adding that line is ok, but maybe we could make it where they should only delete aricles outside of the userspace or something. However, i do feel that if we do so it puts to much of a restriction on a bcrats newly given powers which it should not. --Shadowphoenix 14:15, 27 May 2008 (UTC)

You know that blocking involves a lot more discretion and would be problematic for bcrats when that user is involved in a ArbCom case, whereas deleting is explicit described in a policy? Restricting deletion but allowing to block is just stupid! poke | talk 14:19, 27 May 2008 (UTC)

huh? If you are talking about what I put, I do not think that bcrats should have blocking ablilities.... and I think restricting deletion is a not so hot deal either :S --Shadowphoenix 14:21, 27 May 2008 (UTC)

(Reset indent) As Xeeron stated, ab.er.rant, there are plenty of ways to become directly involved with a user; we're hardly going to be able to prevent that in policy. In the end it comes down to a bureaucrat's judgment of whether they think it's a smart idea to become involved or not - but that's something that I think we can trust bureaucrats on. The restriction on blocking is due to the fact that blocks are by far the most contested sysop action, and the majority of other potential sysop abilities are much more unlikely to result in an ArbComm case (mostly because the majority of other sysop actions are in accordance with specific policies, or specifically time-delayed - speedy deletions have a policy to cover them, and non-speedy deletions have a built-in time lag). (Aiiane - talk - contribs) 15:47, 27 May 2008 (UTC)

Final pending issues

If someone has an issue remaining with part of this proposal draft as it stands, could you please:

• Create a subheading in this section, with an informative title (e.g. "bureaucrats being able to block" or whatever instead of just "wording")
• Describe your issue in that subheading, giving your reasoning
• Also, propose a modification that would resolve your issue, preferably in compromise with any other viewpoints you've seen in respect to that issue

Hopefully, by breaking down any remaining issues into discrete chunks and proposing some potential compromises that could appeal to everyone, we can move towards getting something that everyone can accept for implementation into a finalized policy update. (Aiiane - talk - contribs) 06:51, 28 May 2008 (UTC)

Bump - let's try to finalize this, people. (Aiiane - talk - contribs) 03:02, 29 May 2008 (UTC)

Afternoon bump. Any other issues? (Aiiane - talk - contribs) 23:23, 29 May 2008 (UTC)

Late-night answer: No :) poke | talk 23:31, 29 May 2008 (UTC)

Example Pending Issue

I have an issue with the fact that this document is written in black and white text. It is a problem for me because I don't like non-colorful pages. I would propose modifying the headings of the page to be purple, which would still allow people who like the contrast of black and white pages to read it, but would make it more colorful for people who don't like black and white pages. (Aiiane - talk - contribs) 06:54, 28 May 2008 (UTC)

meh :P poke | talk 10:54, 28 May 2008 (UTC)

I totally agree with what Aiiane is saying here. --Shadowphoenix 13:32, 28 May 2008 (UTC)

Still looks awfully colorless, but I suppose if you all want a change this will have to do. -- Inspired to ____ 03:01, 30 May 2008 (UTC)

[Resolved] Clarification on blocking bcrat statement

Even though i am quite satisfied with the current state of the draft (i would support the implementation on its current state), i think maybe a small reword of the blocking section could leave those worried users happy. Something along the lines of: "Bureaucrats may only use sysop powers to deal with an ongoing situation when no normal sysop is available. Additionally, they may delete pages at any time in accordance with the deletion policy. Bureaucrats are only allowed to issue blocks for the following reasons: spambots, users bypassing a previous block, cases of patent vandalism where the protection of articles would be deemed insufficient.".--Fighterdoken 07:15, 28 May 2008 (UTC)

I think we can shorten the last sentence to something like "Bureaucrats are only allowed to block to stop major disruption."? poke | talk 10:54, 28 May 2008 (UTC)

I would prefer something generic along the lines of Poke's sentence, instead of the explicit list. In fact, I would be content without the "major." -- Brains12 \ talk 14:58, 28 May 2008 (UTC)

I specifically avoided the word "disruption" here, since trolling or non-sense posting (i.e. those done by Erf Shakur) would also fall into that category. My intention with this is to be as specific as possible to cover the concerns of those users who still complain, but if not possible (because of being "too wordy") then i would prefer to keep the draft as is right now.--Fighterdoken 17:44, 28 May 2008 (UTC)

How about "Bureaucrats are only allowed to block in emergencies, specifically editing that impairs the ability of users to access wiki content." That way, we avoid things like trolling, but include things like move bots, vandalism, spam bots, etc. I think we can make do without bureaucrats being able to block sockpuppets. (Aiiane - talk - contribs) 17:48, 28 May 2008 (UTC)

That seems better. Also, half of the sockpuppets would fall here since often they end just doing medium-vandalism, so that is a plus.--Fighterdoken 17:52, 28 May 2008 (UTC)

(edit conflict) Actually, Fighterdoken, this is why I used disruption there. I want to give bcrats the ability to block also trolls when first, no other sysop is around and second, it is real "major" disruption to the wiki (like RC full of those edits). Aiiane, that sentence fits quite well, but I would like to change the "to access wiki content" into something more general like "to use the wiki" or "specifically editing that impairs the normal flow of the wiki" (something like that :P) poke | talk 17:54, 28 May 2008 (UTC)

I'd prefer to keep it as is, for the following reason: I can see someone making a viable (maybe not correct, but viable) argument that trolling impairs people using the wiki (for instance, trolling policy discussions impairing the timely implementation of policy). Thus, I'd prefer to keep it in a more specific sense that applies directly to the cases in our minds right now, and can't be easily warped to something else. Thoughts? (Aiiane - talk - contribs) 17:59, 28 May 2008 (UTC)

(Edit conflict) Then we will have a problem, because "trolling" is a conflictive issue that ends sooner or later in the hand of bcrats (see: raptors). Allowing blocks under that ground is a bad idea, in my opinion.--Fighterdoken 18:00, 28 May 2008 (UTC)

So you would prefer having the RC full of troll edits because no admin is around and the sysops are not allowed to block the troll as long as it doesn't impar the ability of users to access wiki content? :/ In such cases I would prefer a short time block by a bcrat to save the wiki... poke | talk 18:06, 28 May 2008 (UTC)

What are "troll edits", poke? If they're on talk pages, the wiki doesn't need "saving". If they're on content pages, it's vandalism, which hinders the ability of people to access the actual content of the page. (Aiiane - talk - contribs) 18:07, 28 May 2008 (UTC)

(Edit conflict) I must admit that i fail to think of an example for such behavior, which may be the reason why i don't share your vision. Specially, since most "trolling" i remember is done in talk pages anyways with the blame being shared with other users feeding the troll (which usually means the user not obbeying, being banned, bypassing it, creating drama, and being sent to arbcomm for it).--Fighterdoken 18:11, 28 May 2008 (UTC)

(edit conflict) It doesn't matter to me where it happens and what exactly it is, but when RC is full of those unnededy edits, and a admin would already block that user - if one was around -, then I think a bcrat should be allowed to block as well, as it hinders people from using RC and I belive RC is an important thing when using the wiki on the community/contributor-side. poke | talk 18:14, 28 May 2008 (UTC)

There are times, where sysops are not around (see this night), and in such times, when there are persistent trolls spamming the whole RC full, then I think it should be stopped. Even if it stops those people only for a short time, but in that moment, they should be stopped, and when a sysop is online later, he can decide how to go on. poke | talk 18:14, 28 May 2008 (UTC)

btw. I don't hope/think this will ever be needed, but just in case ;) poke | talk 18:20, 28 May 2008 (UTC)

I don't think it's worth adding in to policy. If it really has to be done, it will be done regardless. (Aiiane - talk - contribs) 18:21, 28 May 2008 (UTC)

hm, ok then ^^ poke | talk 18:24, 28 May 2008 (UTC)

I'm going to preliminarily make this modification to the draft then. (Aiiane - talk - contribs) 18:26, 28 May 2008 (UTC)

I'm thinking of a slightly different wording. The part that contains "specifically editing", depending on how you read it, seems to mean something else. I'm thinking it might be better to replace "editing" with either "edits" or "situations". -- ab.er.rant 03:45, 29 May 2008 (UTC)

Or we could recognize that the policy means the same thing either way and stop arguing over pointless semantics. Lord Belar 03:49, 29 May 2008 (UTC)

It's not a problem. Wording tweaked, it is cleaner that way. (Aiiane - talk - contribs) 03:51, 29 May 2008 (UTC)

The wording of policies happens to be important, since it's meant to minimize the chance they get interpreted wrongly. I was more "commenting" than "arguing". Oops, "semantics" again. -- ab.er.rant 05:18, 29 May 2008 (UTC)

I've replaced "Bureaucrats are only allowed to block in emergencies, specifically for edits that impair the ability of users to access wiki content." with "Bureaucrats are only allowed to block in emergencies, specifically for edits that impair the ability of users to access wiki content, such as vandalism." for clarity. -- Gordon Ecker 06:33, 29 May 2008 (UTC)

I thought we didn't want to go with examples? I could see how this extra "clarity" could turn out being used as a "bureaucrats should only block for vandalism" kind of thing... -- Brains12 \ talk 12:14, 29 May 2008 (UTC)

As long as examples aren't what we're defining the scope by (and I think the current wording makes it fairly clear that's not what we're using for definition) it should be okay. (Aiiane - talk - contribs) 15:15, 29 May 2008 (UTC)

Statement from original author

I'm a bit confused because of this edit by Rezyk; It somehow seems as if he doesn't accept any change we made afterwards.. I would like to hear a statement on that. poke | talk 10:54, 28 May 2008 (UTC)

I'm just asserting that the older version is still on the table. Get a good clear consensus for some alternate version that makes that moot and I will be glad. --Rezyk 03:47, 31 May 2008 (UTC)

Pending Implementation

I'm going to continue bumping this page a couple of times a day for the next day or two, but unless someone has raised a non-trivial issue by the end of May 31st (UTC) I'm going to implement this as an accepted policy modification. Please if you have any remaining issues add them above. :) (Aiiane - talk - contribs) 15:45, 30 May 2008 (UTC)

Since there has not been any objection raised for at least the past few days, and most objections had already been worked out prior, I will be implementing this in a few hours. If someone else wants to first, go for it. (Aiiane - talk - contribs) 01:43, 1 June 2008 (UTC)

Made live. (Aiiane - talk - contribs) 03:58, 1 June 2008 (UTC)