Skip to content
This repository has been archived by the owner on Jan 18, 2022. It is now read-only.

Maintainer's Guide

Jump to bottom
Jamie Brynes edited this page Jan 30, 2019 · 17 revisions

This guide is aimed at maintainers of the repository - not external contributors or users.

Branching Strategy

This applies to the gdk-for-unity, gdk-for-unity-fps-starter-project, and gdk-for-unity-blank-project repositories.

These repositories currently follow the master-develop workflow, where master is pinned to the latest release and develop is the branch under active development.

All PRs should be aimed at and merged into the develop branch.

Day to day workflow

When working on a feature, bug fix, etc, make a branch off of the develop branch with an appropriate prefix:

git checkout -b feature/my-feature develop

Appropriate prefixes include: feature, bugfix, docs, hotfix, and experimental (see below). Our CI pipelines filter branches based on these prefixes to enforce this practice.

When you are happy for your branch to be reviewed:

  1. Open a PR against the develop branch.
  2. Fill in the PR template sections (where appropriate).
  3. Select 2-3 reviewers depending on the size/complexity of your PR.
  4. Add relevant labels and milestone.

Experimental Branches

For larger features that are best reviewed in chunks, should have an experimental branch established. The intention of an experimental branch is that individual PRs are made into the experimental branch and when its complete, can be merged into develop with minimal review (as all the components should have been reviewed before). It is also possible for an experimental branch to be dropped.

Note that branch protections should be turned on for experimental branches. This ensures that the review and CI workflow is enforced for PRs into it.

Labels

We use labels to identify and filter PRs and issues. The section details the types of labels we use:

Area labels

These are labels in the form of A: *. These labels are meant to denote what area of the product this issue or PR pertains to. Examples include: A: core, A: mobile, A: codegen.

Status labels

These are labels in the form of S: *. These labels are meant to denote what the status of a PR or issue is. Examples include: S: being-considered, S: blocked, S: inactive-closed.

Type labels

These are labels in the form of T: *. These labels are meant to denote the type of a PR or issue. Examples include: T: bug, T: feature, T: documentation.

Other labels

There are also the size/* labels which are automatically placed on PRs by prow bot. These denote the size (in line count) of a PR.

Issues

There are a few types of issues that may be encountered. Each section below details the rule of thumb to follow when an issue of this type is created.

Bug Reports

If a user opens a bug report:

  1. Mark the issue with the T: Bug label along with a relevant area label.
  2. Open a corresponding ticket on JIRA and add a github_issue label to the JIRA ticket.
  3. Comment on the issue that This is being tracked internally as UTY-wxyz.
  4. (Optional) If applicable, request more information: reproduction steps, version information, etc.

Feature Requests

If a user opens a feature request:

  1. Mark the issue with the T: feature, and S: being-considered label along with a relevant area label.
  2. Open a corresponding ticket on JIRA and add a github_issue label to the JIRA ticket.
  3. Comment on the issue that This is being tracked internally as UTY-wxyz.
  4. (Optional) If applicable, respond with questions: use cases, potential other solutions, etc.

Tracking Issues

A tracking issue is an issue opened by a maintainer to track the status of a large feature or a known issue. Examples: #676.

A tracking issue should contain:

  • A description of the feature / bug.
  • In broad strokes, the remaining issues/questions to be resolved about this feature / bug.
  • Relevant labels (T: Tracking is mandatory)
  • A reference to the internal JIRA ticket.

Milestones

Another way of categorizing and filtering PRs and issues is to use Milestones. These Milestones correspond to a Fix Version in JIRA and eventually to a Release in Github.

  • PRs should have a milestone added once it is known which release the PR will land
  • Issues should have milestones added once it is known which release the issue will be closed in.

Roadmap

We publish a public roadmap to let users know when features are ready to land. The first three columns are buckets of features that are in the various stages of development:

  • In Research - These features are still being researched for feasibility, use cases, and existing solutions. Features listed here may still be speculative and are not guaranteed to be done.
  • In Design - These features are still in the design phase and implementation has not begun.
  • In Implementation - These features are undergoing implementation and has not been targeted at a particular release.

The columns to the right of these three represents specific releases. Releases are either planned (denoted with [Planned]) or done (denoted with [Done]).

In the column of each release are features that were/are going to be released in that release. Until a release has been completed, features may slip from release to release.

Once we have a planned release date for a release, we should add a card to the top of the column stating that the release is provisionally planned for a certain date.

When a release is released, we should edit the card stating the release date to "Released on x/y/z" with a link to the release notes.

Clone this wiki locally