Wikiversity talk:Custodianship/Archive 4

Policy or proposed policy?
The project page was
 * created as proposed policy by Sebmol, 18 August 2006.
 * From the proposal, mentorship was added to Candidates for Custodianship, 19 August 2006.
 * As soon as there was a mentor who accepted, a 'crat implemented it.
 * There was no dissent that I have seen.
 * The procedure was tagged policy,12 February 2007, by JWSchmidt. It had then been in use for seven months. It was firmly established, with complete community agreement. That is why there was no vote.
 * 28 March, 2008, Darklama questioned how the policy was determined.. Behind the question appears to be a belief that a vote is always required. Darklama did not remove the policy tag, but added a template that accepts the page as policy, but requests review and improvement.
 * No substantial changes have been made to the custodianship procedure since then.
 * 8 August 2010, I removed the review template as stale, with the policy stable. Darklama reverted, saying review was still needed, I reverted, and that stuck, and actual changes were made, seeking consensus.
 * 8 June 2011, SB _Johnny changed the policy header to "proposed." I reverted. SB Johnny appeared to accept that. Minor work on the policy continued.
 * 26 November 2011, Thenub314 also changed the policy header to "proposed," edit summary: (just to be clear that there was never a !vote.)
 * I reverted,, with "This is *obviously* policy. Please see Talk."
 * Ottava Rima reverted with Policy need consensus first, any claim something without clear consensus is a policy is, by definition, vandalism. I was quickly indef blocked by SB Johnny, so I could not arrange a discussion, and the page was left like this until now.
 * Custodianship policy is fundamental to the maintenance of Wikiversity. Without a policy, there is no guide for bureaucrats, or for stewards. The real policy was established in 2006, and has been used for every custodian since, including those who later questioned it.
 * Candidates for Custodianship/Darklama
 * Candidates for Custodianship/SB Johnny
 * Candidates for Custodianship/Ottava Rima
 * Candidates for Custodianship/Thenub314


 * It occurred that there was disagreement with a candidacy. The policy was followed without requiring consensus.
 * Candidates_for_Custodianship/Salmon_of_Doubt, implemented when the candidate and SB Johnny agreed. I read three oppositions while the candidate and the mentor are two. The mentor made sure that he could remove the tools at any time (and later did). This is up to agreement between the candidate and mentor.


 * A vote is not required to create a policy; it often occurs in the early days of a wiki that a procedure is established with no controversy, and is routinely followed and is predictable.
 * As there is no serious proposal on the table to change the policy, nor was it changed in the over three years since it was deprecated to proposed, while it continued to be followed, as we need a policy to continue replacing custodians as they leave, I am restoring the policy template. --Abd (discuss • contribs) 04:22, 13 May 2015 (UTC)

Proposal to split the tools
SB Johnny has been talking since 2011 about splitting the tools. It's not a bad idea, but the proposals he made would cripple probationary custodianship as the efficient process it is to create permanent custodians.

When Wikiversity started, a few "temporary adminstrators" were directly named by the founding bureaucrat, and then within a few days, the process was set up for mentorship as we have it now. There is a list of all probationary custodianships at User:Abd/Policy_development. The result has been that, with little fuss, there have been 40 users become probationary custodians, simply by an agreement with a mentor, implemented by a 'crat as if automatically. There have been discussions and opposition, but it has never stopped the process. There is 1 probationary custodian at this time. That leaves 39. Of these, 33 became permanent custodians by vote of the community. 6 did not. Of the 6, only 2 could be considered disruptive, and there is a method known of avoiding that; it was available but was not used (Candidates for Custodianship/Standard stop agreement).

So for a little disruption, transient at most, we easily gained 33 permanent custodians and others who served for a time and helped out. So what's broken? Before fixing it, we should look carefully at what happened!

The data for probationary custodianships shows a drastic fall-off in 2012. At the same time, it became difficult to find a mentor and, even when a mentor was found, to find a bureaucrat to push the button. By 2014, we were down to one active custodian, and he was probationary. Nobody was available to mentor; a suitable candidate asked for a mentor on 15 November 2013. It was not until 1 October 2014 that the probationer had become permanent, and offered to mentor, and it still took 16 more days for a bureaucrat to implement what should be almost automatic by policy and take a few minutes at most.

If we look at the two possible breakdowns in the system, where there was allegedly disruption, we can see a common factor: lack of mentor supervision and responsibility.

So a solution: create an Assistant User Group, with all the custodian tools of the present Custodian group. Custodians would get all the Assistant tools plus one: the ability to add or remove the Assistant user group.

Having all the other tools, Assistants are being trained to be Custodians.

A mentor, a permanent custodian, can then simply implement directly. We would still document this on WV:Candidates for Custodianship (which then becomes a base for a later permanent vote, if the Assistant is ready to go ahead. If there is a belief on the part of any other Custodian that a user is improperly using the tools, the other custodian may warn or even remove the user right. It becomes very easy to fix a problem. To become a Custodian, then, will require a period as an Assistant, plus a vote, as now for Permanent.

For maintaining the wiki, "Permanent" isn't needed. We can create as many Assistants as we need. Any Custodian creating an Assistant is responsible as with any other custodial action, and may still be called a "mentor" or "supervisor." However, if the mentor is absent, any other custodian can act, effectively. If there is a dispute, presumably the Custodians, avoiding wheel-warring, will work it out, consulting the community if necessary.

Requiring a bureaucrat to implement the mentorship actually has never made a difference except, of late, to greatly delay implementation, and then there was occasionally the problem of removal, of needing to go to meta and convince a steward to remove the tools. --Abd (discuss • contribs) 01:57, 16 May 2015 (UTC)


 * I wasn't here when Wikiversity easily gained 33 permanent custodians. But I was here when those permanent custodians were still listed as custodians and did little or nothing to care for Wikiversity.   And those were just the ones that were left after the various purges that occurred, primarily in the 2011 timeframe.  That's not "a little disruption", but a major problem in the approach that either led to accepting too many custodians without sufficient vetting, or changes over time that suggest custodianship should have an annual renewal process not unlike stewardship.  Perhaps both are true.


 * But to address the issue Abd presents, rather than creating a new group, I would recommend enhancing and using the existing Oversighters group. See Special:ListGroupRights.  To the existing Oversighters rights I would add most of the Delete, Edit, Move, and perhaps View rights.  This would allow an Oversighter to manage content at Wikiversity, while restricting access to more problematic tools such as blocking and system administration rights.  Custodians could be given the right to add and remove Oversighters to reduce Bureaucrat labor.  -- Dave Braunschweig (discuss • contribs) 14:06, 16 May 2015 (UTC)
 * Oversight is a high-level tool, quite inappropriate for an Assistant. Wikiversity was very active at one time, but users move on.
 * The 33 permanent custodians did not become so as probationers. They all passed a permanent custodian vote. There were only 6 that did not.
 * The "purges" have been overstated. The main user affected was the founder, JWSchmidt. However, from the numbers of candidacies, we can see a drastic fall in 2012. What happened at the end of 2011? Look at my block log.... As a result of my probationary periods, there was an attack on probationary custodianship itself. I have not documented this yet, but it's easy to find. Under this proposal, there would have been no fuss. If a permanent custodian wanted me to not have the tools, they'd have been taken. No Community Review necessary, unless custodians start wheel-warring. That would not happen now.
 * Yes, there is a problem with permanent custodianship. But this is a different problem. This proposal really is the same as existing process, by policy, except that custodians, having passed a vote, may remove the Assistant tools. Right now, it takes, as you know, meta process to remove a probationary custodian, a can of worms from the past. --Abd (discuss • contribs) 19:26, 16 May 2015 (UTC)


 * But the proposal as I understand it isn't splitting the tools. It is keeping the exact same tools and changing who can approve or remove the setting.  We can accomplish the same thing by removing the unblockself right from custodians.  What I would like to see is a true splitting of the tools.  Create a group that would have the rights we would be comfortable with assigning to a teacher of a class so they can clean up after their own students, or to someone committed to cleaning up content at Wikiversity but not prepared for probationary custodian status.  They may only want that role, or they may, in time. graduate to probationary status.  -- Dave Braunschweig (discuss • contribs) 23:08, 16 May 2015 (UTC)
 * Yes, there might be another split. However, the suggestion is about probationary custodianship, and the issue would be whether or not it is worthwhile have yet another user group. If the Assistant user group -- except for the right to create Assistants -- has the same toolset, the teacher mentioned may or may not decide, later, to go for full custodianship. Such a teacher would be very unlikely to abuse the few extra tools as an Assistant.
 * I have not given all the reasons why this would be a major improvement, but SB Johnny obviously got it immediately.
 * I spent three days studying the development of Wikiversity policy, and the history of probationary custodianship, some of which I documented, and this came out of that, as something that should have been done from the beginning, from the policy as written in the very first draft of WV:Custodianship (automatic crat approval), but wasn't, because the user group was not in place. Further, crats were plentiful, and in the early days, actions were swift. Removal was relatively rare, so it seemed like it was working. Almost ten years later, we have much more experience. It worked, mostly. But we can make it simpler and better. --Abd (discuss • contribs) 13:03, 17 May 2015 (UTC)


 * See Principle of least privilege.  -- Dave Braunschweig (discuss • contribs) 14:00, 17 May 2015 (UTC)
 * This is a wiki, errors can be fixed, misbehavior can be undone. There is little or no security issue at the level of custodian. There is with checkuser and oversight. It seems that Dave is most concerned about the Block/Unblock right, with special importance to unblockself. This is all easily handled with a restriction placed on an Assistant, documented on the WV:Candidates for Custodianship subpage created for the Assistant. "Custodian tools are only to be used on the Blah Blah resource." Any custodian could then notice a violation and warn or remove tools, and if the mentor custodian disagrees, he or she will have the right to restore them -- and then becomes responsible for what ensues. Because of the difficulty of removing tools, it's taken disruptive process to manage it, plus steward action.


 * Present policy is that probationary custodianship "will be approved," if any experienced custodians agree to mentor you and you agree to their mentorship." It has always been understood that "experienced custodians" means permanent ones, which have been approved as such by community consensus. No attention was paid to the removal of probationary custodianship. Being aware of the possible problem, some mentors insisted on the candidate agreeing to the mentor's right to remove the tools. That a mentee might cause disruption, but not be restrained (or supported) by the mentor, was not contemplated. It happened twice in nine years, the first times with me, the second time last year. This makes it all simpler, by leaving the bureaucrat-decided process to the end, after a vote, and then handling the Assistant right assignment locally. Easily given, easily revoked.


 * This is for the full set of tools (excepting the right to create or remove Assistants). This, then, is designed for the original purpose of probationary custodianship, training custodians. That an additional group might be created for other purpose is a separate issue. This is not about "custodianship." It's really a new topic. --Abd (discuss • contribs) 16:32, 17 May 2015 (UTC)


 * Yup. Assistants could then become custodians after a community vote as we do now. A good rule to prevent "wheel warring" over this might be that a custodian can't mentor the same person twice, and also can't remove the permissions from the same person twice. (As an aside, this was originally brought up (by darklama, I think) far earlier than 2011.) --SB_Johnny talk 11:26, 18 May 2015 (UTC)
 * This is just "wheel-warring" applied to one action. Custodians (and many or most users) will ignore "can't" when they can. "Not twice" would fix what problem in Wikiversity history? (It's never happened, to my knowledge.) Rather, custodial actions should be discussed before being reversed. (Absent emergency, and I can't imagine this being an emergency.) Fixing the rule of "not twice" *requires* escalation of a dispute. --Abd (discuss • contribs) 15:59, 18 May 2015 (UTC)
 * (Adding:) Unbundling the tools doesn't really make a lot of sense, IMO. For example, if a subproject is being disrupted, the solution might involve a combination of protection, blocking, and deletion of nonsense pages, and it's much easier for one person to take that on as a single task than it is to break it into bits and run around finding people to form an assembly line. --SB_Johnny talk 11:33, 18 May 2015 (UTC)
 * My thinking. In addition, it would reduce the value of Assistantship in testing readiness for full Custodianship. Nuke excepted. I think nuke should be yanked from the regular custodian tools. Has it ever been used on Wikiversity? A bot with admin rights can handle pretty extreme stuff. There is no unNuke. --Abd (discuss • contribs) 16:14, 18 May 2015 (UTC)

Looking at the list of custodian user rights, I don't see any need for an assistant to have Mass delete pages (nuke), Send a message to multiple users at once (massmessage), or Unblock oneself (unblockself). The mass delete is the most critical in terms of risk. -- Dave Braunschweig (discuss • contribs) 13:48, 18 May 2015 (UTC)
 * I agree about nuke (that's the first one I thought of, I have seen it abused. Colossal nuisance. The wiki was restored from backup). Possibly about massmessage, but I'm not so sure. I don't agree about unblock self. The practical difference would only be with a block of an Assistant by an Assistant. Read the Standard stop agreement (which is about probationary custodianship) and understand how it would work. (It has been used with a number of probationary custodianship, but never invoked, which was downright weird). If an Assistant unblocks self, and this is seen by any custodian as an abuse of tools, the Assistantship may be removed, pending. We will set up policy to handle all this.


 * A permanent custodian may "enjoin" an Assistant against taking described actions (up to and including all intrusive use of tools), without actually yanking them. If the Assistant seems to be in the middle of a series of problematic actions, the Custodian may block, with a note that unblocking self is confirming that the message has been received. If the Assistant then violates the warning, without discussion having found that the actions enjoined were "within proper discretion," it would be completely appropriate for the warning Custodian -- or any other -- to yank the Assistantship.


 * I know of three custodians who unblocked themselves, aside from tests. The first was permanent, it was a 2-hour block for incivility. He not only unblocked himself, he hid it all with RevDel (the preceding warning and the block notice, as I recall), effectively demonstrating his incompetence, resulting in his desysop.


 * The other two were you and the recent desysopped probationer. Consider the situation had the probationer been an Assistant. While he might have unblocked himself, and continued the rogue behavior, that would have lasted until you yanked his tools. As well, any other custodian could have done so, plus with a clear policy in place about Assistants vs Custodians, any steward would have acted quickly, or a Global sysop.


 * Wheel-warring with a Custodian would be immediate cause for desysop. No discussion is needed, no complication of convincing stewards -- who are very reluctant to intervene in local disputes. The Standard stop agreement is complex because it's attempting to deal with a range of situations. The separate user group with Custodian assignment is far simpler, because it allows the custodian to yank the mentorship immediately. The Assistant may still find another mentor, or convince the original mentor that it's safe to resume. No mentor, no Assistantship.


 * This deals with the absent mentor problem. If the mentor is present, and supports the Assistant, the mentor and the opposing Custodian may discuss it; the mentor does have the right, after discussion, to restore the Assistantship. Knowing how these kinds of conflicts have been resolved on Wikipedia (I followed ArbCom for years, occasionally participating), it's like revert warring. An assignment of rights is an editing of the bits for the user. Everyone gets one revert without it being revert warring. Above that, discussion is highly recommended. (It's also recommending before acting, but sometimes circumstances ....) Back and forth without discussion and good-faith attempt to find consensus, this can result in desysopping, and often has.


 * Beyond 1RR, it's probably time to take it to the community.


 * No custodian would have restored those rights for that rogue Assistant. His mentor would not have done it. I know. I had that mentor as a probationary (CC/Abd 2). He was a bureaucrat and could have restored rights. I know him well, he would not have touched that. We followed existing process, it was very straightforward. --Abd (discuss • contribs) 15:23, 18 May 2015 (UTC)


 * A standard stop agreement depends on agreement. A rogue assistant by definition is not following agreement.  Yes, it would be possible to pull the bit and then block, but here's where that falls apart.  What happens if it is an assistant trying to work with another assistant, the very situation I ran into with probie vs. probie?  An assistant would not be able to pull the bit from another assistant, so the block would mean nothing, the same situation we already had that didn't work.  We can't say this will never happen again, because five years ago there were 33 custodians and everyone would have been sure it wouldn't have happened.  It's already happened.  Let's ensure that it can't happen again.  -- Dave Braunschweig (discuss • contribs) 15:58, 18 May 2015 (UTC)
 * Yes, the SSA is an agreement, but with teeth. It was designed to be very clear, so that a steward could decide almost automatically if the agreement was being violated. If violated, desysop. No fuss.
 * The rogue probie was violating no agreement. He was doing what he believed right, necessary, and proper.
 * Dave, you did not run into "probie vs. probie." I was very active in setting up the situation. I made sure you were permanent, because I saw the risk. I created and closed your permanent custodianship. (Because it does not require tools, any user may close a discussion, based on apparent consensus. But this was "irregular." Policy says "bureaucrat." Even doubly irregular, because I was also functioning in the place of the recommending mentor, and I noted that in the close. Because consensus was obvious, it stuck.) It was eligible for close Sept. 6 when it was 8/0/0. Being left open, it became 10/1/1. I closed 00:43, 19 September 2014. i considered the close final after a week.


 * You were blocked 14:29, 16 October 2014, as an escalation of wheel-warring from the probie. I was then able to describe the situation on meta as probationary vs permanent. The steward, as it happened, did not understand that, and merely saw that the probie had unblocked himself, so he desysopped. Later, when it was pointed out that you had also unblocked yourself, he thought he might have made a mistake. To him it was just "sysops." He didn't understand what I'd written about mentors.


 * The meta discussion is worth reading.


 * This change to Assistantship, locally determined, would completely avoid that confusion.


 * Okay, suppose it's probie vs probie. First of all, unblocking oneself is only to be done as an emergency action. Further, the question would be what the probie does if he or she unblocks self. Continue the same behavior, as in "you can't make me"? Is harm being done to others?


 * I.e, probie A blocks user X. Probie B unblocks. Probie A reblocks X and blocks probie B. Probie B unblocks self and unblocks X. Were I an uninvolved custodian seeing this, I would yank the tools for both, immediately, unblock B if not already unblocked (and assuming no other possible disruption by B outside to tool use), and ask them to explain themselves. There is no fixed rule for deciding who is "right" here. For Probie B to stand up for X could make the difference for long-term participation on Wikiversity, even if it takes some time to sort it. But if X was doing serious harm, such that a block was necessary to protect other users, the block of X may have been necessary and the unblock wheel-warring. This was, as described, wheel-warring. Wheel-warring is a not "bad," it is a sign that something is awry. To wheel-war absent an emergency, though, is disruptive.


 * So, now, suppose that probies can block but cannot unblock themselves. This, then, gives an advantage to the first probie to block another probie. Yes, it could be suicidal, but what about X?


 * All is is pretty unlikely. As we get large, as we must, to realize the Wikiversity vision, it will happen. It will still be rare, and any custodian will be able to fix it. Any custodian could mediate between Probie A and B in the above scenario. If that's all that's needed, fine. One step above, the mentors may get involved. So far, this is only on User talk pages. Maybe Custodian Feedback is filed. One step above, it goes to the custodian community on RCA or Notices for Custodians, or, another step up, to the community on the Colloquium, or to Community Review site-messaged. I see that as being very rare. It's only an issue requiring wider attention if the Custodians disagree. --Abd (discuss • contribs) 17:08, 18 May 2015 (UTC)


 * I stand corrected on probie vs. probie. It was custodian vs. probie.  But I think our difference in perspective is also based on experience.  You believe in words and agreements.  As a network admin, I depend on bits.  It's a much cleaner solution, from my perspective.  -- Dave Braunschweig (discuss • contribs) 17:39, 18 May 2015 (UTC)
 * You don't understand my position, Dave. I don't "believe in words and agreements," except for one thing: human beings are programmed by "words and agreements." In particular, it's how we create the future, and this is my primary field. You depend on bits, which feed machines that operate based on them. Given the program and the bits, the behavior of the machine is predictable.


 * The agreements we make become programming for ourselves others; in particular, the SSA creates a program for a steward to follow: Is there a request to stop from a permanent custodian? Check. Did the probationer violate that request by acting contrary to it? Check. Is there a "clearing page" -- it's a page that lifts the stop --? No. Clear the sysop bit. Done. No more discussion here, please, take it up with your home wiki.


 * I know what the stewards routinely need to act. They don't want complicated arguments, they don't want "right and wrong." They actually want clear programming. Which is either generic practice, sometimes, or clear local policy, pointed to by the one making the request. Something they can read in a minute. For a desysop, they will normally want to see a discussion with a vote, where they can tell by the pretty colors what the result is. Really, they want to be machines. And to the extent that they are, it's a good thing. On the other hand, there are exceptions....


 * The SSA is an agreement. We will simplify things if we make it policy. However, SBJ cut the Gordian knot here. I don't want to work on fixing a policy that was broken from day one, by creating this unnecessary third wheel, bureaucrat approval, and by using the sysop group, which cannot be locally removed.


 * Human beings are both machines and more than machines. We program ourselves with agreements. Some of us are broken or malfunctioning and don't keep agreements, but it's actually the exception. I've made agreements with real criminals, and they kept them, I have some amazing stories. That did not mean that I could trust them outside the agreement, and even within it, the saying of the Prophet was, trust in God, and tie your camel. The "camel" is a symbol for the human self, which is, like camels, a cantankerous creature. But treat your camel with respect. --Abd (discuss • contribs) 20:11, 18 May 2015 (UTC)


 * Isn't it possible to understand your position without accepting or agreeing with it? -- Dave Braunschweig (discuss • contribs) 21:01, 18 May 2015 (UTC)
 * Of course it is. Do you [understand my position]? --Abd (discuss • contribs) 12:35, 19 May 2015 (UTC)
 * One of the techniques used in consensus formation is to ask those in dispute to explain the other side that way, such that those on the other side will say, "Yes, that's what we think." If they can't do it, it's a sign they are not listening. It works. Those who stay with the process, in my experience, end up with consensus. But many believe they understand the other side, and "it's wrong."
 * To state the other side is not to accept or agree with it. Rather, it advances the conversation, takes the parties closer to agreement. Wikis, classically, find this too much work. It's not quick. And this is why wikis, which formally depend on consensus, can be terrible at finding it. I've seen what happens when someone who knows consensus process facilitates. I've seen it create cooperation out of disruption. Is that worth pursuing? --Abd (discuss • contribs) 02:15, 30 August 2015 (UTC)