MACI GitHub processes

[ctrlc03]

In this discussion post, we introduce a proposal for how to manage MACI's repository. We encourage anyone to comment and propose alternative processes.

Branches

• main branch for ongoing development
• tags for releases
• feature/fix branches which are to be merged to the main branch after approval
• (for now use dev and main until we finish refactoring and get code audited then can get rid of main)

Updates to make

• Update dev as default branch
• Delete master branch

Conventions

• branch name
  • feat / fix / chore / docs
  • i.e. fix/contracts feat/new-feature docs/contracts chore/run-prettier
• commits style
  • use commitizen https://commitizen-tools.github.io/commitizen/
  • fix(package-name) - fixed x in y because of z + longer description
  • commit using git cz for the interactive commit prompt

Updates to make

• Update README/documentation on this
  • i.e. what defines a feature / bug fix / chore / documentation
• Contributors optionally install Commitizen (https://github.com/commitizen-tools/commitizen#installation)

Publishing releases

• all releasing must be done from the code approved and merged to the main branch
• publishing is done via the CI → https://github.com/privacy-scaling-explorations/maci/wiki/CI-Pipeline#tag-push

Updates to make

• CI workflow: https://github.com/privacy-scaling-explorations/maci/blob/dev/.github/workflows/release.yml
• Document how this works (https://maci.pse.dev/docs/ci-pipeline#tag-push)

Opening a PR

• add the appropriate label
• add a list of changes
• reference the appropriate issue using closing keywords (e.g. Fixes #issueNumber) in the PR description
• PR approvals
  • 1 approval for merge into main
  • 2 approvals for release
  • CI must be green before merge
• ensure branch is deleted after the PR is merged
• when reviewing a PR, go over to the issue(s) that the PR is trying to fix and assign yourself as the reviewer
  • after reviewing a PR we should try to explicitly submit a review to either "approve" it or "request changes" to avoid ambiguity

Updates to make

• Update GH settings to “Automatically delete head branches”
• Create GH PR template (of sections to fill out) e.g. https://github.com/ethereum/ethereum-org-website/blob/dev/.github/PULL_REQUEST_TEMPLATE.md
• Update README/documentation on this

Opening a Issue

• add the appropriate label
• when beginning to work on a issue, assign yourself to it
  • if an external contributor, comment under the issue and we will assign you

Updates to make

• Create GH issue templates
  • Bug report
  • Feature request (e.g. https://github.com/ethereum/ethereum-org-website/blob/dev/.github/ISSUE_TEMPLATE/feature_request.yaml)
• Update README/documentation on this

Versioning

• https://hackmd.io/@samajammin/maci-versioning
• minor version → no breaking changes
• major version → breaking changes
  • changing a circuit is a breaking change as it requires a new trusted setup ceremony

Updates to make

• Add documentation on our approach to versioning (i.e. add https://hackmd.io/@samajammin/maci-versioning to a page in https://maci.pse.dev/docs/)

Security audits

• what triggers an audit
  • changes to circuits and/or contracts and/or cryptographic implementations (Merkle trees, key sharing protocol)
  • new features which change how the protocol works: e.g. El Gamal
• internal vs external audit
  • internal audit when changes are not too big, for instance refactoring work vs protocol changes like El Gamal
  • external audit when there are significant changes like the El Gamal grant work, a new anti collusion method and/or introduction of new zk primitives like Nova recursion for scaling MACI’s circuits
• code freeze → move code to a separate branch for audit which is not to be touched unless we are fixing audit findings
• request audit at least 1 month in advance

[samajammin]

Updates to make
Update master branch to main
Update main as default branch
Delete dev branch

I believe we've now landed on just using dev & tag branches, so updates would be

• Update dev as default branch
• Delete master branch

[samajammin]

Done ✅

[baumstern]

re versioning: semantic-release can automatically determine the next version number based on Conventional Commits

[samajammin]

Cool. @0xmad is this what you had in mind re: automation around SemVer? Or what tools have you used in the past?

[0xmad]

@samajammin yes, I usually use these tools for automation.

[samajammin]

Another GH process question @ctrlc03 - now that we have the Docusaurus website, should we keep the wiki?
https://github.com/privacy-scaling-explorations/maci/wiki

If we can move everything over (which I believe we have) I'd suggest we remove it to avoid potential confusion. We can do that in the GH settings.