Skip to content
Gabrielle Schroeder edited this page Jun 2, 2025 · 3 revisions

Branch Rules

Main branch should be protected through branch rules and require code review. Main should be considered stable and a representation of production code.

Dev branches should be considered fragile; code should compile and run, but features may be prone to errors.

Features branches are for specific features that are being worked on. Naming conventions are preferred. e.g. mt-test for Mark Turner testing.

https://nvie.com/posts/a-successful-git-branching-model/

Project board guidelines

Each GitHub repository should have a project associated with it. This project provides a way to organise your team's tasks beyond a list of GitHub issues.

Tasks are initially added to the board as drafts, and then can be converted to a GitHub issue. The issue must be linked to a GitHub repository. Drafts cannot have issue labels or conversation threads, so are best for just initial thoughts and brainstorming.

Individual tasks should be relatively small (e.g., take around 1-5 days to complete).

Status columns

To track a task's progress, you can move it to different columns in the Kanban board. The Kanban template provides these columns as a starting point:

  • Brainstorming: initial issues or tasks that need to be further discussed and refined
  • Backlog: tasks that are ready to be worked on (requirements have been refined)
  • In progress: tasks that have been started
  • Blocked: tasks that have been started, but have been blocked from being finished (e.g., due to a missing dependency)
  • In Review: tasks that have probably been completed, but need to be reviewed by the team.
  • Done: finished tasks

Tags: issue labels and project fields

To organise tasks, you should add tags to tasks. Consider implementing general project-specific tags (e.g., the work package the task belongs to).

The RSE template project has a default set of project fields - the key ones are:

  • Status: the task's column on the Kanban board, such as "Backlog".
  • Priority: the task's priority level. The default values are, from highest to lowest priority, P0, P1, and P2 (P0 = important and urgent, P1 = important, P2 = nice-to-have).
  • Size: a general indication of the size of the task using T-shirt sizes. E.g., XS = ~1 hour, S = ~1 day, M = ~1 week, L = ~1 month, XL = ~3 months to complete the task.
  • Estimate: a text field for entering a numeric value for the approximate amount of time the task will take. Estimates are added up across all tasks in a column, so can be helpful for getting a general overall estimate of how much time the tasks will take. Because accurate estimates are difficult to make, especially for large tasks, we recommend using Fibonacci sequence numbers (0, 1, 1, 2, 3, 5, 8, 13, 21...) to convey the increasing uncertainty of the estimate as the task increases in size.
  • Iteration: can be used to set a specific block of time (defaults to two week blocks) for working on a task.

Any time estimates should only be used for project planning - they are not a commitment to finish a task by a certain time or a way to evaluate an team member's performance.

Wiki guidelines

Project management

Requirements specification

Software

Installation
Deployment
Testing

Data

Other outputs

Publications and presentations

Contributing

GitHub

Meeting Notes

Clone this wiki locally