Howdy wiki folks. I figure that this blog will mean absolutely nothing to those who aren't frequent Wiki editors, but for those who are, I wanted to go into some detail about a proposal I made on the 'Addressing issues with rights requests' forum thread. Below is the current text of the proposal (as of June 5, 2013)
- Stage 1 - Nomination/Application
- Users may nominate themselves or be nominated by another user for administratorship. The nominee then has to accept the nomination before discussion can begin.
- If the nominee accepts the nomination, they should also choose two Administrative projects when stating their acceptance.
- After a user applies or accepts a nomination, a bureaucrat should determine whether the user is eligible to apply. If they are eligible, the bureaucrat should initiate a period of discussion.
- Stage 2 - Discussion
- A period of discussion shall last at least five days.
- After the five day period of discussion has elapsed, it shall be determined whether a consensus has been reached. Consensus can only be reached in favor of a nominee, not in opposition to them. If the discussion shows consensus for a nominee, the nomination is successful and the user is promoted. If the discussion clearly shows a lack of consensus, the nomination will be ended and the nominee will not be promoted.
- In cases where a consensus is not clear after the initial discussion period, discussion will continue until there is a two-day long period, or longer, in which nothing is added to the discussion.
- If this occurs and a clear consensus exists, the nomination is successful and the user is promoted.
- If this occurs and a consensus in support is not clear, the nomination will proceed to Stage 3.
- If discussion continues for ten or more days, and it is determined by ay least two bureaucrats that progress towards consensus is not occurring, the nomination will proceed to Stage 3.
- Stage 3 - Voting
- Voting is to be used as a last resort to resolve a contested request. Voting shall take place only after Stages 1 and 2 are observed properly.
- Votes may not be accompanied by any argument for or against the nominee - they must be strictly support or oppose votes. There shall be no neutral votes, but users may abstain from voting.
- The voting period shall last seven days. A 2/3rds majority in support is required for a nomination to pass.
- A nominee may choose to terminate their nomination within two days of a nomination reaching this stage; the nominee will receive no penalty for doing so. After that period, normal penalties apply.
- Other rules
- A nominee whose nomination does not lead to a consensus for promotion will not be eligible to be nominated or to request for thirty days.
- A nominee may end a nomination at any time. A nominee that terminates a nomination will not be eligible to be nominated or to request for fifteen days.
- A nominee who has had three failed nominations within any six-month period will be ineligible to be nominated or to request rights for three months, starting at the end of their third failed nomination.
- A nominee who applies for rights and who is ineligible will be automatically denied, and will be ineligible to request rights or to be nominated for an additional fifteen days, beginning after they would have otherwise become eligible. Nominations of ineligible nominees by other users will not result in a penalty against the nominee.
- Guidelines for discussion and consensus
- Points of discussion should be focused on assessing the ability of a nominee to perform their duties. Discussion should avoid sweeping praise or generalizations (e.g. "he/she is a good editor" or "he/she deserves it"), and focus instead on specific reasons why a user is or is not a good fit for the position.
- Users engaged in discussion may contradict the points raised by another user, but should remain respectful at all times. Back-and-forth arguments between two users should be avoided.
- Generally, consensus in a request can be determined by answering these questions:
- Are there major and specific problems raised by multiple users regarding the nominee?
- Is there a lack of agreement between users over whether a nominee is qualified, capable of serving or a good fit for the role?
- If the answer to these questions is 'no', there likely exists a consensus for the nomination.
- Alright, first thing's first - why is this necessary?
Well, I think it's pretty clear to most everyone who witnessed a recent RfA that we need some overhaul to how those requests work. Since we as a community have adopted the standard of seeking consensus, it only stands to reason that we would create an RfA system that embodies that ideal - namely, a system where consensus is built around strong ideas of support for a person, rather than strictly the number of votes they get. So the system I've proposed eliminates voting in favor of a discussion, with the goal being that that discussion leads to a consensus among the participants.
- Why do you have minimum and maximum times specified?
Discussions on The Sims Wiki sometimes have a habit of wrapping up very quickly, while others tend to drag on for weeks or months before reaching a resolution, if they do at all. I've established both a minimum time (5 days) and a maximum time (10 days before a vote) to ensure that the discussion is long enough to allow everyone a chance to participate, while not so long that the discussion dies out.
- Why do you have a voting system? I thought you were against voting.
I don't prefer a voting system to a comment and consensus system. But, including a fall-back voting system is a realistic step, since it's likely that consensus will not develop in 100% of RfAs and RfBs. It's not rational to shut down a request simply because they didn't get crystal clear support, and not having a system to handle these "contested" requests would put the decision of whether or not to determine consensus back into the hands of bureaucrats... which is an awkward position to be in, especially if the bureaucrats weighed in on the nomination.
The additional requirement that votes be up-or-down is meant to further avoid situations where a bureaucrat would be put in the position of nullifying votes without strong supporting arguments. By removing the "strength of argument" issue, it puts all votes on equal footing and enables a clearer count, if voting should be necessary.
- What are the ineligibility penalties for?
Every so often, users will put in an RfA or RfB request that is very obviously going to be denied... at least, it's obvious to everyone but the requester. This isn't a bad faith action on their part usually, but they are not fully understanding of what exactly an RfA or RfB entails and just how much a part of the wiki they need to be before making one. When invariably they run into resistance, their default reaction is often to withdraw their request, thus sparing them the experience of having their request denied or voted down. In the process, they essentially appear to be trying to wipe the slate clean, so they can shortly thereafter re-request without having to explain why they had been denied before.
The ineligibility periods are meant to prevent this. They establish that users who have unsuccessful nominations cannot re-apply or be re-nominated for set durations. This is to prevent an unsuccessful requester from instantly re-requesting, either to hold up the process or because they weren't happy with the result. Additionally, there is an ineligibility penalty for people who withdraw their request, to prevent them from re-applying soon afterwards. These are all in place to encourage a user to complete the requests they start, and to accept the community decisions in those requests.
I'll be happy to answer any questions about the proposal or the points I've mentioned above. Just leave any questions in the comments.
-- LostInRiverview talk ~ blog 04:37, June 5, 2013 (UTC)