Skip to content

Latest commit

 

History

History
54 lines (33 loc) · 3.08 KB

github-workflow.md

File metadata and controls

54 lines (33 loc) · 3.08 KB

GitHub Workflow

This document describes the general GitHub based workflow of the Toggl Mobile team.

Our main priorities when designing our workflow are, from most to least important:

  1. Quality of the apps from a user experience point of view
    • Well designed and implemented features
    • Minimal (read: no) bugs and other issues
  2. Quality of the code base
    • Readability, maintainability, etc.
  3. Make our work as developers smooth, uncomplicated, fun
    • Have few hoops in the way of getting things done

Milestones

As our highest level of organisation on GitHub, we use milestones. Each milestone either corresponds to an upcoming release, or groups issues related to a theme or major feature.

In general, there is always one primary milestone per app, which includes all the issues relevant at the time. Issues inside milestones are sorted from highest to lowest priority, and should be worked on in that order. Milestones usually have deadlines, which indicate the time at which we want all their issues resolved and closed.

We try to schedule our work ahead by at least 1-2 weeks using milestones, to make sure things can always keep moving.

Issues

We try to create issues for any work on the respective app.

Issues are as specific and clear as possible, and should contain or link to all the information needed to start working on them immediately.

When starting work on an issue, the respective developer should assign the issue to themselves to let others know they are working on it. In general, before starting work on a new issue, those already started on should be resolved first.

Unless an issue is invalidated otherwise, it should only be closed by merging a pull request. When opening such a pull request, the issue should be marked with the pending-review label.

Labels

We use labels sparingly to give further information to issues. Here are the common labels we currently use, and when to use them.

  • bug - the issue refers to a functional bug inside the app; these usually have high priority
  • glitch - a non-functional issue in the app, usually related to misbehaving UI
  • cleanup - deals with refactoring, or other changes that should not change how the app functions
  • test-week - this issue can be worked on by someone with little experience with the app's intricacies
  • review-pending - the issue has a pull request, which is awaiting review
  • needs-design - the issue still needs UI/UX design
  • on-hold - the issue cannot be resolved at the moment, or is suspected to be invalid and awaits further testing

Further documentation

For more detailed information on how to submit changes through pull request, how to structure commits, and the branching model we use, please check the following links.