<div dir="ltr">(Apologies for the *much* longer delay in producing these)<br><br># 2020-11-18 Infrastructure Subcommittee meeting<br><br>Participants: Jos Purvis (Cisco), Daniela Hood (GoDaddy), Ryan Sleevi (Google), Dimitris Zacharopoulos (HARICA), Wayne Thayer (Mozilla), Ben Wilson (Mozilla)<br><br>## Agenda<br>* Update on GitHub move<br>* Mailer Migration<br>* Membership Management<br>* Website Navigation<br><br>## GitHub Move<br><br>### Repository migration status and tooling<br>Ryan provided an update that, after the email sent to the management@ list, everyone still active had enabled 2FA, and so now 2FA is enforced for the organization.<br><br>While the repositories have been split-up, we still have the old branches around, and they have not yet been cleaned up. However, we are good to go forward on that.<br><br>Ryan shared that there had been no progress to demonstrate on the tooling front. The scope of work is known, but it just needs to get implemented now. One aspect of this was wanting to align the document metadata, such as the title, version, and date, from a separate file today and into the document itself. This will make it easier for Chairs to manage, by only having to update one file when a new ballot passes, as opposed to today, where they have to edit both the Markdown and the YAML file.<br><br>Ryan also shared that he and Jos had been looking at updating the template used for the PDF, to better align it with the Word doc in visual style, since the current Pandoc-produced PDF is fairly ugly for purpose.<br><br>Dimitris asked about the status of the EV Guidelines and the NCSSRs, as they had not yet been converted to Pandoc. He was interested in understanding how these tools would work. Ryan responded that although we don't have to block alignment on getting the tooling, it probably makes sense to wait until the tooling is complete. This would help provide quicker iteration. Alternatively, if we want to move quicker, the Pandoc->Docx flow is at least visually appealing enough that it could be an interim step, like what has been taken for the BRs, where the process today is exporting the Word doc as a PDF for the final guideline.<br><br>To allow quicker iteration, Ryan suggested landing the GitHub action that builds from the local repositoriy (i.e. not addressing pull requests, just commits). This would allow for rapid iteration/preview of the docx-version of the EVGs/NCSSRs by attaching them as artifacts to local GitHub forks, which isn't possible today with the Travis/AWS integration.<br><br>Jos pointed out that one of the challenges with SC26 was that the BRs were constantly changing, and thus the need to constantly rebase. However, the EVGs and NSRs may not have that same concern, and this might be easier to convert. Dimitris volunteered to take a stab at the NSRs and would work with Ryan on that.<br><br>### Permissions and Workflow<br><br>#### Teams<br><br>Ryan stated teams are set up for each of the CWGs and the Forum containing the Chairs and Vice Chairs, as well as the Infrastructure Subcommittee. The main purpose here is that if on an issue or ballot you want to quickly tag folks, you can use the team alias to do so. This is perhaps most useful for the Infrastructure Subcommittee members, if other CWGs need assistance with tooling or other issues.<br><br>However, it also plays in with the next item, which can build on Teams.<br><br>#### CODEOWNERS<br><br>Ryan described that GitHub allows several integrations with Teams. At the first level, it's possible to just automatically assign pull requests to the appropriate CWG Chairs, to make sure they get notified as appropriate. However, it's also possible to restrict the set of reviewers, such that one of the Chairs must approve every pull request to touch a Guideline before it can be merged. This would help the Chairs ensure the correct workflow was followed, the ballot had been approved, etc.<br><br>One possibility would be to let each CWG decide that, another would be to make a blanket recommendation/requirement at the Forum level that this is how CWGs would work.<br><br>Jos and Dimitris expressed their support for this tooling integration. Dimitris stated that the final pull request merge should definitely be approved by the Chairs. However, as he's been doing things, he's been sending a note to the ballot endorsers/proposers to do the review, particularly after other elements are integrated, such as the table of changes. Ryan responded that it was intended more as an extra safety-net, to prevent arbitrary ballot proposers from accidentally merging something too soon, but he wasn't sure if this was too much tooling integration / process overhead.<br><br>Jos pointed out that future chairs might want to designate or delegate, the same way we have a webmaster. He wasn't sure if Chairs would want to create a "gitmaster" if they're not conversant in GitHub, and wanted to delegate the steps to someone else. However, that option would be supported with what Ryan described.<br><br>In figuring out next steps, Ryan mentioned he's got pull requests opened for CODEOWNERs, which is stored in the repository itself, for both the SCWG and the Forum, which will simply auto-CC the owners on new pull requests. When it comes to deciding whether to require their approval, is that something each CWG should decide, is that something that, like Wiki permissions, is managed by the Forum Infrastructure WG? What are the next steps?<br><br>Jos asked whether it should be up to each CWG to decide, or should it be a standardized thing? Dimitris responded that it should be up to each CWG to decide. Jos was good just adding it to Servercert, but should we reach out to codesigning and s/mime to provide instructions for how to click the button in the UI for their WG. Ryan disagreed, and suggested this should be a standard flow across the Forum, because this helps ensures CWGs follow the Bylaws. The example he described was would we want CWGs setting up their own mailer infrastructure and wikis? No, because there's benefit from shared infrastructure and processes.<br><br>Ryan suggested the next step should be that all CWGs have CODEOWNERs setup for the Chair/Vice-Chair. CWGs can of course add additional members to that set. However, enforcement should be done consistently for all CWGs once that is setup. Jos suggested this might warrant further discussion in the Forum at large before doing so.<br><br>Wayne suggested we just reach out to the chairs of the other CWGs, ask if they see concerns, and if they don't have problems, we just go ahead and implement. This shouldn't require a vote, since it's supporting the existing Bylaws, but we should check with the Chairs so that they have a chance to voice concerns.<br><br>Dimitris stated CWGs aren't required to use GitHub, only the SCWG is, so we can't be sure this would work for other CWGs.<br><br>The group resolved to adopt this process of CODEOWNERS for the SCWG, as Jos was supportive of these changes for the SCWG. The other Chairs would be contacted to understand if there are concerns, and if so, they'd be addressed, but that this would be taken as an all-CWGs approach.<br><br><br>## Mailer Migration<br><br>Jos shared that Jim at GoDaddy is making progress, is close to scheduling the cutover, and should have more details later this week.<br><br><br>## Membership Management<br><br>Jos mentioned that there was interest in making the membership management (between Wiki, GitHub, mailers) easier. Jos suggested that as we wrap up the GitHub work, this should be the next major task for the Subcommittee.<br><br>Wayne agreed that this would be an important and high-value task. We don’t have to fully automate something, we can make incremental progress. Right now, one of the big pain points is just getting the right information from people requesting additions/modifications. We have the spreadsheet in place, we should be able to add a more structured approach to getting that data into the spreadsheet.<br><br>Jos agreed that there were two parts: just change management and identifying what changes need to be made, and separate from that is automating that. Wayne mentioned this could just be as simple as a Google Form with the necessary details.<br><br>Dimitris shared from the Wiki that he’d tried to gather some of this data at <a href="https://wiki.cabforum.org/infra/member-rep-modification-request">https://wiki.cabforum.org/infra/member-rep-modification-request</a> as an initial starting point. Wayne suggested that he would look at Google Forms, but also look at researching alternatives.<br><br>Ryan suggested that it may not be necessary to look at alternatives. Our main priority is something easy for those requesting changes and getting the necessary information. Using Google Forms is a reasonable first step, and we can always replace it. We can choose the source of truth/backend later, such as just putting it into GitHub. Jos mentioned he’d also looked, looking at LDAP or other authentication backends for SSO, and those are also viable. However, both agreed just getting a Google Form in place is a reasonable first-step.<br><br>Dimitris pointed out that a challenge is that such form submissions are anonymous, and the need to authenticate the modification. Ryan agreed that was important, but would still be an improvement over the current status.<br><br><br>## Website Navigation<br><br>Ben sent an e-mail about modifying the menu bar for the website to add S/MIME and Code Signing. Now that we’ve got CWGs, the current menubar layout is a little weird, and wanted to see about promoting things to the top-level.<br><br>Jos asked if we still had the staging site to preview, as he was loathe to make a bunch of edits and confuse people. Ben described how we did this previously was just laying out the website via a series of Wiki pages. In principle he's supportive, but was nervous about having to make a bunch of live edits to the website to preview it.<br><br>Ryan mentioned he was slightly uneasy with the proposal, but that wasn’t a hard blocker. Our navigation is a bit weird as it stands, such as we have direct sections for documents, but also for CWGs, and we have documents like NCSSRs under the Baseline Requirements. Should we also be dividing Ballots by CWGs, for example? There are a host of tricky issues with our current navigation that don't make sense. In principle, not opposed to adding S/MIME or Code Signing, but this actually highlights deeper issues, and should we try to fix the root issue here.<br><br>Ben suggested we could have the CWGs across the top, and then their subject matter within. However, we wanted inåçput on what sort of approach to take for the layout.<br><br>Wayne said the logical part of his brain appreciated the proposal of splitting by CWGs, because that fits how the Forum is structured. But when it comes to use cases, the most common use case is trying to reach the most recent version of the document like the BRs. If we focus on how users are trying to use the website, we probably end up at a hybrid approach, where we might have a single area for the latest version of every document, but then also menu items for the CWGs.<br><br>Jos mentioned that with the GitHub integration, we might be able to get to the point where we just directly link to the latest artifact in GitHub, to reduce/eliminate any of the manual replication that happens today. Jos suggested we might want to create a mindmap of the website, in order to visualize it and better understand some of the concrete proposals.<br><br>Ben pointed out the website has been a mess more or less since we first moved it to wordpress. We have a number of pages where we haven't really updated, as they used to require manual updates, and we had the ability to have lists that were automatically updated, such as ballots and documents if we tagged posts correctly, but we haven't really consistently done that.<br><br>Jos mentioned that he and Ryan had discussed static site generators in the past that didn’t exist before. It makes it easy to keep the entire website in GitHub and as PRs are approved to edit things, they automatically regenerate the site and publish. This would allow flows where, say, minutes are done within PRs, and as they’re approved, they automatically update the website.<br><br>Ryan added that while it’s not going to happen in the next few weeks, he had been looking at further automation for release management, such that as chairs/vice-chairs approve PRs to documents, they can automatically generate the necessary IP Review notices or automatically publish to the website, as necessary. So there are some possibilities once the GitHub integration is finished to make it easier to manage a lot of the manual steps that happen today.<br></div>