[Infrastructure] 2020-11-18 Draft Minutes

[Ryan Sleevi]

(Apologies for the *much* longer delay in producing these)

# 2020-11-18 Infrastructure Subcommittee meeting

Participants: Jos Purvis (Cisco), Daniela Hood (GoDaddy), Ryan Sleevi
(Google), Dimitris Zacharopoulos (HARICA), Wayne Thayer (Mozilla), Ben
Wilson (Mozilla)

## Agenda
* Update on GitHub move
* Mailer Migration
* Membership Management
* Website Navigation

## GitHub Move

### Repository migration status and tooling
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.

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.

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.

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.

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.

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.

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.

### Permissions and Workflow

#### Teams

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.

However, it also plays in with the next item, which can build on Teams.

#### CODEOWNERS

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.

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.

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.

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.

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?

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.

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.

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.

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.

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.


## Mailer Migration

Jos shared that Jim at GoDaddy is making progress, is close to scheduling
the cutover, and should have more details later this week.


## Membership Management

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.

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.

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.

Dimitris shared from the Wiki that he’d tried to gather some of this data
at https://wiki.cabforum.org/infra/member-rep-modification-request as an
initial starting point. Wayne suggested that he would look at Google Forms,
but also look at researching alternatives.

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.

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.


## Website Navigation

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.

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.

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.

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.

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.

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.

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.

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.

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