Talk:Project restarting process

Some initial questions

• Are global sysops an adequate replacement for the local admins? Unless they are able to understand the local language, they are not going to be effective.
• Should there be a threshold of some kind for the "amnesty" (lifting of all bans)? (E.g. should it apply only to users with more than x edits? To users who were indef banned say 10 years ago?)
• Is the "amnesty" irreversible?
• What if the community elects the same admins again?

Regards, GregorB (talk) 17:22, 17 September 2013 (UTC)

It's a good idea, and I support it. Though, I still think it should be tougher on administrators who abuse their powers and allow for Wikimedia to enforce sanctions like a block for a year or longer.--Seiya (talk) 17:58, 17 September 2013 (UTC)

(Edit conflict.) I thought about many of your questions when drafting the current wording:

• As far as I know and understand, global sysops and stewards do exactly that already on many small wikis. I may be wrong though. I see no reason why it wouldn't work in cases of "restarting" if it works elsewhere. It wouldn't be a permanent state anyway, though I'd definitely wait a few weeks before appointing admins, so that everyone gets the opportunity to read their notification email, or read about the restart in the news, and re-join the community.
• I think there shouldn't be a threshold. We're talking about cases where people really get blocked by the ruling admin cabal for voicing certain legitimate opinions, perhaps even after the first edit, and perhaps that has been going on for a really long time. Wikis start with no bans whatsoever, so the same should apply on a restart.
• Any community can set a blocking and banning policy, and according to it block and ban users who are troublemakers again after the amnesty. If they've meanwhile learned to be constructive editors, why not let them edit? It's entirely possible and legitimate that the project's blocking/banning policy will then contain a clause that says that users who were indef blocked before the restart won't get as many chances as others.
• Nothing would happen if the community elected the same admins again. In that case, it would seem like there really wasn't a real reason for restarting the project in the first place, because these admins really had community support. I don't think that if the restart was right in the first place, exactly the same admins would be elected again.

darkweasel94 (talk) 18:10, 17 September 2013 (UTC)

All very good answers. I'm not familiar with the inner workings of Wikipedia regarding global admins. Applied to the issue at hand - which is Croatian Wikipedia, a fairly small community - this should work then.

The idea of edit threshold is to avoid reinstating vandalism-only accounts that were used for just a couple of edits before banning. However, the risk of adverse consequences probably is low in the first place, so one might as well make it simple and reinstate everybody. Same for irreversibility.

If the Croatian Wikipedia admins were removed from their position today, they'd probably elect each other back to their old positions tomorrow. That is: if there weren't for an intervening ArbCom process in which some of them might become banned from reapplying, or perhaps indef banned. And for that to be effective, it has to be decided from outside the project. This is the crucial bit. And indeed, if nobody is sanctioned and everyone is voted back, then there was probably no problem to begin with. GregorB (talk) 18:55, 17 September 2013 (UTC)

Creating new vandalism-only accounts is pretty much exactly as hard as reusing old ones. As for your other concern, how many admins are there on hrwiki? Would those who were driven away or banned by them inevitably be outvoted by them? darkweasel94 (talk) 19:31, 17 September 2013 (UTC)

en:Croatian Wikipedia says: 27 admins, fewer than two dozen editors with 100+ edits a month, around 150 with more than 5 edits a month. If I'm not mistaken, adminships were gained with 15-20 "support" votes. Admins really set the tone. GregorB (talk) 21:51, 17 September 2013 (UTC)

Hm, I could imagine keeping pre-restart admins from having their votes counted in admin elections for one year after the restart; do you think that would solve this problem? darkweasel94 (talk) 11:44, 18 September 2013 (UTC)

I think it would, absolutely. The same should apply to other executive positions (bureaucrats, ArbCom members, etc.) This provision might seem a bit too restrictive for application in a general case, so it might be left as an option. On the other hand, it might be construed as a mandatory "safety switch" designed to prevent the project from immediately falling into the same pattern once again. One year should be sufficient for recovery. GregorB (talk) 12:30, 18 September 2013 (UTC)

I don't think a restarted project would have any bureaucrats or an ArbCom for one year after the restart, because all such structures would also be dissolved. darkweasel94 (talk) 12:39, 18 September 2013 (UTC)

Agree on that. GregorB (talk) 13:18, 18 September 2013 (UTC)

The reason why the project needs to be restarted has to be addressed as well. Without addressing the causes you will end up with the same set of issues. The reason why e.g. Croatian Wikipedia ended up as a point of convergence of various far-right extremist was due to the fact that the initial setup of administrators (e.g. User:Vodomar, User:SpeedyGonsales) favored such worldview, and through selective and subjective application of editorial policy has over the years kept like-minded editors active, and driven others away. After ten years you end up with the mess what we have today.
Restarting the project could give a free-for-all chance to all editors to develop community guidelines, and elect new administrators. The initial position bias void be annulled. Given that these extremist are overall a minority, it is likely that once a sample of active editors becomes more representative of the entire Croatian-speaking population, that their voices will drown and the whole wiki would be steered to the proper direction. In other words, the grace period during which provisional administrators (stewards and global sysops) do patrolling and blocking of obvious vandals must not be chosen as too short.
Two of the former sysops on CW have testified that there is rampant sockpuppet abuse there. It is important to have a checkuser check on all of the active administrators, and permanently ban every one involved in sockpuppeting. This should be done by someone other than the local CU which could be part of the cabal (e.g. User:Vodomar, who is wholeheartedly defending the CW community). Regardless of accusations of abuse against any individual administrator, which may or may not be proven true, sockpuppeting is something that should be clearly marked as crossing the line. --Ivan Štambuk (talk) 19:38, 17 September 2013 (UTC)

Sockpuppeting in the administrator elections that would follow the restart must indeed be looked closely upon by the stewards overseeing them. I'm not really in favor of doing anything selective because of things done before the restart. The restarting process as I imagine it is intended to provide a new chance to everyone, to the entire project. If it additionally had the result of also getting anybody banned, it would be much more usable as a weapon. This isn't intended to be an everyday weapon, it's intended to be an absolute exception that's done only when a project goes really mad, and this is why it is intended to also have some negative consequences on everybody who considers to use it - it would bring back people who they might think were rightfully banned, and it would remove possible good administrators. I'd even propose some rule to limit its usage, such as: if a project has been restarted once, it cannot be restarted again for the next 10 years. darkweasel94 (talk) 19:50, 17 September 2013 (UTC)

Global sysops do not currently act in content disputes, although they may act in cases of spam, vandalism, or perhaps in some other noncontroversial cases (but not explicitly mentioned in policy) like when a change to a MediaWiki message is requested, with consensus. PiRSquared17 (talk) 21:23, 17 September 2013 (UTC)

Thanks for clarifying what you guys would be allowed to do on a "restarted" project. Am I right that there currently are (small) wikis where there are no local sysops, i.e. sysop stuff can be done only by stewards and global sysops? darkweasel94 (talk) 21:37, 17 September 2013 (UTC)

Yes! There are too many with no admins and little to no community, unfortunately. Most African language projects suffer from this condition, e.g. Zulu Wikipedia. Usually these projects have hardly any content, let alone content disputes, so the main things we clean up are vandalism and spam edits. I suppose the situation with stewards is similar, but they can technically act on any project. Global sysops are limited to a certain set of projects, unlike global rollback, which is truly global. Does this answer your question? PiRSquared17 (talk) 21:42, 17 September 2013 (UTC)

Yes, thank you. darkweasel94 (talk) 21:49, 17 September 2013 (UTC)

RfC

I've added this page to Requests for comment. I hope I've done this right, never done that before. darkweasel94 (talk) 19:54, 17 September 2013 (UTC)

Requests for comment/Massive sysop abuse in Chechen Wikipedia

Rschen7754 pointed out on the Wikimedia Forum that a similar "restart" process has been used at least once in the past: Requests for comment/Massive sysop abuse in Chechen Wikipedia. PiRSquared17 (talk) 22:09, 17 September 2013 (UTC)

Perhaps something that needs to be asked is how effective that process was in the end. One difference is that the local community was dead set against the existing administrators, who were mostly inactive except for deleting their recall requests. --Rschen7754 23:00, 17 September 2013 (UTC)

Good point. Chechen case seems more like a short-term usurpation in which, once perpetrators are deposed, things quickly return to normal. What worries me is that the currently discussed case of Croatian Wikipedia seems to be different: the community is being purged of dissidents and other "undesirables" for years now, chiefly by harassing, suppressing discussion, and punitive admin actions. (Three more blocks in the same vein this morning.[1]) As I noted above, CW has more admins than people with 100+ edits a month (and these two sets have a high overlap, obviously), so they will probably be able to outvote the other regulars and legislate themselves back into position. Maybe I'm mistaken in this view - I'll ask people with more insight into CW dynamics. GregorB (talk) 08:18, 18 September 2013 (UTC)

Too drastic

I think the proposal is too drastic and could easily be exploited by a loud minority especially on the smaller communities this proposal wants to protect. -- とある白い猫 ^chi? 00:06, 18 September 2013 (UTC)

Having read up on the Croatian Wikipedia case in the last few days, I think it would be wise if there were safeguards to prevent this type of abuse from happening, rather than discarding the entire process to begin with. As this process is the product of a potential arbitration process, it would be up to that potential "global" ArbCom to decide the case on its own merits while at the same time erring on the side of caution.

I believe a few simple safeguards such as locking the project for a period of time while content and admin behavior issues are being sorted out (to determine whether a project restart is merited), the need for impartial third parties to be involved in the process, and the emphasis on the restart process serving as a last resort, would serve the process well. --Sky Harbor ^(talk) 02:58, 18 September 2013 (UTC)

A global ArbCom that makes selective decisions is problematic I think. It would be usable as a way to centralize everyday drama, and as "if you don't unblock me I'm going to global ArbCom". Communities should be self-governing as far as that's reasonably possible. darkweasel94 (talk) 11:42, 18 September 2013 (UTC)

ArbComs are supposed to be last resorts to begin with, and they have the ability to reject hearing cases if they feel that lower-level bodies are more than capable of doing the job. You do not elevate a petty theft case to the Supreme Court when your local court is best-equipped to handle the case; the same works here. --Sky Harbor ^(talk) 05:00, 19 September 2013 (UTC)

They are supposed to be that, but will they be in practice? Perhaps more than on enwiki where ArbCom appears to be the only way to get an abusive admin removed from their position. But still, I at least wouldn't want to ever sit on a global ArbCom, mainly due to the language barrier and difficulty of judging each project's own policies and practices; an ArbCom for one wiki at least has to know only about its own policies and practices. darkweasel94 (talk) 09:24, 19 September 2013 (UTC)

If it gets exploited it can always be subsequently amended to account for cases of abuse. It is not something set in stone. Similar to "one restart in ten years", there could also be a provision "one request for restart in two years per project". Besides, for this proposal to take effect a conclusive evidence in an RfC must first be submitted. --Ivan Štambuk (talk) 13:29, 18 September 2013 (UTC)

"One request for restart in two years per project" is a bad idea. This would mean that people can submit bad-faith fake requests from time to time just to block people from filing a new one. darkweasel94 (talk) 13:32, 18 September 2013 (UTC)

The requests are composed of evidence. If there are indeed good arguments for a project restart, the "bad request" can easily be turned into a "good request" by the non-submitting parties. Furthermore, evidence of a bad request itself can itself serve as a supportive argument for a project restart. --Ivan Štambuk (talk) 13:39, 18 September 2013 (UTC)

Think of the following case - there's a huge dispute on a wiki where it seems likely that a restart might later be necessary, but now it doesn't objectively meet the criteria yet. Somebody files an RfC, the evidence obviously won't be conclusive enough. Now if the dispute really gets worse, everyone is barred from re-requesting restart. darkweasel94 (talk) 09:27, 19 September 2013 (UTC)

Community notification and the prevention of vindictive action

In the light of recent blocks at CW, I propose the following:

• A deadline for the duration of the RfC is introduced, e.g. two weeks. (This seems a reasonable upper limit to present the evidence). After that the Project Restarting Committee makes the decision.
• Once an RfC is made involving a project restart, a notification must be made in the local Village pump.
• Ban on the election of new administrators is enacted, lasting for at most the duration of RfC + PRC decision making period.
• No new blocks must be introduced against any existing (and not new) unblocked editors having more than 500 edits.

The last point would secure that the person or persons making the proposal is not blocked in revenge, and that their involvement in the local community during the RfC period is secured. Without dissident voices, it would appear that the local community is unanimously against the restart, and that the opinion of casual editors that are not involved or interested in wiki-politics, or do not know English very well, does not get swayed by the loud-mouthed cabal in local votes or discussions. --Ivan Štambuk (talk) 14:09, 18 September 2013 (UTC)

• My original idea was actually to have two phases in the process of requesting: one first phases consisting of a general discussion, similar to what is now happening in regards to hrwiki; if that seems convincing enough, the committee would decide to accept to even look at the case and then open "evidence" pages where each user can, in their own section (similar to enwiki ArbCom cases, here's a current example), provide evidence, and the committee would ask questions. That would not be a discussion, because I don't think that the committee will be able or willing to reach a fair decision by reading 100 walls of text (like the current hrwiki RfC). How long each phase should take, yes there should be a deadline on that.
• Yes there should definitely be an announcement at the village pump, and IMHO even in MediaWiki:Sitenotice.
• I don't agree with your last two points; I don't think this is necessary. After all, a block on the project concerned would not affect Meta, and the language committee would explicitly consider even the opinions of blocked users, exactly for the reason you give. If the ruling cabal continues their misbehavior during the process, e.g. by giving out punitive blocks for participating in the RfC, that is of course even more damning evidence. The language barrier is indeed a problem; it should definitely be permissible to provide evidence, and discuss, in the local language or other languages and have them translated for the committee, and all the procedural rules should be translated into the local language. Not knowing English (well) should not be a barrier to participation.

darkweasel94 (talk) 14:27, 18 September 2013 (UTC)

I'm pasting here from Requests for comment/2013 issues on Croatian Wikipedia and expanding a bit my suggestions for ground rules regarding submissions in the investigative phase:

• Diff or it didn't happen.
• Everyone is free to submit, including IPs. (Which amounts to (semi-)anonymous participation.)
• Those not fluent in English are free to submit and comment in the local language. These comments could optionally be translated into English by volunteers. Also, bilingual instructions for participating.

As noted, punitive actions against participants cannot stop them from submitting to Meta, and can only serve as additional evidence. Immediate counter-measures (blocks of infringing admins) might help, but I'm not sure whether that would be overstepping the authority. GregorB (talk) 15:41, 18 September 2013 (UTC)

Immediate counter-measures do not seem a good idea because it is not easy to immediately judge the real cause of a block. An exception is when somebody actually removes a notice of the RfC from the village pump (i.e. tries to revert it out or block for reverting it back in) or the site notice. darkweasel94 (talk) 15:46, 18 September 2013 (UTC)

Agree, might lead to more trouble. Anyway, if the project is reset eventually, all blocks are lifted. GregorB (talk) 15:52, 18 September 2013 (UTC)

Some changes

I have added a remark about time limitations (10 years between restarts), as discussed above.

For something that may be more controversial: Above, I stated the opinion that pre-restart administrators should not be allowed to participate in administrator elections after the restart for one year. After thinking some more about it, I think that this gives an impression of "collective guilt". I would like to add a more flexible sentence like the following:

Stewards should, after a restart, allow reasonable time of at least six weeks (42 days) to elapse before appointing new administrators. For half a year (183 days) after the restart, the level of consensus required for appointing administrators should be approximately 80 to 90 percent. No bureaucrats should be appointed for two years (730 days) after the restart.

The numbers can still be tweaked, but I think this is a better idea than to allow for any kind of selectively excluding people from anything because of pre-restart deeds, which is contrary to the spirit in which I wrote this proposal. darkweasel94 (talk) 19:55, 18 September 2013 (UTC)

10 years seems a bit excessive to me - 5 years should be fine. (Will restart have an adverse impact on day-to-day operations?) "At least six weeks" is OK; an upper time limit could be specified too. As for the level of consensus - 75% perhaps?

I'm still not decided regarding the (non-)exclusion of admins from admin elections. There are upsides and downsides. Even the (lower) 75% figure can still result in deadlocks: if the pre-restart admins manage to get 25% of the vote against any admin candidate they don't like - which shouldn't be hard - and they are themselves unable to get 75% of support, then no admins will be elected at all.

There also might be ways to unduly influence the admin elections by tweaking the eligibility criteria for voting. Only 50%+1 vote is enough to change the eligibility criteria.

This is all fairly tricky. That's why it is important to discuss... GregorB (talk) 21:09, 18 September 2013 (UTC)

Restart would at least have the impact that sysop stuff will temporarily be harder to deal with (stewards and global sysops probably won't protect a page during an edit war, for example), so yes I would say that a restart would place the wiki into some kind of "state of national emergency" in some ways. If wikis were countries, I would compare a restart to a real-life revolution where the military (global sysops and stewards) temporarily takes over after the removal of the former dictator. I think 75% is already the threshold that wikis sometimes apply anyway (e.g. Commons); perhaps a steward can tell us what threshold they usually use to check if there is community support? It does seem better to elect no admins at all than to spoil the second chance by reelecting admins who will abuse their power again. darkweasel94 (talk) 21:28, 18 September 2013 (UTC)

One way to break the deadlock might be: if no candidate reaches 75%, promote n candidates with the highest percentage. N would need to be a small number (1 seems safe enough :-) ), and there should be a cap on the number of admins that can be elected this way (max. in the first 6 or 12 months). GregorB (talk) 22:25, 18 September 2013 (UTC)

Admin candidates during which time period should be elected like that? After 6 months in my proposal the higher threshold would go away anyway. darkweasel94 (talk) 22:26, 18 September 2013 (UTC)

OK, 6 months, striking the 12 months. It seems to me that 6 months without a local admin (in the worst case) could mean 6 months of rape and pillage (to use your analogy with a country), so deadlocks in this period might be problematic. GregorB (talk) 22:33, 18 September 2013 (UTC)

Well, what would the procedure be exactly? After six weeks of steward rule, people start requesting adminship. No request is successful in the first x months, and then the most successful admins get promoted, but we have to find a value < 6 for x, and also consider that these can well be exactly those the old admin cabal wanted to get promoted. (Sorry if that doesn't make sense, I'm pretty tired already.) darkweasel94 (talk) 22:42, 18 September 2013 (UTC)

No, makes perfect sense. I joked about n=1 - this may well be someone associated with the old cabal, and this time he or she has total power. Still, promoting the top n editors might be left as an option at the discretion of the stewards, and activated no sooner than 3 months after the reset. This would ensure that, even in the worst case, the "state of emergency" does not last longer than 3 months.

When I said this was "tricky", I meant two things: 1) there are lots of details one must take into account, and 2) one would not like to cripple the community and throw it into chaos, or unduly impose things from the outside, as much as is one would not like to make the process ineffective in correcting the initial problem. These aspects may be difficult to balance in a general case, and that's why I feel that the process should have both mandatory and optional steps. Optional steps, taken at the discretion of the steward or triggered by certain circumstances, would give the process more flexibility and thus more chance to succeed without unduly stressing the project. GregorB (talk) 09:15, 19 September 2013 (UTC)

Regarding the recent changes

@User:Sj, User:Darkweasel94 - some remarks about the recent changes (cumulative diff) to this proposal and a bit of my line of thinking here:

• While I was initially reserved myself about the idea to lift all bans (see top of this page), I find this preferable to the latest suggestion because:
  • Manually classifying all bans into vandalism/non-vandalism would be a very big task, while...
  • ...it would have achieved very little, as whoever wanted to vandalize and spam merely had to open another account, so the risk of "setting all the prisoners free" is actually very low.
• I agree with the "probation" concept though - editors with a history of pre-reset blocks can and should be treated as repeat offenders if they commit further violations. The validity (or lack thereof) of previous blocks should be reviewed as necessary.
• I'd send everyone a mail, not just those with 5 or more edits. (I guess vandals don't register their emails on wiki.) In the hr wiki evidence page, we found an example of an editor who was indef banned after making a single good faith, non-policy violating, non-harmful edit.
• Admin elections immediately after the reset are problematic. (I could elaborate on this.) I'd say a moratorium of at least three months is needed for admins, possibly even 6 months for checkusers.
• Admin and checkuser election thresholds have to be at least 66% and 75% respectively, non-alterable by the local community for at least one year after the reset. Lowering the thresholds for any reason (to say 50%) runs the risk of quickly and reliably recreating the pre-reset conditions.
• Ground rules for voting eligibility will have to defined.
• Abusing sockpuppets for purposes of voting should carry a mandatory indef ban. (Is this the SOP in more or less all wikis?) Checked by neutral off-site CUs at least until local CUs are elected.
• 5 or 10-year moratorium on resets is problematic. (I could elaborate on this too.)

I'm going to write a more fully fleshed out alternative proposal and post it here by the end of the week hopefully. GregorB (talk) 21:14, 4 November 2013 (UTC)

CU and OS are actually governed by the global policies: m:CheckUser policy and m:Oversight policy. Among them is a 70% and 25 votes for support minimum. Of course, local projects are still allowed to set higher standards (but not lower standards). --Rschen7754 06:37, 5 November 2013 (UTC)

Also, there is the option of electing temporary sysops to keep the wiki running before permanent sysops are elected; they last for 3 months (or 6 months, or 1 year). A wiki can also be made a GS wiki and allow non-controversial actions from stewards and global sysops. --Rschen7754 06:40, 5 November 2013 (UTC)

Thanks Gregor for these thoughts. I agree with all of your comments, they make sense. I wasn't the one who suggested a moratorium; I just changed it from '10' to an unspecified number of years. But I'd be fine with not including such a clause at all, at least not until the issue arises in practice. –SJ talk  01:04, 7 November 2013 (UTC)

Yes, I noticed you changed this paragraph, which led me to assume you had doubts about the originally proposed 10-year period, and that's why I mentioned this subject. Same as e.g. admin recall: we don't want repeated votes and drama, but on the other hand, does moratorium on recalls after an unsuccessful one means total immunity against complaints in this period? My best guess is that whoever decides on project restart will take previous resets into consideration when considering repeated requests, and that no explicit moratoriums are required. GregorB (talk) 08:59, 7 November 2013 (UTC)

Been too busy with both hr wiki and RL stuff recently. The case for hr wiki reset just got stronger (there is now a doubt that CU process has been subverted), so I'll get back to this issue by the end next week (well, hopefully). GregorB (talk) 10:24, 14 November 2013 (UTC)

Unfortunately, I don't think I'll be drafting an alternative proposal, unless there is renewed interest in this issue. Let me just enumerate what I feel are high-level requirements:

• Restart has to be radical if necessary, to ensure things don't simply go back to pre-restart state.
• On the other hand, it is desirable reduce both the degree and the duration of disruption of regular activities.
• Restart has to be neutral in a sense that it does not favor status quo over changes, or vice versa.
• The process has to be tamper-resistant, so that it can't be subverted by individuals or cliques that attempt to unduly influence it either by gaming the system or violating the rules outright.
• The restart process has to be given enough time.
• The community still makes all the decisions about admins and other user rights, policies, etc., but does so in a controlled way.
• Banned users are accepted back. This is important in cases when there is a suspicion of bans being abused in the past.

Easy to say, not easy to implement... GregorB (talk) 17:27, 3 February 2014 (UTC)