Task Force objective

...

The expected output is a centrally located concise reference document to make project maintainers and contributors aware of the universe of project related guidelines and best practices, along with links to the various resources available to them for further learning and adoption.  Follow-on targeted task forces may be proposed.

NOTE: This wiki page is intended for initial brainstorming and collaboration. Eventually the task force output will be

The content is being published at https://toc.hyperledger.org/ , see Pull Request https://github.com/hyperledger/toc/pull/111

...

Proposed project best practices (with links to existing content, related task forces, etc)

...

• Required

  • README.md

  • CONTRIBUTING.md

  • LICENSE

  • CODE_OF_CONDUCT.md

  • SECURITY.md

  • CHANGELOG.md

  • MAINTAINERS.md

  • CI files
• Recommended

  • NOTICE

  • License headers on all source files

  • Build files

  • Test files

Inclusive naming includes guidance around:

...

• 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)

• Finding new contributors and users
  • Present at Meetups - Virtual or in person – these are well attended and the videos also get many views
    
    • Email meetup@hyperledger.org if you're interested in presenting or join one of the bi-weekly Meetup and Workshop planning calls every other Thursday at 9:30 AM pacific
  • Host technical Workshops - Virtual or in person (e.g. Global Forum) – these are well attended and the videos also get many views
    
    • Reach out to one of the Hyperledger Community Architects or join one of the bi-weekly Meetup and Workshop planning calls every other Thursday at 9:30 AM pacific
  • Take part in annual Mentorship program
    • Near the beginning of each year maintainers have the option to submit projects to the annual Hyperledger mentorship program and work with mentees or code, documentation or research projects
  • Other things to consider
    • This doc has other ideas to consider to help you connect with more users and contributors: Raising the Profile of your Hyperledger Project or Lab

• Pull Requests

  • 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://wikilf-hyperledger.hyperledgeratlassian.orgnet/wiki/display/BESU/Contributing

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

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

  • https://wikilf-hyperledger.hyperledgeratlassian.orgnet/wiki/display/indy/How+to+Contribute

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

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

• TODO - 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

• Review, respond, and act on reported security vulnerabilities

• 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
    

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

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

• Review OpenSSF secure developer guide and OpenSSF overview presentation to TOC (charts, replay)

• Review and obtain OpenSSF Best Practices Badge - criteria

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

Documentation - see Documentation task force and Onboarding task force

• 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.

...