Re: Request for CCG Chair Intervention in CCG Process

Thanks Manu.  I agree it may be overkill in some cases, and if we see
things slow way too far down on early incubation items we can address as a
community.  That is one of the benefits we have as a community group, that
we can adopt appropriate process where needed e.g. in this case for
managing dissent: where the Editors of a work item act in the role of the
"Chairs" in a traditional W3C working group.

I have a clarification from the docs on your 3rd point:

> 3. There will be no ability for a group to use any form of
>    simple majority or supermajority voting to make a
>    temporary decision, manage dissent, and/or move on. We
>    are now required to use the full blown W3C Process for
>    all resolutions in work item groups.


Quoting from here: https://www.w3.org/2020/Process-20200915/#Consensus
"A charter may include threshold requirements for consensus decisions. For
instance, a charter might require a supermajority of eligible participants
(i.e., some established percentage above 50%) to support certain types of
consensus decisions."

In the CCG this implies that the Work Item editors may determine mechanisms
such as supermajority voting at the work item level to achieve consensus,
but I would caution that unless a method is clearly defined and approved by
contributors to the work item this could lead to issues such as we have
seen here.  Resolutions where it is clear that the group is strongly
divided and there is no clear consensus at all, or even a direction towards
consensus, that receive a formal objection would likely not be upheld on an
appeal.  Because of the goal for consensus, simple majority approaches
could be highly problematic.  Likely, when consensus cannot be reached the
topic should be shelved and revisited at a later date when it appears that
consensus might be possible on a particular topic.

Mike Prorock
CTO, Founder
https://mesur.io/



On Fri, Aug 20, 2021 at 9:38 AM Manu Sporny <msporny@digitalbazaar.com>
wrote:

> On 8/20/21 7:15 AM, Mike Prorock wrote:
> > You are asking some great questions.  I am going to answer inline so
> that
> > things don't get missed.
>
> Thank you for the responses, Mike, Heather, and Wayne. The CCG Chairs
> position
> feels crystal clear to me and I really appreciate the speed and
> decisiveness
> with which the Chairs engaged.
>
> What I was most concerned about was that the work item groups would end up
> with no way to manage dissent and that work item members could bypass work
> item consensus by repeatedly raising a formal objection. It sounds like
> there
> are good protections in place to prevent that from happening (and for the
> check and balance to not be abused by the Editors).
>
> It does change the mental model that I understood the Work Item Groups to
> be
> operating under, but that's fine -- there's a clear path to determining
> consensus and managing dissent now where the responsibility is delegated to
> the Editors and with an appeal path to the CCG Chairs. That feels
> manageable
> and scalable to me.
>
> I had tried to ensure buy-in in the entire VC HTTP API group so that
> everyone
> could participate in the dissent recordation process for managing dissent,
> instead of depending on the Organizer to do so (by allowing for more
> dissent
> to be recorded and then moving on), but unfortunately this was misread as
> changing the consensus process... which led to more trouble than it was
> worth.
>
> I was also operating under the assumption that applying the full weight of
> the
> W3C Process to a work item was overkill, that resolutions made in a work
> item
> group were preliminary findings (what could be challenged later), but it
> seems
> as if some folks in the community want us to operate with full W3C Process
> from day one. I personally think that this desire is misguided for work
> items
> under incubation, but will try to operate under this mode until it becomes
> a
> problem (and will then re-raise the concern at that point in time). Perhaps
> I'm worrying about it prematurely.
>
> To be clear, I had assumed that work item groups just operated as lowercase
> "working groups" per W3C Process where the organizer was acting as Chair
> with
> the broad ability to seek consensus and manage dissent, which included
> broadening the amount of dissent that could be recorded (this is what
> temporarily switching to simple majority / super majority voting does for
> decisions that can be challenged later - FCGS, FPWD, CR, PR, REC <-- each
> stage allows for a formal objection to anything in the specification on any
> technical ground).
>
> What I'm understanding now is that:
>
> 1. The Editors, not the Organizers, determine consensus
>    and manage dissent.
>
> 2. Any dissent on a resolution recorded by the Editors,
>    through a formal objection, is raised to the CCG Chairs
>    for a final decision.
>
> 3. There will be no ability for a group to use any form of
>    simple majority or supermajority voting to make a
>    temporary decision, manage dissent, and/or move on. We
>    are now required to use the full blown W3C Process for
>    all resolutions in work item groups.
>
> Works for me, proposals for the VC HTTP API work item group to move on are
> forthcoming.
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)
> https://www.digitalbazaar.com/
>
>
>