Page History

...

• First and foremost, foster a welcoming, positive, and public environment where contributions are encouraged - see YouTube presentation
• Decisions should be made in public, or at least socialized in public

• Mailing lists - start with a single mailing list, consider multiple if there becomes a need (users versus contributors/maintainers)
  

• Discord Chat - important to strike a balance between too few and too many chat channels, link to Discord task force output

• Public meetings - on a regular cadence. Ask community about best meeting time, consider two meetings to cover different regions, or rotating meeting times (shifted 8 hours or 12 hours)

• Meetups - Virtual or in person. TODO - Add link to organizer guide and planning call, meetup mailing list.
• Workshops - Combination of in person (e.g. Global Forum), virtual, and recorded, usually in-demand and well-attended.

• Pull Requests - quick

  • Quick review turnarounds are appreciated and encourage future contributions (and shows up in Insight reports).

  • Equal attention to PRs - review in order of arrival as a general rule of thumb.

  • 'Over'-communicate in PR comments, especially if review is delayed - contributors don't know what is in a maintainer's head
  • Be gentle on new contributors, perhaps relax coding guidelines and fix up later
  • Don't leave contributors hanging... if the contribution is not a good fit say so
  • Mentor new contributors through the process, in PRs and otherwise

• 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 have to re-invent and re-document, or at least a common template.

Security - see also 2022 security task force

• Provide named security contacts per project (at least two contacts)

• Define security issue reporting process in SECURITY.md with reference to Hyperledger reporting process

• Follow security issue disclosure process - see Disclosure task force

• Leverage automated scans, tooling depends on language but usually includes some combination of:

  • linters

  • Software Composition Analysis dependency scans, e.g. Dependabot, Govulncheck 

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

• Keep Pin dependencies and keep dependencies up to date, e e.g. using Dependabot, although be wary of auto-upgrades and look for malware.

• Engage with Hyperledger staff on possibility of Schedule security audits for Graduated project major releases, address audit results and socialize

• Review OpenSSF secure developer guide

• Review and obtain OpenSSF Best Practices Badge - criteria

• Sign release artifacts (TBD) - see proposed Security Artifact Signing task force

...