Generalizing AC Appeals and using this procedure for recall.

[frivoal]

This PR is a first draft attempting to address #886 and #882. Neither haveIt has not been resolved on at this point, but this shows what adopting themit 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

[TallTed]

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,

[TallTed]

— 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,

[frivoal]

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?

[TallTed]

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.

[frivoal]

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… ;)

[TallTed]

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,

[frivoal]

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)

[chaals]

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

[frivoal]

@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]

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.