Generalizing AC Appeals and using this procedure for recall. #888

frivoal · 2024-06-18T12:29:27Z

This PR is a first draft attempting to address ~~#886 and~~ #882. ~~Neither have~~It has not been resolved on at this point, but this shows what adopting ~~them~~it could look like.

It can be reviewed as a whole, or commit by commit~~, to distinguish the effects of #886 from those of #882~~.

update: #886 has been handled separately, removing discussion of it from this pull request.

Preview | Diff

index.bs

TallTed · 2024-06-18T22:05:51Z

index.bs

+	A single [=Member=] or group of [=related Members=] cannot re-invoke this process
+	sooner than 6-month since their previous invocation,


It's unclear when the six-month timer begins. So, this —

Suggested change

A single [=Member=] or group of [=related Members=] cannot re-invoke this process

sooner than 6-month since their previous invocation,

A single [=Member=] or group of [=related Members=] cannot re-invoke the [=recall=] process

less than six months following the conclusion of their previous invocation,

— or this —

Suggested change

A single [=Member=] or group of [=related Members=] cannot re-invoke this process

sooner than 6-month since their previous invocation,

A single [=Member=] or group of [=related Members=] cannot re-invoke the [=recall=] process

less than six months following the initiation of their previous invocation,

I meant the second one, but it seems to me that the existing phrasing already is unambiguous (and shorter). Can you help me understand why you think it's not clear?

why you think it's not clear

Uh... because it wasn't clear to me, after reading several times. Hence my comment, and alternate suggestions.

It matters, because if the process initiated on 2025-06-01 takes 2025-09-15, re-invocation request might not be accepted until 2025-12-01 or until 2026-03-15. It's important to be able to calculate which date applies.

I think the key to me is that "invoking" is a point in time, at the start, not a period, just the same way "initiating is" (with the nuance that invoking is more specific: it's initiating by saying something).

So, your second phrasing matches what I meant, but to me it feels redundant: at the since the start of the beginning of the initiation of the invocation… ;)

I think that your phrasing is ambiguous enough that it could be read as starting the six month timer at conclusion of the previous invocation, which would be certain to prevent overlapping recall process runs, which seems a likely reason for this timer.

Starting the timer at "invocation time" leaves the potential of overlap, if an early run takes longer than 6 months (which seems possible if unlikely).

It might help to include a reason for this required time lapse?

Suggested change

A single [=Member=] or group of [=related Members=] cannot re-invoke this process

sooner than 6-month since their previous invocation,

A single [=Member=] or group of [=related Members=] cannot re-invoke the [=recall=] process

less than six months following the start of the process based on their previous invocation,

It might help to include a reason for this required time lapse?

Generally, if you ask for a recall and the motion does not pass, being able to ask again and again has more to do with harassment than with accountability, even if you target different subsets of the elected body every time, so we should try to prevent it. However, if new facts come to light, asking for another recall might be appropriate.

if an early run takes longer than 6 months (which seems possible if unlikely).

I don't think it is or should be possible:

first someone invokes the recall

Within one week, the Team must open a poll to see if there's support

Withing one week of that, if we don't reach 5%, it's over, and if we do, we launch the full recall vote

after the vote, the procedure ends, and there's no recourse

It is true that the Process doesn't specify how long the vote should stay open, but a 6 month balloting period is unheard of and would be unreasonable. Maybe we should encode into the Process that the ballot stay open for 28 days, which is a typical duration for that sort of things (e.g., that's what was used for the EME AC Appeal)

index.bs

chaals · 2024-07-02T17:40:54Z

An alternative mid-ground would be stating a "supermajority" threshold: twice => > 2/3 or 67%, thrice => > 3/4 or 75%

frivoal · 2024-07-03T03:14:57Z

@chaals, I'd rather not phrase it this way, because when you just say "supermajority of 2/3" or some such phrasing, it's ambiguous how you treat abstain ballots. You can make it clear, but that usually make the phrasing longer and clunkier, which is why I think "x times as many ballots for as against" or that sort of phrasing is better.

TallTed · 2024-07-26T16:34:01Z

index.bs

@@ -1318,6 +1350,9 @@ Elected Groups Vacated Seats</h5>
 		<li>
 			the participant resigns, or

+		<li>
+			the participant is [=recalled=], or


These "or" list items should be rewritten, with a new lead-in —
An [=Advisory Board=] or [=TAG=] participant's seat is vacated when any of the following occurs:
— and all of the , or should be removed from the <li> that follow. GitHub won't let me make a suggestion that reaches so far above and below the lines changed by this PR. If need be, I'll submit a PR for this, but I'm hoping this comment will be sufficient for you to adjust #888.

index.bs

This extracts the 5% confirmation vote, followed by the actual vote into a separate procedure, invoked by the AC Appeal, making it reusable. Co-authored-by: Ted Thibodeau Jr <[email protected]>

See w3c#882 Co-authored-by: Ted Thibodeau Jr <[email protected]>

Also enable individual removal of problematic participants by the body itself w3c#882

frivoal · 2024-12-06T08:40:14Z

I've updated this draft PR to reflect my current take on this issue, as expressed in https://github.com/w3c/AB-memberonly/issues/237#issuecomment-2354297741.

frivoal · 2025-01-20T07:45:22Z

The AB has not reached a conclusion on this topic. Temporarily removing agenda+

martinthomson

I don't spend a lot of time with this part of the process and there are a few comments here that reflect that. Feel free to defer those to issues if you would prefer not to engage with them.

martinthomson · 2025-01-31T03:32:43Z

index.bs

+	If at least three quarters of the participants in the group,
+	excluding the individual who is the subject of such vote,
+	then vote in favor of the proposal,
+	the individual's seat on [=AB=] or [=TAG=] is [=vacated=] immediately.


I would say that a lower threshold is sufficient. A simple majority might suffice in this case.

Consider this: if there are three people who are willing to raise this, then that alone is indicative of dysfunction in need of remediation. Removal should not be the first option there, but if you need it, then there is a chance that some people will be forced to recuse or some will be absent, making it quite difficult to reach 3/4.

I disagree. I think it should take a strong supermajority to eject someone. We want to stay clear of the possibility that someone gets kicked out (or simply fears getting kicked out) simply because half the group disagrees with them (and lacks restraint).

Making an allowance for people who need to recuse could make sense, but I don't think it should be possible to kick out someone just because some of their supports didn't show up that day. It is an extraordinary measure, and I find it appropriate for it to need an extraordinary level of support.

What might be more appropriate is that for the vote to succeed, all members of the elected body must participate (avoiding the issue of "my supporters didn't show up), and thus for the proposal to carry a simple majority is sufficient. Not requiring every member to participate is where risk is introduced. To be additionally clear, abstaining is acceptable.

Exclusion by simple majority seems inappropriate to me for something that amounts to a disciplinary procedure. In cases where it is warranted, reaching a significant super majority (everybody but a friend or two) should be doable.

Simple majority seems far too easy to reach for mere differences of opinion, which is not what this should be about.

I can make a different argument: those who initiate this process risk the wrath of the AC (and the other process whereby the AC loses faith in all the participants). They do so because they believe that they cannot continue to work with the identified person. They have to convince a whole bunch of other people -- half the body -- that this extraordinary disciplinary action is warranted. The result -- success or failure -- is then made public.

I've seen some dysfunction in groups, but never at this level. If it were the case that half the body wants someone gone, that's enough for me.

I would instead say that removal on the basis of convincing half a body is already too high a bar to clear.

Gaming out this scenario in my head based on the current process, I see one major issue with forcing a two thirds or three quarters majority for these groups in a few delicate scenarios. The process already has a provision for the CEO removing a member of the AB/TAG for either not conducting themselves to the standards of the body or to the organization (while not defined this way in the process, it's fairly clear this is to the standard of the code of conduct). With that already in place, I see this mechanism coming into play only in scenarios where there is a difference in opinion between the AB/TAG and CEO on the reason for dismissal. Why I find it concerning to have such a high bar as 7-8 out of a max of 11 vs simple majority (which would be 5-6) is the potential nature of a case where the CEO refuses to act on an issue.

I can see this becoming an issue in cases of the more grey areas of the code of conduct: bullying, continued harassment (especially microaggressions), or interpersonal misconduct. The code of conduct directs us to focus on impact over intent, but I can still see a scenario where a member of an elected body continually mistreats another member, and the impacted member goes to the CEO to have it addressed and is dismissed as it is viewed as "not so bad" or "just ignore them". In cases where this situation gets to the point where the person needs to take it to a dismissal process, having the 2/3 or 3/4 majority would require potentially convincing 7-8 people of the issue occurring, which puts significant strain on the person making the accusation. I worry we'd more likely see people choosing to leave the elected body for their own protection over having to put themselves through this kind of process.

EDIT: Just to be explicitly clear here, we need to view this process through the lens of the marginalized, we want diversity in our bodies, to achieve that we need processes that ensure the most vulnerable are protected.

There is a serious problem with enabling a simple majority of members to the rest of the entire body. If you enable a simple majority to eject members, those 5-6 members could eject everyone else off the body. This may seem like an extreme, and like "this would never be done" - but if that were possible in US politics, I think we all know it 100% would have been used by now. The bar for ejecting members should not be so low - it should be a strong consensus of the rest of the body.

The CEO is not the first port of call to address a case where there is mistreatment. The Chair should be. After that, perhaps the CEO, or perhaps first the ombuds. The entire body should be involved if necessary, but having to convince 2/3 of your colleagues is not the first step; and we should be selecting Chairs to be the necessary arbiters of fairness and justice.

We HAVE diversity in our elected bodies; and as deeply as I agree that we should view our processes through the lens of the marginalized, I want to ensure that we also protect against abuse of tools we put in place. If we don't believe that censure by the Chair will have effect, or that 2/3rds of the body won't care about abuse, then frankly we are likely to have a Bad Time regardless; but even then, we should not enable the body to be taken over by a simple majority.

I find that scenario less plausible than the one Wendy described. If the W3C ends up as badly dysfunctional as current US politics, I'll have taken my toys elsewhere long past.

Consider that the group needs to report the action to the community. Do that often and it will be abundantly clear to the entire membership.

we need to view this process through the lens of the marginalized, we want diversity in our bodies, to achieve that we need processes that ensure the most vulnerable are protected.

Well, that makes me double down on super-majority even more. Unless we are content with marginalized people being tokens of diversity who are welcome to be there as long as they don't say anything that might upset the status quo, we need to make sure that they are comfortable speaking up even if they're going to go against the grain.

If you have to weigh everything you say against the risk of being kicked out, then you'll say much less, even when what you have to say is legit. There should be a very high bar before kicking out someone who has been duly elected, and protecting the rights of minorities is among the reasons for that. Let's not risk a tyranny of the majority.

I also don't think it's appropriate in a governance document to assume that people will be well-behaved, and that what happens in other polities cannot happen to us. We're just as human as anywhere else, and the whole point of having formal governance is to deal with cases where things can go wrong. «I'll just move to [IETF | Canada] if things end up too dysfunctional» may be a comforting thought, but it isn't good governance.

This discussion is quite distinct from the rest of the points made about this PR. To try and keep things contained, I have split the PR in two, with this particular aspect being moved to its own PR: #986

martinthomson · 2025-01-31T03:34:35Z

index.bs

+	all seats on [=AB=] or [=TAG=] are [=vacated=] immediately;
+	if it fails, it cannot be invoked on the same body
+	sooner than 6-month since their previous invocation.
+


I think that in both cases, you want to include some sort of reporting responsibility. That is, there is an announcement that the seat is vacated.

There is no way to hide what is happened here and you don't want to have people learn via rumor mills. Information should be publicly communicated to the AC by the chairs or Team as promptly as possible.

Does this help?

Suggested change

The [=Team=] must announce the conclusion of the [=Advisory Committee Override=] to the [=Advisory Committee=].

That would be fine for the latter, but there is no requirement on the TAG/AB to announce when they act.

martinthomson · 2025-01-31T03:36:07Z

index.bs

+	An [=Advisory Committee representative=] initiates a [=vote of no confidence=]
+	by sending a request to the Team, and <em class=rfc2119>should</em> also share this request with the Advisory Committee.
+	The request <em class=rfc2119>must</em> identify which of the [=AB=] or [=TAG=] is targeted,
+	and <em class=rfc2119>should</em> also include the rationale.


I think that you want a three member threshold for this too. Otherwise, this is open to trolling and DoS.

I'd be OK with a higher threshold than three, but not a lower one.

If that takes the form of one AC member initiating an override that has to be seconded by two other members in all cases, that would be ideal. I know that this mechanism hasn't been activated, but it's an organizational vulnerability.

It already is a 3 stage thing:

someone calls for a vote of no confidence

we check if >=5% of the membership agree that we should run a vote of no confidence (within a time limit of 1 week)

if so, we run the actual vote of no confidence

Adding an "at least two people need to agree" seems redundant with step two.

I think that the second step is not feasible (you allow more time for the final vote, which only needs to clear the same threshold). So I am suggesting a replacement for that stage.

martinthomson · 2025-01-31T03:41:43Z

index.bs

@@ -1368,6 +1419,12 @@ Elected Groups Vacated Seats</h5>
 			and the maximum number corresponds to all unoccupied seats.
 			Except for the number of available seats and the length of the terms,
 			the <a href="#AB-TAG-elections">usual rules for Advisory Board and Technical Architecture Group Elections</a> apply.
+
+		<li>
+			If seats are vacated due to a successful [=vote of no confidence=],


I think that you want to set a threshold for triggering an election, not just have this for the no confidence vote. The bodies will likely function with a few gaps, but there is a critical point at which the groups are non-viable. I might suggest 2/3 of the target size as that threshold.

Suggested change

If seats are vacated due to a successful [=vote of no confidence=],

If vacancies reduce

the number of [=AB=] participants to 6 or fewer

or the number of [=TAG=] participants to 7 or fewer,

That seems like a separate discussion. The previous bullet point in this list already deal with the case of seats being vacated for reasons other than a successful vote of no confidence, by letting the chair decide whether to run an special election or not. Your proposal would make it no longer a choice by the chair, which may or may not be a good idea, but is a separate idea. If you want to pursue that, could I ask you to open a separate issue?

I sort of agree, but I don't think that you can separate that out completely. You are introducing new ways in which the membership of these groups can drop to critically low levels. Though we don't expect this process to be used often, in combination with existing stuff, you have increased the risk of the groups being understaffed. Staffed to zero is just one special case.

martinthomson · 2025-01-31T03:43:15Z

index.bs

+			the [=Team=] <em class=rfc2119>must</em> organize an election,
+			under the same condition as for individually vacated seats,


Suggested change

the [=Team=] <em class=rfc2119>must</em> organize an election,

under the same condition as for individually vacated seats,

the [=Team=] <em class=rfc2119>must</em> organize an election.

Vacated seats are filled for the remainder of the term of the vacancy,

martinthomson · 2025-01-31T03:45:09Z

index.bs

+			If seats are vacated due to a successful [=vote of no confidence=],
+			the [=Team=] <em class=rfc2119>must</em> organize an election,
+			under the same condition as for individually vacated seats,
+			unless the next regularly scheduled election is fewer than three months away.


I'm not clear on the three month choice. That means that you might win an election for a 3 month and a day term. That's pretty pointless, I'd go with six.

Suggested change

unless the next regularly scheduled election is fewer than three months away.

unless the next regularly scheduled election for the vacancy is less than six months away,

in which case the remainder of the term is extended by two years.

Strong +1 to this, three months is just too short a time to get involved.

Works for me. I'll let chairs decide if there's consensus on this point or not.

martinthomson · 2025-01-31T03:50:20Z

index.bs

 	If, within <span class="time-interval">one week</span> of the Team's announcement,
-	5% or more of the [=Advisory Committee=] support the appeal request,
-	the Team <em class="rfc2119">must</em> organize an appeal vote
+	5% or more of the [=Advisory Committee=] support holding the vote,


This is basically like having a vote to have a vote. I don't see the point.

It reduces some of my concerns about DoS, engaging this mechanism is exactly the sort of thing I'd like to avoid, but it also makes it nearly infeasible to use this process. Even though 5% seems small, that's a pretty significant movement given the activity levels in a pretty large consortium. I suggested one objector and two seconds, but you could make the two into five or something like that.

This is the pre-existing mechanism and threshold used for AC appeals. This attempts to reuse this system, not to change this.

And you're right, I don't think a 5% threshold is small. It is actually a non trivial barrier to meet. But I don't think it should be trivial to launch votes of no confidence (or AC appeals), so I'm personally comfortable with that.

If you do want to insist on a lower threshold, could you clarify if you want that change both for AC appeals AND votes of no confidence (in which case I'd suggest opening a separate issue), or only for votes of no confidence (in which case this is indeed the right place to discuss it)?

I'm more concerned about the time limit. Not only do you have to muster 5% of the membership, you have to do so within a week.

I was viewing this with a lens of the vote of no confidence, but I can't think of a case where this wouldn't be a problem for other such appeals. I don't want this sort of thing to be easy to trigger, but right now it seems to be akin to impossible. A healthy system might have this appeal run once every few years, but I can't remember a single occurrence, partly because this requires the moving of mountains. An accountability system that does not operate is probably one that cannot function, so it might as well not exist.

martinthomson · 2025-01-31T03:52:35Z

index.bs

@@ -2917,24 +3000,19 @@ Appeal by Advisory Committee Representatives</h3>
 	(including explicit “abstain” ballots) 
 	by [=Advisory Committee Representatives=]:
 	* if fewer than 5% participate,
-		the vote fails.
+		the proposal is rejected.
 	* if at least 5% but no more than 15% participate,
 		and the number of “Approve” ballots exceeds three times (3x) the number of “Reject” ballots,


This seems pretty silly. I understand the goal, but it encourages tactical voting due to it being non-contiguous. Opponents can withhold participation to get a better outcome.

It might be worth an example. For simplicity, let's assume 100 members.

At the 3x to 2x threshold (15%), four "reject" votes blocks any number of "approve" votes up to 11, but one more "reject" vote causes the motion to pass. This is because at 16 participating, five "reject" votes is overridden by 11 "approve" votes.

Worse, prior to the 2x to 1x threshold (20%), a motion is blocked by seven "reject" votes at 13:7 in favor. Up to six more "reject" votes causes the motion to pass. If opponents want to have their say and retain the same outcome, they need to find seven more "reject" votes (with no more "approve" votes).

There are ways to address this, but it involves math. I wonder if this goal is worth that.

We're not defining this mechanism here, just reusing it (and adjusting the phrasing slightly to make it work in new contexts). I suggest filing a separate issue if you dislike the mechanism itself. For context, this was adopted through PR #901, based on issue #886 (the prior state was a simple 50% majority, independent of the level of participation).

Now, as to the substance of the question, in case you do decide to pursue it, here's a little extra information / opinion:

It is true that this is discontinuous, and has slightly weird properties because of that, but I don't think it actually matters in practice, because it's very hard to operationalize: it's only reliably advantageous for "no" voters to refrain voting when close to the threshold if they can (a) know what the current tally is, and (b) count on no more "yes" vote coming in. Depending on how we set up the vote, (a) might be true, but we could easily guard against that by deciding that this must always be a secret ballot. And even if we don't, (b) won't be true, so people cannot really count on staying below the threshold.

I think there is value in having something of that nature in general to avoid consequence-heavy decisions being taken by accident just because not enough people were paying attention. Especially in the case of votes of no confidence, I consider them more likely than other kind of votes to be at risk of being invoked repeatedly by disgruntled parties. I think it would be unfortunate if the nth instance of a vote of no confidence passed despite wide opposition, simply because people got tired of answering largely the same question over and over again, or even on the first try because we're just past an election, and too many don't bother answer because they think it's obvious. So having a high bar when participation is low seems appropriate.

Though it is indeed a little odd, I think there's value in matching the same system used by the bylaws rather than coming up with something similar but different, even if better. Or we should change both to match.

index.bs

Co-authored-by: Ted Thibodeau Jr <[email protected]>

index.bs

TallTed · 2025-02-07T19:41:48Z

index.bs

+	An [=Advisory Board=] or [=TAG=] participant's seat is <dfn lt="vacated|vacant">vacated</dfn> when:

 	<ul>
 		<li>
 			the participant resigns, or

+		<li>
+			the participant is [=removed=], or
+
+		<li>
+			a [=vote of no confidence=] in the body they are part of is successful, or
+
 		<li>
 			an Advisory Board or TAG participant changes affiliations
 			such that the <a href="#AB-TAG-constraints">Advisory Board and TAG participation constraints</a> are no longer met,


I can only suggest through line 1374, but similar changes should be made through line 1384.

Suggested change

An [=Advisory Board=] or [=TAG=] participant's seat is <dfn lt="vacated|vacant">vacated</dfn> when:

<ul>

<li>

the participant resigns, or

<li>

the participant is [=removed=], or

<li>

a [=vote of no confidence=] in the body they are part of is successful, or

<li>

an Advisory Board or TAG participant changes affiliations

such that the <a href="#AB-TAG-constraints">Advisory Board and TAG participation constraints</a> are no longer met,

An [=Advisory Board=] or [=TAG=] participant's seat is <dfn lt="vacated|vacant">vacated</dfn> when any of the following occurs:

<ul>

<li>

The participant resigns.

</li>

<li>

The participant is [=removed=].

</li>

<li>

A [=vote of no confidence=] in the body they are part of is successful.

</li>

<li>

An Advisory Board or TAG participant changes affiliations

such that the <a href="#AB-TAG-constraints">Advisory Board and TAG participation constraints</a> are no longer met.

</li>

frivoal added the Agenda+ label Jun 18, 2024

TallTed suggested changes Jun 18, 2024

View reviewed changes

TallTed reviewed Jun 27, 2024

View reviewed changes

index.bs Outdated Show resolved Hide resolved

TallTed reviewed Jun 27, 2024

View reviewed changes

index.bs Outdated Show resolved Hide resolved

frivoal force-pushed the w3c-vote branch 2 times, most recently from 4866220 to d6b102a Compare June 29, 2024 06:07

frivoal force-pushed the w3c-vote branch 2 times, most recently from d77299a to e2edd24 Compare July 16, 2024 14:38

frivoal force-pushed the w3c-vote branch from e2edd24 to 77200d3 Compare July 24, 2024 21:00

TallTed suggested changes Jul 26, 2024

View reviewed changes

Dlbandy04 approved these changes Dec 1, 2024

View reviewed changes

frivoal and others added 3 commits December 6, 2024 17:20

Refactor AC Appeals

acf7faf

This extracts the 5% confirmation vote, followed by the actual vote into a separate procedure, invoked by the AC Appeal, making it reusable. Co-authored-by: Ted Thibodeau Jr <[email protected]>

Add recall procedures for AB and TAG members

9881333

See w3c#882 Co-authored-by: Ted Thibodeau Jr <[email protected]>

Limit AB/TAG recalls by the AC to collective votes of no confidence

Loading
Loading status checks…

95013e2

Also enable individual removal of problematic participants by the body itself w3c#882

frivoal force-pushed the w3c-vote branch from bb31fcd to 95013e2 Compare December 6, 2024 08:37

frivoal removed the Agenda+ label Jan 20, 2025

martinthomson reviewed Jan 31, 2025

View reviewed changes

TallTed reviewed Jan 31, 2025

View reviewed changes

index.bs Outdated Show resolved Hide resolved

rephrase

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.

GPG key ID: B5690EEEBB952194

Verified
Learn about vigilant mode

Loading
Loading status checks…

ebb1fba

Co-authored-by: Ted Thibodeau Jr <[email protected]>

wareid reviewed Feb 3, 2025

View reviewed changes

index.bs Outdated Show resolved Hide resolved

improve phrasing

Verified

This commit was created on GitHub.com and signed with GitHub’s verified signature.

GPG key ID: B5690EEEBB952194

Verified
Learn about vigilant mode

Loading
Loading status checks…

9818823

TallTed reviewed Feb 7, 2025

View reviewed changes

frivoal mentioned this pull request Feb 12, 2025

Enable AB/TAG to remove one of their members #986

Open

Refocus this PR to be about votes of no confident only

Loading
Loading status checks…

4d8eb53

frivoal added the Needs AB Feedback label Feb 12, 2025

		A single [=Member=] or group of [=related Members=] cannot re-invoke this process
		sooner than 6-month since their previous invocation,


	The [=Team=] must announce the conclusion of the [=Advisory Committee Override=] to the [=Advisory Committee=].

-			If seats are vacated due to a successful [=vote of no confidence=],
+			If vacancies reduce
+			the number of [=AB=] participants to 6 or fewer
+			or the number of [=TAG=] participants to 7 or fewer,

		the [=Team=] <em class=rfc2119>must</em> organize an election,
		under the same condition as for individually vacated seats,

	unless the next regularly scheduled election is fewer than three months away.
	unless the next regularly scheduled election for the vacancy is less than six months away,
	in which case the remainder of the term is extended by two years.

Generalizing AC Appeals and using this procedure for recall. #888

Are you sure you want to change the base?

Generalizing AC Appeals and using this procedure for recall. #888

Conversation

frivoal commented Jun 18, 2024 • edited by pr-preview bot Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

chaals commented Jul 2, 2024 via email

frivoal commented Jul 3, 2024

Choose a reason for hiding this comment

frivoal commented Dec 6, 2024

frivoal commented Jan 20, 2025

martinthomson left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wareid Feb 10, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

frivoal Feb 11, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

frivoal commented Jun 18, 2024 •

edited by pr-preview bot

Loading

wareid Feb 10, 2025 •

edited

Loading

frivoal Feb 11, 2025 •

edited

Loading