Making the Council's short circuit a little more flexible about w3process

[dwsinger]

I think that in your initial text there is a good direction, that there is no opposition.

At least x% respond (80%?). At least y% vote in favor (positive support, not abstaining). No-one opposes. ?

[frivoal]

I'd be in favor of a threshold higher than that, though I'm still a little fuzzy on how high. The reason being that if only a small majority of the council has looked at the proposal, it's difficult to be confident that the broad collective expertise of the council has fully been engaged and has considered the question. Possibly the missing third has nothing to add, but before validating a decision without discussion, I'd like most people to have considered it. I think it's good not to be stuck on a couple of non responsive individuals, but we should still be aiming to have most people engaged. I'd say 67% is on the low side. I'm comfortable with 80% as initially proposed, but during CG discussions, some felt that 90% would be better. I could go lower, maybe 75%, but beyond that starts to feel low.

Anyway, currently it's 100%. So far, even if we haven't yet found the right spot, there seems to be agreement that we want some number less than 100.

[frivoal]

This was discussed in the AB, and the AB is supportive, with a clarification: we should not close the vote and declare short circuit as soon as we hit the threshold. The poll needs to remain open for a least a set period of time to give a chance to respond to people who would respond but are just a bit late. (If we reach 100% participation, there's no need to wait of course).

So, the open questions are:

• what is the threshold?
• what is the duration of the poll?

My suggestion would be 80% and 2 weeks.

[chaals]

These things generally spend weeks in the pipelines. Someone going on a sufficiently long vacation that they can't respond should be taking leave of absence from their position, except that doesn't exist as a concept. It is, I believe, possible for someone to state that they formally abstain from all proposals up to a certain date, if they are going to be offline for a significant period.

If there is a member of the AB or TAG (or BoD for that matter) who just disappears for an extended period and fails to respond, I think the way to deal with it is not just finding workarounds.

[frivoal]

Having a 100% response rate from a group of more than 20 people is always going to be challenging. What alternative do you suggest, that doesn't result in most attempts at short-circuit to fail due to 1 or two missing responses, causing us to have to spend more time in fully constituting the council, only to observe that we're still in agreement, and then resolve on the same thing once the unanimity requirement has been dropped?

[css-meeting-bot]

The Revising W3C Process CG just discussed #852.

The full IRC log of that discussion

<plh> subtopic: #852
<plh> github: https://github.com//issues/852
<cpn> Florian: When setting up a Council, if team has a recommendation for disposing the issue, and everyone agrees, we skip the Council
<cpn> ... Two things: We could do something slightly less drastic. Also, getting feedback from everything is hard
<cpn> ... So this is before we discuss, if anyone disagrees or isn't sure, we should talk about it
<cpn> ... It's important to have a lot of people behind the proposal for it to be legitimate
<cpn> ... So if any single voice says no, it needs to stay. If a few don't answer at all but 90% of the council says yes and 10% don't respond, is that good enough and still legitimate?
<plh> q+
<plh> ack plh
<cpn> ... Should I draft a PR?
<cpn> PLH: I think it's a bit too early
<cpn> ... In the case of TimBL, he doesn't want to abstain indefinitely just yet
<cpn> ... Was this discussed in the AB and TAG?
<cpn> Florian: Not in a formal meeting
<cpn> PLH: I think you should consult them. But they may not be best to judge the current situation
<cpn> cwilso: In general it seemed like a good idea. Raise in the AB
<cpn> q+
<fantasai> scribe+
<plh> ack cpn
<fantasai> cpn: I think the legitimacy point is a good one here. I would want to keep a high threshold.
<fantasai> ... with such a large group, ~20 people
<fantasai> ... at that level 10% would be OK, but below that would raise legitimacy
<fantasai> florian: higher threshold than 80%?
<fantasai> [several: 90% seems safer]
<fantasai> cpn: percentages are strange
<fantasai> florian: Could go with a number, e.g. if 1-2 people don't respond it still passes
<cpn> s/strange/strange when we're talking about a group of 20 in total/

[hober]

how about 67%?

[tantek]

I like the direction of this @frivoal.

One key addition I would like to see added, for the reasons of documenting a proper process and acknowledgement of how Formal Objections were handled:

IF the Team recommends a path which is equivalent to DROPPING the (i.e. REJECTING) the proposed action that the AC voted on, e.g.

• If the AC voted on a charter, and the Team withdraws the charter that was voted on
• if the AC voted on a REC transition, and the Team withdraws the version of the REC that was voted on (for any reason, with any variations)

THEN the council as part of accepting the Team's recommendation MUST record for the matter of historical record, something like:

One or more Formal Objections to AC poll (insert permalink to AC poll) were UPHELD and thus the item that was polled is recorded as REJECTED by W3C.

This will help make it clear:

• what happened with so-and-so formal objection?
• which formal objections were UPHELD (perhaps as a set) and which were DISMISSED (perhaps as a set)?

which we may use to gather statistics etc. in the future on things like:

• number of W3C polls which were REJECTED or PASSED
• specifically, number of proposed charters which were REJECTED or PASSED
• number of proposed REC transitions which were REJECTED or PASSED
  etc.

and then we can use the REJECTED examples to document the WHYs of REJECTION to help improve future proposals to poll, and polls themselves.

[frivoal]

@tantek I support explicit record keeping and transparency, so without having thought about the details too much yet, I am generally supportive of your intent. Some of this may already exist, but we may have holes to plug or other improvements to make. However, that is a matter of reporting on decisions, while the issue I opened is about how the decision itself gets made. I think this should be handled as a separate issue.

[frivoal]

Moved #852 (comment) to a distinct issue #870 (comment).