w3c
redirect all wording that does not have consensus to discussion in Rubric
The editors claim, in pull/27, with support, that this Note's development has not been operating under rules seeking consensus, and that it should not.
Per the W3C Process standard, in section 3.3.1. Managing Dissent, it is clear that working groups "SHOULD favor proposals that create the weakest objections".
Per discussion in the DID WG, there is a renewed call to manage dissent using the Rubric. This issue will be complete once all wording that does not have consensus is redirected to discussion in the Rubric.
- Dissent within pull/27 will be there, while the pull request is open.
- Other dissent will be submitted as new pull requests, for as long as necessary.
[pull request forthcoming]
The Implementation Guide has been published as a Working Group Note. It is not a recommendation track document, and does not fall under the W3C process requirements for recommendation track documents. The only consensus that was required for the Implementation Guide Note was the decision we made as a working group to publish it. This does not mean that we do not strive for consensus on additions to the Implementation Guide, but it does allow for differing opinions to be represented in the case that consensus cannot be reached. This is in contrast with recommendation track documents, whose contents must reflect the consensus of the group.
The suggestion I made during today's call was that we add criteria to the DID Rubric so that DID Methods might be evaluated in line with the concerns discussed during the call, and that these additions to the rubric be made in conjunction with language in the implementation guide for DID Method implementers such as that begun in PR 27.
On Tue, Sep 14, 2021, 11:16 rxgrant @.***> wrote:
The editors claim http:///w3c/did-imp-guide/pull/27/#issuecomment-919120486, in pull/27 http:///w3c/did-imp-guide/pull/27/#issuecomment-918584987, with support http:///w3c/did-imp-guide/pull/27/#issuecomment-918745249, that this Note's development has not been operating under rules seeking consensus, and that it should not.
Per the W3C Process standard https://www.w3.org/2020/Process-20200915/, in section 3.3.1. Managing Dissent https://www.w3.org/2020/Process-20200915/#managing-dissent, it is clear that working groups "SHOULD favor proposals that create the weakest objections".
Per discussion in the DID WG https://www.w3.org/2019/did-wg/Meetings/Minutes/2021-09-14-did#section6, there is a renewed call to manage dissent using the Rubric http:///w3c/did-rubric. This issue will be complete once all wording that does not have consensus is redirected to discussion in the Rubric.
- Dissent within pull/27 will be there, while the pull request is open.
- Other dissent will be submitted as new pull requests, for as long as necessary.
[pull request forthcoming]
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/w3c/did-imp-guide/issues/30, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACPFKP5PR3WIHRFBOOY6BBLUB57QVANCNFSM5EAT6CBQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Seeking consensus is not only for standards track documents. Section 3.3 of the W3C Process document, from which the very clear instructions above were pulled ("SHOULD favor proposals that create the weakest objections"), applies to all group activities.
3.3. Consensus
Consensus is a core value of W3C. To promote consensus, the W3C process requires Chairs to ensure that groups consider all legitimate views and objections, and endeavor to resolve them, whether these views and objections are expressed by the active participants of the group or by others (e.g., another W3C group, a group in another organization, or the general public). Decisions may be made during meetings (face-to-face or distributed) as well as through email.
The relaxation of a Note from strict consensus is not an excuse for mutually-disagreeing opinion sections in an implementation guide that is published under the group's name.
With that said, I do see the fight moving on and this issue being eventually closed.
@rxgrant —
The relaxation of a Note from strict consensus is not an excuse for mutually-disagreeing opinion sections in an implementation guide that is published under the group's name.
If you've been keeping up with all the issues here on the ImpGuide, you'll hopefully have noticed that current efforts are to take all of those "mutually disagreeing opinions" out of the ImpGuide and move them into the Rubric which has been constructed explicitly to address such opinion tradeoffs — which is what the disagreements generally amount to, i.e., prioritizing security, or the intangible "human rights", or a similarly intangible "ease of use", or compute consumption, or datapipe consumption, or storage consumption, or any other aspect a DID method might have, above all others.
"Strict consensus" has not been a W3C practice in the 20ish years I've been involved, if ever. WGs, XGs, CGs, and others, are all charged to (as you quoted!) "consider all legitimate views and objections, and endeavor to resolve them." Groups are not required to reach perfect consensus on anything.
In all the groups in which I've participated, we've generally striven to reach text that all members "can live with", such that a poll of opinions has no –1 votes (which are generally taken as a prelude to a Formal Objection in REC-track context), though displeasure may be recorded by –0.9 or similar. Sometimes, the resolution is by super-majority vote within the group. Sometimes, it's by simple-majority. Sometimes, it's by allowing for the subject in contention to be handled in any or all ways being advocated by any member — which can be challenging for interop, but can also improve interop, by allowing a way, for instance, to transform some content from one media type to another.
"Strict consensus" has not been a W3C practice in the 20ish years I've been involved, if ever.
We're in agreement on that point and I'm pointing out that under the circumstances in effect there is still an obligation to minimize dissent. We've made great strides but there's still text in the Implementation Guide that this issue will address.
there's still text in the Implementation Guide that this issue will address.
Can you point to the specific language in the Implementation Guide that you feel needs to be addressed?