Issues

Views of issues can be found under Build in the DevRev app and in sprint boards. You can export views to CSV or JSON by selecting Actions in the upper-right corner and choosing the format.

Attributes

Issues are assigned to an engineer, PM, designer, or any other team member through the Owner attribute. This attribute can be effectively used in filters and Group conditions across various vistas in DevRev to track specific work, capacity, and more.

Other key attributes such as Effort (in days) and Target close date can be used to estimate work and delivery to keep stakeholders in the know.

Issues are attached to parts in order to align efforts with product priorities.

As to the size of an issue and the flexibility it offers to manage changes in size, issues offer hierarchy in the form of parent-child relationships and granularity.

From an issue, you can create a parent issue or a child issue. In an issue, select Link Issues in the Issues pane and select the type to add.

While a parent issue can and usually does have multiple children, an issue can have only one parent. If you try to add a parent to an issue that already has one, it fails.

Tasks can be used to break an issue down into smaller pieces. Issues may involve a checklist of items to be handled that can be represented as tasks.

Discussion and events

The Discussion tab of issues is to facilitate communication and collaboration on a given work item across engineers, PMs, designers, and any other stakeholder within an organization.

The Events tab provides a log of key events such as owner assignments/changes, stage changes, and dependency updates.

Create an issue

1. Go to Build > Issues from the sidebar on the left.

2. Click New Issue on the top right corner of your screen.

3. Add a title and description for your new issue. You can also attach files related to the issue in the description.

4. Select which part of the company/product this issue is related to.

   

5. Enter other attributes for the issue: change the assignee or accept the default; enter the severity; add any relevant tags to help employees identify any relevant traits of the issue; select the workspace that the issue pertains to.

6. If there are other tickets or issues that relate to this issue, click Link Records and select the relevant items.

7. If you would like to immediately create another issue, select Create multiple.

8. Click Create.

Tags

• Stalled
• Priority/Escalated
• Fast/Slow Moving
• Blocked
• Resolution: [values]
• Impact: [values]
• Reason: [values]

An autonomous issue is an issue created automatically from an external event, such as a new VCS branch or pull request. These issues have the tag autonomous.

Stages

The following figure shows the state machine for issues.

Open

• Triage

  Issues that are newly created. From here either a user or automation takes a look at the issue and makes a determination of where it should go. In certain cases it may be immediately closed as a duplicate if the reported concern already exists in another issue. In other cases, the owner may determine that the issue is invalid or can't be fixed for other reasons and close the issue as won't fix.

  If the issue isn't a duplicate and is something that should be accepted, the dev determines how soon it should be addressed by moving into the backlog, prioritized stage.

• Backlog (later)

  Issues that have been accepted but aren't planned for the next few development cycles (next and now). Issues in the backlog stage may be groomed at regular intervals to move to prioritized or in development depending on the current priority and bandwidth.

• Prioritized

  Issues that are planned to be completed in the current or subsequent development cycle but which have not yet been started. Issues in the prioritized stage should have clear requirements. Issues in the prioritized stage may be taken up for execution (promoted to in development) or deprioritized (demoted to backlog).

In-progress

• In development

  The issue owner is actively working on the issue. When the owner has their resolution in a good state they request review which puts the issue in the in review stage.

• In review

  The issue and resolution are currently being reviewed. In certain scenarios, the reviewer may request changes to the proposed solution. In this scenario, the stage would transition back to in development. If the reviewers approve the fixes, the issue progresses into the in testing stage for validation.

• In testing

  The fixes have been approved and are currently undergoing validation. If the tests fail or bugs are made apparent, the issue transitions back to the in development stage as changes are required. If the tests pass and the fix is acceptable, the issue starts the deployment (CD) lifecycle and transition into the in deployment stage.

• In deployment

  The fixes are currently being deployed. When the deployment is complete, the issue transitions to the resolved stage. Traditional CD processes may move changes through various environments. These transitions should be tracked with stage notes.

Closed

• Won't fix

  It can't be addressed with a change to the product.

• Duplicate

  Redundant with some other issue.

• Resolved

  Deployment is complete.