Feature Delivery

This outlines the ideal process for implementing something on CiviForm from start to finish. Not all issues go through this entire process, but at a high level, this is how it should work.

1. When a new feature is desired (or significant changes to an existing one), we create a Product Requirements Document (PRD). This is created and worked on by a CiviForm Product Manager (PM), or created by a representative of a Civic Entity (CE) and approved by a PM.
2. The PM brings in representatives from Design and Engineering to agree upon the scope and resolve any open questions about what is needed. For engineering, the representative will typically be the engineer identified as the engineering Tech Lead (TL) for this feature, who will carry it through the engineering steps.
3. Once the PRD is set, Design creates all mocks needed.
4. Once mocks are finalized, the TL will then create a Technical Design Document (TDD). Other engineers will be assigned to be either approvers or reviewers. Approvers are responsible for thoroughly vetting the whole document, understanding the code landscape involved in the TDD, and providing approval when it is ready. A TDD is ready for approval when there are no more open questions or additional things to investigate, and no "TODOs" the document. Reviewers are a bit more casual, providing feedback where they see things to comment on, but not necessarily doing a full deep dive.
5. Once the TDD is approved, the TL creates all of the implementation issues in GitHub for the feature. This includes a feature flag issue, and all of the work identified in the TDD. The TL isn't necessarily responsible for completing all of the issues, but is responsible for ensuring the issues have sufficient detail and are all completed before declaring the feature complete.
6. When the feature is code complete, review the feature with Product and Design.
7. Follow the procedure for the feature flag, which includes the process for notifying CEs of the feature and eventually removing the flag.
8. PM may hold a retrospective or work directly with CEs to ensure the feature is meeting their needs. If not, we may need another cycle of iteration.

Not every single issue goes through this process. For smaller issues, we may not need a full PRD or TDD. Bug fixes in particular bypass most of this. Sometimes we may not have mocks before we need to start writing the TDD, so there may be some back and forth. But ideally, this is how a feature should get added into CiviForm.

Issue Delivery

Our work board is the primary source of truth for what is being worked on at the moment. These include the five primary statuses for any issue:

1. Ready for Development - The issue is ready to be picked up by engineering.

An issue is Ready for Development when it has sufficient detail in the issue to be picked up by an engineer, with any relevant PRD/Mocks/TDD linked in it. When it shows up on the work board in this column, it has also been prioritized for work in this sprint.

2. Blocked - An "In Progress" issue that requires additional input or is waiting on something else in order to move forward.

This includes issues that are waiting on UX or product decisions.

3. In Progress - The issue is actively being worked on.

An In Progress issue should always have a developer assigned to it who is working on the issue.

4. Needs Review - Development is complete and code is merged for the issue, but it needs further review from stakeholders.

Not every single issue will need additional review. An issue that is bookending a feature where PM/Design sign off is needed may end up in this column. A complex issue that needs bug bashing may also end up in this column.

5. Done - Development is complete on the issue with all code merged and issue is fully addressed.

All issues with this status should also be closed. GitHub doesn't always do this automatically, so make sure to close it when setting this status.

There are a few additional statuses which don't currently show up on the work board to keep the board streamlined, but which can be important in the lifecycle of an issue.

• Needs Triage - This is the default status for a new issue, which means it needs triaging to determine its priority and labels. PMs and Eng leadership regularly triages issues with this status to disposition them.
• Needs Scoping - Typically these are feature request issues that need attention by PMs and Eng leadership to figure out details before moving to Ready for Development.
• PRDs/TDDs - This is an issue for working on a PRD or TDD for a feature.
• Needs Design - [DEPRECATED] Do not use this anymore. This issue needs mocks or design input before moving forward.