How we use GitHub

We use GitHub as an issue tracker our git server to store our code and documents (like the current one).

TL;DR

Project ≈ Building cycle
Issue Labels ≈ Filters
PR titles and labels ≈ Release notes

Labels

We use GitHub labels for a few purposes:

for Issues:
- to set a type and weight of the issue:
  - issue-type:improvement-request ✨
  - issue-type:bug-report 🐞
  - issue-type:burning-issue 🔥
  - issue-type:technical ⚙️
- to set a module to make it easy to find related issues: module:MODULE_NAME labels (e.g. module:payment, module:permission)
- to set a technical stack of the issue (stack:php, stack:js, stack:css, stack:frontend, stack:server admin, stack:security, stack:design)
- to set status of the issue: blocking-another-issue, blocked-by-another-issue, help wanted, duplicate, not a bug
- to identify good issues for new module owners: good first issue
- to define the relation of the issue to other modules: topic:notifications, topic:analytics
for Pull Requests:
- to instruct ReleaseDrafter to prepare changelogs:
  - size:
    - pr-size:patch for small bug fixes or internal changes
    - pr-size:minor for new features or changes that affect the user
  - category
    - pr-category:fix for bug fixes
    - pr-category:feature for new features
    - pr-category:removed for removed features
    - pr-category:internal anything that doesn't affect app users
    - pr-category:skip-changelog use this label with caution since we might lose track of important changes

Projects

Project board - is a kanban board for the current goals (sprint/building cycle/cool-down/etc.).

Example: https://github.com/orgs/InteractionDesignFoundation/projects/66

Example of a project:

Rules for project columns

In progress

One issue/task per developer
If you have more than one issue in progress, it means you are either blocked or multitasking, which is not effective.

In Review / Blocked

PRs have the highest priorities to avoid merge conflicts and allow developers to be in context on next review rounds.