Re: Migrating supporting repositories to CCG?

I have a slightly different take.

To *formally* move something into the CCG it does need to go through the
work item process. That said, looking at those items, the repos support a
general idea - and that general idea is what I would suggest go through the
work item process, and specify the repos under that proposed work item.

We've transfered multiple repos under a single work item request in the
past and this can be the same.

So I suggest the path forward is to: create a single work item that
satisfies the work item requirements, and put all those repos under that
work item.

Make sense?

-Heather

On Wed, Apr 13, 2022 at 3:08 PM Mike Prorock <mprorock@mesur.io> wrote:

> Excellent question - my gut feel is that the primary work item editors in
> this case are sufficient to support a move without full re-approval.  This
> is assuming, as is the case here, that these items are directly in support
> of or part of an approved work item.  Onus would be on the work item editor
> to ensure no objects from work item participants, etc on this.
>
> That is my read, but I would like to see if there is a different take.
>
> Mike Prorock
> CTO, Founder
> https://mesur.io/
>
>
>
> On Wed, Apr 13, 2022 at 5:18 PM Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
>> Hey CCG Chairs (and Emeritus Chairs),
>>
>> This question came up during a VC API telecon:
>>
>> Can Github repositories that support an existing CCG work item be moved
>> to CCG
>> automatically, or does every Github repository need to go through the work
>> item process?
>>
>> For example, if "Work Item X" is adopted as a CCG work item, then we
>> create a
>> "Work Item X Use Cases", "Work Item X Test Suite", or "Work Item X
>> Developer
>> Guide" in personal/corporate Github repositories... do those latter three
>> items need to go through the work item adoption process, or can the
>> supporting
>> items just be moved over to CCG as long as the author and Work Item Group
>> agree to move those things over?
>>
>> This is of immediate relevance to the VC API group as we have the
>> following
>> test suite repositories that we expect to contribute to the CCG over the
>> next
>> couple of months:
>>
>> * Implementations (VC API implementer configurations and
>>   authz Github secrets)
>> * Assertion libraries (e.g., test VC, Data Integrity, and
>>   JWT well-formed-ness (not crypto) checking)
>> * Basic VC Issuer API
>> * Basic VC Verifier API
>> * Cryptosuites (Ed25519, NIST ECDSA, Koblitz ECDSA, VC-
>>   JWT, BBS+, etc.)
>> * Basic Presentation Exchange
>> * Credential Refresh 2021
>> * Industry Vertical VCs (Student ID, Permanent Resident
>>   Card, Skill, Transcript, etc.)
>>
>> Moving every single one of those things through the CCG work item process
>> feels like overkill if folks in the VC API group are already doing the
>> work as
>> a part of the VC API testing initiative.
>>
>> The question to the Chairs are, can we just move those test suites into
>> CCG,
>> or do we need to move every single one of those things through the CCG
>> work
>> item process?
>>
>> -- 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/
>>
>>
>>

-- 
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/>