Transparency v Private peer review

Some important concepts that need to be included for the process to meet the needs of the Community.

Transparency is goodness for a situation where an user is being involuntarily removed from a positions. In these cases a public vote by ArbCom is good. This public vote might be after reviewing the recommendations or finding of an Audit Subcommittee investigation.
But additionally I think that internal discussion and peer pressure that induces an user to leave the position with the understanding to not get access back without an election is goodness. If our goal is removing the tools in the least stressful and disruptive manner, then I think private peer review that results in a resignation is fine.
Transparency and Private peer review both have a role and need not be seen as mutually exclusive ideas as we move forward with more vigorous standards, monitoring, reviews, and sometimes forced removal. FloNight♥♥♥ 18:44, 8 May 2009 (UTC)[reply]
Indeed not; both routes you suggest are acceptable processes to follow. What would not be acceptable would be a nontransparent process that did not result in removal where appropriate. That is, when there is a public complaint, it is not acceptable for that to be dealt with in a private fashion. So when there is a private "peer review" that results in a private outcome, that's fine, as long as that privacy does not affect future events (ie the user does not then run for re-election without the community being properly aware of what happened behind closed doors). When there is a public complaint (ie a complaint that comes at the body of functionaries from the community) then transparency is paramount; the complaint must be handled in a clear and open fashion so that the complainants can see that 'justice' is being done. There's no reason to encourage one over the other.
Currently, because there is no approved process for a 'public' complaint to be actioned, we only work with private complaints: when there is a public complaint, it is either ignored, or it explodes into enough of a festering tarpit to force a private action. All we need to do here is to make it possible to deal with public complaints in a sane and orderly fashion. Then private actions can return to being the "less stressful and disruptive [approach]" that you say, rather than the blowout-valve for the community when public complaints build out of control. Happy‑melon 19:04, 8 May 2009 (UTC)[reply]
We are in agreement then. :-) Public complaints handled in public is exactly right. Private feedback from internal peer reviews or Audit Subcommittee investigations that result in voluntary removal with no chance for return of tools without an election is also a good outcome. FloNight♥♥♥ 19:27, 8 May 2009 (UTC)[reply]
As long as that election is not made without awareness of what went on that led to the removal. Equivalently to RTV: if the user wishes to 'fade' from Functionary position, that's fine; but if they want to return to that position, it's beholden on those who were involved with the private action to then put all the cards on the table so that the people voting in the election have the complete picture. If they make the conscious decision to put themselves back in the public eye, it's only right that transparency then takes priority over drama-minimisation. Happy‑melon 20:20, 8 May 2009 (UTC)[reply]
Yep. I agree. They person can leave the position amicably and not have a public hearing or vote as long as they understand that a public release of information will occur if they decide to stand again. The Audit Subcommittee will have people that can monitor the canidates to make sure that public disclosure of previous private understanding happen.
Since these are volunteer positions users need to be allowed to leave a position when they want to go. Forcing them to stay in the position for the sake of a public hearing would not serve the Community or the person well. FloNight♥♥♥ 20:37, 8 May 2009 (UTC)[reply]
Definitely; forcing a volunteer to stay in place just so we can throw eggs at them isn't going to help anything. I think this is/will be a valid and important part of the Audit Subcommittee's work; it fits perfectly with its wider mandate to ensure that the community knows everything it needs to know about Functionary activity. Happy‑melon 20:43, 8 May 2009 (UTC)[reply]

Discussion of comment by Thatcher[edit]

I believe it is a mistake to create a special definition and special processes for "functionaries." This case is not about demoting Jayjg as a "functionary," it is about removing two specific user rights. These user rights are controlled by Arbcom and are assigned to users in whom the Arbcom places enormous trust and confidence. (Although recently there was an election to gauge community levels of trust and confidence, the candidates were pre-approved by Arbcom and Arbcom will not honor the election of a candidate in whom Arbcom does not have trust and confidence.) If Arbcom no longer has trust and confidence in an individual, Arbcom has the authority, the right, and the obligation to remove those special user rights that they control. Trust and confidence can be lost for many reasons, not just demonstrable misuse of those rights. (And, I agree with the sentiments above that getting into a confrontation with someone who has special user rights can be intimidating even if that user does not misuse those rights in that confrontation.) Ultimately, Arbcom has the authority to remove checkuser and oversight for any reason, and since the community elected these people on the basis of being intelligent, reasonable and levelheaded, it is probable that any decision that a majority agrees with is probably reasonable and levelheaded as well. With respect to Casliber, you don't need this RFC. Thatcher 11:57, 9 May 2009 (UTC)[reply]

But this isn't about the authority of the Community to create functionaries; it's about their authority to remove them. The CU/OS election policy clearly indicates that ArbCom will only appoint CheckUsers and Oversighters from a pool of candidates that had over 66% support in the election. Jimbo only appoints Arbitrators from a pool of candidates with over 50% support in the ArbCom elections. The message is clear: the community does not have the authority to create CU/OS/Arbs without the approval of the relevant body, but it does have the right to veto candidates. It is untenable to hold that that right does not extend to revoking the approval of existing Functionaries. ArbCom does indeed have the right, authority and duty to remove Functionaries, but that is not mutually exclusive to the right and authority of the Community to do the same (this is what I was discussing with FloNight on talk). Currently there is no process by which this Community right can be properly exercised, and that is the problem this RfC hopes to solve, I believe. Happy‑melon 12:26, 9 May 2009 (UTC)[reply]
I think you need to read the RFC again (or I do). Unless I missed something, the question posed is "Under what circumstances should arbcom remove functionary rights..." The question of whether the community should have the ability to remove functionaries is an interesting one, but has not been posed in this RFC. Thatcher 13:00, 9 May 2009 (UTC)[reply]
How about something more along the lines of "under what circumstances, and in what way, should the community formally advise ArbCom that there is reason for them to consider removing ... " ??? would that get round the issue? ++Lar: t/c 13:05, 9 May 2009 (UTC)[reply]
No, you're quite right. It's just that in my mind at least, the question posed is not actually the question that needs to be answered. ArbCom can grant Functionary rights; ArbCom can, therefore, take Functionary rights away; this is, as you say, entirely obvious. The reason this issue is complicated is that it is not Arbcom taking the initiative; this is a complaint brought by the Community. This is not the result of an Arbitrator or the Audit Subcommittee saying "ooh look, user X is using the tools improperly", it's the Community saying "I think you need to re-evaluate the situation here". The authority of ArbCom to do that reappraisal on their own initiative shouldn't be in question; it's whether, when and how such a request from the Community should be acted upon (and how much say the Community should have in the final outcome). I agree with you, in fact, that "this RfC" is not needed; it's asking a question which is already answered. But I don't see any reason why it can't be used to also ask the questions that we actually need to discuss; "this RfC" is long overdue. Happy‑melon 13:40, 9 May 2009 (UTC)[reply]
Well, I was more thinking (and writing out aloud. My first ruminations were along the lines of the implicit subconscious cretion of a cabal of 'special users, but when framed more simply I reconsidered (as per my vote at the case in question). The latter I don't think is a problem as negative feedback can flow by many means to the arbs, but am happy to see wht comes up. Casliber (talk · contribs) 20:42, 9 May 2009 (UTC)[reply]
More