Page History

...

This wiki page is intended for initial brainstorming and collaboration. Eventually the task force output will be published at https://toc.hyperledger.org/ and follow-on targeted task forces may be proposed.

Maintainers guidelines includes guidance around:

...

Common Repository Structure includes guidance around required repository files such as:

...

Inclusive naming includes guidance around:

• Master Switching 'master' to 'main' branch

• Inclusive naming conventions

• Inclusive language statement

...

• Legal - Apache 2 license

• Community support - Active and diverse contributors, plus see Community section below

• Test coverage - Automated unit and integration test suites

• Documentation - plus see Documentation section below

• Infrastructure - plus see Common Repository Structure and Community sections

• Security - plus see Security section below

• OpenSSF Best Practices Badge - https://bestpractices.coreinfrastructure.org/en

• NOTE - As the TOC comes to consensus on more best practices, we could add those to Project Incubation Exit Criteria.

Project Governance

• RFC process examplesfor driving consensus and agreement on project decisions, features, design, etc. Examples:

  • https://github.com/hyperledger/aries-rfcs

  • https://github.com/hyperledger/sawtooth-rfcs (same process in Ursa, Grid)

  • https://github.com/hyperledger/fabric-rfcs (evolution of sawtooth RFC process)

• Team structure, decision making - example https://github.com/hyperledger/sawtooth-rfcs/blob/main/text/0006-sawtooth-governance.md

Community

• Mailing lists - perhaps one targeted for users and another targeted for contributors/maintainers?
  

• Discord Chat - important to strike a balance between too few and too many chat channels

• Public meetings - regular cadence

• Pull Request fast turnaroundsRequests - quick review turnarounds are appreciated

• Contributing docs - examples:

  • https://wiki.hyperledger.org/display/BESU/Contributing

  • https://github.com/hyperledger/cacti/blob/main/CONTRIBUTING.md

  • https://hyperledger-fabric.readthedocs.io/en/latest/CONTRIBUTING.html

  • https://wiki.hyperledger.org/display/indy/How+to+Contribute

  • https://hyperledger.github.io/firefly/contributors/

  • https://github.com/hyperledger/iroha/blob/main/CONTRIBUTING.rst

• NOTE - Perhaps common "contributing" content can be aggregated so that each project doesn't re-invent.

Security - add link to security task force

• Named security contacts per project (at least two)

• Security issue reporting process ( defined in SECURITY.md)

• Security issue disclosure process - see task force https://github.com/hyperledger/toc/issues/48

• Automated Leverage automated scans

  • linters

  • Software Composition Analysis dependency scans (, e.g. Dependabot, Govulncheck (depends on language) 

  • Static Application Security Testing (SAST) aka static analysis scans (, e.g. CodeQL, Snyk)
    

• Keep dependencies up to date (e.g. Dependabot)

• Major release security audits

• Security audits for Graduated project major releases

• Review OpenSSF secure developer guide - https://github.com/ossf/wg-best-practices-os-developers/blob/main/docs/Concise-Guide-for-Developing-More-Secure-Software.md

• Review and obtain OpenSSF Best Practices Badge criteria -   https://bestpractices.coreinfrastructure.org/en/criteria/0

• Security Artifact Signing - proposed task force - https://github.com/hyperledger/toc/issues/49

...

• User guide including Getting Started / Tutorial

• Developer guide including coding guidelines, build instructions, test instructions

• Application developer guide

• Recommended documentation platform?

Releases

• Follow an established Release taxonomy - either SemVer or CalVer

• Documented Document release strategy, release process, branch strategy

• Document Long-term support (LTS) release strategy - example 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 release

• Release artifacts - attached to GitHub release, docker images in GitHub Packages versus Dockerhub

...

• GitHub Actions recommended

• Pull request checks

  • DCO

  • Unit tests

  • Integration tests

  • Scans (- see Security section, more comprehensive scans can be run nightly )
  Release actions
  • instead

• Test coverage reporting

• See Automated Pipelines task force - https://github.com/hyperledger/toc/issues/44

...

• Use .github/settings.yml so that repository settings can be managed and tracked via pull requests

• Recommended initial repository settings, e.g. Repository options, Branch protection rules

• Rebase merging is preferred over Merge commits and Squash merging to keep commit history clean (assuming contributors squash/amend their own pull requests)

• Although there are often multiple paths to achieve an outcome in git and GitHub, there is value in defining a suggested path, both for the benefit of new GitHub users, and for the sake of project consistency.

  • Examples - amending commits versus squashing commits, Mergifyio for simplifying to simplify cherry picks and backports.

  • Example guidance - https://hyperledger-fabric.readthedocs.io/en/latest/github/github.html