Ambiguity about the formation time of a Council, and through that, about its composition

[frivoal]

Process 5.6.2.1 says:

Membership of each Council instance is fixed at formation, and is not changed by any AB or TAG elections occurring before that Council has reached a conclusion. However, if participation in a Council falls so low as to hinder effective and balanced deliberations, the W3C Council Chair should dissolve the Council and call for a new one to be convened.

Turns out that's ambiguous. When is "at formation"?

• When the (first) FO about a particular decision is registered?
• When the W3C community is first told of the potential composition of the council and asked if there are reasons to dismiss?
• When the poll for dismissal is sent?
• When the poll for dismissal has concluded?

As time can elapse between these various steps, if some AB/TAG member start/end their term somewhere in the middle of these steps, it's currently not quite clear what happens. If included, they're included until the end of the council, but do they get included at all?

The original intent was to avoid changing the composition of the council once it has started debating things, to avoid disruptions to ongoing discussion and having to restart take time to bring new members up to speed. Since those discussions don't start until the council is fully formed, this might argue for "formation" being after the dismissal poll has closed. Once we know exactly who the actual council is, members will start talking to each other, and we don't change anymore.

However, the Team has pointed out that locking down after they have published the list of potential members has the downside that we would need to re-run this (and subsequent steps), which could delay the start of the council, and might push us over deadlines which could otherwise have been respected: If new potential members get added (because they were just elected), we need to give the opportunity to the AC to list reasons to dismiss them, even if they're already done so for the others, then we need to re-run the dismissal poll, as the new members both need to be evaluated for dismissal and given a chance to weigh in on the dismissal of other members.

That process isn't so long that we'd be at risk of having to run it many times in a row, as there shouldn't be that many AB/TAG composition changes in a row, but it could easily add several weeks.

Arguably, if have sent the list to the W3C community asking for potential reasons to dismiss, but haven't yet run the poll for dismissal, we could add the new names / remove the old ones from the list, extend by maybe a week, and then run the dismissal poll.

Interestingly, we are most likely to have to worry about this case at all in Councils that are already late. Typically, these formation steps should be fairly quick, so the likelihood that they'll coincide with term start/end is not that high, but if formation drags on for a particular council, the likelihood increases.

So here are a few possibilities I can see, with pros & cons:

1. Once the dismissal poll has concluded, the list is fixed. If anyone's term ends before that, they get removed, if anyone's term starts before that, they get added to the list shared with the W3C community, and we extend (by a couple of weeks?) the time the W3C community has to provide reasons and the dismissal poll itself.
    + most representative council composition
    - may cause a few weeks of delay, and is more likely to happen to councils that are already late

2. once the list of potential members has been sent to the W3C community, the list is fixed: no one gets added, and no one gets removed (other than dismissal and renunciation)
    + easy to do
    - that means we fix council composition possibly 90 days ahead of any actual council discussions, keeping "for continuity" people's whose term is over and weren't part of the discussion (since the discussion hasn't started yet), and who might be getting increasingly hard to get a hold off.
    +/- does not cause delays by automatic addition of a few weeks like option 1, but this may disincentivize the Team from sending the list of potential members early, potentially causing delays anyways due to a late start

3. People whose term end before the conclusion of the dismissal poll are automatically removed. People whose term start after the FO has been registered do not get added
    + easy to do
    + does not cause delays
    + does not lock in people whose term has ended before the meaningful start of the council
    + does not incentivize the Team to wait
    - We occasionally end up with Councils that are a few members short of what a full-sized council would be

I think option 1 is what I imagined would happen when we drafted the Council process initially, but I had not anticipated the reluctance to add a few weeks to Councils that are potentially already late. Option 2 is arguably another valid interpretation of the process as it stands. But I think option 3 is my favorite: the downside is limited, and if we were to end up in a situation where the council really is understaffed to a problematic degree, the chair has the ability to dissolve and get a fresh full council.

If we agree that's the best option, I'll draft a minimally invasive PR to set this up.

Do people have other preferences?

[ylafon]

Option 3 is my reading of the current text of the process, especially as it is unrealistic for long running FOs to keep people who ended up their terms to continue to have time, even if Option 1 would be ideal, having unlimited time and unrestricted resources.

[dmrazzy]

I'm count me in

[TallTed]

+1 for Option 3.

[fantasai]

I think Option 3 is reasonable as long as the turnover is small, but if we have a wipeout election (has happened in the past, when the Membership decided they wanted something different from the elected body), that leaves the Council in a not-so-good state. Also the distance between FO registration and the close of the dismissal poll is relatively long.

Option 1 only causes problems if the dismissal poll itself overlaps a term boundary; I think we can handle a 2-week delay in such cases. If we really think it's too much to allow that, then we can re-use the threshold from the unanimous short circuit: we extend only if we lose too many people.