github.com/cosmos/cosmos-sdk@v0.50.10/.github/ISSUE_TEMPLATE/module-readiness-checklist.md (about)

     1  ---
     2  name: Module Readiness Checklist
     3  about: Pre-flight checklist that modules must pass in order to be included in a release of the Cosmos SDK
     4  labels: 'module-readiness-checklist'
     5  ---
     6  
     7  ## x/{MODULE_NAME} Module Readiness Checklist
     8  
     9  This checklist is to be used for tracking the final internal audit of new Cosmos SDK modules prior to inclusion in a published release.
    10  
    11  ### Release Candidate Checklist
    12  
    13  The following checklist should be gone through once the module has been fully implemented. This audit should be performed directly on `main`, or preferably on a `alpha` or `beta` release tag that includes the module.
    14  
    15  The module **should not** be included in any Release Candidate tag until it has passed this checklist.
    16  
    17  - [ ] API audit (at least 1 person) (@assignee)
    18    - [ ] Are Msg and Query methods and types well-named and organized?
    19    - [ ] Is everything well documented (inline godoc as well as the spec [README.md](https://github.com/cosmos/cosmos-sdk/blob/main/docs/spec/SPEC-SPEC.md) in module directory)
    20  - [ ] State machine audit (at least 2 people) (@assignee1, @assignee2)
    21    - [ ] Read through MsgServer code and verify correctness upon visual inspection
    22    - [ ] Ensure all state machine code which could be confusing is properly commented
    23    - [ ] Make sure state machine logic matches Msg method documentation
    24    - [ ] Ensure that all state machine edge cases are covered with tests and that test coverage is sufficient (at least 90% coverage on module code)
    25    - [ ] 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
    26    - [ ] Assess potential risks of any new third party dependencies and decide whether a dependency audit is needed
    27  - [ ] Completeness audit, fully implemented with tests (at least 1 person) (@assignee)
    28    - [ ] Genesis import and export of all state
    29    - [ ] Query services
    30    - [ ] CLI methods
    31    - [ ] All necessary migration scripts are present (if this is an upgrade of existing module)
    32  
    33  ### Published Release Checklist
    34  
    35  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):
    36  
    37  - [ ] Testnet / devnet testing (2-3 people) (@assignee1, @assignee2, @assignee3)
    38    - [ ] All Msg methods have been tested especially in light of any potential threats identified
    39    - [ ] Genesis import and export has been tested
    40  - [ ] Nice to have (and needed in some cases if threats could be high): Official 3rd party audit