The community developing Indy believes that it has met the requirements for graduation to an active Hyperledger project. Below are the requirements listed in the Exit Criteria document as well as our answers and responses.
Legal
All code has been made available under the Apache License and is free of incompatible dependencies
✓ All Hyperledger code is available under Apache 2. (see the LICENSE file in Indy repositories)
Project name has been checked for trademark issues
✓ Done.
Community support
The project must have an active and diverse set of contributing members representing various constituencies
✓ We have developers from the US, Canada, India, Russia, and Europe.
The project is not highly dependent on any single contributor (there are at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project)
✓ Sovrin Foundation, Evernym, Province of British Columbia, Brigham Young University, Deutsche Telekom, Danube Tech, and more.
Release plans are developed and executed in public by the community.
✓
Sufficient test coverage
✓ Maintainers to keep high test coverage in our code bases. When `libindy` was last tested, it’s test case coverage was at 94%
The project must include a comprehensive unit and integration test suite and document its coverage. Additional performance and scale test capability is desirable.
✓ Indy has comprehensive unit and integration tests on it’s projects. However, collection of test coverage is difficult considering our tech stack. Steven Gubler is actively working on a solution to start collecting these metrics programmatically using a coverage tool that is potentially compatible with our projects (kcov). While this work is being incorporated in to automated processes maintainers need to remain vigilant about keeping high test coverage in all new submissions.
Sufficient user documentation
✓
The project must include enough documentation for anyone to test or deploy any of the modules.
✓
Alignment
The project must document what requirements and use cases it addresses.
The project must document how it fits within the Hyperledger Architecture
Where applicable, the project should be compatible with other active Hyperledger projects.
- ✓ Hyperledger Ursa support is underway, and integration with the new Ursa release is expected as soon as merge issues between indy-crypto and ursa 0.1.x can be resolved.
✓ Other Hyperledger projects like Fabric and Sawtooth, while very useful projects, lack key functionalities that Indy needs. However, the Indy project is designed with compatibility in mind and is very open to integrations with other Hyperledger projects when possible.
The project should use the Hyperledger standard release taxonomy, once that is agreed upon.
✓
Project must make a release, even a “developer preview”, before graduation.
✓ Done.
Infrastructure
Gerrit or Github repo has been created
Mailing lists have been created and are archived
✓ Done.
Other communication means used, such as slack channels, are set up
✓ Done: Hyperledger’s RocketChat instance
Project is set up with Continuous Integration
✓ Done.
All information necessary for someone to join the community and be able to start contributing is duly documented (location of repo, list of maintainers, mailing lists addresses, slack channels if used, etc) following the Hyperledger Project standard practice (CONTRIBUTING.md MAINTAINERS.txt etc)
✓
CII Badge
A team seeking to graduate from incubation shall have started the CII Badge application and be nearly complete with incomplete badge requirements referenced in their graduation proposal. 100% of the applicable criteria for the CII Badge is a requirement for releasing a 1.0 of the project. That does not mean the project must have 100% of all criteria, just 100% of the applicable criteria. This is to allow for projects such as test harnesses, that have “N/A” answers for questions that don't offer that as an option.
✓