Issues - gh05tdog/DAPM_Master_Thesis_Group_D GitHub Wiki

Introduction

All tasks that we undertake, whether itโ€™s a bug fix, feature request, or improvement, will be logged as an Issue within the github ecosystem, so that we ensure that we always have 1. transparency and 2. accountability.

This page will give a thorough outline of how we utilize Issues, as wells as the rules and guidelines to follow.

How We Use Issues in Our Workflow

When creating a new Issue, the following setups are required:

  1. Title and description: Ensure to give enough detail to encapsulate what it needs to fulfill in order to be Done.
  • Acceptance Criteria : When an issue is created, specific AC are setup to help define the scope of the Issue, to highlight Definition of Done (DOD).
  1. Assignees: The Issue is not assigned to anyone in the beginning, this occurs when the Issue is moved from Todo to In Progress
  2. Projects: Make sure to link it to the project, so that i will be passed onto the Kanban board

Once the issue has been linked to the project, go to the Kanban board to continue setting up the issue: Here we are working with 2 essential tags: Priority and Complexity

  1. Priority (MoSCoW): In our project, we work with the MoSCoW method to help prioritize the issues. This ensures that we work and focus on the most critical tasks first. The MoSCoW acronym stands for the following: "Must have" , "Should have" , "Could have" , "Won't have".

  2. Complexity: We utilize an estimate of the complexity, to ensure that we have a somewhat idea of the scope of the Issue, with regards to how long it is going to take us to finish it. We are utilizing the following estimate numbers: It could be:

    1. Open-and-shut case
    2. Quickie - all is known
    3. Research required
    4. Experiments required
    5. Training required
    6. This issue is too big/complex and needs to be broken down into smaller issues

Rules and Guidelines for Issues