Group Module - Module Readiness Checklist

[blushi]

x/group 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.

Ping @blushi if there's any clarifying question on group spec.

The module should not be included in any Release Candidate tag until it has passed this checklist.

• API audit (at least 1 person)
  • Are Msg and Query methods and types well-named and organized? @AmauryM refactor(group): API naming audit #11515
  • Are Proto definitions well-named? @AmauryM
  • Is everything well documented (inline godoc as well as /spec/ folder in module directory) @AmauryM
    • docs: Groups spec cleanups #11631
    • docs: update groups spec & cli instructions #11516
    • Add missing client documentation for TallyResult query (https://github.com/cosmos/cosmos-sdk/pull
      /11315#issuecomment-1078959575)
    • Change docs and CLI from timeout to windows (see Discord post by Noam)
  • Ensure ORM documentation is clear @cmwaters @AmauryM chore: group ORM audit changes #11842
• State machine audit (at least 2 people)
  • Read through Keeper and MsgServer code and verify correctness upon visual inspection @AmauryM chore(group): State machine audit #11559 @atheeshp
  • Ensure all state machine code which could be confusing is properly commented @AmauryM @atheeshp
  • Make sure state machine logic matches Msg method documentation @AmauryM @atheeshp
  • Ensure that all state machine edge cases are covered with tests and that test coverage is sufficient (at least 90% coverage on module code) @AmauryM
    • keeper package tests @JeancarloBarrios feat(group): add test for keeper and cli #11679
  • 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 @AmauryM @atheeshp
    • algorithmic complexity and places this could be exploited (ex. nested for loops)
    • charging gas complex computation (ex. for loops)
    • Storage is safe (we don't pollute the state).
  • Assess potential risks of any new third party dependencies and decide whether a dependency audit is needed
  • Ensure ORM code is correct (@AmauryM) chore: group ORM audit changes #11842
  • Ensure math code is correct @AmauryM
    • Did not audit github.com/cockroachdb/apd/v2
• Completeness audit, fully implemented with tests (at least 1 person)
  • Genesis import and export of all state (@AmauryM)
  • Query services (@AmauryM)
  • CLI methods (@JeancarloBarrios feat(group): add test for keeper and cli #11679)
  • All necessary migration scripts are present (if this is an upgrade of existing module)
• Blocker Issues
  • Pruning of Withdrawn and Aborted group proposals #11531
  • fix(group): Allow group total weight to be 0 #11682
  • fix(group): Better error logs for MsgExec #11746

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) Manual Testing for v0.46 #11880
  • 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

[amaury1093]

Completed!