Longhorn issues will be tracked in GitHub milestones and their status will be managed by the Longhorn Sprint.

• New (RD)

  • For any issue that has been created, it will be in the new state.
  • The PM or Maintainers will review it and move it to the planning milestone for the following plan.
  • RDs can also raise issues as a high priority, so the PM or Maintainer can help with setting the milestone.
  • If it's a bug, it may be moved to the upcoming milestone, depending on its severity and impact.

• Analysis and Design (RD)

  • When the assignee starts working on the issue for LEP/POC, the issue should be moved to the analysis and design state.

• Implement (RD)

  • When the assignee starts working on the development, the issue should be moved to the implement state.

• Review (RD)

  • After the corresponding PRs are ready, the issue should be moved to the review state. Also, need to provide the wrap-up information to the ready-for-test comment in the issue like https://github.com/longhorn/longhorn/issues/4826#issuecomment-1633577799.

• Ready for Testing (QA)

  • When the issue is ready for QA testing, the assignee should move it to the ready for testing state, and then QA will take over to help with the following testing.
  • A QA will be assigned to help with the testing.
  • The QA should review the ready-for-test comment of the issue to see if enough info has been provided and the required PRs already, especially test and doc PRs. If any of them is not ready, return the issue back to the implement state, and the assignee should continue working on it to make it ready again.

• Testing (QA)

  • The issue should be moved to the testing state when the QA starts testing. If the test fails, the issue should be returned to the implement state.
  • After testing, the QA should also review if any tests can be improved later and create corresponding tickets for that.

• Close (QA)

  • After the test passes, the issue should be closed with a verification comment. If the issue doesn't require any QA e2e testing, the PM can close it directly with a reason.

The following state updates will be executed by the Longhorn GitHub Action.

• For issues in the New, Analysis and Design, and Implement states, the Sprint field will be cleared. The issue owner must update the Sprint field at the start of the next sprint.
• For issues in the Review state, the Sprint field will be automatically updated to the next sprint.
• For issues in the Ready for Testing, Testing, and Closed states, the Sprint field will remain unchanged.

Longhorn QA or DevOps Issue issues will be managed by the QA Sprint.

QA issues can be categorized into the following:

• Negative Test Cases: Issues labeled with kind/test and area/negative-testing.
• Manual-to-Automation Test Cases: Issues labeled with kind/test and area/manual-to-automation-testing.
• Infra Issues: Issues labeled with area/infra.

• New

  • For any issue that has been created, it will be in the new state.

• Analysis and Design

  • When the assignee starts working on the issue, the issue should be moved to the analysis and design state.

• Implement

  • When the assignee starts working on the development, the issue should be moved to the implement state.

• Review

  • After the corresponding PRs are ready, the issue should be moved to the review state. Also, need to provide the wrap-up information to the ready-for-test comment in the issue like https://github.com/longhorn/longhorn/issues/4826#issuecomment-1633577799.

• Testing

  • Once the issue is approved and merged, it should be moved to the Testing state to re-run the test case and ensure nothing is broken. If the test fails, the issue should be moved back to the Implement state.

• Close

  • After the test passes, the issue should be closed with a verification comment.

The following state updates will be executed by the Longhorn GitHub Action.

• For issues in the New, Analysis and Design, and Implement states, the Sprint field will be cleared. The issue owner must update the Sprint field at the start of the next sprint.
• For issues in the Review state, the Sprint field will be automatically updated to the next sprint.
• For issues in the Testing and Closed states, the Sprint field will remain unchanged.

• For an IMPROVEMENT/FEATURE ticket

  • RD should create a skeleton for the test case and is highly encouraged to implement it.
  • If the implementation is incomplete, QA should complete the test case.

• For a BUG ticket:

  • If found by QA, QA should implement the corresponding test case.
  • If reported by RD or an external user
    • RD should create a skeleton for the test case and is encouraged to implement it.
    • If the implementation is incompleted, QA should complete the test case.

TEST tickets will remain on the QA Sprint board instead of moving between boards for ensuring clearer management. Since engineering and QA sprints run concurrently, we can track progress, bandwidth, and effort in Longhorn Sprint and QA Sprint boards within a sprint.