Plasma Bugtracking

We use the github bugtracker, and while users/new contributors and such should be able to submit a bug without too much process. We need a little more process to decide which bugs are important and what we should be working on when.

These guidelines might change a bit as we settle in and figure out what works.

Background

Roadmap

The Plasma Roadmap is published on the website and gives a high-level overview of what we want to work on. It divides our progress into several milestones, each milestone is made of several features.

Releases & Versioning

Plasma is currently not-quite usable (I must remember to update this doc when it is!) and so there are currently no version numbers or release schedule. Once it is I think it’d be fairly reasonable to manage two releases per year using something like a train model - because it’s more important to release something rather than have a release wait potentially indefinitely for a particular feature. It’s my guess that twice yearly is not too fast that each release will have a reasonable number of new features, but not too slow that anyone feels they’re waiting too long to get new features.

Regarding bugs this means which version a feature lands in is only meaningful with regard to relative priorities, and bugs/features don’t need to be tagged with a version.

That said, there will probably be meaningful versions such as "1.0" where we declare some API/language/library stability.

Github

Github’s bugtracker allows us to label issues. We already have several kinds of labels

Type: bug, enhancement, maintenance, optimisation
Component: build, compiler, runtime, gc, language, docs etc
Skill: C++, Mercury, Type system, etc
Meta: help-wanted, good-first-bug, no-domain-knowledge
Status: new, accepted, duplicate, invalid, wontfix, resolved
Type: bug, enhancement, maintenance, optimisation
Other: project

We will extend these and probably rename a few of them.

Github also supports a notion of milestones. I beleive these function like labels except that an issue may only belong to a single milestone. The Milestones view has nice progress bars too.

Github also supports project boards, Some large tasks have project boards (eg the module system).

We may not always use github, TODO: find a way to download all this data from github.

Milestones & tasks

the roadmap divides our work into milestones and tasks. Each roadmap task shall be a github milestone. For example, some current milestones are:

Testing
Interfaces
Text handling
Language groundwork
Ergonomics
Closures & functional features
Modules MVP
FFI
Standard library

These should correspond to current roadmap items. Not all of them currently do.

Triaging & labelling

Triaging is a process by someone looks at the issue and assigns various attributes to help with sorting/finding that issue later. It usually decides the issue’s priority (in our case, milestone). Triaging is the responsibility of project maintainers, users do not need to worry about this.

Each issue may have have one or more labels for skills, and usually one for component but this may be more if it’s a cross-cutting issue or zero if it covers the project as a whole.

Each issue should have exactly one type or be a project bug (bug, enhancement, maintainance task or optimisation).

Each issue may belong in a milestone and/or a project board.

Each issue should have a status, it should begin as "new".

Untriaged bugs can be found with this search.

To summarise, to triage a bug assign:

The "status: new",
one type label,
probably one component or feature label, maybe more,
any number of skill labels,
meta labels as appropriate,
if the bug is part of some larger goal it should have a milestone and possibly also belong to a project board.