Open Enclave Community Governance Committee Meeting Archive 2019

# Open Enclave Community Governance Committee Meeting Archive 2019 > For the **current** CGC meeting notes, please refer to: https://hackmd.io/TOJhJXswQ5yfObq1T659ug ## November 26, 2019 **Time:** 8:00am Pacific Time **Chair:** Dave Thaler **Minutes:** Amaury Chamayou **Present:** John Kordich, Dave Thaler, Mike Brasher, Amaury Chamayou, Akash Gupta, Anand Krishnamoorthi, Andy Schwartzmeyer **Missing:** Simon Leet ### Agenda * Get minute taker, and record attendance * Follow-up on past action items * Triage meeting invitation, and listing on https://github.com/openenclave/openenclave/blob/master/docs/Contributing.md and/or https://github.com/openenclave/openenclave/blob/master/docs/Governance.md * Status of transfer to CCC * Microsoft Copyright statement: https://github.com/openenclave/openenclave/pull/2260 * Microsoft CLA * Microsoft Code of Conduct * Docs mentioning above: https://github.com/openenclave/openenclave/blob/master/docs/Contributing.md * Any infrastructure costs? * Dependencies * Unresolved items from previous meetings: * Next steps for issue [#1920](https://github.com/openenclave/openenclave/issues/1920) Improve "How to Submit a PR" / add "How to Review a PR". * Review [CODEOWNERS](https://github.com/openenclave/openenclave/blob/master/docs/CODEOWNERS) file. * What are our criteria for PR submissions? * Do we need tests? Do features need to be guarded? * What does it mean for a feature to make it into master versus into a release? * Define classifications for "Experimental" or "Preview" features (e.g. as they apply to PR [#2195](https://github.com/openenclave/openenclave/pull/2195)). * Continuation of PR [#2163](https://github.com/openenclave/openenclave/pull/2163) Add proposed API guidelines. * New business * Should we invite Linux Foundation PM to the meeting? * Vote on adding Jordan Hand and Chris Rod as committers * Vote on adding Radhika to CGC * Committers.md still lists JohnKord as Microsoft * Contributor Covenant update * Select next meeting date and chair * Who was selected and when? ### Minutes Triage meeting: consensus to invite Radhika Copyright statement: Done CLA: Done Code of Conduct: Done John & Dave: CCC should use the latest release branch (v0.7.x) Infra costs: Who should pay for operating the CI/main repo? Dave will discuss with Li. Microsoft-specific changes would happen on a forked repo in ADO (Azure OneBranch). Already setup, but no CI there. Paul will know about the cost of the existing infra. Dependencies: 3rd party dependencies decided by committers on technical merits. Escalation to the CGC if consensus cannot be reached. Linux foundation PM in meetings. Andy and Simon will reach out to the LF to confirm exact role and cost. Committers: Chris Rod not proposed. Jordan Hand proposed. Full-time member of the OE SDK team, proposed by Radhika. Here are all PRs from Jordan and some issues he opened https://github.com/openenclave/openenclave/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3Ajhand2+ Here are just the merged ones https://github.com/openenclave/openenclave/pull/2326 https://github.com/openenclave/openenclave/pull/2322 https://github.com/openenclave/openenclave/pull/2312 Here is are issues he has opened. https://github.com/openenclave/openenclave/issues/2314 https://github.com/openenclave/openenclave/issues/2148 Consensus reached on adding Jordan Hand as a committer. (Simon's agreement, conveyed by Andy) Consensus reached on adding Radhika to the CGC. (Simon's agreement, conveyed by Andy) Consensus reached on keeping John on the CGC and updating his email address. Contributor Covenant: approved. Code Owners: John: remove Emil? Radhika should be in charge of tests. Remove #1920 as resolved for next time. Next meeting: January 7 Chair: Mike Brasher ## November 5, 2019 **Time:** 8:00am Pacific Time **Chair:** Akash Gupta **Minutes:** Mike Brasher **Present:** John Kordich, Dave Thaler, Mike Brasher, Aumaury Chamayou, Akash Gupta, Anand Krishnamoorthi, Andy Schwartzmeyer, Simon Leet **Missing:** None ### Agenda * Unresolved items from previous meetings: * Reconcile MS leadership decisions with CGC leadership of OE SDK project as a CCC project * What should be our triage process and how does it deal with prioritization conflicts with MS? * Next steps for issue [#1920](https://github.com/openenclave/openenclave/issues/1920) Improve "How to Submit a PR" / add "How to Review a PR". * Review [CODEOWNERS](https://github.com/openenclave/openenclave/blob/master/docs/CODEOWNERS) file. * What are our criteria for PR submissions? * Do we need tests? Do features need to be guarded? * What does it mean for a feature to make it into master versus into a release? * Define classifications for "Experimental" or "Preview" features (e.g. as they apply to PR [#2195](https://github.com/openenclave/openenclave/pull/2195)). * Continuation of PR [#2163](https://github.com/openenclave/openenclave/pull/2163) Add proposed API guidelines. * Any updates from EU OSS 2019 Lyon ### Minutes * Reconcile MS leadership decisions with CGC leadership of OE SDK project as a CCC project * Dave: Not talked about at CCC. * John: Need to clarify difference between CGC and CCC. * Dave: What should the triage process be? How do we want to run it? * John: MS may have its own priorities independent of Triage priorities. * Dave: Is there a resource defined to work on this? If so it can be prioritized higher. * Mike: Priorities should be backed by resources from the interested company. * Akash: Need to ensure PR's will be reviewed. * Dave: Add enough people for each area of responsibility to make sure each is covered. * Andy: Set up meeting to group review PR's? Cover in meeting if short, assign to someone if not. * Dave: If code owner set up correctly and working, then PR review meeting should not be necessary. * Akash: Should the triage meeting be public? * John: We could bring the old triage process back. Should wait for Simon. * Dave: Triage meeting should be public so should be published somewhere. * Dave: Setting a priority is not as important as setting an owner. * Mike: Function of triage process is to identify owner. * Simon: Don't know if triage solves the problem of driving direction. It doesn't matter who owns a triage item if we never get to the them. * Simon: There is a lot of work we don't track * Mike: Agree that large architetural discussion are beyond the scope of the Triage (too high level?) * Simon: Seems Dave proposes everything through Triage process. That's one way to do it? * Mike: Where do overall architectural decisions go? * Simon: Related to question of where there is a Steering Committee? * Andy: All committers are the technical steering committee. The CGC is the subgroup of of committers to make sure the process continues to work. You could call the CGC the technical steering committees. We should only interfere if asked. TSC (technical steering committee). So TSC is not necessarily equivalent to the CGC. * Andy: Advocates for a triage meeting. * Simon: So TSC is the triage meeting? So the loudest voice wins? * Simon: Should design go through triage? * Dave: Don't see design review as being review of triage. More about tracking than technical discussion. * Andy: I don't think we should be super involved in design. * Mike: Where do we cover high-level design and archtiecture. * Mike: Other open-source projects have F2F meeting to discuss directions. * Simon: Need detail on specific process for handling design/architecture. How sets the direction for the project? Do all committers have to come to concensus or does this rever back to the CGC. * John: Should go to CGC for a vote if cannot reach concensus. * Simon: What should we be doing differently? Is this good enough for now. * Dave: Summarize: we can form a TSC when we get more commiters? * Simon: Intel will become part of the process. How much weight do they have in this process? * Dave: Other companies will have reps on the CGC. Maybe we should have this discussion once this is the case. * John: We should reach out to Intel so see who they want on the CGC? * Dave: We have 11 minutes left. Should we defer * Mike: 1. Bering back triage but beffer version 2. Ask first non-MS contributors how they want steer the project. * What happened at the CCC? * Mike: All projects unamimously accepted. Separate vote to accept OE into incubator phase carried with one abstension. * Dave: Talked about funding of Github and CI. * Next meeting? * Dave: Will chair. * Akash: How to run publically? * Dave: We can use Teams. ## October 15th, 2019 **Time:** 9:30am Pacific Time **Chair:** Simon Leet **Minutes:** Simon Leet **Present:** Simon Leet, John Kordich, Dave Thaler, Mike Brasher, Aumaury Chamayou, Akash Gupta **Missing:** Andy Schwartzmeyer, Anand Krishnamoorthi ### Agenda * Confirm CCC TAC Project member and plans for EU OSS 2019 in Lyon. **#new** * Vote on adding Vikas as committer. **#new** * Close on the informal consensus that all new developers need to have a track record of commits and area of ownership before being added as committers. * Close on question of public meetings. * Should we record the meeting and make it available offline? * Should we release the minutes publicly? * Should we have a notion of executive sessions for personnel votes? * Review [CODEOWNERS](https://github.com/openenclave/openenclave/blob/master/docs/CODEOWNERS) file. * Should we enforce CODEOWNERS via bors? This is a [new bors feature](https://forum.bors.tech/t/bors-support-for-codeowners/357). **#new** * Discuss issue [#2169](https://github.com/openenclave/openenclave/issues/2169): Release process is unclear. * Review PR [#2229](https://github.com/openenclave/openenclave/pull/2229): Add a release manager selection process to [Releasing.md](https://github.com/openenclave/openenclave/blob/master/docs/Releasing.md). **#new** * Review PR [#2230](https://github.com/openenclave/openenclave/pull/2230): Set John Kordich as the Release Manager. **#new** * Will we continue to release the OE SDK debian package through the Microsoft APT repo? * Will we release Windows nuget packages through nuget.org? * Define classifications for "Experimental" or "Preview" features (e.g. as they apply to PR [#2195](https://github.com/openenclave/openenclave/pull/2195)). * Continuation of PR [#2163](https://github.com/openenclave/openenclave/pull/2163) Add proposed API guidelines. * Next steps for issue [#1920](https://github.com/openenclave/openenclave/issues/1920) Improve "How to Submit a PR" / add "How to Review a PR". * How many approvals do we need? * When do we expect those approvals by? * Do we enforce this with tooling? * What are our criteria for PR submissions? * Do we need tests? Do features need to be guarded? * What does it mean for a feature to make it into master versus into a release? ### Minutes * **Announcement:** New short link for CGC minutes at https://aka.ms/openenclave/cgc * Mike has been selected to represent the project at Lyon to the TAC * Dave: Stephen Wallis has indicated that the project leads will not get a vote on the TAC, although we will still need to have someone present the project to the TAC. * **Future topic: Reconcile MS leadership decisions with CGC leadership of OE SDK project as a CCC project** * In particular, concerns about keeping particular features planned * Mike: We should do feature development in the open, unless it discloses MS product plans * Simon & John agree * Dave pointed out that such features should probably not be part of the OE SDK project anyway. * Vote on adding Vikas as committer * All agree that he will not be added as a committer yet. * A committer should only be added after a track record of commits to the project. * Close on question of public meetings: * Should we record the meeting and make it available offline? * No, especially anything dealing with personnel discussions should be kept in the meeting * Should we release the minutes publicly? * Yes, and they are public already and should be the primary means of the community keeping in touch with CGC meetings and decisions. * Should we have a notion of executive sessions for personnel votes? * No, since we are not recording the meetings and there's no separation of technical vs. personnel. * Regarding the release management: * John has submitted PRs [#2229](https://github.com/openenclave/openenclave/pull/2229) and [#2230](https://github.com/openenclave/openenclave/pull/2230) as follow up to [#2169](https://github.com/openenclave/openenclave/issues/2169) already and both have been approved by super-majority. * John wants full consensus for them still, so **Mike has an action item to review today and sign off on both PRs.** * Will we continue to release the OE SDK debian package through the Microsoft APT repo? * Mike: We at MS can continue to choose to release it there or not, independent CGC. * We should probably clean up the documentation to tell folks not to use the MS repo. * Dave: Does the CGC want a separate release mechanism? * Mike: We already do this via GitHub release page, and that will continue with v0.7 and beyond. * Dave: Do we want a CCC maintained APT repo? * Mike: They are hard to maintain (MS has problems with it) and we probably don't want to do that separately. * Dave: If we want one, then it should be brought up by Mike at Lyon * Mike: Too early right now, we'll reconsider in the future. * Dave: Are the maintenance of APT repos general to other types? (e.g. YUM) * Mike: Don't know. * Aumaury: We don't need it since it's an SDK anyway and folks are going to have to recompile their app when picking a new version, so the value of having a signed, up to date repo for package distribution is low. * Dave: At least the devs don't have to recompile the OE SDK. * Aumaury: But they can't do binary replacement with the package. * Dave: Are binary/source distros a thing? * Mike: There's generally a split of bins, libs & sources and we only do bins & libs in one package today. * John: Binary package for something like oesgx might be useful as a separate package. * Dave: I can see the value of having oesign as a separate binary package since signers might be different from. * **John will file an issue to track this separation.** * Done, see issue [#2255](https://github.com/openenclave/openenclave/issues/2255) Release a binary package of Open Enclave tools that can be useful on a given platform. * Aumaury: having a binary package would then make it valuable to have repos to update these things. * John: yes, and then we will have to upstream that to the distro repros (RedHat, Canonical) * Dave: Since RedHat is part of CCC TAC, it would be interesting to get it upstream into the RedHat repo. * Will we release Windows nuget packages through nuget.org? * John: Yes, the plan of record is that we will build the nuget and upload to nuget.org, but it will be unsigned. * Dave: We have VS/VSCode extensions that are uploaded to nuget.org that are signed. It should be pretty easy, if not well-documented. We should just have it signed. * John: We are looking into the process of signing it through the MS-internal pipeline, but it's not ready yet. * Dave: I'm suggesting that we use the same signing keys as the VS/VSCode extensions, and it doesn't have to be for v0.7. If there's a better process, we're happy to switch to it as well. Otherwise, we can help sign the OE SDK package through the manual process. * The same principle applies to nuget.org as the MS APT: we can choose to release an MS-signed version independent of the GitHub CCC release * Simon: does that mean that the GitHub version is different and remains unsigned? * Dave: Maybe, but we should consider signing that as well. What happens with the Linux APT package? * Simon: APT packages are not signed * John: Usually it depends on the repo to provide signatures (hashes) of the packages * **Investigate: what key or signing strategy are we going to use for the public packages (APT, RPM, nuget)** * See issue [#2256](https://github.com/openenclave/openenclave/issues/2256) OE SDK packages need a key/signing strategy. * For v0.7 release: still waiting for Hernan's documentation changes and DCAP, but should be on track for EOW. * For time reasons, skipping over the API guidelines question in favor of the more important PR requirements discussion for the rest of this meeting: * How many approvals do we need? * Historically, the team had decided for 2 approvals, but it was not enforced. * Dave: tentatively agree, but subject to the SLAs of when the approvals are provided, which leads into the next question. * When do we expect those approvals by? * Dave: IoTivity had minimum review period of X (~1 day) and minimum of 2 reviewers. * John: Do we have an expiration for PRs? * e.g. after a week only one approval is needed? * Mike: what about when there is no one around to review? It's better to merge and revert than block. * Simon: No, force pushing history to public branches is rare and particularly for secrets accidentally merged, there's no good strategy for removing secrets other than revoking it everywhere. If there is no one to review (e.g. holiday period) then arguably there's not a strong reason to be rushing PRs into the repo anyway. * Dave: Approval should be done by area of responsibility. * Dave supports enforcing approvals via the CODEOWNERS list? * How are the reviewers represented correctly? * Dave: triage to review * Simon: that's manual an not scalable, can we just use CODEOWNERS & bors for automatic enforcement? * Dave: yes, we should use automation then * This answers the next question: "Do we enforce this with tooling?" * Dave would like that the approvers come from the appropriate sets of CODEOWNERS * e.g. PR contains build changes and feature changes, it should be approved by an owner from each area. * Simon: tools aren't smart enough to do that today, this will sill require a manual process. This brings us back to some kind of triage process? * Triage meeting expired, we need to renew it * John will renew the triage meeting, one for later this week in preparation for the v0.7 release. * John would also like not to have to always run the triage meeting, and there's an agreement that it does not need to be coordinated by a committer. * Simon: I want to add a future agenda item for discussing what our triage process is supposed to look like; in particular, whether it's just about triage or it also has elements of technical steering, and how MS priorities are reconciled with the OE SDK as a public project. * Alternative to triage is to put the responsibility on committers to exercise due dilligence in ensuring that appropriate review coverage has been provided before merging a PR. * John: we shouldn't used the `bors delegate` function casually, and the person who does the merge should be on the hook for ensuring that the right reviewers have done this. We should make this clear that this is a new rule and broadcast this and could revoke committer-ship from folks who violate this rule. * Akash, Dave, Simon agree. * **Summary:** * **We will require 2 approvals and an approval to come from CODEOWNERS as enforced by tooling.** * **This is only a baseline that is automated, it is still the responsibility of committers to ensure that appropriate review coverage is provided before merging PRs.** * Review of CODEOWNERS * Simon: generally looks okay, but it spews a lot of Reviewers into the PR by default. Suggest that contributors and committers start using the Assignee field in GitHub to explicitly require specific reviewers to clarify, particularly for ensuring appropriate coverage as just discussed. * Ran out of time before the end of the meeting. * Choose next chair: Akash has volunteered to chair the next meeting. ## September 27th, 2019 **Time:** 10:00am Pacific Time **Chair:** John Kordich **Minutes:** Andy Schwartzmeyer **Present:** John Kordich, Andy Schwartzmeyer, Akash Gupta, Simon Leet, Dave Thaler, Anand Krishnamoorthi **Missing:** Mike Brasher, Amaury Chamayou ### Agenda * Before the meeting please read: * Add proposed quorum rules - https://github.com/openenclave/openenclave/pull/2165 * Add proposed API guidelines - https://github.com/openenclave/openenclave/pull/2163 * Old Business: * Discuss PR Review Guidelines * https://github.com/openenclave/openenclave/issues/1920 * New Business: * Discussion about process PRs: * Add proposed quorum rules - https://github.com/openenclave/openenclave/pull/2165 * Add proposed API guidelines - https://github.com/openenclave/openenclave/pull/2163 * Release process is unclear - https://github.com/openenclave/openenclave/issues/2169 * Releasing through Microsoft APT repo? * Releasing Windows nuget packages through nuget.org? * Whether or not we should make these meetings public to "observers" * Review CODEOWNERS file * CCC TAC Project member * "Experimental" or "Preview", and requirements for such features (e.g., PR 2195) ### Minutes * Reviewing "Add proposed quorum rules #2165" * While we don't have quorum in the meeting, and we are choosing to decide that we don't have consensus, we are calling a vote on the PR. Of the approvals on the PR, we have 6/8 approvals (with no objections) for 75%, and so we are going to merge the PR. * We need to formally define "consensus" as there is some disagreement among members on its definition. * Reviewing "Add proposed API guidelines #2163" * We are not currently taking a vote, but calling out the need for the committee to review this PR. * Some discussion on Committee member's responsibilities to review and move forward on items between CGC meetings. * Reviewing "Improve 'How to Submit a PR' / add 'How to Review a PR' #1920" * Dave points out the contradiction between "timeout" based reviews and number of reviewers required (specifically reviewers from the related areas). How do we resolve that conflict? * John points out that the worst case scenario is that unwanted changes can later be reverted, and so we should lean toward ease of contribution. Andy seconded that opinion. * Anand gave some historical context on the bar originally being very high for the master branch, but has since been lowered. * John brought up that we have CI that enforces master building and passing tests, but that we need code coverage. * Simon discussed the Google DevOps model that expects features to be broken into small and independently tested pieces, with tests included in each PR. The downside to this model is that the CI (which runs the tests) can often be the expensive bottle-neck for these changes (such as the Windows work). * Anand asks "What does it mean for us to do a relase?" in respect to features being broken into small pieces versus including an entire feature. * Simon states that the convergence of Dave and Anand's points is "what is the difference between a release of changes, and a continous integration of small changes in master?" * Simon proposes we stop thinking of checking in features, and instead think of smallest units of testable code, but that begs the question of what ends up in the master branch versus in a release and so exposed to a user. * Much further discussion between Dave and Simon to understand each other's side. * We should add proper code coverage (for SGX and TrustZone) to our CI pipeline. * First set of questions: * How many approvals do we need? * When do we expect those approvals by? * Do we enforce this with tooling? * Second set of questions: * What are our criteria for PR submissions? * Do we need tests? Do features need to be guarded? * Third question: * What does it mean for a feature to make it into master versus into a release? * Reviewing "Release process is unclear #2169" * We should update the Releasing document to clarify that it is the group of committers that choose to do a release, and then a release manager is chosen by the committers. * We should propose a new release and nominate a manager via GitHub PR or Issue, and clarify what a vote via email on this means. * We should propose that a feature being merged into master is an intention that it is ready for the next release. * John proposes that as part of the next release, John will submit a proposal of modifications to this document. * Akash brought up that if a vote-based process goes forward, we will end up with the same person releasing every time, which is unfair. * Public meetings * Should we record the meeting and make it available offline? * Should we release the minutes publicly? * Should we have a notion of executive sessions for personnel votes? * Who should be the CCC TAC Project member? * Dave shared with us that the CCC may also have a representative from our project, so we are seeking a CGC committee member to attend the CCC session with Dave, a CCC TAC member. ## September 9th, 2019 **Time:** 10:00am Pacific Time **Chair:** Andrew Schwartzmeyer **Minutes:** John Kordich **Present:** Andy, Simon, Amaury, Mike, Akash, Dave ### Agenda * Establish Committee Meeting cadence * Review the [governance](https://github.com/openenclave/openenclave/blob/master/docs/GovernanceModel.md) and [charter](https://github.com/openenclave/openenclave/blob/master/docs/Maintainers.md) * Review consensus seeking process versus majority approval * In [PR #2115](https://github.com/openenclave/openenclave/pull/2115) we added a new committer without waiting for consensus from the committee. * Discuss PR review guidelines * See [Issue #1920](https://github.com/openenclave/openenclave/issues/1920) * How long should the "holding period" be, and how do we enforce it? * How many sign-offs should we require, and does it depend on the nature of the change? * Move from Teams to Zoom for external access * Setup a public community meeting * Discussion about adding Anand Krishnamoorthi as a maintainer * Review maintainers list and areas ### Minutes * Each maintainer introduced themselves and their realms of ownership * Simon asks: How much of an expectation is there for preparation before this meeting in the future among each individual maintainer? Andy: Chairs should set that expectation in the Agenda. * Mike: How far in advance should an agenda be published? Andy: Depends on cadence, but we should determine this later this meeting. Mike: Maybe 3 days? * After this meeting concludes, we'll choose a chair for the next meeting. * Cadence: * Andy suggests no more frequent than every two weeks. * Mike: Every three weeks may be a good starting point, and we can adjust this according to the load. John seconds this proposal. * John requests that we don't do Monday mornings due to conflicts * Simon: Can we call out-of-band meetings for important issues? Dave: This is part of reviewing the charter * Proposal to come back to determining the next meeting date until after the review of the governance and charter passes. * Review the Governance and Charter: * Andy: We recently added a new contributor without full consensus, which isn't the right process. * Dave: The process for adding new contributors/maintainers is underspecified in our current process. In favor of ratifying our current process, and then amending them later. * Dave: Would like clarity between the relationship between triage meetings and the maintainers meeting. * Mike: Would like to understand who can be in these CMC meetings. Should this be open to the public? * Simon: The triage meeting requires enough details that you will need committers to contribute to the discussion. What's the resolution for disagreements? John: Bring it up at the next CMC meeting? * Simon: If a decision gets made when a maintainer isn't there, and they disagree, then they don't have a say. * John: Voting by proxy? Most disagree. Simon: Voting ahead of time should be possible. * Dave: There are some decisions difficult to reverse, like adopting new people to the CMC. * John: What number of maintainers at a meeting should qualify for quorum? * Dave: We should make this explicit. * Mike: We shouldn't be voting in the absence of all representatives from any given partners. * Dave: We should aim to make Microsoft (or any company) no larger than 1/3rd of the governance. * Andy: We should be aiming to get a couple people from each company to join the CMC. * Simon: Should we make people who aren't code contributors maintainers? * Simon: When is a vote allowed? * Andy: We should be careful with difficult decisions & decisions that aren't easily reversed. * Simon: Do we need something more explicit than "You should behave in good faith"? * Discuss PR review guidelines * Punted to later discussion * Discussion about adding Anand as a maintainer * Seconded/Thirded * Dave: How many maintainers should there be total? Andy: Maybe 12, 4 from Microsoft. This may mean some of us step down. * Vote called to make Anand a maintainer: All vote Yes * Move from Teams to Zoom for external access * Defer to future meeting until we have more external users * Simon: should people who don't commit code be a committer? * Proposal: Remove both Li and Pushkar as committers. * Proposal passes to remove Li and Pushkar as committers * Dave: People who are contributors aren't necessarily committers. * Simon: CI systems should be accessible to contributors that aren't committers * Simon: Add build tag for Brett's committer entry * Set up a process for merging from forked branches for all contributors. * Enforce this practice * Andy: Submit this change as a PR * John: Offer guidance to developers on this process. * Figure out a time for the next meeting for either this week or next week. * John has volunteered to be the next chair.