...
- Documentation should minimally target these audiences
User guide including Getting Started / Tutorial
Project developer guide including coding guidelines, design docs, build instructions, test instructions
Application developer guide
- Documentation task force will address Common styling guide, Recommended common publishing platform, Document best practices for creating documentation, etc.
...
- Maintain a written project roadmap, discuss in project meetings
- Create, clarify, and label issues in Github for contributors, e.g. use label "good first issue" - perhaps split label into sub-labels, e.g. no experience (100) vs SME but no project experience needed (400)
- Review, triage, comment on, and close inbound Github issues
...
Follow an established Release taxonomy - either SemVer or CalVer, use consistent release tags for alpha, beta, etc
Document release strategy, release process including required approvals, 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
Release artifacts
binaries attached to GitHub release
docker images - transition from Dockerhub to GitHub Packages? Will there be size limitations on 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
Continuous Integration (CI)
GitHub Actions is the recommended CI platform, although we need to address the 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 on schedule (e.g. nightly) rather than on each pull request (e.g. various platform tests)
- Inspect Github Actions run results on your own fork prior to opening Pull Request
Pull request checks
Unit tests
Integration tests
- Scans - see Security section, consider running on schedule (e.g. nightly) rather than on each pull request
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
...