| Badge Type | Qualification Criteria | Monitoring Method | Monitoring Frequency | Requirement for Stages | Penalty for Non-Compliance | Notes |
|---|---|---|---|---|---|---|
| Legal | Project Badging Proposal | Declarations in repo and in files, GitHub Action to monitor | Continuous | All | Move to "deprecated"? | Ask Ry (or various project maintainers) about using GitHub action to track this |
| Diversity/Decentralized | Project Badging Proposal | Look at (or parse programmatically) MAINTAINERS.md (possibly with additional org field), check commit activity and dashboard over a time period | Continuous | All | Need at least 3 independent (i.e., from different orgs) regular committers for the projct to be deemed healthy from the community's perspective. (This is specified in the Incubation exit criteria). Ensure that project is not dominated by one particular org, even if superficially the project has a diversity of maintainers. Check if there's a programmatic way to find out how diverse the contributions have been. | |
| Release | Project Badging Proposal | Scan the GitHub repo to measure frequency of new releases, check ROADMAP.md, decent amount of activity on public channels (Discord and mailing lists), existence of public RFCs | It's easy to evaluate what's in the repo, but hard to track how much the project's maintenance has occurred publicly with community visibility. Perhaps we should just mandate the first and rely on self-declaration for the second. | |||
| Testing | Project Badging Proposal | Ensure that processes for unit and integration testing are in place and run periodically. Test coverage MD file; ask maintainers to self-report this. | (Evaluate this badge vs "Production" badge) Exact criteria to use is hard to determine. Collect coverage stats from various GitHub actions, check report badges on README? It may be enough to have projects report their test coverage results in a well-known location, as this will inspire confidence in users (the exact criteria and numbers are less important). | |||
| Documentation | Project Badging Proposal | |||||
| Project Badging Proposal | We probably don't need this one as these criteria are assumed to be fulfilled if a project proposal is accepted. | |||||
| Infrastructure | Project Badging Proposal | |||||
| CII | Project Badging Proposal | |||||
| Security? | https://github.com/arsulegai/tsc/blob/security-gov/governing-documents/security.md (PR under review) | |||||
| Reuse/Unique? | Should reuse components from other Hyperledger projects as needed and not reinvent the wheel | |||||
| CI/CD | Best Practices for Automated Pipelines | |||||
| Automation/Usability? | Can users easily launch and test the software using automated scripts or do they have to jump through hoops to get started? | |||||
| OpenSSF Best Practices? | https://github.com/hyperledger/toc/blob/gh-pages/guidelines/project-best-practices.md | |||||
| Conformity? | Does the look and feel of the repo structure and the documentation match that of other projects (according to Hyperledger's recommended practices)? This may overlap with "documentation". Need suggestions from documentation task force. | |||||
| Responsiveness/Engagement? | Are maintainers engaging with the community and responding reasonably promptly to questions and solicitations for involvement? Need suggestions from onboarding task force. The number of summer mentees may also factor into this. | |||||
| Production? | Is the software currently being used in at least one production-grade system outside of Hyperledger (publicly verifiable or certified by third party consumer)? | Evaluate adopters and see what stage of their projects they are in | This may be a more useful criterion and badge than "Testing". |
Overview
Content Tools
Activity