Juju Project Bug Triage Rules and Plan

[Curtis Hovey-Canonical]

# Juju Project Bug Triage

Understanding when an issue must be addressed now, soon, or whenever an
opportunity is presented.

Good triage communicates how work will be undertaken to address the
issue and when it will be resolved. Collecting good details about the
issue allows developers to plan to solutions for related bugs.

We will triage all the bugs that affect the Juju super project:
    https://bugs.launchpad.net/juju-project

We will know we are done when there are no new, Confirmed, or incomplete
(with response) issues. We will also have retriaged all the Critical and
High bugs to ensure their Importance reflects our intent.

Bugs will be retriaged when the projects goals are revised, which is
every 3 months at the most. Project leads and stakeholders will
participate in retriage as they plan and refine goals.

The individual Juju projects need to define their tags and make them
official so that Lp will auto-complete them. I have some suggestions for
tag, but I cannot actually define them.

We have a draft of the triage workflow. It will be finalised when are
certain it is clear
    http://people.canonical.com/~curtis/Triage-flow.svg

The following rules emphasis action. We can see that many bugs do not
conform to these rules. eg. there are 5 critical bugs older than 30 days
old -- I am not convinced these issues are critical because they failed
to interrupt the work schedule


## Importance (priority conflated with a little severity)

There are three levels of Importance. The levels indicate if the issue
will be included in the planned work, interrupts planned work, or there
are no plans.

*Critical*: Do now.
Interrupt  scheduled work to address the issue.  In most cases, the
issue will be assigned to someone and set in progress.

*High*: Do soon.
Commit to do this soon. Schedule the issue; assign to a milestone when
it is clear when the issue will be addressed.

*Low*: Do when there is an opportunity.
There is no commitment to address the issue. It won’t be scheduled.
Developers may fix the issue while working on another issue, and if so
it will be assigned to a milestone.

The general rule is that developers only work on High issues to meet
their goals. Critical work is undertaken to meet an impending deadline
that was not planned for.

A critical issue that is not assigned and in progress is not
demonstrating it is Critical, maybe it is High. High issues that are
consistently deferred, that are always in the future are not High, maybe
they are Low.


## Status

The immediate goal is to get every issue triaged. This means the
issue’simportance is understood and it is set to Triaged. Issues that
are New, Confirmed, and  Incomplete (with response) need to collect
enough information so the project developers can understand how to
reproduce the problem and how to verify it is addressed.

Some issues will be marked Invalid or Won’t Fix quickly because they do
not pertain to the project, or to its long term goals. Many issues will
marked as Triaged for a long time because the solution does not pertain
to the short term goals.


## Assignee

Issues that are In Progress, Fixed Committed, and Fix Released should be
assigned so that everyone knows who to discuss the issue with. If the
issue status is something else, then assigning someone is probably
wrong. If the issue was In Progress, but work was abandoned, then
unassign it (and change the status back to Triaged) . Do not imply
someone is working on an issue when this isn’t the case.


## Milestone

Assign issues to a milestone when there is commitment to deliver a
solution at a certain time. This is also true for feature-based
milestones where the issue is a dependency of the deliverable. When an
Issue is In progress, someone is assigned to work on it, the milestone
is probably known.

Do not assign issues to milestones when when it is not clear when the
issue will be addressed. Project’s often set goals for a period of
months, but planners can only reliably commit to a few weeks. Plans will
change  as new issues are discovered and the project responds to the
ecosystem (market, community, etc...) Frequently changing the milestone
an issue is targeted to indicates that too much effort is being spent
planning.

Some projects create a milestone named “future” that represents the end
point of the goals. It is understood to be some months in the future.
High bugs must be fixed by the Future milestone. Issues are moved
forward to another milestone when it is known at which release they will
be resolved. This technique reduces pressure to over plan, and moving
issues forward (instead of back) “feels” better to all parties. Any High
issue that is not assigned to a milestone is either a candidate for the
next future milestone, or is actually Low status.


## Tags (classifying the problem)

Tag issues so that they can be included in reports. Tags help triagers
locate duplicate issues, drivers plan upcoming work, and developers
choose related bugs that can be fixed together.

Tags are unique to a project. They are a common language for
understanding the subject of an issue. Tags describe an axises of the
problem, but issues will rarely have a tag for every axis. The meaning
of the tags must be clear to project contributors.

When triaging a bug, ask questions such as these to identify the issue’s
tags. The questions vaguely describe an axis. You don’t need a tag for
every question, and some questions will yield multiple tags.

*Who* are the interested stakeholders?
Stakeholders are organisations and sometimes other projects. Don’t
confuse the project with the technology the project produces. List the
stakeholders who want this issue solved.
    cts, is, cpc, community, maas-project, omnibus-project,
    gui-project, cloud-installer-project, landscape-project,
    juju-project

*What* is the nature of the issue?
Choose one term that best described the nature issue.
    tech-debt, regression, test-failure, paper-cut, defect,
    exception, crash, race-condition, performance, time-out,
    improvement, feature

*Where* do we look to make the fix?
List  the affected modules, component, or subsystems. “doc” and
“packaging” are tags common to most projects.
    testing, swift-double, nova-double, cli, gui, client, authentication,
    agents, hooks, maas, ec2, azure, openstack, nova, glance, swift,
    charmworld, charm-tools

*When* did the issue first appear?
List a combination of series, version, architecture. Might include
browser or client version.
    1.14.0, 1.16.0, amd64, i386, armhf, ubuntu, mac, win,
    FF, Chrome, IE10

*Which* technologies are involved?
Project with multiple technologies often have contributors that
specialise in just a few of them. Choose one term.
    go, python, html, js, css

*How* much effort is needed to for a core developer to solve the issue?
Avoid terms like “trivial” and “easy” because they are ambiguous.
Choose one term.
    hours, days, week, or months

-- 
Curtis Hovey
Canonical Cloud Development and Operations
http://launchpad.net/~sinzui