<div dir="ltr">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.<div><br></div><div>I've added these to the <a href="https://github.com/cabforum/documents/projects/1">Infrastructure Project Board</a> for now, until we can discuss on our next call.</div><div><br></div><div># Structure</div><div><br></div><div>Right now, we do everything in <a href="http://github.com/cabforum/documents">github.com/cabforum/documents</a> . On the Wiki, we segment out activity based on the CWG-level.<br></div><div><br></div><div>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</div><div><br></div><div>## Question</div><div>We discussed a little on our prior calls, but should we consider:</div><div>1. A separate repository per WG (CWG, FWG)?</div><div>2. A separate repository per Final Guideline?</div><div><br></div><div>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?</div><div><br></div><div>## Proposal</div><div>If we adopt #1, concretely, this would be my proposed hierarchy:</div><div>1. cabforum/forum</div><div>  - Contains Bylaws.md, RFC3647_Template.md, SCWG-charter.md, SCMWG-charter.md</div><div>  - The charters are placed here since rechartering requires Forum-wide approval</div><div>2. cabforum/server</div><div>  - Contains BR.md, EVG.md, NSR.md</div><div>3. cabforum/code_signing</div><div>  - Contains br-csc</div><div>4. cabforum/smime</div><div>  - Contains any eventual documents for the S/MIME WG</div><div>5. cabforum/spec-tools</div><div>  - Avoiding a catchall name like 'infra', this is the set of tools used to build the specifications (e.g. pandoc, weasyprint, etc)</div><div><br></div><div><br></div><div># Permissions</div><div><br></div><div>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?<br></div><div><br>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.</div><div><br></div><div>If we use a single repository, we'd likely accomplish this via <a href="https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners">CODEOWNERS</a></div><div>If we use a multiple repository (as above), we could use repository permissions.</div><div><br></div><div>## Question<br></div><div>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?</div><div><br></div><div><br></div><div># IPR Agreement</div><div><br></div><div>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.</div><div><br></div><div>It seems like we could use an automated webhook to validate that those opening PRs (and potentially issues?) have signed the IP Agreement.</div><div><br></div><div>## Question</div><div>Are there concerns with using a tool like <a href="https://colineberhardt.github.io/cla-bot/">https://colineberhardt.github.io/cla-bot/</a> to automate verification that the GitHub user is mapped to a Forum Member or Interested Party and has the IPR agreement on file?</div><div><br></div><div>Since the IP Agreement is Forum Wide, this would be creating something like <a href="https://github.com/cabforum/cla-config/">https://github.com/cabforum/cla-config/</a> (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.</div><div><br></div><div><br></div></div>