Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

Issue Specification

  • Issue type

    • Bug

      • A bug which is not that urgent so it will be fixed in next releases

    • Epic

      • A big user story that needs to be broken down

    • Incident

      • A bug from production which needs to be fixed immediately (we can't wait until next release)

    • Story

      • An issue which adds a new functionality into an application

    • Task

      • A mostly technical task that doesn't add any new feature

    • Development Sub-Task

      • A sub-task with code review state

    • Sub-tas

      • The sub-task of the issue

  • Summary (title)

    • Short and accurate description

    • Used as commit message later

    • Use imperative form

      • If applied, this commit will your subject line here

  • Priority

    • Critical

      • Only for critical incidents that prevent using the fundamental functionality of the application

    • High

      • Important features that need to be delivered very soon

      • Bugs that need to be fixed in the next version

    • Medium

      • Default priority

    • Low

      • Nice to have features and improvements

  • Components

    • All affected components

    • Components are assigned to Story, Bug, etc. (not Subtasks)

  • Subtasks

    • Subtask for each git repository by default (FDP Server Implementation, FDP Frontend Implementation, etc.)

    • Use Subtask for a component when necessary (e.g., more people working in the same repository on different component)

Issue Workflow

1. Create Issue

  • Fill in the Summary (title) according to the specification and Description if necessary

  • Assign Components that will be likely affected

  • Assign Priority according to the specification

  • Move issue to an appropriate position in the backlog (based on its priority compared to the other issues)

2. Plan Sprint

  • Select issues for the sprint

  • Reassign Priority within the sprint (High for must have issues)

  • Assign Version

  • Review Components and update

3. Start Working

  • Create Subtasks according to the specification

  • Assign people to the subtasks

  • Set Subtask to In Progress

4. Finish Working

4.1 Working in the base branch (develop)

  • Create a commit with the Subtask issue number and main issue Summary (title)

    • e.g., [FDP-123] Add RDF store

  • Push commit and set Subtask to Done

4.2 Working in a separate branch

  • Create a new branch according to Gitflow Workflow

  • Squash all commits before opening a pull request

  • Use the same naming convention for commit and pull request as in 4.1

  • Use Rebase and Merge to have a linear history


  • No labels