Skip to content

Latest commit

 

History

History
78 lines (54 loc) · 3.57 KB

github.md

File metadata and controls

78 lines (54 loc) · 3.57 KB
Raw

github

Some tips and info for using github projects for more than just storing your code. ;)

Table of Contents

  1. About projects
    1. Kanban board
  2. Issues
    1. Labels
    2. Opening issues
    3. Closing issues
  3. Pull Requests
    1. Assignee vs Reviewer

About Projects

TODO (check this page as well)

Project-board

The project-board is separated in 5 columns.

Column Info
Backlog This column is not automated, because it's just collecting unplanned issues.
Todo Issues, which are in the current scope, are manually moved to this column. Reopened issues or Pull-Requests are moved to this column automatically. It is very likely, that the Backlog contains more work than can be worked on.
In Progress This column is automated, but does nothing automatically. With this, GitHub takes issues in this column into account when calculating the progress-bar.
In Review Issues, whose branches are in Pull-Request to master, are in this column.
Done Finished tasks lands here.

Issues

Every task, that can be done in several days, should be wrapped into an issue. So working with issues, reading and writing them, happens very often. That's why they should follow an atomic structure and common format, so you can find relevant information faster.

For examples, have a look at this project's templates. You find them in .github/ISSUE_TEMPLATE/. When creating a new issue, GitHub takes these templates and asks the issue-creator to use them.

Labels

Maybe, this list changes with time. In general, one single label should not cover different kind of information, like type (e.g. bugfix, feature), status (e.g. in-progress) and priority (e.g. high, middle, low). To provide these different kind of information via labels, prefixes help (e.g. bugfix becomes type: bugfix).

In my opinion, information like priority or status are related to the repository's state and shouldn't be used as label. I prefer creating Projects (the register next to the Wiki) resulting in following labels.

  • bugfix: Of course, this label is relevant for bugs. Special about this is the absence of a hotfix-label. Here holds the same argument as above: hotfix does imply priority and status, since it should be in progress immediately, which is covered by the project.
  • documentation: Clearly, explanations and information about the repo or the code should be added.
  • duplicate: If an issue addresses the same topic as another issue, discussions and similar should be part of one issue-card. The other issue-card gets this label.
  • feature: This label refers to some "practical" work, like coding or setting up something. Improvements of existing features are covered by this label as well.
  • testing: Refers to some testing issue, e.g. when a new test-case should be added.

Opening issues

TODO

Closing issues

TODO (check this page as well)

Pull Requests

TODO

Assignee vs. Reviewer

TODO