User talk:Barkeep49/ARBPOL amendment sandbox

Petition time

• Shall we just get rid of the petition phase? I feel like that's the oddest part of the whole process and doesn't fit well with the identical quorum provision. – Joe (talk) 07:05, 18 May 2023 (UTC)

  I think if we have a bureaucratic ratification process, it shouldn't be allowed to be started by anyone on a whim. Especially if we institute a minimum voting period and requirements to close. I would support reducing the petition requirement to 50 votes to make it less tedious. But it's nice to have all ratifications be reasonable proposals that can be advertised on the Watchlist. Galobtter (talk) 07:34, 18 May 2023 (UTC)

  Good point, though perhaps something that could be dealt with through WP:IAR, as we do with hopeless RfA noms? But failing getting rid of it completely, I would support lowering it to 50 or lower. There is something off about having proposers gather 100 people in support of something before the vote even starts, when 100 is also enough for the the vote to succeed. It makes it a bit of an uphill battle for the opposition. – Joe (talk) 08:30, 18 May 2023 (UTC)

  I wouldn't oppose lowering it to 50, but I don't see the current values not as creating an uphill battle for the opposition; instead it guarantees that any proposal that is brought to a vote has sufficient community support to have a reasonable chance of passing. BilledMammal (talk) 13:14, 18 May 2023 (UTC)

  I mean, it objectively does. Consider the current vote. Most people opposed to the idea would not have paid much attention to the petition, because it explicitly asked for a list of people who support the idea and nothing else. When the voting started, we had to race against time to articulate a counter-argument, while the hundred people who'd already decided to vote "yes" simply trickled in to get the count up to the required figure. And surprise surprise, the amendment has already technically passed, just over 24 hours after it was proposed. Please note I'm not saying that the proposers of the current vote did anything wrong, it's just obviously a bit of an unbalanced system. – Joe (talk) 14:10, 18 May 2023 (UTC)

  @Joe Roe I endorsed the petition, as it seemed feasible, germane, and relevant - not because I thought it should or shouldn't pass in a vote; just that it wouldn't be a waste of community time to have such a vote. — xaosflux ^Talk 15:21, 18 May 2023 (UTC)

  Seems you're in the minority there. By my count, 57 of those who signed the petition have voted, and only one of them voted no. Funnily enough, there are exactly 56 more yes votes than no votes at the moment. – Joe (talk) 07:15, 22 May 2023 (UTC)

  @Joe Roe how would your feelings about this change (or not) in conjunction with increasing the number of people who have to support the ratification of the amendment and/or upping the support %? Barkeep49 (talk) 20:06, 24 May 2023 (UTC)

  Yeah, I think it's the 100–100 thing that really sticks out to me as odd. I understand the rationale for the petition phase, but the bar for then passing should then be higher. – Joe (talk) 09:32, 25 May 2023 (UTC)

  I don't support getting rid of the petition. If we're getting rid of Jimbo as a (rather ineffective) check on ArbCom, getting rid of the community's check on ArbCom (being able to petition and vote for a change, something beyond "wait until the next election") doesn't seem a good idea. Wehwalt (talk) 13:01, 18 May 2023 (UTC)

  That's not what I'm suggesting, I'm saying we allow proposed amendments to go straight for a vote without the extra step of gathering one hundred signatures. – Joe (talk) 14:04, 18 May 2023 (UTC)

• I think the petition phase is useful, to avoid bothering the community at large with frivolous votes. We often get definantly-not-ready-for-primetime RFC at the VP's. — xaosflux ^Talk 14:35, 18 May 2023 (UTC)

  I agree with xaos. Best, Barkeep49 (talk) 14:59, 18 May 2023 (UTC)

• I'm fine with some reasonable maximum time limit to gather 100 endorsements, 1 month seems to be reasonable there. — xaosflux ^Talk 15:23, 18 May 2023 (UTC)

Ratification time

• Either 2 or 3 is acceptable. They are simple and easy to understand. Options 1 isn't bad, except that I'm not quite sure that "in good standing" means. Option 3(alt) is just too complicated. -- RoySmith (talk) 10:28, 18 May 2023 (UTC)
• I would be in favor of a soft-limit closing time; it should be at least 30 days, but if there is still active discussion at 30 days, then it should remain open until the active discussion has clearly stopped; say 1 week or so. I don't like the idea of hard limits, which are subject to WP:GAME. --Jayron32 11:01, 18 May 2023 (UTC)
• What I like about the current rules is it allows a rapid response to ArbCom overstepping; while in many circumstances there is no urgency that isn't the case in all circumstances. Perhaps if we changed the rules so that if the proposal affects any active remedies or open cases the remedy or case is suspended so long as the vote is open and has more than 45% support?

The quorum requirement would prevent this being abused, but I can still see some issues with it and there may be a better solution. BilledMammal (talk) 12:59, 18 May 2023 (UTC)

Perhaps have a default time but allow the proposal to set a shorter closing time, though the quorum requirements could not be changed and it shouldn't be less than 7 days. The shorter closing time would be part of the package that people would vote on. Wehwalt (talk) 13:04, 18 May 2023 (UTC)

@BilledMammal @Wehwalt does Option 3 alt 2 capture this thinking? Best, Barkeep49 (talk) 14:58, 18 May 2023 (UTC)

In concept, yes. Maybe also something like "If at any time after one week, the margin either for or against reaches 100 and remains there or higher for 24 hours, the matter will be deemed closed." That is the equivalent of SNOW (or, perhaps, the mercy rule) and the time period it has to stay there is a protection against gaming. Wehwalt (talk) 15:12, 18 May 2023 (UTC)

One of the great virtues, for me, is how simple the language is in ARBPOL. I think this new clause already is more complex than ideal and so adding further clarifications would only make this worse. If something is non-urgent and clearly going to pass, we can either IAR or just take down notifications of it and let the clock run out. Best, Barkeep49 (talk) 15:15, 18 May 2023 (UTC)

Yes - and we have seen something similar work before, in the 2022 Banners RfC - although I think it needs some wordsmithing. Perhaps: The ratification process will run for 30 days unless a shorter period, which may be as short as upon reaching the minimum thresholds, is included in the proposal. BilledMammal (talk) 15:23, 18 May 2023 (UTC)

Sure. But also people should feel free to make edits on the ideas page. Idea is to keep discussion here so the brainstormed ideas don't get lost/overwhelmed. Barkeep49 (talk) 15:25, 18 May 2023 (UTC)

• While recognizing and agreeing with their intent, I really, really dislike options 3-alt-1 and 3-alt-2 as written. They both have just about all of the drawbacks of the current system ("amendment passes as soon as it meets the quorum and support thresholds, unless everyone's too timid to close it"). 3-alt-1 is the same as the current requirements to pass, so if - as seems very likely - we have everyone in favor saying "pass immediately once it meets the minimums" and everyone opposed saying "let it run the full 30 days", both the close-as-passing and close-early requirements will be met at the same time. 3-alt-2 is still vulnerable to an early rush organized off-wiki, though at least they'd have to subvert the stage-1 petition too.
  If 30 (or even 7!) days is too long for our hypothetical doomsday scenario and we really want to provide for that, we can do so by having increased thresholds to close early. For example, if we keep 50%+1 with 100 minimum supports, the voting stage has to stay open for 30 days; 67%+1 with 200 supports can close any time after the first 7 days; 80%+1 with 500 supports can close immediately on passing. (I haven't given particular thought to the specific numbers.) —Cryptic 01:20, 19 May 2023 (UTC)

  @Cyptic: so would combining isaac's idea below with this suit you? Something like 30 days or a net of 100 supports more than oppose, whichever comes first. Barkeep49 (talk) 20:23, 24 May 2023 (UTC)

Number of supports

• I like the idea of a dynamic number and so my favorite is 10% (rounding up) of the ACE participants. I think RfA could see some substantial changes and having it be based on a less related process doesn't strike me as good of an idea. Barkeep49 (talk) 01:31, 18 May 2023 (UTC)
• I think a minimum number of total votes (quorum) plus a somewhat higher support percentage than 50%+1 would be a good approach. I've been toying with the idea of a net vote threshold, but I think it's simpler to set a quorum. isaacl (talk) 01:44, 18 May 2023 (UTC)

  That's an interesting idea. 200 becomes a far more reasonable number if it's supports and opposes. Barkeep49 (talk) 01:51, 18 May 2023 (UTC)

  This seems more gameable than what we currently have. If, say, there's well over a hundred supports but that number's been holding steady for a while, and we're still short of the total quorum, then voting in opposition is more likely to make the motion pass than doing nothing. You don't want a situation where an amendment with a 110-90 vote would pass but one with 190-0 would fail, and you especially don't want one with 190-0 and 90 fake "I'm not officially opposing because it hurts my position, so I'll just give all the reasons I think this is bad down here in the Community Discussion section instead" comments to fail. —Cryptic 02:59, 18 May 2023 (UTC)

  I was thinking of this idea myself, but you raise reasonable objections about the issue of a boycott. I think I like Barkeep's idea of a dynamic number and would agree with 10% as a reasonable figure; currently that would be 157 supports. BilledMammal (talk) 13:09, 18 May 2023 (UTC)

  That is still by favorite option in this category by a fair margin. The only issue I could see is that if we ever had an emergency election we have no idea how many voters we'd get for that (and/or how many we'd get in the next regular election). But I think that's truly unknowable and not a reason to stop this on its face. Best, Barkeep49 (talk) 15:01, 18 May 2023 (UTC)

  I still would rather set a quorum by some past participation metrics than an absolute support count. Maybe a quorum of something like 20% of the average of the last two arbitration committee elections. isaacl (talk) 15:36, 18 May 2023 (UTC)

  I think gaming the system with comments instead of votes can be handled, since it's the weighing in that matters for determining consensus. A complete boycott can be handled by counting any shortfall in quorum as opposes. isaacl (talk) 14:28, 18 May 2023 (UTC)

  I think isaacl's idea is a really interesting one to avoid the gaming aspects of a general support+oppose quorum - I think it would be a good way to mitigate the issue while keeping the positive. Nosebagbear (talk) 15:43, 18 May 2023 (UTC)

  Pretty sure counting the shortfall on a quorum of support+oppose as opposes is exactly equivalent to a quorum of only supports half as large (or 60% as large or whatever, if the goal percentage is changed). Which is exactly what we have now, except less confusing and much more concise. —Cryptic 00:07, 19 May 2023 (UTC)

  I think a support percentage is more commonplace than an absolute number of supports, and I think being able to adjust the support level based on a percentage is a better match for what many people consider than adjusting an absolute support level. So though of course the two methods can be used to produce similar results, I think the quorum + support percentage approach is a more familiar approach. isaacl (talk) 00:25, 19 May 2023 (UTC)

Support %

• Potentially unpopular opinion but if we fix the ratification time issues and raise the number of supports, I'm not sure we need to raise the support %. The extra steps and safeguards with ARBPOL, compared to other policy changes, would be sufficient for me. Barkeep49 (talk) 01:31, 18 May 2023 (UTC)

  We don't want to make it too easy to change fundamental rules, but, yeah, I can see requiring a broad participation making it less important to rely on requiring a super-majority to protect from overly-drastic changes. I still feel that a 50%+1 criteria could be a problem. I will note that the current trend of the admendment carrying by more than 2 to 1, if it continues, would preclude any questions about the legitimacy of the results. Donald Albury 01:52, 18 May 2023 (UTC)

  I don't like 50% + 1 because it puts an emphasis on turning out every last vote. I'd rather have a somewhat higher than 50% threshold (combined with a quorum) so the community can be reasonably assured that the result wouldn't change by adding a few more days and more vote-whipping. isaacl (talk) 01:55, 18 May 2023 (UTC)

  This is the only thing I feel strongly about. A simple majority is just too low a bar for such an important decision. Even relatively minor questions like "Should User:X become an admin?" require a supermajority. I don't know which of 3/5 or 2/3 is preferable. I'm thinking 2/3, if only because that would put this in line with RfA. -- RoySmith (talk) 10:33, 18 May 2023 (UTC)

  For this, I have faith in the quorum requirements; I trust the community, and if the majority of the community wants to change the nature of ARBCOM then that is good enough for me. It also matches the requirement for arbitrators, which allows them to be elected with 50% + 1 support. BilledMammal (talk) 12:51, 18 May 2023 (UTC)

  There's also something galling about a vote passed with a requirement of only a majority that provides it can't be changed except with a supermajority. Wehwalt (talk) 13:10, 18 May 2023 (UTC)

  I think with a quorum requirement, there is more reason to believe that the vote is a reasonable sampling of the interested members of the community, and thus am OK with a lower threshold than those. I'd support something just a little higher than 50% in order to accommodate jitter in the vote totals. isaacl (talk) 14:38, 18 May 2023 (UTC)

  We could use a percentage one, or a "leading by X votes" one. E.g. In a 99-99 tie, a close couldn't occur until it was 109-99. Nosebagbear (talk) 15:44, 18 May 2023 (UTC)

• We let someone get on arbcom, and basically have lifetime CUOS, with 50%+1 vote, arbcom remedies pass with 50%+1 vote - this is a special area as it is the last step of dispute resolution, and the ability to get a result is important. — xaosflux ^Talk 18:50, 18 May 2023 (UTC)

When to propose changing the amendment process

Personally I would prefer altering the amendment process on its own. Bundling it with another unrelated change will make it more likely that both changes will fail to pass. isaacl (talk) 01:50, 18 May 2023 (UTC)

In addition, I don't think we want to be debating the process at the same time as using the process; it could result in a race condition situation, where if the process debate is closed first the primary proposal fails, but if the primary proposal is closed first it passes. BilledMammal (talk) 13:26, 18 May 2023 (UTC)

If bundled together, I don't think it is feasible to try to use the modified process at the same time. Technically speaking the process should not be in effect until after the bundled proposal is approved. (If the two are going to be run with separate petitions and votes one after the other, then I don't see the advantage of waiting until then to change the amendment process.) isaacl (talk) 14:14, 18 May 2023 (UTC)

I think it would probably be best to run the changes simultaneously but distinctly, with it being clear that the status quo amendment methodology is used for all the referenda. It will be easier to avoid not reaching the high thresholds if people are able to vote on them all at once. Nosebagbear (talk) 15:46, 18 May 2023 (UTC)

I thought I read something about holding this discussion at the same time as the next general proposal to modify ARBPOL, but I can't find that line at the moment. I agree that it would be fine to run all the procedural proposals at the same time, if it is clear that the status quo methodology is the one used. BilledMammal (talk) 15:51, 18 May 2023 (UTC)

If we think the process issues are significant enough to be a problem with the next proposal to modify the arbitration policy (regarding something other than the amendment process), then it would be good to resolve those issues before then. isaacl (talk) 15:56, 18 May 2023 (UTC)

Reduce hoops and barriers

I'm not sure I understand why we need more hoops and barriers for this than any other policy in Wikipedia. Is the bulk of arbcom policy more important than WP:NOT or WP:V?

I mean if we want to get technical, the main reason arbcom cases are done the way they are is because early arbcoms members were far fewer and several also happened to be lawyers (my rusty memory vaguely recalls Fred Bauder had a significant hand in it and often clerked cases). We could probably dispense with all the bureaucracy if we wanted to. I'm not saying do that, by the way, I can see some value in our current system. But I think we need to be careful with the idea that arbcom is anything "more special" than anything else in the community.

If you want to set a minimum number of contributors to a discussion, I'm fine with that.

But I don't think any number of gatekeepers is going to prevent pitchforks if the community is so inclined. But set it for whatever value you think keeps arbcom policy safe from the pillaging hordes.

Where I am most concerned is any process that moves away from WP:CON.

I see absolutely no reason why an arbcom policy discussion is any different or needs any more process than what the community did here, for example: Wikipedia:Verifiability/2012 RfC.

If you want to make the closer 1 or more bureaucrats and in "close" closes, to have a crat chat, so be it. We already have those processes in place and trusted people in those positions who already know how to close discussions. - jc37 02:31, 18 May 2023 (UTC)

I think the fact that it seems like all RfCs that are high attendance end up appealed would argue against make it a straight, nebulously defined, RfC. Best, Barkeep49 (talk) 02:34, 18 May 2023 (UTC)

That's usually more a problem of the framing of the premise than the RFC. If you want to provide a helpful (optional) template for proposers, that not necessarily a bad idea.

And besides that, one could argue that that is a feature not a bug.

And we definitely shouldn't be avoiding WP:CON, because it's "easier". That's what WP:IAR is for. It exists in conjunction with WP:CON. There are solid reasons for that too. - jc37 02:38, 18 May 2023 (UTC)

I don't think we should put all our eggs in one basket. Consensus decision-making works for us 99.9% of the time, but ArbCom exists for that 0.01%. In a scenario where consensus is systematically failing to produce good outcomes (e.g. because of a moral panic), a bit of bureaucracy making it harder to spread to ArbCom is no bad thing. – Joe (talk) 08:09, 18 May 2023 (UTC)

That Abcom deals with things the community hasn't, has to do with Arbcom's remit as a behaviour-addressing body. This is about the creation or modification of Wikipedia policy related to Arcom. There is simply no reason that this policy should be treated any different than any other policy on Wikipedia. - jc37 13:34, 18 May 2023 (UTC)

For procedural policies that aren't affected by other policies I do wonder if a pure vote is better than a consensus system. Per WP:DETCON, Consensus is ascertained by the quality of the arguments given on the various sides of an issue, as viewed through the lens of Wikipedia policy. When there are no relevant policies, such as when there is a discussion about the nature of ArbCom, I don't think a closer is better positioned to assess the quality of the arguments than the voting editors themselves. BilledMammal (talk) 13:59, 18 May 2023 (UTC)

The editors are not and should not be called "voting editors". They are contributors to a discussion. And while contributing, they indeed do that.

And once the discussion is "over" (however that is determined), then a closer looks at the discussion to see if the community has come to a consensus. When there is also existing/broader policy and common practice, the closer weighs that, as well. If there isn't, then there is nothing "extra" to be weighed. - jc37 14:22, 18 May 2023 (UTC)

If there isn't, then there is nothing "extra" to be weighed. If there is nothing extra to be weighed then I can't see a basis for the closer to go off anything other than a straight vote count, which is why I think explicitly using a pure vote system in such circumstances is a good idea as it simplifies the close and removes the possibility of a supervote. BilledMammal (talk) 15:00, 18 May 2023 (UTC)

discussions are more nuanced than merely a "vote count". If what you said is true, then it would be true for any and all discussions on Wikipedia. - jc37 15:35, 18 May 2023 (UTC)

Most discussions are influenced by policy, and it is that the closer is expected to take into account to prevent issues such as WP:LOCALCONSENSUS. When they are not influenced by policy I'm not sure what else the closer is supposed to take into account. BilledMammal (talk) 15:53, 18 May 2023 (UTC)

The discussion itself. A discussion is not about "drive by voting". There are plenty of DRV discussions (for example) where new users find out that that is true. - jc37 16:14, 18 May 2023 (UTC)

Voter qualifications

While only a very few IPs have voted so far, if we're going to look at amendments, we should look at who the voters should be. It might be simplest to say that if you haven't reached autoconfirmed, you can join the discussion but not vote.--Wehwalt (talk) 12:25, 18 May 2023 (UTC)

I would prefer if we didn't disenfranchise established IP editors, but I recognize that is probably a losing battle given the existing proliferation of EC restrictions. BilledMammal (talk) 13:02, 18 May 2023 (UTC)

The problem is how to identify established IP editors. Does someone volunteer to scrutinize each one, and what standards do they use to validate if they are established? isaacl (talk) 14:16, 18 May 2023 (UTC)

Autoconfirmed seems fine enough. IP (soon to be masked IP) just lacks accountability, even if you are currently buying one static IP - you likely have access to many, and you can always stop buying or ask to have your IP changed. — xaosflux ^Talk 14:37, 18 May 2023 (UTC)

Ultimately we have a literal handful, if that, of genuinely established IPs. I'm not sure what methodology we'd use to authorise a handful of manual signoffs. We can find one that works - perhaps 2 'crats concur, with each 'crat only being able to signoff on 3 IPs. But the complexity might outweigh the gain, depending on how we view any ethical aspects. The outliers notwithstanding, autoconfirmed would be good. Presumably our normal rules would suffice to strike any who are socking. Nosebagbear (talk) 15:50, 18 May 2023 (UTC)

I also support requiring autoconfirmed. We want as clean a count as possible in case of a narrow margin (passing or failing). Donald Albury 21:33, 18 May 2023 (UTC)

Autoconfirmed is so lax a standard that it isn't one at all. If someone registers an account the day an amendment vote begins, and votes on it four days later as their eleventh edit, they're autoconfirmed. And they'll likely get reverted and blocked as "someone's obvious sock", no matter how bland their vote or their first ten edits are. That's a far worse experience for a previously stable-ip anon.

Seems to me we already have reasonable suffrage requirements worked out - the same as for arbcom elections: account registered at least two months before the voting stage begins, 150 mainspace edits ever and 10 in any namespace in the past year as of a month before, not fully blocked, and not a bot or named "Vanished" or "Renamed". (I can see arguments either way for writing those current requirements into arbcom policy and requiring another amendment if they change substantially and we want to track those changes, or "was eligible to vote in the previous arbcom election".) And if that's too complex - I don't think it is, considering those checks can be automated (and likely doable for every user who's edited the vote page in a single query) - extendedconfirmed is trivially easy to check, though a higher requirement in most respects. —Cryptic 00:30, 19 May 2023 (UTC)

While I would support requiring extended confirmed, that may not have enough support. Using the same criteria as those for arbcom elections might work, but, would we need scrutineers for that? Donald Albury 12:05, 19 May 2023 (UTC)

I don't think scrutineers would be needed as the votes are not secret ballot in a ratification referendum. Anyone could deal with an ineligible voter and if there's any question, normal discussion should take care of it. Wehwalt (talk) 13:39, 19 May 2023 (UTC)

To avoid concerns of selective examination of qualifications, it would be best for the qualifications of all voters to be validated. I imagine, though, some volunteers will step up to do it (just as volunteers prepare the voter roll for the arbitration committee elections). isaacl (talk) 16:30, 19 May 2023 (UTC)

Putting on my cynic hat, and knowing this is pointing to more bureauracy, but who will validate the qualifications of the validators? Ideal would be for several respected editors to individually check qualifications, and agree on all evaluations, but, well, the functioning of Wikipedia is rarely ideal. Donald Albury 18:33, 19 May 2023 (UTC)

I feel like this is one of those "it works in practice (ACE) but would never work in theory" situations (of which the whole of Wikipedia is another). Best, Barkeep49 (talk) 18:35, 19 May 2023 (UTC)

Revert to what I said and the caterpillar doesn't trip and fall through excessive discussion of proper walking technique. Wehwalt (talk) 18:38, 19 May 2023 (UTC)

As far as I know, the voter roll is generated through a query, possibly with postprocessing (see Wikipedia talk:Arbitration Committee Elections December 2022/Coordination § Voter eligibility list for Cyberpower678 and Xaosflux co-ordinating on it). The list of names is openly provided so anyone can cross check it. isaacl (talk) 20:20, 19 May 2023 (UTC)

If we go with "was eligible to vote in the last yearly election" instead of "would be eligible to vote in a yearly election if one was happening now instead of an amendment", then we'd have to ensure a similar list was created and preserved every year. Some of the requirements are hard to reconstruct for a specific point in the past. The block and deletion logs, for example, are set up so they're easy for a human to read and tell if a given edit was live or account was blocked on such-and-such a date; they're not set up to be easily or quickly parsable by a program or query. Whether an edit is live or account is blocked right now are.

Also might be problematic for accounts that are renamed between an election and amendment. —Cryptic 00:08, 20 May 2023 (UTC)

I don't think anyone's suggested using the voter roll from the previous election. I agree that a list generated specifically for the amendment vote would be easier to manage. isaacl (talk) 00:35, 20 May 2023 (UTC)

Everything except I guess weird edge cases is indeed automateable. —Cryptic 19:09, 19 May 2023 (UTC)

Overturning Arbcom judgements

Moved to Wikipedia:Village pump (idea lab)

@Adam Cuerden, Wehwalt, Isaacl, BilledMammal, Newyorkbrad, Izno, Nosebagbear, Donald Albury, and ProcrastinatingReader:: I've copied this to the VPI because it feels at risk of overwhelming the discussion above. Barkeep49 (talk) 16:18, 26 May 2023 (UTC)