[Infrastructure] GitHub streamlining

[Ben Wilson]

#1 looks good to me. The SMIME WG discussed using GitHub this morning.
During the initial drafting of a document for that WG, it might be good if
they had more flexibility in updating the main document (until a final
version is ready to be published).

On Wed, Aug 5, 2020 at 11:15 AM Ryan Sleevi <sleevi at google.com> wrote:

> As we transition to GitHub-based workflows for some of our activities, I
> was curious if we should start collecting recommended workflows, in
> thinking about how permissions, contributions, and reviews should work.
>
> I've added these to the Infrastructure Project Board
> <https://github.com/cabforum/documents/projects/1> for now, until we can
> discuss on our next call.
>
> # Structure
>
> Right now, we do everything in github.com/cabforum/documents . On the
> Wiki, we segment out activity based on the CWG-level.
>
> Right now, we have the Forum-wide documents (Bylaws), the SCWG documents
> (BRs, EVGs, NSRs), and at least one CSC WG document (br-csc, which is just
> a text file). Many other SDOs take the approach of either using a
> repository-per-WG or even a repository-per-specification, or a mix of both.
> Per our Bylaws, each Final Guideline is the work product of an individual
> CWG
>
> ## Question
> We discussed a little on our prior calls, but should we consider:
> 1. A separate repository per WG (CWG, FWG)?
> 2. A separate repository per Final Guideline?
>
> I realize the SCWG NetSec Subcommittee has been considering how the NSRs
> might integrate in the BRs, and there were previous discussions of folding
> the EVGs into the BRs (and, previously, a ballot was held to formally state
> we should adopt RFC 3647 format for the EVGs to facilitate that), but
> neither of those have happened yet, so #2 might be onerous for the SCWG.
> But #1 seems good?
>
> ## Proposal
> If we adopt #1, concretely, this would be my proposed hierarchy:
> 1. cabforum/forum
>   - Contains Bylaws.md, RFC3647_Template.md, SCWG-charter.md,
> SCMWG-charter.md
>   - The charters are placed here since rechartering requires Forum-wide
> approval
> 2. cabforum/server
>   - Contains BR.md, EVG.md, NSR.md
> 3. cabforum/code_signing
>   - Contains br-csc
> 4. cabforum/smime
>   - Contains any eventual documents for the S/MIME WG
> 5. cabforum/spec-tools
>   - Avoiding a catchall name like 'infra', this is the set of tools used
> to build the specifications (e.g. pandoc, weasyprint, etc)
>
>
> # Permissions
>
> Independent of whether we adopt the structure suggested above (although
> hopefully in concert with it), should we adjust the permissions so that the
> relevant Chair/Vice-Chair shall approve changes to the documents?
>
> Specifically, we can use permissions to create Github teams like
> "SCWG-Officers" and "CSC-Officers", which will contain the GitHub IDs of
> the Chair and Vice Chair, and require that the officer approve a merge for
> the respective documents.
>
> If we use a single repository, we'd likely accomplish this via CODEOWNERS
> <https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners>
> If we use a multiple repository (as above), we could use repository
> permissions.
>
> ## Question
> Are there any concerns with going ahead and doing this now, given that
> teams are managed at the organization level (i.e. the "cabforum" level), so
> we can just use the CODEOWNERs approach until we decide on structure?
>
>
> # IPR Agreement
>
> As folks know, at the Forum level, we require participation to be
> accompanied by the IPR Agreement. This is conceptually similar to a CLA
> within open-source.
>
> It seems like we could use an automated webhook to validate that those
> opening PRs (and potentially issues?) have signed the IP Agreement.
>
> ## Question
> Are there concerns with using a tool like
> https://colineberhardt.github.io/cla-bot/ to automate verification that
> the GitHub user is mapped to a Forum Member or Interested Party and has the
> IPR agreement on file?
>
> Since the IP Agreement is Forum Wide, this would be creating something
> like https://github.com/cabforum/cla-config/ (as a private repository) to
> track the Forum-wide config, and that'd apply to all of the cabforum/
> Organization, if we go the route of multiple repositories, or it could be
> done within cabforum/documents itself.
>
>
> _______________________________________________
> Infrastructure mailing list
> Infrastructure at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/infrastructure
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/infrastructure/attachments/20200805/6c715faa/attachment.html>