Increase membership of the AB, possibly TAG

[cwilso]

I suggested in the AC meeting in Berlin that we should increase the number of participants in the AB if not also the TAG to account for the increased "diversity" we are garnering with STV. There seemed to be general support, or at least some support and a lack of antipathy.

I would recommend we increase the number of AB seats by 2 (to 11 elected seats), and the TAG by 1 (to three appointed, 7 elected seats).

[nrooney]

I actually support this - there's a lot of work to do and more people will help.

[dwsinger]

As long as we feel we can find the candidates, I am OK with this. The downsides to larger groups is the sense that in a small group you can't be a passenger; and finding the candidates.

[bkardell]

It feels like the discussion at https://lists.w3.org/Archives/Member/w3c-ac-forum/2018AprJun/0009.html is very relevant to this discussion for two reasons: 1) If any restructuring happens as in there, it seems relevant to reconsider the whole idea of appointed seats... They seem to cease to make any sense in that model. 2) If before that, even, it seems like these bodies need more seats.... well... that seems relevant to how restructuring should happen.

I feel more the record pretty much like @dwsinger expressed: Making this group too big is going to be counter productive, but I don't know what 'right size' is either - that's a comment I've made a number of times, and a big part of that is related to being able to find good candidates. Just filling slots to fill them is no good, and neither is turning away really great options because there just aren't enough seats.

[jeffjaffe]

The Advisory Board discussed this issue on 16 May 2018 and there was a consensus of support for Chris' proposal.

The AB also noted that it is important to get the TAG's input on the TAG part of the proposal.

[dwsinger]

If we have continued anxiety about finding candidates, we could say that each body must have at least N and no more than M. With a larger body, we might have to consider what to do if we have too few nominations.

[frivoal]

If we do an "at least N, no more than M" system, we need to be clear about what this means with STV (assuming we stick to that). If the number of candidates falls between the two numbers, is everybody elected automatically, or is there some possible result of the election that can reject candidates for not being popular enough (as long as we still have at least N)?

I have been involved in non profit board elections with an "at least N, no more than M" system using approval voting, and in that case, how it works is obvious and non controversial.

[michaelchampion]

The "at least N, no more than M" system could be used to make the No Other Candidate option meaningful. One reason that option doesn't have any actual effect is that it's not clear what would happen if No Other Candidate beat one or more actual candidates. In the N - M system, it would simply mean the candidates that got less support than No Other Candidate wouldn't get seats so long as N seats were filled.

To be clear I MUCH prefer a simple approval ballot. In general, we have only slightly more candidates for the AB and TAG than open seats, and it's wasteful and hurtful to spend so much energy arguing about how to choose which qualified candidates to reject. I'd suggest we set M at somewhere around 11 - 13, hold an approval ballot to ensure that the AC can non-approve any candidates that aren't qualified or don't behave appropriately, and refocus energy on solving real problems. (If there are more than M nominees, we could select the set of M with the most approval, or those who have not already had a chance to serve, or whatever).

[dwsinger]

I’ll continue to be opposed to using “and no other candidate” for reasons previously stated.

Ideally, we don’t elect un-preferred candidates because they lose to a preferred one. In most systems I know, this is caused by seeing an announcement “Mordor has joined the W3C and Sauron has been nominated to run for the AB.”, and people panic and nominate Gandalf.

We don’t announce nominations until after the close of nominations; why? Can we improve transparency and announce as they are received?

On Jun 12, 2018, at 8:29 , Michael Champion notifications@github.com wrote:

The "at least N, no more than M" system could be used to make the No Other Candidate option meaningful. One reason that option doesn't have any actual effect is that it's not clear what would happen if No Other Candidate beat one or more actual candidates. In the N - M system, it would simply mean the candidates that got less support than No Other Candidate wouldn't get seats so long as N seats were filled.

To be clear I MUCH prefer a simple approval ballot. In general, we have only slightly more candidates for the AB and TAG than open seats, and it's wasteful and hurtful to spend so much energy arguing about how to choose which qualified candidates to reject. I'd suggest we set M at somewhere around 11 - 13, hold an approval ballot to ensure that the AC can non-approve any candidates that aren't qualified or don't behave appropriately, and refocus energy on solving real problems. (If there are more than M nominees, we could select the set of M with the most approval, or those who have not already had a chance to serve, or whatever).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

David Singer Manager, Software Standards, Apple Inc.

[bkardell]

We don’t announce nominations until after the close of nominations; why? Can we improve transparency and announce as they are received?

Yes. Yes. Please!

[cwilso]

As long as the W3C continues to use STV, it is simply not as simple as "get someone else to run". 1st choice impacts elections FAR more than subsequent selections, so a very small set of core supporters, along with voters who happen to list them in the "order of preference", will easily defeat a likely-small set of people who understand how to use their vote appropriately and want to prioritize a relatively unknown candidate.

That said, announcing nominations as they come in would be a positive IMO. (of course, Mordor wouldn't nominate Sauron until just before nominations close.)

On Tue, Jun 12, 2018 at 12:01 PM, Brian Kardell notifications@github.com wrote:

We don’t announce nominations until after the close of nominations; why? Can we improve transparency and announce as they are received?

Yes. Yes. Please!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/w3c/w3process/issues/190#issuecomment-396698400, or mute the thread https://github.com/notifications/unsubscribe-auth/AAe8eYq2HYBQr75R9wpx99P1tPOtQHZmks5t8A_7gaJpZM4T9fzX .

[bkardell]

Fully agree with what @cwilso said above. Feels like announcement is actually better as a separate topic (which I fully support) largely unrelated to increasing size or how elected, it's just a good idea.

[dwsinger]

agreed, opening a separate issue on why announcements are not made immediately. see #193

[LJWatson]

If the "at least N, no more than M" approach is complex with STV, perhaps we should move forward with @Cwilso's original suggestion (that the AB endorsed)? We can then at least make some progress.

[dwsinger]

alas, I don't think it's complicated. If the number of people running is such that we would fall below the minimum N, that is the same as today: we can't fill the TAG/AB to its required level. If all were elected and we would end up with a TAG of M or fewer, they are elected unopposed (just like today where N=M). Otherwise, we hold an election to end up with M on the TAG/AB.

If we were to adopt "and no other candidate" we'd have to have the election when previously we would elect unopposed, and we'd have the possibility of not meeting the minimal fill level.

[michaelchampion]

"At least N, no more than M" is simple with approval voting. We'd get the set of people with the most support by the AC, nothing bad happens if someone doesn't get enough approvals (there'd just be one fewer person on the TAG or AB). There would be a problem if we get fewer then N nominees, like with any system. If there are more than M approvals, there would be various options:

• Drop those with the fewest approvals
• Drop those who have served the longest terms before ("soft" term limits)
• Randomly select winners from those who were approved
• ...?

[frivoal]

Dropping those with fewest approvals if we have too many seems the simplest and works quite well. I don't think we need to bring in any random selection into this. Soft term limits could be done that way, but I would much rather keep the whole thing very simple.

[chaals]

Some pros:

• there is plenty of work to do. More people might help get more done.
• more seats allows for more diversity, and supports deeper as well as broader representation.

Some cons:

• More people might mean a further dilution of the sense of responsibility for getting stuff done.
• Scheduling meetings is difficult already. More people will complicate that further, unless we accept a higher rate of non-attendance as a reasonable trade-off.
• More seats means we need to find more nominees at each election.

Also:

• STV with the no other candidate option, approval voting with a maximum of "N" candidates elected both fit the "between X and X+n members" proposal.
• More nominees looks likely to increase the time some people spend on the AB unless we enforce some kind of term limit.
• Randomly deciding who to kick off, without randomly deciding who is there in the first place, seems like a bad idea to me.
• Serving on the AB is an expensive undertaking. Unless we change that somehow, we may be pushing further toward giving larger members more say in what happens. Opinions differ on whether that is a good thing (legitimately, which is why this is in the "also" section)

[dwsinger]

On Jul 14, 2018, at 11:33 , chaals notifications@github.com wrote:

Some pros:

• there is plenty of work to do. More people might help get more done. • more seats allows for more diversity, and supports deeper as well as broader representation. Some cons:

• More people might mean a further dilution of the sense of responsibility for getting stuff done. • Scheduling meetings is difficult already. More people will complicate that further, unless we accept a higher rate of non-attendance as a reasonable trade-off. • More seats means we need to find more nominees at each election. Also:

• STV with the no other candidate option,

I see “no other candidate” as quite orthogonal; why are they linked? with or without NOC, we risk ending up below N (if we have too few nominated, or with NOC, approved).

approval voting with a maximum of "N" candidates elected both fit the "between X and X+n members" proposal. • More nominees looks likely to increase the time some people spend on the AB unless we enforce some kind of term limit. • Randomly deciding who to kick off, without randomly deciding who is there in the first place, seems like a bad idea to me.

Happily, we don’t need it for “at least N and nor more than M”.

• Serving on the AB is an expensive undertaking. Unless we change that somehow, we may be pushing further toward giving larger members more say in what happens. Opinions differ on whether that is a good thing (legitimately, which is why this is in the "also" section) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

David Singer Manager, Software Standards, Apple Inc.

[dwsinger]

after observing the work mode of the AB, which is that all of us have to say something about everything, I do not think enlarging the AB is prudent, as it will slow us down, not speed us up...

[cwilso]

That seems self-fulfilling. Increasing diversity also means you have to listen to more points of view, but that wasn't a statement against STV that I heard at the time STV was proposed.

[chaals]

I don't support this proposal.

edit I.e. I would vote against it, but not block an overall consensus with a formal objection.

[dwsinger]

@chaals I don't support it either (because I think a larger AB would be less effective, alas), but I am not sure I oppose it yet. At the moment, I'd like clarity on the concerns, and whether we're likely to have support, or opposition...

[LJWatson]

Of the points made by Chaals, I think the cons can be mitigated, and the pros make it worth doing.

Some cons:

• More people might mean a further dilution of the sense of responsibility for getting stuff done.>

It might, but then again, it might not. Increasing the number of people increases the chance of both active participants and less active ones, and whereas more of the latter will make little difference to our productivity, more of the former will.

• Scheduling meetings is difficult already. More people will complicate that further, unless we accept a higher rate of non-attendance as a reasonable trade-off.>

We already accept a degree of non-attendance, so adjusting this accordingly wouldn't seem to make much material difference.

We need to be better at scheduling meetings in any case, but there are ways to make this easier - such as using a relatively fixed meeting schedule.

• More seats means we need to find more nominees at each election.>>

It does. This is something we're aiming to do anyway, so again, it doesn't feel much like a material change, and certainly not one for the worse.

[dwsinger]

We can alleviate the "we have to find more nominees" by adopting "at least N and no more than M". If there are enough nominees to fill <=M seats then they are elected unopposed. If there are >M, we have an election. (and as today, if <N, then we have an underfill problem).

[cwilso]

What happens today in an underfill problem, and what could we do that would be different?

On Tue, Sep 11, 2018 at 9:15 AM David Singer notifications@github.com wrote:

We can alleviate the "we have to find more nominees" by adopting "at least N and no more than M". If there are enough nominees to fill <=M seats then they are elected unopposed. If there are >M, we have an election. (and as today, if <N, then we have an underfill problem).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/w3process/issues/190#issuecomment-420330856, or mute the thread https://github.com/notifications/unsubscribe-auth/AAe8eaXM-aMKg82vZmp9s5H10NUnVIENks5uZ-GcgaJpZM4T9fzX .

[michaelchampion]

I recall the AB having consensus to resolve this issue along the lines of https://github.com/w3c/w3process/pull/202/commits/b2cb88629e78c74a7e45a4d5c20c4fbf303a010 5. I don't understand why the Process CG id debating whether to increase the size of the AB.

I do agree that "at least n and no more than m" is better than simply setting the number at 11. We don't want to make it hard to seat an AB if there are not enough nominees.

[dwsinger]

I am simply suggesting that we leave the underfill threshold and handling as it is now, and raise the threshold at which an election happens; that's the only effect of "at least N and no more than M". I think the team panics and tries to find candidates if there are not enough nominees, but I am not sure.

[chaals]

@cwilso if there is an underfill problem today then nomination is extended until the problem is resolved.

The practice I recall has been that an extension of time is announced, so that rather than the first x people to nominate being able to take a guaranteed seat there is a likelihood of an election.

[michaelchampion]

I don't agree with the concern in https://github.com/w3c/w3process/issues/190#issuecomment-420089780 that a larger AB or TAG would be less effective. There is not time and expertise available to really dig into the various issues on the agenda of either group, so the obvious answer is to add more people.

That might fall afoul of the Mythical Man-Month and make the groups even less effective because people are deluged with email and GitHub traffic on things that are not of much importance. "the increased communication overhead will consume an ever increasing quantity of the calendar time available. When n people have to communicate among themselves, as n increases, their output decreases and when it becomes negative the project is delayed further with every person added."

The main mitigation strategy for the O(N**2) communication problem is modularization/specialization: Not everyone has to be in every discussion. Also, I'm not sure it's the communication overhead that is the problem, it's a lack of consensus on key issues. I suspect the chairs of the TAG and AB will need to find a way other than perpetual bikeshedding to settle such issues (e.g. STV). Binding ballots, appeal to the AC or Director, agreement to disagree, whatever.

[chaals]

@michaelchampion

I don't understand why the Process CG id debating [this issue] ...

Because the Process CG is where a resolution to the issue gets implemented. The AC will also debate (if they choose) any issue, since they are the ones who advise the director on whether or not to accept a proposed update to the Process.

[cwilso]

Not really. The AB owns the decision-making, and the resolution they decided on (as per Jeff's comment: https://github.com/w3c/w3process/issues/190#issuecomment-389439047) is implemented here in the Process CG (in https://github.com/w3c/w3process/pull/202). The output of the Process CG is subject to the AB's approval, which then goes for a vote in the AC.

On Tue, Sep 11, 2018 at 9:51 AM chaals notifications@github.com wrote:

@michaelchampion https://github.com/michaelchampion

I don't understand why the Process CG id debating [this issue] ...

Because the Process CG is where a resolution to the issue gets implemented. The AC will also debate (if they choose) any issue, since they are the ones who advise the director on whether or not to accept a proposed update to the Process.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/w3process/issues/190#issuecomment-420342710, or mute the thread https://github.com/notifications/unsubscribe-auth/AAe8eW5fzBymOmnt2XWaBy-WJf3aDG7Hks5uZ-oigaJpZM4T9fzX .

[frivoal]

Given that the folks involved in this conversation are largely the same as those who made the AB resolution, I am somewhat confused at how the AB could have consensus but we don't have consensus here.

So, did the AB have consensus back then? If yes, we're just implementing, there's nothing to be discussed, and https://github.com/w3c/w3process/commit/b2cb88629e78c74a7e45a4d5c20c4fbf303a010 is a fine implementation of that decision.

Or did we mistakenly record a consensus that wasn't actually there, and are trying to reopen the discussion?

[dwsinger]

indeed, if there were a way to reject candidates, then whether or not N=M, we would need to deal with the need always to have an election, and what to do if too few candidates are elected. we don't have that situation now (nor did we in the past)

[frivoal]

Closed by #202