FIP-40 Milestone Checklist
- Eric Butz
Prod = Product Manager or whoever is leading the FIP
PM = Project Manager
Dev = Lead Developer
QA = Lead QA
Subject | Owner | Description | Jira Links and Notes |
|---|---|---|---|
Definition | ย | ย | ย |
Create FIP | Prod | Follow FIP process to create and get to
| |
Create initial Epic or Story | PM | Create initial Epic or Story | |
Create FIP Dev Wiki Directory | PM | Create directory for FIP docs under Development Documents wiki | Done |
Create stories and subtasks | PM | Subtasks/stories created for items in the Development Milestone Checklist | |
Requirements and Scoping | ย | ย | ย |
FIP-40 Requirements - Project kickoff | PM | Kickoff meeting held with Product Manager to review requirements | |
FIP-40 Requirements - Complete FIP | PM | FIP reviewed and moved to Accepted status | |
FIP-40 Master release schedule | PM | Update master release schedule with feature actions and endpoints | |
Design and Scoping | ย | ย | ย |
FIP-40 Requirements - Functional / Technical design | Dev | Complete technical design and save to wiki. Design draft should include a first draft of all elements outlined in the Development Spec. Template: [FIP-nn] Development - Spec | |
FIP-40 Estimate stories | Dev | Each story should be unit of work that is deliverable in a 2 week sprint. An initial estimate should be included with every development story. | |
FIP-40 Design review | Dev | Functional spec approved by architecture champions and team | |
FIP-40 Design - Update FIP | Dev | Update FIP with any changes resulting from design review | |
Development | ย | ย | ย |
FIP-40 Complete development | Dev | Complete all development for feature. This may include multiple stories and subtasks for larger features. Include link to PR in story. Includes
| |
FIP-40 Ram bump analysis | Dev | Determine RAM allocation for new actions and set RAM bump accordingly. This information should be added to the FIP. | |
FIP-40 Fee analysis | Dev | Estimate initial fees for all actions. In cases where the action requires additional RAM, the fees should be correlated with the RAM estimates. This informationshould be added to the FIP | |
FIP-40 ABI Validation | Dev | Validate json for any new ABIs or ABIs that have been updated. If deploying new contract, make sure ABI copy command is in fio.devtools contracts/build.sh | |
FIP-40 History Plugin | Dev | For transactions that automatically create accounts (e.g., regdomain) if the public key used is new, we need to make sure that the correct entries are added to the the history_plugin.cpp. See for example: https://github.com/fioprotocol/fio/pull/363/files | |
FIP-40 Dev - Update FIP and development spec | Dev | Update the FIP and development spec to make sure they are aligned with the latest code. This includes:
| |
FIP-40 Code review | Dev | Code review of PR from all core devs, release management, and QA FIO does DAC-style code reviews wherein the following core team members are required to review all major PRs:
If a developer approves a PR, it is assumed that they have taken the time to do a thorough review. Just checking the box is inadequate and puts the chain at risk. If a bug or structural issue escapes, we will be taking joint responsibility for not finding it during our reviews. If a developer wants to dig deeper and has questions for the main developer, they should initiate a discussion with the developer. | |
FIP-40 Deployment release guide | Dev | Create deployment release guide. This is used by release management to define needed msigs during testnet and mainnet deployments Includes:
Template: https://fioprotocol.atlassian.net/wiki/spaces/FD/pages/507904016 | |
Unit Testing | ย | ย | ย |
FIP-40 Unit testing - Action and getter unit tests | Dev | Includes initial development of unit tests for handoff to QA:
| |
FIP-40 Unit testing - Performance tests | Dev | Create first level performance testing results reviewed with architecture champions (can be performed on dev machine, try to uncover any obvious perf limits) | |
FIP-40 Dev - Test guide | Dev | Add testing info to this story for QA. This is a brainstorming list of items from the developer to make sure specific items are tested. Includes:
| |
FIP-40 Dev - QA handoff | Dev | Review code and unit tests with QA and Release Management. | |
SDKs | ย | ย | ย |
FIP-40 SDK updates | PM | Create epic/stories to track SDK Release (if changes are needed for new features) | |
QA | ย | ย | ย |
FIP-40 QA - Feature Testing | QA | Complete feature testing, including:
Deliverables include:
| |
FIP-40 QA - Performance testing | QA | Complete performance testing, including:
| |
FIP-40 QA - History node testing | QA | Test against node with V1 History and confirm no errors in log file (add results to Dev Spec) For transactions that automatically create accounts (e.g., regdomain) if the public key used is new, we need to make sure that the correct entries are added to the the history_plugin.cpp. See for example: https://github.com/fioprotocol/fio/pull/363/files To test, the transaction should be run, and a history get_actions for the target account should show the (regdomain, etc.) action. When released to testnet, it should be confirmed that http://bloks.io shows the appropriate transaction history. | |
FIP-40 Testnet smoketest | QA | Add new actions and getters to | |
FIP-40 QA - Test review | QA | System and performance tests and results reviewed with Dev team | |
UAT | ย | ย | ย |
FIP-40 UAT - Merge to develop and install release on DEV server | PM | Merge feature to develop (if not already done). Install release on DEV1 server ( This is a task to ensure that their feature or fix is on a publicly accessible DEV server so it can be reviewed by Product Management. This should be done after system testing is complete. | |
FIP-40 UAT - System testing | QA | Complete system testing, including:
| |
FIP-40 UAT - Confirm feature and QA complete | PM | Confirm all bugs and outstanding items completed | |
FIP-40 UAT - Product Management signoff | PM | Get signoff from Product Management
|
ย
ย