w3process
w3process copied to clipboard
w3c
Limit the scope of FO Council deliberations
The FO Council should sustain an FO only if rejecting the FO would necessarily result in a violation of the W3C process, today or in the future. For example, the FO Council should not:
- consider rules outside of those specified in the W3C process
- sustain an FO that merely proposes an alternative technical solution
- expand the scope of the FO beyond that at intersection of the FO and the decision challenged by the FO
Constraining the scope of the FO Council is essential since:
- the FO Council must not be a venue where technical decisions are made, for which the primary venue is the WG and the ultimate venue is the AC
- the FO Council must not be a venue where process or policy is created/modified, for which the primary venue is the AB and the ultimate venue is the AC
- the FO Council membership will usually include members that have a stake in the decision, and the decision FO council decision should be in the best interest of the web community and not partisan
- FO council members are not necessarily experts in the technical area of the FO
- making the work of the FO council simpler makes it easier to reach decisions and maintain engagement of FO council members
https://www.w3.org/Consortium/Process/Drafts/director-free https://github.com/w3c/AB-memberonly/blob/master/documents/FormalObjectionCouncilGuide.md#i-considerations
[edit: clarified that W3C Process means the W3C Process document in its entirety, not merely the sequence of steps involved in publishing a REC.]
I'm afraid that all those limitations might just make the FO council rather powerles. It seems that you're proposing is (correct me if I misunderstood):
- if it's a process issue, punt to the AB
- if ti's a technical issue, leave it to the WG
- if it's more political/societal issue, it should be the AC decision.
In practice, complicated FO might be a mix of all of those, or disputes between several WGs point of views, or even holes in what the process specifies. Stating all those limitations, while the council is meant to cover what has not been resolved by all our common rules, seems to make it completely useless in the end. That said, stating explicitly that the FO council has to check first that all the rules and normal process have been followed is a good idea. Then, unless obvious oversight is identified, it should not be limited any further.
@caribouW3 Thanks for the feedback. Clarifications below.
if it's a process issue, punt to the AB
If the FO complains that process has been violated, then it is in scope of the FO council.
If the FO complains that the process itself is not adequate, then it is outside the scope of the FO council: the FO council should not create new process and/or modify existing process. The FO council should be able to interpret current process of course.
if ti's a technical issue, leave it to the WG
Yes, technical issues should really be left to the WG (and the AC) since this is where experts are -- unless rejecting the FO would result in a technical issue would result in a process violation.
if it's more political/societal issue, it should be the AC decision.
Yes, the FO council should not create policy for the W3C.
In summary, the FO council should focus solely on process violations.
I concur with @caribouW3 . Focusing the Council solely on process violations would make the Council mostly useless. The formal objections are rarely, if at all, process violations. FOs are about charters and technical specifications: we argue on scope, approach (including use cases and requirements), or solutions. Working Groups don't operate in a vacuum but are part of a larger Web ecosystem.
The Council was designed to replace the Director: make the best decision for the World Wide Web.
I think the complexity of previous FOs need to be considered; they are not typically purely formal, rule-based, procedural. They are usually about what's right for the web and consortium, and are typically "hard questions".
They are usually about what's right for the web and consortium, and are typically "hard questions".
How does on define "hard question"? As it stands, there are no limitations to what folks can file as FO and what the Council will consider.
My proposal is to limit the work of the Council to process violations.
This idea is to provide some consistency and predictability to members in a director-free world, and make sure that member consensus cannot be overridden but in the most exceptional circumstances.
Thank you for clarifying the intent.
If the FO complains that process has been violated, then it is in scope of the FO council.
Agreed, the Council can judge whether the process has been followed correctly or not, in most cases. However, typical FO are not at all about process violation, I think.
If the FO complains that the process itself is not adequate, then it is outside the scope of the FO council: the FO council should not create new process and/or modify existing process. The FO council should be able to interpret current process of course.
FO against process changes are already in the court of the AC+AB+possibly this CG when trying to adapt the process if needed.
if ti's a technical issue, leave it to the WG
Yes, technical issues should really be left to the WG (and the AC) since this is where experts are -- unless rejecting the FO would result in a technical issue would result in a process violation.
That is mostly where I disagree with your proposal. Formal objections can come from inside a WG, where either consensus has been reached except for a minority of (strong) objectors, or another group (e.g. WG, or horizontal reviewing group) is opposing the WG's resolution. In those cases, they are not violation of process (quite the contrary, FO are a process tool for dealing with disagreement). I expect the FO council to form some kind of mediation between the disagreeing entities.
if it's more political/societal issue, it should be the AC decision.
Yes, the FO council should not create policy for the W3C.
I'm also somewhat reluctant to say this, even though AC is generally the right place to discuss this kind if issues, it is even harder to get consensus from the entire AC than in a WG, hence the rather high likelihood to get FO on such matters.
In summary, the FO council should focus solely on process violations.
I must state that I'm speaking from myself only here (sorry, I should've said so earlier), but clearly I don't think such a council would be very useful.
Process violations result in the team handling them, not FOs. Hard questions are … well, all the questions without an easy answer such as a rule in a process document. Look at what people FO about: things they think will be bad for the web, are wrong for society, contrary to values, and so on. And we need to handle them in community, not rely on an omniscient Director.
@caribouW3
Formal objections can come from inside a WG, where either consensus has been reached except for a minority of (strong) objectors, or another group (e.g. WG, or horizontal reviewing group) is opposing the WG's resolution. In those cases, they are not violation of process (quite the contrary, FO are a process tool for dealing with disagreement).
When I mean "W3C process" I literally mean the W3C Process.
The W3C process is quite broad. For example, it specifies that W3C work revolves around the standardization of Web technologies, so that an objection that a charter scope falls outside of the standardization of Web technologies would be in scope of the Council.
I expect the FO council to form some kind of mediation between the disagreeing entities.
Unfortunately, the FO council produces only "yay" or "nay" so I do not see how mediation is possible (or required).
P.S.: Limiting the scope of FO Council (and thus the FO process) encourages objectors to cast their objections in light of the W3C Process, so "I do not like this technology" might become "This choice of technology is fundamentally incompatible with Clause X of the W3C Process".
P.S.: Limiting the scope of FO Council (and thus the FO process) encourages objectors to cast their objections in light of the W3C Process, so "I do not like this technology" might become "This choice of technology is fundamentally incompatible with Clause X of the W3C Process".
Getting people to phrase technical or "philosophical / societal perspective" objections in that way would, IMHO, be a terrible outcome.
We want the process to provide easy guidance to understand how things should work in a consensus-driven collaborative effort at problem-solving, and emergency guardrails for when the community doesn't manage to live up too that. Encouraging people to work out how to interpret the Process to support their contention that some technology or market outcome violates a provision of process introduces all kinds of pressures and behaviours that run counter to those goals.
W3C Recommendations have value because they demonstrate fairly strong support from the community. Not merely having followed rules, but having addressed, by consensus, every issue or disagreement anyone has. Enabling working groups to issue Recommendations that gather strong objections as long as the rules have been followed would certainly make it easier to issue Recommendations, but it would also greatly diminish their value. Enabling chairs to make decisions that people strongly disagree with as long as no rule has been violated might make it easier to chair, but it would be a great disservice to the community.
We are not trying to adjudicate guilt or innocence, determined by whether people complied with rules. We are trying to find the most agreeable way forward, in the interest of the Web and W3C, in a situation where normal deliberations have so far failed to achieve consensus.
The discussion seems to have deviated from the issue and proposal at hand.
This issue does not propose to prevent folks from objecting and/or to encourage groups to overlook objections -- ignoring strong objections is unlikely to result in successful standards and will likely result in negative consequences in the long run, e.g. negative AC vote or board appeal.
This issues proposes that the FO council to consider FOs in the context of the W3C process.
It would be counter-productive and surprising if W3C spent considerable amount of effort creating a detailed process only to ignore it when considering formal objections. It would also encourage folks to: (a) use the FO council instead of this present process to modify the W3C process and (b) use the FO council to force adoption of their technical ideas instead on working on a compromise.
Now I am lost. If you commit a Process Violation, it should be caught sooner than a Council, but if not, of course the Council should consider that in their decision, and the decision ought not contravene the Process. Does that need saying explicitly?
Does that need saying explicitly
AFAIK the current draft revised process neither specifies that an FO should be against a requirement of the W3C process nor that the FO Council should base its decision on the W3C process.
See, for example, Considerations which does not even mention the W3C process.
Specifying that an FO should be against a requirement of the W3C process and that the FO Council should be based its decision on the W3C process would resolve this issue.
Maybe we are closer than we think :)
No, FOs are not typically about the W3C Process. "This is outside the scope of w3C", "This is not in accordance with our values", "This presumes the answer to a question that the community has not yet resolved" are none of them Process points at all.
So we disagree about your premise. Most Process violations are resolved much earlier, and most FOs do not concern simple Process violations.
"This is outside the scope of w3C" [...] are none of them Process points at all.
The W3C Process in fact contains guidance on the scope of the W3C, so an FO could be constructed along the lines of "this project is outside the scope of the W3C", e.g. I would like to create a WG to standardize the size of sardine cans.
I see the W3C Process as a set of rules that members agree to follow when they choose to do technical work within the W3C. These members plan their activities accordingly. It would be very disruptive to stop/impair technical work for a reason (the objection) that is not based on these rules.
I would think that someone what wishes the change the rules, e.g. impose additional requirements on WGs, should work on modifying the W3C Process (like what we are doing here) instead of filing an FO.
Do you know of other member-driven SDOs that allow technical work to be stopped by a participant who does not like the rules and/or believes additional rules are necessary? Usually, the steps needed to alter rules are on a completely different track than that of the technical work.
@dwsinger Thanks for the feedback and for you patience in explaining your position.
I think our concerns may finally overlap. You're worried about the Council making up Process as we go along; we are concerned about Charters doing that, and specifically that the new TT charter weakened the Process requirements for independent interoperable implementations, which might set a dangerous precedent. The process:
While no exhaustive list of requirements is provided here, when assessing that there is adequate implementation experience the Director will consider (though not be limited to):
- is each feature of the current specification implemented, and how is this demonstrated?
- are there independent interoperable implementations of the current specification?
- are there implementations created by people other than the authors of the specification?
- are implementations publicly deployed?
- is there implementation experience at all levels of the specification’s ecosystem (authoring, consuming, publishing…)?
- are there reports of difficulties or problems with implementation?
notably that "two independent factors of verification" is different from two implementations, a point reinforced by allowing content, which isn't (but might be evidence of) an implementation, per se.
A charter cannot override the W3C process, i.e. the W3C process always takes precedence over a charter.
Conversely, charters should not impose requirements beyond those specified in the W3C process -- otherwise each group ends up operating a different set of rules, which makes it difficult to share expertise/experience across groups.
Re: specific example you cite, the W3C Process actually does not require two independent implementations, but instead requires implementation experience and provides a non-exhaustive list of means by which such implementation experience can be demonstrated.
Perhaps the W3C Process should be more specific on what "implementation" and "independent" mean, but an FO Council is not the place to do this. If anything the Process CG, the AB and ultimately the AC are.
P.S.: To be clear, I am very much in favor of clarifying the notion of implementation experience, since this has been a point of friction over the years. In fact I think we (the W3C) should do this now and am happy to participate. I just do not think an FO council is the right place to do it.
(I don't think the concerns overlap - because the way I see the Formal Objections to the TT charter is that it uses flexibility that was designed into the process for a world where there aren't always multiple independent implementations. But at last, that question is going to be decided by a W3C Council Experiment. Let's see what happens).
It isn't the W3C rules that stop us from have a working group on Sardine cans. If there is a proposal, we will get a decision, following the process, whether this is work W3C thinks it should do. If a charter is proposed, and supported by 30 or so members, and 2 object that this is out of scope for W3C in general, the Council will have to make a decision. There is no violation of Process to discuss, it's a question about markets, technical preferences, and so on.
I believe that this is the case for most formal objections, and am pretty sure it is the case for pretty much all those that I have filed. IMHO there was no process issue in the EME decision (easily the most contentious FO decision W3C has made in its history).
I doubt that we are going to completely disambiguate the meanings of:
- independent
- interoperable
- implementation
In this FO. They all have squishy areas. What we don't want to do is have either the TT charter, or the decision of this FO, set too broad a precedent before we work through the myriad 'soft edges' of these definitions.
It isn't the W3C rules that stop us from have a working group on Sardine cans.
It certainly conflicts with the current W3C Process that states W3C work revolves around the standardization of Web technologies.
It is really paramount that the W3C writes down what its mission, principles, rules are for when the Director (and many of the folks on this thread) have moved on.
Agreed, we need tighter mission, scope, and values – but they will never be tight enough to be unerringly diagnostic, there will always be judgment calls.
but they will never be tight enough to be unerringly diagnostic, there will always be judgment calls.
Sure... that is not incompatible with specifying that an FO should be against a requirement of the W3C process and that the FO Council should be based its decision on the W3C process :)
I doubt that we are going to completely disambiguate the meanings of:
* independent
#167
@dwsinger wrote
but they will never be tight enough to be unerringly diagnostic, there will always be judgment calls.
@palemieux replied
Sure... that is not incompatible with specifying that an FO should be against a requirement of the W3C process and that the FO Council should be based its decision on the W3C process :)
In practice I believe, and I believe @dwsinger is arguing precisely that the kind of judgement required is incompatible with a requirement the FOs be based on some violation of W3C Process.
Such a requirement would ignore the historical realities of Formal Objections, meaning most would be dismissed unexamined.
While this might make things faster, it would deprive W3C of a mechanism that can bring important non-procedural issues to wider prominence for a larger group of stakeholders to check that they were actually decided in the best interests of the Web, by using the larger group of stakeholders as a proxy for a better approximation to representing "the best interests of the Web".
Replacing that mechanism would require far more day-to-day involvement in Working Groups by far more members, which is an unrealistic cost that is unsustainable in practice. Therefore the outcome would be that there is less oversight and a bad decision is much less likely to be overturned by more thoughtful review, while a good decision that is challenged will no longer be reinforced by additional review. (Using the outcome of an FO review as a first proxy for a good or bad decision, which is somewhat optimistic but the best tool we actually have available...)
@nigelmegitt you might think "independent" is obvious, but in the session at TPAC we identified questions: how long ago can an open-source project have forked, for the two forks to be "independent"? Are two implementations by different engineers at the same company "independent"? Conversely, if the same consultant is hired by two companies to advise on how to implement (but doesn't write all the code), are those "independent"? And so on
@dwsinger I certainly do not think "independent" is obvious. My comment was a link to the issue when I first pointed this out and asked for clarification, more than 4 and a half years ago!