Forum:Addressing issues with rights requests

Please forgive me if I don't write an incredibly long wall of text about the recent issues we've encountered with requests for rights (i.e. TSW:RFA and TSW:RFB). I doubt I need to rehash the cluster-you-know-what we just experienced with the most recent request, and I don't want to turn this thread into a place to complain about the opinions of others in that RfA. This is the place to solve the obviously flawed RfA and RfB system. Because there are a couple things which are broken, clearly.

I would like everyone to use this thread for several goals. I would like us all to come to some general agreement on how we want to determine consensus on Requests going forward. Whether this means we stick to the idea of counting support versus opposition votes, or whether this means we somehow objectively weigh each vote on the merits of its arguments, I don't know. If we decide to stick with voting, then we should at the very least come to an agreement on whether or not votes can be struck out, and on what grounds, and following which procedures. We should also determine what margin of support needs to be attained before a request can be successful. This is going to be a difficult matter to solve, so I emphasize patience and creative ideas.

Aside from the major job of sorting out consensus, there are a few simpler fixes I think we could implement. First, I think we should add a rule on RfAs limiting them to one request at a time. This rule currently exists on RfBs, but not RfAs, I think it should be implemented on RfAs too.

Second, I think the whole process might go smoother if we implement some sort of commentary period before the clock on voting begins. To those who think that the RfA process as it is is already too slow... I believe that having a period to work out issues with a candidate before the voting begins might be able to alleviate a lot of the problems that have come up. Here's what I'm thinking:

After an RfA or RfB passes the initial nomination/request stage, the bureaucrat facilitating the discussion opens a period for public comment. This would be a time where regular users can ask the candidate questions, give input on matters and give their general opinion, but not vote. My thinking is that this period would last a week, but that the Request would progress to a vote if no user leaves a comment for at least two days. This gives the option for users to weigh in before a vote, but also ensures that a vote begins if no one really wishes to comment. This would also make it possible to determine if there was overwhelming consensus for a user before the voting even begins... in such a case, voting could be skipped entirely as it wouldn't be necessary, though this should only really happen if support for a candidate is unanimous in the comment phase.

I think having a comment period would also alleviate the issues raised with possible "weak" votes of support or opposition, since the arguments for or against a candidate could be fully flushed out without them necessarily needing to carry any weight as a vote.

Finally, on a more urgent note, I believe that we should temporarily suspend Requests for Administratorship and Requests for Bureaucratship, effective immediately. I think we can all agree that there are several issues with the system as-is, and we owe it to ourselves and to potential applicants/nominees to solve the issues before new Requests are heard. Therefore I am immediately asking for feedback on whether RfAs and RfBs should be closed. Please let me know your thoughts on that matter, on anything else I've mentioned, or on anything relevant that you'd like to discuss.

--  LostInRiverview talk ~ blog 06:33, May 10, 2013 (UTC)

Discussion
Okay, I have put some major thought into my opinion and have, at the best of my ability, tryed to word it properly so you can all understand it. Firstly, I agree with adding the rule to rfa. One request is hard enough, but having two requests? That will just confuse others and it will muck up the system. Also, I think that you should consider adding another rule into the rfa. It appears in most of the supporting votes of a a most recently closed rfa that the point "x deserves this because..." appeared. I have to say, if I am being honest and I am always honest, that this is a pointless point. One doesn't deserve admin rights, the role of administrator doesn't come naturally to a user, you only become an administrator if the community agrees and states clearly why the user should have the role of administrator. Secondly, I am all for the commenting period of rfas before the voting period began. This way, if bureaucrats, admins or any other users have questions then the applicant/nominee can have the chance to answer the questions in a controlled environment without having the pressure of their request going into a vote without proper discussion. But, I think a week is too long, I was thinking of a time period around 2-4 days, but again that is my own personal opinion. The time period, if this was implemented, should be up to the bureaucrats and admins. And thirdly, you should highly consider suspending Requests for Administratorship and Requests for Bureaucratship, but just for temporarily. However, this may cause a problem if a user planning on apply for the role of admin, then the request page could be flooded with admin requests. Although, this can be avoided if the rule of one request at a time is implemented.

I do expect my opinion on this matter to have some controversy against it as I have mentioned my own rfa request in a point somewhere up above. I also can't help but feel personally responsible for this thread and another thread being created. I just wanted my point to be put across to the community as I feel very highly about the rfa page. I hope that this point (and the point above) won't be read as in a selfish way, as that is the last thing I am. I just feel that these rules should have been implemented a little while ago. HanaGoth96 ( Neigh...? ) 07:35, May 10, 2013 (UTC)
 * Don't put yourself down over that, I've personally had concerns about reasoning for a while. Your RfA might have been what instigated that thread but not you in general. 11:41, May 10, 2013 (UTC)
 * You aren't responsible for what happened, as Lab said. A lot of these issues have been under the surface for awhile, and while they cropped up during your RfA, they could have easily come up during someone else's RfA or RfB. --  LostInRiverview talk ~ blog 13:21, May 10, 2013 (UTC)

This is going to show as a very difficult issue for the community to dissect but I'll try my best to put my views across.

Currently, the RfA page states that:

"Strength of argument is more important than the number of votes."

By this extension it would seem right to abide by this by emphasising reasoning in the voting process and ultimately have RfA mediated by a neutral bureaucrat. I'd say for an RfA/B to pass, we stick with between 66% (two-thirds) to maybe 70% of the support vote is needed.

As for the striking issue, and I really hope this is the absolute last time I have to explain this, that particular vote was striked because it was genuinely a rude comment to not just the nominee (who ironically the vote was supporting) but the community in general and had conflicted with general wiki policies. I'll admit I felt conflicted by my actions but the argument stands that reasoning used that can be taken negatively by other users on personal grounds is  absolutely  not allowed and must stop.

As for striking in general, the issue is that striking a vote could be seen as an attempt to shift consensus from one side to another unless it's applied very carefully. If a neutral bureaucrat is mediating the RfA once the voting period is up then it's their job to determine whether an argument is valid or not. Unless an argument in general is proven as completely false (like saying "user X does absolutely nothing so they shouldn't be admin" when they actually do a lot), seen as demeaning in one way or another or if it has absolutely nothing to do with the RfA/RfB then striking would be pointless.

As for the proposed commentary period. I'm indifferent. I can see how it may ease the process based on past events but I somewhat question the neccessity as one could easily oppose User X for something that they did/should have made a comment on during the commentary process only to no avail, which could effectively make things more heated.

To end my tl;dr paragraph, I support temporarily suspending RfA/RfB and I support the "one at a time" rule being adopted on RfA as it works so well for RfB. If I think of anything else I'd like to place on the table, I'll drop by later. 11:41, May 10, 2013 (UTC)

Information: RfA and RfB pages have been closed and locked, pending the outcome of these discussions. --  LostInRiverview talk ~ blog 22:43, May 10, 2013 (UTC)

I know this steers away from (part of) the original proposal a little bit but I've noticed some wikis put RfA/RfB nominations onto their own subpage, which makes things less cluttered, allows for more focused and straightforward discussion on a specific RfX (including a dedicated comments section) and ultimately eases workflow enough that we could allow multiple RfX nominations at a time if we wanted to (one could argue it's like the Forum to our CPTP). With this, I'm wondering if the community at large would be interested in this at all. Note that at this point, this doesn't contradict my above support for the one nom at a time regulation, I'm just putting this across as a potential alternative and to see what other's think. 22:01, May 13, 2013 (UTC)
 * I considered suggesting that, but I didn't want to put forward too many changes at one time. I support the idea, however. --  LostInRiverview talk ~ blog 22:08, May 13, 2013 (UTC)

Okay, this is going to be another wall of text, because I think there are a few things I need to say about this process. I've been mulling over my thoughts for the past couple days, and I hope that I can state them here in some degree of clarity. Don't expect me to give you a tl;dr at the end... I don't know if I can summarize my concerns or ideas.

First, to resolve the issue of the striking vote - I want to make it clear that my suggesting it here is not a response to Lost Labyrinth's striking of Auror's vote per se, though that action does spur the discussion. The idea of whether LL was justified in striking the vote is actually not relevant, so I chose not to get into reasoning the first time I mentioned it. I was hoping that it wouldn't be brought up here since I agree, it is best left in the past. However, what should be discussed, and what has been I think the elephant in the room has been a discussion of, essentially, who is allowed to strike out votes, under what circumstances, and for what reasons. Again, this has nothing to do with LL's choice to strike out Auror's vote in the particular RfA, but that action (even though it was reversed) does spur a discussion of whether or not actions similar to it should be allowed. But, I believe this whole issue should be a moot point, for reasons which will be clear soon.

There's the concept of strength of argument in a vote, versus simply taking a count of those in favor and opposed. The RfA page does stipulate that at least a 2/3rds majority must support a candidate, but that does not even begin to consider whether the arguments from those supporters are anything more substantive than 'they deserve it' or 'they are a good editor'. This again brings up the sticky wicket of striking out votes, because ultimately someone needs to decide whether some particular argument really is strong enough to justify accepting the vote that is cast.

It occurs to me that no one so far has really been able to solve the issue of relevant versus irrelevant votes. For all the other fixes we can put into place - limiting nominations to one at a time, having nominations on a separate page, having a comments period - none of these address one of the core flaws of the RfA itself. Voting is a flawed system.

Here's the real dilemma. We want a system that reaches a quick and relatively clear result. Our history of trying to find consensus usually is a weird blend of votes and deliberation, with the weight of these experiences being more towards these being votes - we divide ourselves along support/oppose boundaries, we count those persons who support or oppose and tally them up. Straight voting like this would work as a system, if we were not dedicated to also achieving a consensus. That drive towards reaching a consensus muddles the process, since we now need to show that the community in general agrees with an idea or a proposal or, in these situations, a nominee. It's very hard to demonstrate that when you have simply a list of Yes and No.

This problem is further exacerbated by the fact that we don't have a period of discussion, a period of insight into a nominee, or a time where we, the community, can weigh in on a person without it being recorded as a 'support' or 'oppose'. We really need this. Discussions, however, tend to take a long time and usually don't yield a clear outcome. And, by the time some people have had a chance to weigh in and give strong reasons behind their thoughts, other people have become bored and wandered off, and we lose that voice in the discussion.

How on earth do we fix this? I think the best place to start would be to abolish voting on RfAs and RfBs. Yes, you read that correctly. Voting is a divisive system that, by its very nature, destroys any meaningful consensus we could develop. The manner in which we've adapted voting to fit the needs of an RfA or RfB are severely lacking as well, since there's no reasonable way to strike out votes or to monitor the contents of a vote to ensure strength of argument. The only sure-fire way we have to get a consensus on a person is to discuss them, to fully air any issues we may have with them, and get everyone into some general agreement.

Now, it's very difficult to put what I've just suggested into practice, but for the sake of clarity, I'm going to try. What I have drafted below would be an implementation of what I've just described above. Don't think of it as a formal proposal, but rather as a jumping-off point to reaching some kind of agreement on how these issues are handled.


 * 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 a consensus still does not exist, the nomination will be ended and the user will not be promoted.
 * 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 be ended and the nominee will not be promoted.


 * 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.

As I stipulated above, this is an idea. Please do keep an open mind and consider the potential in this idea.

I want to stress, before I wrap this up at long last, that voting as a means to determine consensus is a flawed system, as it neither reaches a consensus or adequately serves as a voting mechanism. We try to do two distinct things with the system we have in place now - we try to build agreement between users, while simultaneously trying to count votes. This is not possible, especially if the issues are complex and emotions are running high. If we choose not to go with a solution like the one I've outlined above, then I must insist that we completely drop any pretense of consensus in RfAs or RfBs, and instead transition to a strict voting system, where candidates get only a yes or a no vote and there is no such thing as 'strength of argument'. We can't have both, we can only have one or the other. I think, I hope, and I believe that we want a system of consensus, not simply a manner for voting. If that is the case, we must replace the current RfA and RfB framework. That is the cold hard truth.

-  LostInRiverview talk ~ blog 06:09, May 14, 2013 (UTC)
 * I'll try and keep this short. I see where your coming from with your argument and the only simple solution does, at this stage, seem to be a case of "option A or option B". Will this idea actually work? From experience, I'd actually lean towards this being a case of us having actually implemented it, whether it's for just a trial period (which in actuality is pretty hard to do with an RfX considering how dynamic any system would be with this) or indefinitely, before we know for sure whether it's good for us or not. I'd like to keep an open mind about this, considering our problem and that we need a solution, but I'd also need the community's thoughts on this too (note that I've already sent an automated message and put a link to this in the community corner...to little avail :/) before we get anywhere. So far it does look like RfA/B is getting a major overhaul, pending the rest of the community pitching in... 20:16, May 14, 2013 (UTC)
 * The discussion period is still a bit like voting though, isn't it? As in voting, it is basically just a way of showing your support for or opposition of a candidate's nomination. I know it might not be accepted, but what if (and this is only a suggestion) the nominee has to either (a) nominate themselves or (b) be nominated by an admin or bureaucrat who thinks they are ready for it. Being nominated by your ordinary user isn't necessarily a bad thing, but when they just say "Oh, User X is my friend and they are really nice. They should be a sysop/crat" is just them saying they like the person. I'm not saying it has to be that every nomination like this is auto-declined, but it could be something to think about. If a user puts up a good argument, then take the nomination into consideration maybe...? This is only a suggestion.


 * Now, if User X was nominated by an Admin or Bureaucrat who thinks they are ready to take on the task, or even a user who is trusted (if they so choose to nominate someone), it might be a bit easier because this is coming from someone who already possesses the tool, and from their experience with it, something that other users don't have in their belts, they can deem someone ready to take on the task.


 * Also, I might suggest that the nomination should be allowed to be voted upon, but only by admins and bureaucrats. They each have experience with the tool and can decide if they think User X is ready to take on such a task. 21:57, May 18, 2013 (UTC)
 * The general direction that RfAs and RfBs has taken throughout the wiki's history has been towards more "regular" user (i.e. not admin/bureaucrat) involvement. Back when I first applied for Administrator, the requests were simply approved or denied by a bureaucrat. Over time, users would weigh in (informally) on requests and help the bureaucrats make the decisions, then eventually it transitioned into the voting system where action isn't taken until the community consents to it.
 * The reason I bring this up is because implementing your idea of limiting voting to admins/bureaucrats only runs contrary to this pattern, and it's simply not something I could support. I think it's important that we keep these decisions community-focused, and making it admin-only voting detracts from that.
 * I'm also not crazy about the idea of limiting nominations. My main concerns are that a self-nomination could potentially be viewed as less "worthy" of adminship, since 'a user with admin potential would obviously be nominated by an admin if they really had any potential,' or similar thoughts. An additional concern is whether nominees brought forward by admins might be viewed through the lens of 'oh, the admins support them, so I should too.' We've seen this style of thinking broken on a few occasions, so this is a secondary concern of mine.
 * To back-track to your point on whether the comment period is essentially voting... it really isn't. Voting, as is currently implemented, goes through the list of posts made by users and adds up the number of VoteFor versus the number of VoteAgainst and determines the consensus based on the vote totals, augmented with the "strength of argument." In a lot of cases, this system works just fine for the needs of the wiki. However, sometimes there is a disagreement over whether an argument is well-suited for supporting the vote it accompanies, or whether a vote should be counted with more "weight" based proportionally on the strength of the argument that accompanies it. Commenting, on the other hand, allows a discourse to develop without focusing on how many "Supports" versus "Opposes" a candidate has. There is no counting and no question of 'strength of argument' because those concepts are completely absent from a consensus-based system, as I've outlined above. --  LostInRiverview talk ~ blog 05:48, May 19, 2013 (UTC)
 * I know it's another issue entirely but as it was brought up, I may as well say it. Self nominating is usually meant to be a sign that the candidate has high self esteem, which is actually a very good thing for an admin to have, and that the candidate is confident about what they're doing. It's never usually an issue on its own but the only way a self-nom can be seen as "less worthy" is if the candidate has been bragging over-the-top about it (aka a rarity here) or down to misinformation about how the nomination process should be viewed.


 * Oh and based on the concern that "if an admin thinks they're good enough then they must be", that can basically be seen as the fact that "admins are users too" is being thrown out the window. Like every other user on the wiki, admins are imperfect and they can make mistakes. Basically if the argument made by the nominator, administrator or not, is sound for the nominee to be considered for admin/bureaucrat then I don't see a problem with whoever nominates who.


 * As for the suggestion itself, I can see how it would limit drama but if we went that route then it would also mean that we are limiting the ability for the community at-large to have their say, which contradicts the idea of community consensus, whether that be a voting or commenting system.


 * At this stage, it appears that the issues lie with a mixture of a flawed RfX system, misbeliefs about the process amongst a few other things. Currently all we have is ideas with no clear indication of what direction we want to go with this (admittedly it's hard to get anywhere when only 4 users have bothered to weigh in since this was put up 9 days ago). I do hope we can at least get a breakeven/compromise from this but regardless of whether we majorly revamp the RfX process or not, change is clearly needed. 10:08, May 19, 2013 (UTC)

Shifting gears
Okay, so, this thread has gone un-commented for a week and even then, discussion was still slow. Seeing as all the controversy from that particular RfA has blown over, now would be a good time to discuss this in-depth. I'm going to list some of the ideas suggested and using this section, users can express their views on them. The ideas are as follows:
 * Limiting to one RfA at a time.
 * A commentary period before voting takes place.
 * Changing the way votes are counted with further emphasis on reasoning.
 * Adopting a system where RfA/RfB nominations are placed as individual subpages (would render the first bullet point as potentially unnecessary if we went this route).
 * Replacing voting with a commenting system (would render points #2 and #3 redundant).

Note that these are just ideas at this point, not proposals. I've noted where one idea may contradict another as a means of aiding the thoughts of the community. Everything above this section is probably worth reading as it does argue in relation to these points.

I'd like to emphasise that whether we completely overhaul the RfX system in its entirety or merely implement just one of these ideas, it's pretty obvious that a change is long overdue. Like an RfA, this discussion won't get anywhere without the community having their say and we need the community at-large to get involved with this as this is a very important discussion and this isn't one of those threads that we can afford to conclude with no consensus on the basis of being dead. 09:53, May 28, 2013 (UTC)
 * I have been watching this thread in the shadows since posting my thoughts on the matter so I could assess what has been said and have noted some of the points that I think should be implemented. I agree that there should only be one rfa at a time, as this could make the requests page less cluttered and make it look more in a controlled environment. I am going to disagree with the next three points due to my full support for the last point. I have recently had a change of heart on the voting point in my last paragraph of text. Voting on either of the requests page has clearly been broken in some ways, therefore it would probably be a better idea to implement the commenting period instead and scraping the voting completely. Although, this is just my opinion on what Lab has said, I'm just going to go back into the shadows of this thread and hope that the community will voice their own opinions on what has been said. Beds (parlare - da leggere ) 10:14, May 28, 2013 (UTC)

As the person that proposed the 'commenting instead of voting' system above, I'm obviously in support of the fifth point listed above. I give extensive reasoning for this in my initial write-up, so I'm not going to copy it here. As for holding individual RfA/B nominations on separate pages, I think it's a good idea. If we do go that route, I can see a lot less of a problem in running two or more requests simultaneously. --  LostInRiverview talk ~ blog 14:54, May 28, 2013 (UTC)

I have been watching this forum for awhile now. I agree with Hana that there should only be one rfa at a time. It makes the page much tidier and neater and it would work better. I totally approve of the fifth point. It would also make the page tidier too. On my wiki we follow the same rule so that we can understand the requests because sometimes large sentences can be hard to understand. (well this is only my point of view) So to conclude my point of view I think that there should only be one rfa at a time. Jason034 message wall • blog 13:07, May 30, 2013 (UTC)

Edit: I've just read the fifth point and it is different to what I thought: bullet point you request. Jason034 message wall • blog 19:31, May 30, 2013 (UTC)
 * Bullet point #5 wouldn't necessarily be a major cosmetic change if we went that route, just a change in the RfA system and structure. 13:12, May 31, 2013 (UTC)
 * I agree with bullets #2 and #4 whilst I disagree with #1, #3, and #5. I see no sufficient reason to limit the "Rfa" to a single user. That would subsequently cause delay in action when concerning user rights. Changing the way votes are counted because of individual description and reasoning is (from perspective) biased. What could be adequate reasoning for a particular vote might be insufficient (from another perspective). For the last bullet; No, no, and no. There is absolutely no need to remove the voting system. I'm indifferent to changing the way votes are measured, but the voting system should not be removed altogether. Ѧüя◎ґ (talk) 02:44, June 4, 2013 (UTC)
 * Auror has a point in saying that limiting the RfX to only one would slow down the process of discerning between who does or does not deserve rights, but limiting it to one allows for a neater page and I think it's a very rare occurrence for there to be more than one at a time. I am was indifferent to the commentary period, but I think it is a much better alternative to the voting system altogether, actually. You count votes, but you don't count comments that make no sense, which actually is very clear to me. So, you know what, I'm gonna support Bullet #5. I really have no preference on making a subpage for each of the Requests, because I see how it could tidy things up a bit and keep it all in one place, but it could also get a bit confusing. But commentary = win. 03:08, June 4, 2013 (UTC)
 * I for one agree primarily with #2, but disagree with the rest. As for #3, however, I do have an alternate suggestion: Have the RfA be a debate-style system in which the users votes for the superior argument, meaning this will eliminate the "user deserves it" without discarding the vote system which I think should stay as a whole, as the others who support the nomination could vote for the argument to show their favor. Probably will be impossible to implement, so disregard my idea.  MILK FOR THE UNYUUFEX, FLAT CHEST FOR THE CUTENESS THRONE, SKULLS FOR THE SKULL PROBES (user talk:Mathetesalexandrou) 03:11, June 4, 2013 (UTC)
 * For what it's worth, the idea you crossed out wouldn't be impossible to implement IMO. I don't necessarily support that approach, but it could be done. --  LostInRiverview talk ~ blog 03:18, June 4, 2013 (UTC)

Having watched this thread the past week, it appears that the idea of having requests/nominations on subpages (with the main RfA page being more of a hub which lists the current RfAs) has been well received, but I also see a mixed response to everything else, with some supporting the idea of a commenting system but not others and the same case applies to the commentary period, as well as the one RfA at a time idea, even with regards to the individual subpages suggestion. It seems clear enough to me that there is a general agreement that the RfX process could do with being more discussion-based. Given some of the arguments here, finding a suitable compromise does seem difficult but I am open to that idea based on what we have so far.

I'll keep this running for a little while longer and see what we can get out of it. 21:49, June 4, 2013 (UTC)

I want to try and reach as close to a consensus as we can. So, I'm proposing the following, added to the main proposal I made above


 * 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.

I don't love the idea of voting, but sometimes I accept that it is necessary to reach a decision. I definitely want to avoid any issues with votes being nullified, so it's important that the last-resort vote be a straight up-or-down. I've also eliminated neutral votes, since depending on interpretation they can be interpreted as votes against a nominee (eg 20 people voted but 10 were neutral, so the majority of votes weren't in support). I understand that people want to participate and demonstrate their neutrality, but it tends to make these processes even more difficult to interpret than they already are.

I hope that what I've put forward is a good compromise. --  LostInRiverview talk ~ blog 22:54, June 4, 2013 (UTC)
 * I see where you're coming from with the voting being an issue; many users (including myself) often don't really give any reason for why and this just seems even more in that direction since users can't explain their vote. I agree completely that voting should be a last resort and I really like the system you have put forward, especially because it gives much more time for opinions to be given. I'm completely in favor of this :) 23:16, June 4, 2013 (UTC)

Voting
In an effort to resolve this discussion, I'd like to move forward with a couple votes.

Lost Labyrinth listed five bullet points above. The first and fourth points - limiting RfA and RfB to one at a time, and setting each request onto its own page - both received support, but the points might be considered to be contradictory to each other. So, one vote will help determine whether we want to implement the 'One request at a time' rule, the 'Separate pages for each request' rule, or both.

The second vote will probably be a little more controversial, since it would be that vote that settles ultimately how the requests will be processed. The first option would be to keep a week-long voting period, to implement a commenting period beforehand, and to focus on voting reasoning. The second option is to implement a discussion and comment-based consensus system, with voting being used as a fallback if consensus fails. Since the issue is very abstract and the two options I listed may not satisfy people, there will be a third option, not supporting either proposal in their entirety, and continuing the discussion.

You can go below to vote. --  LostInRiverview talk ~ blog 20:05, June 11, 2013 (UTC)

First Vote
Question: ''Should Requests for Administratorship and Bureaucratship (RfA/RfBs) be limited to one-request-at-a-time, be held on separate pages, or both? When voting, please use the following labels with your vote:''
 * Option 1 supports implementation of only a one-request-at-a-time system.
 * Option 2 supports implementation of only separate pages for each new request
 * Option 3 supports the implementation of both one-request-at-a-time and separate pages for each new request

This vote is now closed.

Option 3 - I think having requests on separate pages makes sense from a housekeeping standpoint. I also think limiting to 1 RfA and 1 RfB at any one time makes sense, to make sure that the attention of everyone is focused on a particular issue. So, I support implementing both. --  LostInRiverview talk ~ blog 20:15, June 11, 2013 (UTC)

Option 2 - Cosmetically it makes the RfX pages look less cluttered. The landing page would just list the current nominations with links to the subpages and it would be easier to focus attention on multiple discussions this way. 21:22, June 11, 2013 (UTC)

Option 1 - Personally, I don't see the pros to having separate pages for each request. However, I believe that having one request at a time would be ideal, especially if there could be such a long process for RfB (depending on the result of the second vote). -- Bleeh (talk) (blog) 02:46, June 12, 2013 (UTC)

Option 1 - Staying with what I said per the discussion, I'm still firm on the option of having one request at a time. Like Bleeh, I don't see any pros on having separate pages for each request. Having one request at a time could also make both request pages look like they are in a controlled environment. Beds (parlare - da leggere ) 07:14, June 12, 2013 (UTC)

Option 1 - I think this would be simpler than having a page for each request, as I believe doing that would be a bit tedious. ~ Waikikamukow  ( Anyone wanna chat? ) 11:07, June 12, 2013 (UTC)

Option 2 - I'd rather not limit requests to one person at a time. Ѧüя◎ґ (talk) 19:17, June 12, 2013 (UTC)

Option 3 - Per LiR. 19:23, June 12, 2013 (UTC)

Option 3 - It makes it a lot less cluttered and as pointed out, everyone is focused on the one nomination. 19:43, June 12, 2013 (UTC)

Second Vote
Question: Should RfAs and RfBs implement a commentary period prior to voting, or implement a comment-based consensus system which eliminates voting except in certain circumstances, or should further discussion be held before a decision is made on this issue?
 * Option 1 supports a commenting period before a voting period, and a focus on substantive rational votes.
 * Option 2 supports a system that utilizes a comment and discussion period, with a voting period used if a consensus is not reached.
 * Option 3 opposes both Option 1 and Option 2, and instead states that discussion should continue until a more reasonable solution can be found.

This vote is now closed

Option 2. First off, I don't really support Option 3. We've had this discussion ongoing for weeks, and I don't think additional time is going to bring forward many substantive ideas. As for the difference between options 1 and 2... to me, it comes down to which system is more fair. If a hypothetical user applied for rights and was turned down because some of the votes in their favor were found not to have strong enough reasoning behind them, that seems less fair than a system in which that applicant can have a straight up-or-down vote if there is unclear consensus. I've said it before but it's worth saying again... there's no really good way to implement a system where votes can be struck out, so it would make sense to create a system that avoids voting if possible. --  LostInRiverview talk ~ blog 20:19, June 11, 2013 (UTC)

Option 2 - Seems to follow the trend most discussions here take - if the actual discussion itself doesn't say much then take it to a vote - so I guess this is as fair as you can get with this. 19:46, June 15, 2013 (UTC)

Option 2. To me, it seems to be the most sensible and time efficient option. Ѧüя◎ґ (talk) 21:52, June 11, 2013 (UTC)

Option 2 - I don't like the idea of someone deciding if a vote is justified or not, as votes are simply a yes or no (or neutral or abstain) and a short sentence following it. An actual discussion period would give more insight into the views of the users voting and give voters a better opportunity to express their sentiments. -- Bleeh (talk) <font color="#489094">(blog) 02:46, June 12, 2013 (UTC)

Option 2 - After some thought, I think Option 2 would be the best option. It would give the nominee less pressure while the commentary period takes place. And, as Auror stated, it is time efficient. <font color="#6B1D51">Beds (<font color="#512d17">parlare - <font color="#512d17">da leggere ) 07:14, June 12, 2013 (UTC)

Option 2 - I believe that if the consensus is reached during the comment period, then a voting time is simply not needed. Like Auror, I think it's the most effective option out of the three. ~ Waikikamukow  ( Anyone wanna chat? ) 11:07, June 12, 2013 (UTC)

Option 2 - Per above. 19:23, June 12, 2013 (UTC)

Option 2 - I think everyone else has summed up what I would likely say. 19:45, June 12, 2013 (UTC)

Option 2 - It seems to be the most suitable option for the 'strength of vote' sort of thing used with the original RfA/B, but also eliminates the black-and-white "You can/can't become an admin" atmosphere the old process generated. <font face="Courier (typeface)"><font color="#74C365">Asher <font color="#FFA700">Éire 'Sup? 20:09, June 13, 2013 (UTC)

Moving Forward
There seems to be consensus in both votes, so in the idea of wrapping this up ASAP, I'm closing them down.

The second vote, which I had assumed would be controversial, was not. Option 2 - a system that utilizes a comment and discussion period, with a voting period used if a consensus is not reached - received support. Since it was largely indicative of the proposed system outlined way above, that is what will be implemented. It's worth noting that if there are issues with that system, they can be dealt with later, and a new system can be devised if necessary.

The first vote is a little more work to figure out. The presence of option three - allowing a vote for both options 1 and 2 - complicates the counting of the vote. Ultimately, six of the eight respondents supported implementing Option 1 - three people voted exclusively for option 1, and three for option 2, which included option 1. Five of the eight respondents supported implementing Option 2. Since a majority of respondents technically support both options, the only fair and practical resolution is to implement both options 1 and 2.

As soon as the requests pages are re-written to reflect these changes, requests will be re-opened. In the meantime, I'll leave this thread open just in case there's a need to discuss this further. --  LostInRiverview talk ~ blog 00:57, June 17, 2013 (UTC)

Follow-up
Alright, we've been through two RfAs now under this new system. What does everyone think about it? Are there any positives or negatives you can pinpoint? --  LostInRiverview talk ~ blog 05:28, June 25, 2013 (UTC)


 * I like the new system - the last two requests were dealt with very well and everyone commenting on them seemed to understand the new process and followed the new rules set very well. All in all, I think the Wiki is really going to benefit from the new ruleset. <font color="#6B1D51">Beds (<font color="#512d17">talk ) (<font color="#512d17">blog ) 09:18, June 25, 2013 (UTC)
 * Per Hana! ~ Waikikamukow  ( Anyone wanna chat? )  10:05, June 25, 2013 (UTC)

Something else
This is another thing that has been under the hood for a while now and as it's loosely related to an RfX system, I figured I should use this thread to bring it up.

Currently, there's a nomination awaiting a response from the nominee. This nomination was made 1 week ago. As we're using a system where only one request is processed at a time, this can be somewhat of an issue should that nomination remain in its current state indefinitely and possibly being a blockade to any other requests/nominations waiting to take place while we deal with this one.

This wouldn't be such a problem if we allowed multiple requests at a time, but as the majority have already stated their desire for one request at a time there's no point continuing to look at that idea unless those who supported the one request rule would consider backtracking (I'm not expecting any miracles). The only other way is to implement a timeout period before a request is sidelined in favour of newer requests, which in my view seems somewhat unfair to the nominee should they be on a short-but-long-term break from the wiki. Forgive me if it seems like I'm trying to rush RfX requests but leaving nominations to sit there indefinitely isn't, in my opinion, good practice.

I feel this is worth some kind of discussion. 14:14, July 5, 2013 (UTC)
 * Eh.. I like the idea of a timeout period, but even having that could still prevent another user from nominating themself or another user. I mean, if we have a 1-week deadline, and that user does not respond even within that one week, other users who were willing to nominate wouldn't get the chance to for at least the week that the user did not respond to the other nomination... maybe we should think about having multiple, but maybe no more than 2 or 3 at a time...? but even that could be a hassle to deal with. 14:25, July 5, 2013 (UTC)
 * The way I had been thinking, and the way I ultimately edited the RfA page to say, is that multiple 'pending requests' can be there at the same time, awaiting a response from the nominee. If an applicant wanted to apply in the meantime, they could still do so and their application would be taken first. In other words, we take the RfA (or RfB) applications in order of when the application/nomination was "ready" to be discussed.


 * That would also allow us to form a queue of RfA applicants/nominees if multiple people wanted to apply or be nominated at around the same time. The list would be first-come first-served, based on the order in which the applications or nominations were "ready" to be discussed. --  LostInRiverview talk ~ blog 15:21, July 5, 2013 (UTC)
 * I guess the queue system could work. If as an alternative we thought about multiple requests, I wouldn't mind imposing a cap of 2 or 3 nominations at one time as Pidge suggested. I'm not hoping for a silver lining on that one though so I guess the queue system is probably our best bet, unless anybody else has another idea. 23:18, July 6, 2013 (UTC)
 * I have no problem with the queue system, but will we be putting a limit on how long a nomination can go without a response from the nominee? 02:22, July 7, 2013 (UTC)
 * I like the idea of having a queue/the multiple pending requests, and I think what Pidge is saying about putting a limit on the amount of time between a nomination and an accept to that nomination, is a good idea too. ~ Waikikamukow  ( Anyone wanna chat? ) 07:06, July 7, 2013 (UTC)

Bumping this thread, it looks like having requests queue is accepted. As for having a time limit on pending requests... how long are we thinking? Two weeks, a month perhaps? --  LostInRiverview talk ~ blog 18:59, August 6, 2013 (UTC)
 * Two weeks seems reasonable enough. In my opinion, there's really no point considering a user for an RfX if they're never here and, unless they're declared absent via their user page or other extreme circumstances, it really shouldn't take any more than 2 weeks for somebody to respond to their nomination. 23:58, August 6, 2013 (UTC)
 * Two weeks is more than enough time to accept, so if that isn't enough time I don't know what is... I'm down with that. 03:18, August 7, 2013 (UTC)

And one last thing...
Forgive me for bumping once again with something else but as it's directly related to the new system, I may as well bring it up here before we put this forum to bed.

The old system required one to have 50 edits before they could vote and that was explicitly stated in the ruleset. One of the abuse filters is currently regulating this but nonetheless I'd like to propose we apply the same restriction on the new system for both discussion and voting. My reasoning for this is that we've had cases in the past where users have had users from other wikis vote in support based on personal ties and those users aren't active members of the community. This could easily be seen as swaying the vote to the nominee's favour if the users who are actually active here aren't in support of the RfX.

I'd also like to propose that those 50 edits are explicitly made within the project namespaces (Mainspace, Fanon and Tutorial). I think this would be useful as somebody with little to no community presence shouldn't really be weighing in on an RfA and somebody who, for example, only makes 50 blog comments before trying to join in with the discussion doesn't really constitute as part of the community.

I can already anticipate mixed opinions on the second point but I'd still like to know what everybody thinks. 19:59, August 13, 2013 (UTC)