| 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 | Test coverage MD file?, collect coverage stats from various GitHub actions, check report badges on README. | Exact criteria to use is hard to determine. | |||
| 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)? |
Overview
Content Tools
Activity