UDWiki talk:Administration/Policy Discussion/Re-Evaluating Re-Evaluations and Other Sysopness
A/RE
I'm a fan of "no more automatic A/REs" #2 ("Only do A/RE when community calls for it.") in principle, but it's a little undefined. Who's allowed to trigger an A/RE? Other sysops? Crats only? Any community member?
I've also added another option there (now #3 "Only do A/RE when the sysop submits themself for it.") because I've seen that proposed before, and would also be in support of that as an option. I'm not a fan of #1 (maybe if misconduct is found, rather than the case appearing?) and #4 seems pretty redundant if they'll be demoted for it soon anyway (plus sops should be able to comment on their own A/REs). Bob Moncrief EBD•W! 00:10, 6 November 2015 (UTC)
Personally, I lean more towards a combination of a few of the stated ideas, namely, I think that an A/RE for a particular sysop should happen at anyone's request so long as ANY of the following is true:
- It's been more than X months since the sysop's last A/RE
- The sysop falls under the Truly Inactive Sysop policy
- The sysop has been found guilty of misconduct
- The sysop is the user requesting it
Basically, if no one sees a point in one, we won't have one, but whenever something happens (or doesn't happen) that would warrant a discussion regarding that sysop, we give people the ability to initiate one then. And yes, it may result in snap A/RE proceedings in response to things that sysops do that are unpopular, but, frankly, I'm okay with giving the wiki community a greater ability to influence our tenures as sysops. Plus, the final say still falls on the 'crats, so we have a moderating influence in place to ensure things don't get too out of hand. —Aichon— 00:33, 6 November 2015 (UTC)
- A/RE should *NOT* be called after a sysop is found guilty of misconduct, at least not right after it. Its really easy for everybody to just focus on the misconduct case and not on what the psyop has done so far for the wiki.
- My take on A/RE is simple, "if it's been more than 6 months since the sysop last A/RE, any user can request a new re-evaluation of the sysop", "can" being a really strong word here, not to be confused with "should"
- Also, scrap the 'trully inactive sysop policy'. It serves no purpose for a low traffic wiki. --hagnat 12:46, 6 November 2015 (UTC)
- The truly inactive policy has already served us well a few times, last time when Bob suddenly vanished off the surface of the earth and I was the only crat still around it. Why sacrifice a contingency plan, especially when it is trivially easy to fulfill? -- Spiderzed▋ 13:06, 6 November 2015 (UTC)
- crat work (heh, kraftwerk) is different than psyop work. The impact an inactive crat has in the community is different than a psyop. An inactive crat should be demoted back to sysop, while an inactive sysop can remain as is indefinitely. --hagnat 15:25, 6 November 2015 (UTC)
- The truly inactive policy has already served us well a few times, last time when Bob suddenly vanished off the surface of the earth and I was the only crat still around it. Why sacrifice a contingency plan, especially when it is trivially easy to fulfill? -- Spiderzed▋ 13:06, 6 November 2015 (UTC)
I would think making it: "A/RE should occur when necessary. A sysop must determine if A/RE is justified, but any user can request it. Requests should include justification." would be fine. --KCLZANecroConnect 08:10, 8 November 2015 (UTC)
A/BP
Regarding A/BP, I think changes to it are less urgent than to A/RE, but in general I'm in favor of the standard twice-yearly elections proposed by SZ on the A/RE discussion. I'd vote no to anything creating more than two bureaucrats at once unless someone manages to convince me. Bob Moncrief EBD•W! 00:13, 6 November 2015 (UTC)
- I'm against the "every sysop is a 'crat" idea, but I'm okay with the idea of making more 'crats, for the simple reason that it ensures we have a 'crat around when we need one. That may be less pressing if we're reducing the frequency of A/RE proceedings, however, but I still see it as being a benefit worth having. That said, I'm okay with keeping just two as well. I won't really fight either way on this one, so long as it's not the "every sysop" idea, since that one is way too dangerous. —Aichon— 00:36, 6 November 2015 (UTC)
- What about having three crats ? Have a single, yearly election among all psyops and pass the stick around. Three crats ensure that a) if there is a tie between two crats, a third one will untie it b) serves as security in case one of the crats becomes inactive --hagnat 12:51, 6 November 2015 (UTC)
Thoughts
Annually review all sops on UD's birthday. Vote for both crat seats at the same time every six months. Leave to stand for 3 minutes, stir then reheat for 2 minutes. Serve. --RosslessnessWant to complete a dangerous mission? 19:54, 6 November 2015 (UTC)
- This seems the simplest suggestion so far. -- AHLGTG THE END IS NIGH! 04:41, 7 November 2015 (UTC)
- I'm a fan. +1 Bob Moncrief EBD•W! 06:48, 7 November 2015 (UTC)
- Oh god. If there's something I could imagine would be more pointless than having our current 8 month A/REs, it's having 10 at a time where everyone just says "varch" and makes shitty jokes on every one. Yet I agree, this is probably the best suggestion so far, sadly. A ZOMBIE ANT 11:14, 7 November 2015 (UTC)
- It wouldn't work without you making those shitty jokes DDR. That's why I love you so much. --RosslessnessWant to complete a dangerous mission? 00:58, 8 November 2015 (UTC)
Voting
Are you all comfortable with me putting some content up that could be voted on soon (particular Ross' suggestion)? Should we vote on one option or should I let you choose between a few? -- AHLGTG THE END IS NIGH! 22:07, 10 November 2015 (UTC)
- Yes, and I think policy rules require one option to be voted on (unless submitted as separate policy proposals). Bob Moncrief EBD•W! 02:18, 11 November 2015 (UTC)
- It's actually been done before, and failed for different reasons. I'll put up what I think is the favoured option, and let things sit for a little while before a vote. -- AHLGTG THE END IS NIGH! 14:41, 11 November 2015 (UTC)
Single Evaluation / Crat Promotion
Here is another take. We re-evaluate every sysops on UD's bday AND we vote for who to promote to crat. Users will be given three options
- Yes to maintain the user as a sysop
- No to demote him
- Promote to promote the user further, to bureaucrat
Any sysop with more than X promote votes is cratified. --hagnat 15:30, 11 November 2015 (UTC)
One week A/RE + UD's birthday = problems
UD's birthday is one day before Independence Day (4th of July) in the US, which is a major national holiday. A lot of (northern hemisphere) folks are already traveling around that time of year because they're on summer vacation, and even more Americans are traveling that particular week than during the rest of the summer, simply because they're going to visit friends and family for the holiday. Especially if we're doing all of the sysops at once, we want to make sure that people have a chance to chime in, so might I suggest that if we do them all at once on that date, we also bump A/RE up to a two-week process instead of a one-week process? After all, it's already the only one-week thing we have around here, and there have been calls in the past to bump it up to two weeks anyway. Seems like a good time to do so. —Aichon— 17:03, 11 November 2015 (UTC)
- hear, hear! --hagnat 19:07, 11 November 2015 (UTC)
Passed: List of changes made
This policy has passed. Congratulations to all!
That said, I have gone through and made changes to several pages where the new procedures are relevant. These changes are more extensive than a simple text change on a single page, so I have illuminated them further below. Please comment here or on the relevant talk pages where possible. Thanks!
- I have added or altered notices to the three policies which are affected by this change: 1, 2, 3.
- I have made several changes to the A/BP intro text. Key changes include:
- Replacing scheduling procedures per this policy.
- Altered voting procedures non-explicity changed by this policy. The relevant points are 1) the first- and second-place candidates are elected; 2) because "All users have only one vote per bureaucrat position to be filled", this means that in regularly-scheduled elections, each user can cast two votes.
- I have made several changes to the A/RE intro text. Key changes include:
- Replacing scheduling procedures per this policy.
- Altering comment duration from one to two weeks per this policy.
- I have changed the Sysop Check template & associated text, paring out the "Last Evaluation" and "Next Evaluation" columns as irrelevant, and adding a notice to that effect. See the discussion on the Sysop Check talk page.
- I have added a clarifying line to the Demotions procedures clarifying what happens if a Bureaucrat is demoted for inactivity.
My largest area concern is on the A/BP procedures, section 1 point 5:
[[User:"In the event of a tied vote the remaining bureaucrats will decide between the tied candidates." 1|"In the event of a tied vote the remaining bureaucrats will decide between the tied candidates." 1]] said: |
{{{2}}} |
It was not decided how this point now operates. In the event of a two-way tie for second place, does the other newly-elected bureaucrat choose, or do the outgoing bureaucrats? What about in the case of a three-way tie for first place?
Thank you so much, and if I've missed anything, please let me know! Bob Moncrief EBD•W! 17:37, 29 November 2015 (UTC)
- why not have another vote? A ZOMBIE ANT 19:03, 29 November 2015 (UTC)
- In the event of a tie for the most votes, then those two sysops will just become 'crats. Two-way tie for second place, or three-way, then I'd say the outgoing (both) 'crats would break the tie (unless, er, both outgoing 'crats are tied between breaking the tie). Or maybe just the sysop that's in first place breaks tie? Okay, but if two/three-way tie between first-place... then I don't know. If one 'crat goes inactive or resigns, then the other 'crat decides between ties. Maybe? Yeah, actually maybe another 3-day, (or maybe 5-day, 7-day) vote to break tie? -- AHLGTG THE END IS NIGH! 19:24, 29 November 2015 (UTC)