Skip to content

SD_Issue_Guidelines.md

Latest commit

 

History

History
65 lines (36 loc) · 2.71 KB

SD_Issue_Guidelines.md

File metadata and controls

65 lines (36 loc) · 2.71 KB

Purpose

The purpose of this guideline is to provide a structured approach for Software Developers (SD) when creating an issue on GitHub. This ensures that Product Owners (PO) can easily understand the context, prioritize tasks effectively, and maintain clear communication throughout the development process.

Step 1: Issue Creation

1.1 Title

Create a concise and descriptive title for the issue. Use imperative language to clearly state what needs to be done.

1.2 Template

Fill in the issue template with all the relevant information. Include details such as:

  • Description: Clearly articulate the problem, enhancement, or task.
  • User story : Outline the expected outcome after the issue is resolved.
  • Acceptance criteria : Describe the aim of the issue and define the acceptance crieria.
  • Steps to Reproduce Bug (if applicable): Provide step-by-step instructions for reproducing the issue.

Step 2: Tags and Milestone

2.1 Tags

Select appropriate tags that categorize the issue. Common tags may include:

  • bug: For bug reports.
  • enhancement: For new features or improvements.
  • documentation: For issues related to documentation.
  • help wanted: If additional assistance is needed.

2.2 Milestone

Assign the issue to the appropriate milestone if applicable. This helps in organizing and tracking the progress of features or tasks within a specific release.

Step 3: Mention Product Owners

3.1 Tagging

Mention the relevant Product Owners in the issue description using the @username syntax to notify them of the new issue.

3.2 Clarification

Seek clarification or input from the Product Owners if any details are unclear. Ensure that they are aware of the issue and its significance.

Step 4: Backlog Confirmation

4.1 Product Owner's Review

Product Owners review the issue and, if accepted, move it to the appropriate backlog. If rejected or requires changes, they communicate the feedback to the Software Developer.

4.2 Confirmation to SD

Once an issue is accepted and moved to the backlog, Product Owners confirm this with a comment on the issue. This serves as an acknowledgment for the Software Developer to start working on it.

Step 5: Development

5.1 Assignee

The Software Developer assigned to the issue starts working on it promptly.

5.2 Progress Updates

Provide regular updates on the progress of the issue. If facing challenges or delays, communicate them early to avoid misunderstandings.

Following this guideline ensures a smooth and efficient workflow, fostering clear communication between Software Developers and Product Owners throughout the development process.