Skip to content

Development

We use GitHub for our development workflow. This includes:

  • Issues for bug reports, feature requests, and general discussions
  • Pull requests for code reviews and contributions
  • Projects for organizing our development workflow
  • Actions for continuous integration (CI)

The Development Project

At HULKs we use a quite heavily modified version of the KanBan workflow (1). The Current Board visualizes our current development status. The List is mainly for organizing multiple iterations for a more long-term overview (important for dev-leads).

  1. The modifications were mainly done to address the fact that we do not have fixed working hours. Limiting the amount of cards that are in progress does not work. Especially for members that are not present on a daily basis.

Terms

Assignee: The person that is responsible for a card; has the exclusive right to move a card as soon as there is one. The assignee's job depends on the Kanban column:

  • No assignee: Open, Done
  • Assignee works on issue/pull request (if more or less progress happens on it): In Progress
  • Assignee is responsible to bring a pull request to main (e.g. reviewer, tester): Request for Review

Note

Github distinguishes between reviewers and assignees. We also do that. While the assignee (in most cases one person) is responsible for the card and bring the branch into the main, the reviewer(s) (can be more than one) can review the code at any time in addition to the notes that were given by the assignee. In general: More reviewers results in better code, so feel free to review anything you like.

Author: The person that created this card (issue/pull request). Responsible for answering questions (issues/pull requests) and implement/discuss requested changes (pull requests).

Columns

Our project board is divided into the following four columns:

Open In Progress Request for Review Done
-------- Developer is responsible Reviewer is responsible --------
The hidden column

The hidden column is a special column that is not visible on the project board. It contains all open issues, that are not in Open and that currently should not be worked on. This is to keep the project board clean and focused on the current iteration.

Open

The Open section contains by the dev-leads selected issues that are important and of high priority for the current iteration.

Note

If you want to work on issues that are not in Open: Feel free to do so, but please create and issue beforehand and assign yourself to it, so that others know that you are working on it.

Move or add an issue to In Progress and assign yourself when you start working on it.

In Progress

The In Progress section contains:

  • issues that have an assignee, but no open pull request. As soon as there is an open pull request fixing this issue, the issue card should be replaced by this pull request card (removing the Issue from the Project but not closing it as it is not fixed in the main yet). The issue must then be mentioned with the fixes keyword in the pull requests description.
  • pull requests that are not ready for review yet and are currently wip.

Move a pull request into Request for Review when you have finished your work and tested the pull request yourself on relevant platforms. At this stage a pull requests' description should be finalized (fill out the template properly).

Request for Review

The Request for Review section contains pull requests that are ready to be reviewed.

Attention

This section is a prioritized FIFO queue. Add new cards at the bottom. The dev-leads might decide to move it further up if the pull request is rather important.

Tip

If your pull request is not ready for review yet but you already want to get some feedback, move it to Request for Review and create it as a draft pull request.

Tip

Enable auto-merge if your pull request is not a draft pull request

Assign yourself if you want to review a pull request.

Conversation-Resolve-Policy

The person (the reviewer) who opened a conversation is the only one allowed to resolve it. The reviewer and author may use this policy to see which feedback has not been addressed yet.

Continuous Integration (CI)

To ensure the quality of our code, we use continuous integration (CI) to automatically run tests and checks on every pull request. If the CI fails, merging will be blocked.

Test-driven development

We aim to write tests for all core functionality, where testing is feasible. To test higher-level functionality, we are currently in the development of including the behavior simulator in the CI.