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.

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

TODO

Roadmap

TODO

Clone this wiki locally