Generalizing AC Appeals and using this procedure for recall. #888
Conversation
index.bs
Outdated
| A single [=Member=] or group of [=related Members=] cannot re-invoke this process | ||
| sooner than 6-month since their previous invocation, |
There was a problem hiding this comment.
It's unclear when the six-month timer begins. So, this —
| 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, |
There was a problem hiding this comment.
— or this —
| 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, |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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… ;)
There was a problem hiding this comment.
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?
| 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, |
There was a problem hiding this comment.
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)
frivoal
force-pushed
the
w3c-vote
branch
2 times, most recently
from
4866220 to
d6b102a
Compare
|
An alternative mid-ground would be stating a "supermajority" threshold:
twice => > 2/3 or 67%, thrice => > 3/4 or 75%
|
|
@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. |
frivoal
force-pushed
the
w3c-vote
branch
2 times, most recently
from
d77299a to
e2edd24
Compare
index.bs
Outdated
| @@ -1318,6 +1350,9 @@ Elected Groups Vacated Seats</h5> | |||
| <li> | |||
| the participant resigns, or | |||
|
|
|||
| <li> | |||
| the participant is [=recalled=], or | |||
There was a problem hiding this comment.
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.
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
|
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
removed
the
Agenda+
|
The AB has not reached a conclusion on this topic. Temporarily removing agenda+ |
| 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. |
There was a problem hiding this comment.
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.
| 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. | ||
|
|
There was a problem hiding this comment.
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.
| 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. |
There was a problem hiding this comment.
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.
| @@ -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=], | |||
There was a problem hiding this comment.
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.
| 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, |
There was a problem hiding this comment.
| 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, |
| 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. |
There was a problem hiding this comment.
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.
| 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. |
| 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, |
There was a problem hiding this comment.
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.
| @@ -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, | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Co-authored-by: Ted Thibodeau Jr <[email protected]>
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 adoptingthemit 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