zydronium/manage.get.gov
1
0
Fork 0
mirror of https://github.com/cisagov/manage.get.gov.git synced 2025-08-06 09:45:23 +02:00
Code Issues Projects Releases Packages Wiki Activity

fixed typos

Browse source
This commit is contained in:
Alysia Broddrick 2023-11-06 10:23:26 -08:00
parent 7bc1c008b1
commit ecdf52982d
No known key found for this signature in database
GPG key ID: 03917052CD0F06B7
1 changed files with 6 additions and 6 deletions
Download patch file Download diff file Expand all files Collapse all files

12
docs/product/product_strategy.md
View file

@ -27,22 +27,22 @@ CISA lacks a scalable, efficient, and secure method of managing the .gov TLD pro
Bugs on production software need to be documented quickly and triaged to determine if fixes need to be made outside of the normal release cadence. Triage levels will be Critical, High, Medium, and Low to indicate the level of priority for fix, not neccessarily the level of severity. See below for more details
**Critical**- should only be determined by the product owner and means the fix for this _critical_ bug needs to have a quick fix for it created ASAP. This is the only case where a bug fix can be added outside of the normal release cycle and directly onto the stable release.
**Critical**- should only be determined by the product owner and means the fix for this critical bug needs to have a quick fix for it created ASAP. This is the only case where a bug fix can be added outside of the normal release cycle and directly onto the stable release.
**High**- Can be determined by product owner or other team member, and indicates this bug is critical enough to warrant being added into the current sprint.
**Medium**- Should be added to a sprint coming up but is not blocking users, or enough users to warrant rushing it into a sprint
**Low**- A minor bug, that could even wait until after the next big launch date to be implemented.
### Steps for Triaging
1. When a bug is found, whether by a developer/designer or from feedback from an end user, a ticket should be made immediately. The actual ticket maker of the ticket can be a member of the product team as needed.
1. When a bug is found, whether by a developer/designer or from feedback from an end user, a ticket should be made immediately. The actual maker of the ticket can be a member of the product team as needed.
2. This bug ticket immediately gets a priority added Critical/High/Medium/Low, with Critcal requiring the product owner's request.
3. Anything marked as critical should be refined immediately and engineering should be notified via Slack that a Critical ticket has been created (if not already notified)
4. All items not marked as critical by the product owner, should wait until refinement to be refined and may have their prioirty level changed during refinement.
3. Anything marked as `critical` should be refined immediately and engineering should be notified via Slack that a Critical ticket has been created (if not already notified)
4. All items not marked as `critical` by the product owner, can wait until refinement to be refined and may have their prioirty level changed during that meeting.
### Steps for dealing with Critical Bugs
1. Once the critical bug ticket is refined and the bug is clear, an engineer should be assigned to work on it. (No ticket, no work)
2. At the same point, two other engineers should be assigned to review the PR once it's made. One of the reviewing engineers can be subsititued for a designer if this is a design/content/other user facing bug fix.
3. In the case where engineering lead is not responsive/ unavailable to assign it immediatley engineers should see the public slack message and volunteer as needed. The product team will be back up to make sure someone is assigned or volunteers for the ticket/PR review ASAP.
4. Once done the developer, now needs to make a PR as usual but should tagged the assigned PR reviewers in a public slack message that the PR is now waiting on their review. They should drop other tasks in order to review this promptly.
3. In the case where the engineering lead is not responsive/ unavailable to assign the ticket immediatley, other engineers should see the public slack message and volunteer as needed. The product team will be backup to make sure someone is assigned or volunteers for the ticket/PR review ASAP.
4. Once done the developer, now needs to make a PR as usual but should tag the assigned PR reviewers in a public slack message stating that the PR is now waiting on their review. These reviewers should drop other tasks in order to review this promptly.
5. See the Making bug fixes on stable during production readme for how to push changes to stable once the PR is approved