[Infrastructure] GitHub streamlining

[Ryan Sleevi]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/infrastructure/attachments/20200805/ef900871/attachment.html>