Proposal for Process Experimentation - #1189
Conversation
The W3C Process Document is managed by the Advisory Board. Changes to the Process Document are reviewed by the Advisory Committee and adopted by consensus. The Membership has not explicitly granted the Advisory Board the authority to conduct experiments related to the existing process. This is a proposal to legitimize temporary alternative Processes authorized by the Advisory Board.
hober
left a comment
There was a problem hiding this comment.
This is great! It's not quite ready to land, but I'd be okay with landing something awfully close to this.
|
|
||
| <ul> | ||
| <li>the Advisory Board must issue a <a href="#process-experiment-report">Process Experiment Report</a></li> | ||
| <li>the extension must be approved by majority vote of the Advisory Committee by a ballot open for 10 business days at a minimum.</li> |
There was a problem hiding this comment.
First, a simplification:
| <li>the extension must be approved by majority vote of the Advisory Committee by a ballot open for 10 business days at a minimum.</li> | |
| <li>the extension must be approved by the Advisory Committee by a ballot open for 10 business days at a minimum.</li> |
Second, when the AC is polled using WBS, one of the options included is the ability to FO. Should this text say something about that not being the case? Or is it okay for FOs to happen to extension requests?
There was a problem hiding this comment.
I am not anticipating a usual AC review form, but an up or down vote in this case.
In pursuit of ability, and because the AC is making the decision directly (without any party further assessing the outcome of the Member perspectives), I don't see the same need for FOs.
Co-authored-by: Theresa O’Connor <tess@oconnor.cx>
|
"business days" is not very precise - if you're going to use them it's
helpful to define them.
And I think the length of review isn't to enable or manage FOs, it is so AC
reps can read the request, talk to other people, and make and record a
decision that accords with their employer's thoughts even if it takes a few
days to convince said employer of why their thoughts should be a particular
way...
|
|
I'm inclined to anticipate patent policy exceptions, but far more concerned
about changing the code of conduct - the point of the CoC is that it
balances the need for reasonably free expression with the need for
individuals to be able to participate actively in a group.
I guess the test really arises when someone makes a proposal - at which
point the AC can always vote it down.
|
Fair point. I see the process doc does not use the phrase, so I'll fall back to the "week" unit (and make the change in place). |
frivoal
left a comment
There was a problem hiding this comment.
I support the idea experimentation, but I am skeptical of the approach proposed here.
| <ul> | ||
| <li>Alter the rules that give the Advisory Board the authority to conduct experiments or permanently change a policy.</li> | ||
| <li>Affect the W3C Member Agreement or incorporation documents (bylaws, certificate of incorporation).</li> | ||
| <li>Alter patent policy commitments.</li> |
There was a problem hiding this comment.
What does that mean? a strict interpretation would be that nothing about the REC track or about decision making can be changed, because that would change (possibly significantly) what can be in documents about which patent commitments are made. I suspect you don't mean that, as the REC track is probably something we do want to run experiments about.
It might mean that section 5 of the patent policy cannot be changed by an experiment. That too seems unlikely to be what's intended, as it feels far too narrow to actually protect the continuity of commitments.
So something in between is likely intended, but I am not sure what.
There was a problem hiding this comment.
Let's back up a bit:
- My thought is that an experiment should not introduce ambiguity about whether someone has made a commitment to the W3C patent policy or whether a specification benefits from protections under those commitments. The first question is: is that a worthwhile goal? If not, or if we think that the people designing the experiments should have flexibility, then we can simplify the proposal. My assumption was that we would not want ambiguity or doubt around patent policy guarantees.
- I have not studied the question in depth yet, but my initial thought was that we would get an understanding of the boundaries of experimentation related to the patent policy by looking at the patent policy. It includes provisions that (unless modified) set expectations. For example, it talks about charters referring to the policy, so we should make sure that's still a thing in a charter. It talks about "Working Group participants" making commitments, so we should not (at least for now) move to a model where specifications are developed outside of Working Groups ("workstreams" come to mind). As you have pointed out, the Patent Policy relies on a "Patent Review Draft" so we need one of those, however we get it. In short, my hope is that looking closely at the patent policy will tell us what we need to preserve in the process document.
|
|
||
| <h3 id="experiment-scope">Scope limitations</h3> | ||
|
|
||
| Authorized Process Experiments must not: |
There was a problem hiding this comment.
What happens if the experiments (inadvertently maybe) do some of the things they supposedly must not do? Are they automatically void? Does that grant someone (who) the ability to shut them down?
There was a problem hiding this comment.
I agree with you that we should have a way to void the "substantive" outcome of an experiment, such as a final decision after experimenting with some new approach to handling formal objections.
The proposal requires the AB to publish a Report at the conclusion of an experiment. We could take this further:
- The AB announces the report.
- If the AB itself concludes that the experiment did not remain within the scope limitations, via the Report the AB declares the substantive outcome to be void. Otherwise, the AB declares the outcome to be valid.
- The AC can appeal that declaration (either way).
Goals of this proposal:
- Empower the AB to acknowledge (possibly after receiving input from the community) issues with the experiment, to stop it early if needed, and to limit damages (perhaps mostly to frustrated parties who were in the experiment).
- Provide some agility to the AB to validate experimental results (through the appeal bar) while still giving Members final decision-making power.
|
|
||
| <h3>Extensions</h3> | ||
|
|
||
| An Authorized Process Experiment expires automatically on its specified end date but may be extended at most one time for up to one year. |
There was a problem hiding this comment.
I don't know how this can actually work. It seems that the AB can make an experiment to be slightly different in some way but substantially the same, and then it would be a new experiment, not an extension of an existing one, and then they'd need no permission.
Few things are as permanent as temporary measures.
There was a problem hiding this comment.
The AC gets to approve the extension. If the AC believes the AB is trying to pull a fast one and work around the process, then they can vote down the extension.
There was a problem hiding this comment.
Relying on vigilance from the AC is an imperfect mechanism, but the right one despite its imperfections, if you ask me. If the membership can't bother to lead a member-led organization, we have bigger fish to fry than the efficacy of this new mechanism.
There was a problem hiding this comment.
The AC gets to approve (or not) the extension if it is declared to be an extension, but the AB gets to decide whether to describe it as an extension or not in the first place. If the AB declares something to be a different experiment rather than an extension, nobody is asked to check how much of a stretch that is.
There was a problem hiding this comment.
We now enable the AC to appeal any experiment. So if they think the AB is pulling a fast one by calling it a new experiment, they can appeal it.
This raises the question of whether an extension mechanism is necessary if the AC can appeal every experiment. But I think it's useful to set expectations, and I have in mind:
- Experiments must be time-limited.
- If more time is needed because the experiment is promising, one extension should not seen as ok.
- But at any time the AC an appeal an experiment, and the AB should be held to account if they appear to be abusing the process.
| The Advisory Boards must notify the Membership and public of its decision to authorize a Process Experiment | ||
| no less than three weeks before the planned start of the experiment. | ||
| Provided the experiment remains within <a href="#experiment-scope">scope limitations</a>, | ||
| the authorization itself is not subject to the usual Formal Objection mechanisms, but it is subject to Advisory Committee Appeal. |
There was a problem hiding this comment.
The inclusion of AC Appeal is a step in the right direction, but a small one, I am concerned that the ability for the AB to modify the process largely at will and with no authorization is a giant shift in our power structure, and a shift away from a "rule of law" type of governance.
Sure, there are some time limitations (but I don't think they're much of a limitation in practice, see https://github.com/w3c/process/pull/1189/changes#r3974937741), and there are some very small scope limitations, but this effectively gives the AB the ability to change any and all parts of the Process with hardly any oversight. The name "Advisory Board", alongside with its description that says "has no decision-making authority within W3C; its role is strictly advisory" then becomes really inappropriate. It becomes something more suited to be called maybe an Executive Committee or Directorate.
Sure, we do have elections which can bring some measure of accountability into this, but even then, it is still a massive shift from being governed by collectively approved rules to enabling governance by executive orders.
There is a broader lesson about governance here. We may think we don't need detailed rules because we have longstanding norms of good behavior, or that we can always vote out anyone who abuses their power. But norms can be ignored, and electoral safeguards are only useful if they actually work.
Likewise, giving the AB broad power to override the Process may seem efficient, provided we trust it to use that power responsibly. But when rules can be set aside at will, it becomes unclear whether an exercise of power is actually lawful, and who has the authority to say so when it isn't.
This is why the rule of law matters: it is designed for when good governance norms fail.
There was a problem hiding this comment.
I am concerned that the ability for the AB to modify the process largely at will and with no authorization
I find this characterization of the proposed experiment mechanism to be at odds with the text of the proposal. The text requires (with RFC 2119 MUST) the AB to tell the AC about each and every experiment they’d like to run, weeks before they run them, and the AC is empowered to appeal any and all of them.
If the AB proposes to run an experiment in which it suspends all rules and lets anarchy prevail for a year, and we can’t find a single AC rep to appeal that, we have much bigger problems. That said, I'm encouraged by the effort elsewhere in the discussion on this PR where we're all trying to make sure experiments have the right sort of guardrails etc.
is a giant shift in our power structure, and a shift away from a "rule of law" type of governance.
No, it’s not. In fact, I’d argue the opposite. It’s enabling the Membership to more fully realize a Member-led consortium, by giving it necessary tools to experiment with process changes, so that we can identify concrete changes that we can be confident will actually improve the effectiveness of the organization re: meeting the Membership’s needs.
This is why the rule of law matters: it is designed for when good governance norms fail.
I agree!
Co-authored-by: Florian Rivoal <git@florian.rivoal.net>
|
De-threaded this because this bikeshedding is a distraction from the rest of the discussion on the PR; please don’t spend many calories thinking about this, but I didn’t want to leave this bit unanswered:
The names of both the AC and the AB do not reflect either body’s actual role around here, and haven’t for years. The AC was merely advisory in the Director-as-sole-formal-decisionmaker early years, but it hasn’t been merely advisory since well before my time. (These days, it's much closer to explicitly being the consortium’s font of authority than it is an advisory body.) The AB, too, is not merely advisory; certainly not in this era of W3C Councils. I’m inclined to leave the names in place. I think it’s charming that the IETF’s designation for a spec that’s reached maturity is merely a "Request For Comments", and that our final standards are mere "Recommendations." Just so, I’m fine with continuing to call the AC the AC, and the AB the AB, even though we know the word "advisory" doesn’t really precisely describe either any more. « Ce corps qui s’appelait et qui s’appelle encore le Saint-Empire romain n’était en aucune manière ni saint, ni romain, ni empire. » But, if people insist that we abandon such long-standing names for the things, can we at least try to keep the abbreviations? "Assemblée du Consortium", anyone? |
The W3C Process Document is managed by the Advisory Board. Changes to the Process Document are reviewed by the Advisory Committee and adopted by consensus. The Membership has not explicitly granted the Advisory Board the authority to conduct experiments related to the existing process.
This is a proposal to legitimize temporary alternative Processes authorized by the Advisory Board.
Preview | Diff