How Issues are Managed

The Concourse project uses GitHub issues to keep track of bug reports and feature requests. This document exists to shed some light on the project's workflow and explain some of the things you may observe as you request features, report bugs, and keep track of the issues that you care about.

GitHub issues should not be used for questions or support - please use the forums instead!

Common Labels

Classifications

enhancement

This label is applied to issues that are requesting or proposing new functionality.

Having this label does not imply advocacy for the issue's feature -- it's just a classification.

bug

This label is applied when the issue describes something is either not behaving as intended or has regressed from previous versions (in which case it may be given an additional regression label).

Bug reports should have clear steps to reproduce. If an issue is reported without an easy way of confirming that it's a bug, it may end up being closed with no resolution.

Anything with a bug label is somewhat objective, and should probably be fixed as soon as there's a clear idea of how to do so.

Communication

good first issue

This label is applied to issues that are small enough in scope that a first-time contributor could relatively easily start working on it and submit a pull request.

help wanted

This label is similar to good first issue but is a bit more of a cry for help. It may be an enhancement that a lot of people want, or a bug that needs more information and testing in order to fully understand.

high impact

Substantial features that enable new workflows or have wide-reaching implications are given a high impact label.

High-impact features are treated with great caution. Implementing feature after feature is something to be avoided in service of keeping Concourse simple and focused. For this reason, it's very important that high-impact feature requests spend a good amount of time on context-building, not just solution-building.

Feature requests with a high impact label are often left to stew for a while until there is a solid understanding of the problem space and until there's a good idea of how many people would be affected by it (ideally in a good way). This is done by pattern-matching feature requests/bugs to find common ground, or by kicking off an RFC to work on a proposal.

If an issue falls within scope of an already-existing RFC or high impact issue it may be closed in service of centralizing discussion on the RFC or other issue.

Concourse's scope is naturally very large -- every developer should use a CI system -- so it's important to take special care when making any high-impact change, in an effort to keep Concourse simple in spite of the many different ways that people will want to use it. The Concourse ethos is to measure ten times and cut once.

anti/* (anti-patterns)

These labels are used to call out common anti-patterns that should generally be avoided. They are big and red and scary and are typically a bad sign, though they don't outright shut down an issue - they may sometimes be used as a warning shot when the issue touches on tricky aspects that should be carefully avoided.

Each label is further described in the Anti Patterns document.

Process Lifecycle

size/* (complexity estimates)

These labels are a rough estimate of the complexity for the issue, implementation-wise. They are typically applied to issues that are prioritized in the backlog of one of our projects.

paused, documented

These labels are applied to issues as part of our development workflow at Pivotal.

• paused means we started on an issue but had to put it down temporarily to work on something more emergent.

• documented means we've written release notes (and any additional documentation) necessary for the change.

Epics

The concourse repo projects are used for grouping together substantial tracks of work that span many GitHub issues. This is for discoverability and to show progress somewhere easy to find.

Each of these projects only has two columns: "Planned" and "Done". Issues are automatically transferred to "Done" when they are closed.

Milestones

Milestones are used for release planning. They may sometimes be given a due date to reflect the estimated time of the release. This is more to set expectations and is never a firm date.