Page History

...

• Maintain a written project roadmap, discuss in project meetings
• Create, clarify, and label issues in Github for contributors. Use Github default labels, e.g. use label "good first issue"
  • Consider splitting "good first issue"
  - perhaps split
  • label into
  sub-
  • multiple labels, e.g.
  no experience (100) vs SME but no project experience needed (400
  • "good-first-issue-100-introductory" through "good-first-issue-400-expert" (see Cacti project)
• Review, triage, comment on, and close inbound Github issues

...

• Follow an established Release taxonomy - either SemVer or CalVer, ; use consistent pre-release tags for (e.g. -preview, -alpha, -beta, etc)

• Document release strategy , and release process including required approvals,

• Document branch strategy, e.g. one branch per major.minor release works well so that it can be maintained in isolation while delivering major.minor.patch releases

• Document Long-term support (LTS) release strategy - example https://github.com/hyperledger/fabric-rfcs/blob/main/text/0005-lts-release-strategy.md

• Use Github Actions to automate release process, e.g. publish artifacts and release notes upon drafting a GitHub release
• Use Reproducible builds - see website
• Sign release commits with GPG (-S or --gpg-sign) and ; sign release artifacts - see security Security Artifact Signing task force

• Release artifacts

  • binaries attached to GitHub release

  • docker images - transition from Dockerhub to GitHub Packages? See data transfer and storage limits on GitHub Packages...

  • NPM packages - don't publish on every commit due to NPM limit of 1000 versions

...

• GitHub Actions is the recommended CI platform, although we need to address the use efficiently due to limits on number of runners, some ideas:

  • BuildJet
  • Use cancel-in-progress to suppress multiple jobs for multiple pushes to the same pull request
  • Uncheck branch protection rule "Require branches to be up to date before merging" to reduce number of runs (potentially add a scheduled run if you are concerned about incompatible PRs getting merged)
  • Use filters to eliminate unnecessary runs, e.g. doc PRs shouldn't require building and testing code.
  • Consider running some jobs on schedule (e.g. nightly) rather than on each pull request (e.g. various full matrix of platform tests)
  • Inspect Github Actions run results on your own fork prior to opening Pull Request

• Pull request checks

  • DCO - Developer Certificate of Origin

  • Unit tests

  • Integration tests

  • Scans - see Security section, consider running on schedule (e.g. nightly) rather than on each pull request
  • Be wary - just because a change passes checks doesn't mean it is necessarily good, it still requires judicious maintainer review

• Test coverage reporting - run on-demand or nightly

• Keep CI clean and green at all times, address failures and flakes

• See proposed Automated Pipelines task force

...