Skip to content
This repository has been archived by the owner on Dec 13, 2020. It is now read-only.

Issues reporting flow

Jump to bottom
Mia Arh edited this page Mar 6, 2019 · 1 revision

Make sure you select the right repository

Currently, we have 12 open repositories on GitHub. To ease your choice you can select between the 4 main ones:

We might split the issue into the backend and frontend related tasks and it’s possible we’ll move them to another repo.

Go to the issues section

Under branch name select issues Click on the green button “New issue”

All tasks will be structured under the Crust organization projects. We have some level of automation here, otherwise it’s project manager’s responsibility to prepare and delegate tasks, meaning you don’t have to worry about hat.

Ideally, a single project will include issues per one release. Issues from all four repositories will aggregate in one project.

Assigning

At least for now, you don’t have to assign the issue to anybody. Project manager is going to be following all newly opened issues, allocate them to the correct project and assign the developers.

Labels

GitHub labels are a quick way to categorize and filter issues. The structure of labels we use is based on Sane GitHub Labels article on Medium and adjusted to our needs:

  • The default priority of the issue is ‘Normal’. If the issue you’re opening isn’t time sensitive and you just wanted to put it to GitHub so it’s not forgotten please feel free to apply ‘Priority: Low’ label
  • ‘Priority: High’ is meant for really urgent issues that are blocking our workflow. Don’t abuse it :)
  • Don't apply any Type related label. To engineers, the difference between a bug and a feature request is clear. A bug is a discrepancy between how the code is actually working and how the code was intended to work. A feature request requires new code to satisfy a case that can’t be handled by the current codebase. To an end user, something might look like a bug but was in fact never implemented. The issue will get the Type label before it goes to development.
  • A project manager will review an issue you reported and maybe ask you to supplement it needed. When the issue is completed I’ll put on a label “Status: Accepted” which means it’s ready for development.

Projects

The project will be assigned by the project manager after the issue is reviewed and accepted. Issues without project can be considered unreviewed and/or unplanned. Issues with "Backlog" project can be considered as reviewed but unplanned

Milestones

We don’t plan to use milestones, because we can’t use them across repos. Instead, we’ll define release based projects.

Clone this wiki locally