Re: Request for CCG Chair Intervention in CCG Process

Orie,
I would request you revisit the following link included in the prior email
from the Chairs: https://www.w3.org/2020/Process-20200915/#Consensus

Quoting:
"Where unanimity is not possible, a group should strive to make consensus
decisions where there is significant support and few abstentions. The
Process Document does not require a particular percentage of eligible
participants to agree to a motion in order for a decision to be made. To
avoid decisions where there is widespread apathy, (i.e., little support and
many abstentions), groups should set minimum thresholds of active support
before a decision can be recorded. The appropriate percentage may vary
depending on the size of the group and the nature of the decision. 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."


Michael Prorock
CTO, Founder
mesur.io

On Thu, Aug 19, 2021, 14:57 Orie Steele <orie@transmute.industries> wrote:

> > Should they be removed entirely, as well?
>
> Yes, PRs for resolutions that have objections should not be merged.
>
> Editors are responsible for implementing consensus and acknowledging when
> it does not exist.
>
> As an editor, based on my experience on the calls, I recommend the
> chairs direct the editors to move API authorization out of scope for the
> work item and into a separate document, that can explain the pro's and
> con's of GNAP and OAuth, and have the main spec simply refer to that
> document, and note that the working group could not agree to any normative
> requirements regarding securing HTTP APIs.
>
> Perhaps new work items called "vc-http-api-with-gnap" and
> "vc-http-api-with-oauth", or similar.
>
> As an implementer, Transmute has no plans to support GNAP at this time,
> and we can't afford to participate on a work item that bundles support for
> it as a requirement.
>
> If other implementers feel the same about OAuth2, the only option I can
> see is to not discuss either in the VC-HTTP-API work item calls.
>
> OS
>
>
>
>
>
> On Thu, Aug 19, 2021 at 12:06 PM Adrian Gropper <agropper@healthurl.com>
> wrote:
>
>> Thank you for the quick and thorough response. I believe the other two
>> resolutions made that day do not meet the criteria for group consensus.
>> Should they be removed entirely, as well?
>>
>> - Adrian
>>
>>
>> On Thu, Aug 19, 2021 at 12:50 PM Heather Vescent <
>> heathervescent@gmail.com> wrote:
>>
>>> Dear Community,
>>>
>>> At CCG, all decisions should be driven by consensus of the community for
>>> a particular work item. As a W3C community group, we have the W3C processes
>>> at our disposal, but these are as a best practice, not a requirement if
>>> another process is in the best interest of the community. In this case we
>>> refer to consensus from this document:
>>> https://www.w3.org/2020/Process-20200915/#Consensus
>>>
>>> In the topic of VC-HTTP-API and GNAP, both sides have been collaborating
>>> in good faith despite opposing perspectives. Based on discussion of this
>>> issue and review of it by the three CCG co-chairs, we offer the following
>>> clarifications:
>>>
>>> 1) We believe as chairs that most importantly all parties are acting in
>>> good faith, and we ask the community to extend that good faith to each
>>> other especially with those with opposing viewpoints.
>>>
>>> 2) The work item escalation processes is first to raise objections to
>>> the work item spec editors (in this case: Manu Sporny, Markus Sabadello,
>>> Mike Varley, Orie Steele, Mahmoud Alkhraishi). If this does not result in a
>>> resolution or there is a principled objection, the escalation can be
>>> brought to the CCG Chairs.
>>>
>>> 3) While there is a formal process to approve an official CCG work item;
>>> we do not have formally defined operational requirements for individual
>>> work items. The chairs will document the escalation process described above
>>> (#2) in the work item process document:
>>> https://w3c-ccg.github.io/workitem-process.
>>>
>>> 4) We as chairs do not believe based on call transcripts and github
>>> discussions that the "RESOLUTION: One of the authorization mechanisms
>>> defined for the VC HTTP API MUST be GNAP" has group consensus, and as
>>> chairs recommend removing it entirely.
>>>
>>> 5) We as chairs recommend in the future as a best practice that any PRs
>>> be separated with a single PR per resolution wherever possible.
>>>
>>> The chairs believed a reasoned and swift response was in the best
>>> interest of forward momentum of the work.
>>>
>>> - The CCG Chairs
>>> Heather, Mike & Wayne
>>>
>>> On Thu, Aug 19, 2021 at 7:52 AM Mike Prorock <mprorock@mesur.io> wrote:
>>>
>>>> The chairs are meeting today to begin discussion on the issue.   We
>>>> will try and be timely with a response.
>>>>
>>>> Michael Prorock
>>>> CTO, Founder
>>>> mesur.io
>>>>
>>>> On Wed, Aug 18, 2021, 21:31 Joe Andrieu <joe@legreq.com> wrote:
>>>>
>>>>>
>>>>> On Wed, Aug 18, 2021, at 2:52 PM, Manu Sporny wrote:
>>>>>
>>>>> This is a request for intervention by the CCG Chairs on a CCG Process
>>>>> question
>>>>> that has been raised in the VC HTTP API Work Item group.
>>>>>
>>>>>
>>>>> Yes, please.
>>>>>
>>>>> I answered Manu's latest in Github. You can find my position
>>>>> articulated at
>>>>> https://github.com/w3c-ccg/vc-http-api/pull/224#issuecomment-901536833
>>>>>
>>>>> TLDR: subgroup/task force call facilitators should not be free to
>>>>> manipulate voting processes. Especially when doing to with the express
>>>>> purpose of bypassing consensus. Spectext without consensus should not be
>>>>> merged.
>>>>>
>>>>> The chairs are the appropriate authority for resolving this impasse.
>>>>>
>>>>> -j
>>>>>
>>>>> On Wed, Aug 18, 2021, at 2:52 PM, Manu Sporny wrote:
>>>>>
>>>>> This is a request for intervention by the CCG Chairs on a CCG Process
>>>>> question
>>>>> that has been raised in the VC HTTP API Work Item group.
>>>>>
>>>>> The crux of the issue is that there are some in the VC HTTP API Work
>>>>> Item
>>>>> group that believe that there is no clear escalation process for
>>>>> resolving
>>>>> decisions that are unable to achieve group consensus.
>>>>>
>>>>> Some have asserted that the definition of "consensus" is not clear and
>>>>> that
>>>>> the CCG does not necessarily follow W3C Process (because it has
>>>>> created its
>>>>> own bespoke rules over the years).
>>>>>
>>>>> A recent attempt at polling for consensus, and then when that failed,
>>>>> backing
>>>>> off to a majority vote of those present, and when that failed, using a
>>>>> simple
>>>>> majority vote of those that were present:
>>>>>
>>>>> https://w3c-ccg.github.io/meetings/2021-07-13-vchttpapi/#topic-4
>>>>>
>>>>> ... has resulted in an objection that the approach is not acceptable
>>>>> for the CCG:
>>>>>
>>>>> https://github.com/w3c-ccg/vc-http-api/pull/224#discussion_r682106281
>>>>>
>>>>> ... which then resulted in a meta discussion about CCG process:
>>>>>
>>>>> https://w3c-ccg.github.io/meetings/2021-08-17-vchttpapi/#topic-3
>>>>>
>>>>> Chairs, please clarify the escalation process for decisions that don't
>>>>> achieve
>>>>> consensus.
>>>>>
>>>>> My personal suggestion is to make the following clarifications:
>>>>>
>>>>> 1. Clarify that the applicable definitions and
>>>>>    sections of the W3C Process document are the base
>>>>>    definitions and operating procedure for the CCG and the
>>>>>    Work Item groups. Refer to the document explicitly
>>>>>    from the CCG Process.
>>>>>
>>>>> 2. Clearly state that all decisions are to be made
>>>>>    by group consensus (as defined by the W3C Process
>>>>>    Document). If consensus fails, the Editors
>>>>>    of a particular document can make a binding consensus
>>>>>    decision to get the group to move on. That decision can
>>>>>    be appealed with the W3C CCG Chairs who will make
>>>>>    the final decision.
>>>>>
>>>>> Please provide a resolution to this issue sooner than later, as it
>>>>> continues
>>>>> to negatively impact the VC HTTP API work.
>>>>>
>>>>> -- 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/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Joe Andrieu, PMP
>>>>>                        joe@legreq.com
>>>>> LEGENDARY REQUIREMENTS
>>>>>        +1(805)705-8651
>>>>> Do what matters.
>>>>>                      http://legreq.com
>>>>> <http://www.legendaryrequirements.com>
>>>>>
>>>>>
>>>>>
>>>
>>> --
>>> Heather Vescent <http://www.heathervescent.com/>
>>> Co-Chair, Credentials Community Group @W3C
>>> <https://www.w3.org/community/credentials/>
>>> President, The Purple Tornado, Inc <https://thepurpletornado.com/>
>>> Author, The Secret of Spies <https://amzn.to/2GfJpXH>
>>> Author, The Cyber Attack Survival Manual
>>> <https://www.amazon.com/Cyber-Attack-Survival-Manual-Apocalypse/dp/1681886545/>
>>> Author, A Comprehensive Guide to Self Sovereign Identity
>>> <https://ssiscoop.com/>
>>>
>>> @heathervescent <https://twitter.com/heathervescent> | Film Futures
>>> <https://vimeo.com/heathervescent> | Medium
>>> <https://medium.com/@heathervescent/> | LinkedIn
>>> <https://www.linkedin.com/in/heathervescent/> | Future of Security
>>> Updates <https://app.convertkit.com/landing_pages/325779/>
>>>
>>
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
>