From c9ef428053308091ced3f275404ba97c5f6ef75c Mon Sep 17 00:00:00 2001 From: Cory Date: Fri, 19 Mar 2021 07:35:25 -0700 Subject: [PATCH] Add issue template for "Module Readiness Checklist" (#8901) * add module readiness checklist template * Update .github/ISSUE_TEMPLATE/module_readiness_checklist.md Co-authored-by: Aleksandr Bezobchuk * update about in module-readiness-checklist Co-authored-by: Aleksandr Bezobchuk Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com> --- .../module-readiness-checklist.md | 40 +++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 .github/ISSUE_TEMPLATE/module-readiness-checklist.md diff --git a/.github/ISSUE_TEMPLATE/module-readiness-checklist.md b/.github/ISSUE_TEMPLATE/module-readiness-checklist.md new file mode 100644 index 0000000000..2d14413ad9 --- /dev/null +++ b/.github/ISSUE_TEMPLATE/module-readiness-checklist.md @@ -0,0 +1,40 @@ +--- +name: Module Readiness Checklist +about: Pre-flight checklist that modules must pass in order to be included in a release of the Cosmos SDK +labels: 'module-readiness-checklist' +--- + +## x/{MODULE_NAME} Module Readiness Checklist + +This checklist is to be used for tracking the final internal audit of new Cosmos SDK modules prior to inclusion in a published release. + +### Release Candidate Checklist + +The following checklist should be gone through once the module has been fully implemented. This audit should be performed directly on `master`, or preferably on a `alpha` or `beta` release tag that includes the module. + +The module **should not** be included in any Release Candidate tag until it has passed this checklist. + +- [ ] API audit (at least 1 person) (@assignee) + - [ ] Are Msg and Query methods and types well-named and organized? + - [ ] Is everything well documented (inline godoc as well as [`/spec/` folder](https://github.com/cosmos/cosmos-sdk/blob/master/docs/spec/SPEC-SPEC.md) in module directory) +- [ ] State machine audit (at least 2 people) (@assignee1, @assignee2) + - [ ] Read through MsgServer code and verify correctness upon visual inspection + - [ ] Ensure all state machine code which could be confusing is properly commented + - [ ] Make sure state machine logic matches Msg method documentation + - [ ] Ensure that all state machine edge cases are covered with tests and that test coverage is sufficient (at least 90% coverage on module code) + - [ ] Assess potential threats for each method including spam attacks and ensure that threats have been addressed sufficiently. This should be done by writing up threat assessment for each method + - [ ] Assess potential risks of any new third party dependencies and decide whether a dependency audit is needed +- [ ] Completeness audit, fully implemented with tests (at least 1 person) (@assignee) + - [ ] Genesis import and export of all state + - [ ] Query services + - [ ] CLI methods + - [ ] All necessary migration scripts are present (if this is an upgrade of existing module) + +### Published Release Checklist + +After the above checks have been audited and the module is included in a tagged Release Candidate, the following additional checklist should be undertaken for live testing, and potentially a 3rd party audit (if deemed necessary): + +- [ ] Testnet / devnet testing (2-3 people) (@assignee1, @assignee2, @assignee3) + - [ ] All Msg methods have been tested especially in light of any potential threats identified + - [ ] Genesis import and export has been tested +- [ ] Nice to have (and needed in some cases if threats could be high): Official 3rd party audit