Skip to content
johanneswieland edited this page Aug 10, 2021 · 12 revisions

We use Github Issues as our task manager. It serves both as a record of what is and needs to be done, as well as a reproducible record of our work.

Scope

An issue should be a well-defined task.

If you are assigned multiple tasks, then complete one before you start the next.

Working on an Issue

Create a branch called issue-[issue number].

Work on your task until you have completed your deliverable.

Deliverable

Each issue should finish be completed with a deliverable. These usually include:

  • A completed task directory with a markdown file describing what the code does.
  • An entry in the logbook of the results of the exercise.

Once you have completed your deliverable write a summary for the issue. The summary describes the reason for proceeding in the way you did and a link to the deliverable(s). The summary should allow someone to understand what you did to address an issue and why, without the need to look at the details of the code basis or the logbook.

After completing your summary, initiate a pull request.

  • You may get feedback on your pull request. Do not close the issue until all feedback has been addressed and your pull request has been merged.

Feedback

One or more people will review your deliverable and code. They may ask you to make changes in the issue thread. You should address these changes in the same branch issue-[issue number].

Once you have addressed the feedback, initiate another pull request.

Closing an issue

Once your code has been merged, you need to write a final summary. The final summary should be self-contained: (1) it explains the reasoning for the final implementation and (2) contains links to the final deliverable. A person reading the final summary should be able to follow the reasoning without having to read the issue thread.

You can close the issue with this final summary.

Clone this wiki locally