Project: Contour (Orchestration & Management / Service Proxy)
File: github.md

This document outlines how we use GitHub. Contour attempts to ship on a monthly-ish, generally every four to six weeks, basis. These releases are tracked with a milestone. The current release is the milestone with the closest delivery date. Issues which are not assigned to the current milestone should not be worked on. This project has three levels of priority: p0 - Must fix immediately. This is reserved for bugs and security issues. A milestone cannot ship with open p0 issues. p1 - Should be done. p1 issues assigned to a milestone should be completed during that milestone. p2 - May be done. p2 issues assigned to a milestone may be completed during that milestone if time permits. Issues without a priority are unprioritised. Priority will be assigned by a PM or release manager during issue triage. We encourage support questions via issues. Questions will be tagged `question` and are not assigned a milestone or a priority. Any issue which lacks sufficient information for triage will be tagged `waiting-for-info`. Issues with this tag may be closed after a reasonable length of time if further information is not forthcoming. Issues without tags have not be triaged. During issue triage, usually by a project member, release manager, or pm, one or more tags will be assigned. `Needs-Product` indicates the issue needs attention by a product owner or PM. `Needs-design-doc` indicates the issue requires a design document to be circulated. These are blocking states, these labels must be resolved, either by PM or agreeing on a design. Issues within a milestone should be assigned to an owner when work commences on them. Assigning an issue indicates that you are working on it. Before you start to work on an issue you should assign yourself. From that point onward you are responsible for the issue and you are expected to report timely status on the issue to anyone that asks. If you cease work on an issue, even if incomplete, you should leave a comment to that effect on the issue and remove yourself as the assignee. From that point onward you are no longer responsible for the issue, however you may be approached as a subject matter expert--as the last person to touch the issue--by future assignees. For infrequent contributors who are not members of the Contour project, assign yourself by leaving a comment to that effect on the issue. Do not hoard issues, you won't enjoy it PRs which are related to issues in the current milestone should be assigned to the current milestone. This is an indicator to reviewers that the PR is ready for review and should be reviewed in the current milestone. Occasionally PRs may be assigned to the next milestone indicating they are for review at the start of the next development cycle. All PRs should reference the issue they relate to either by one of the following; `Fixes #NNNN` indicating that merging this issue will fix issue #NNNN `Updates #NNNN` indicating that merging this issue will progress issue #NNNN to some degree. If there is no `Updates` or `Fixes` line in the PR the review will, with the exception of trivial or self evident fixes, be deferred. The `help wanted` and `good first issue` tags may be assigned to issues in the current milestone. To limit the amount of work in progress, `help wanted` and `good first issue` should not be used for issues outside the current milestone.