Launchpad bug workflow change

[Emmet Hikory]

On 6/20/07, Henrik Nilsen Omma <henrik at ubuntu.com> wrote:
> Jordan Mantha wrote:
> > This is just not true. In Universe we have a great number of people working
> > on bugs that are not able to upload. These people use status,
> > subscriptions, and assignments to get their work sponsored. Even in Main
> > there are quite a number of people who aren't in ubuntu-dev that work on
> > bugs. Your statement is only true in the sense that a developer must touch
> > it at some point to upload the fix, but the work is often enough not done
> > by the developer.
> >
<...>
> If we want a certain group of people who write code but are not MOTU or
> core-dev to be able to set the whole range of status settings then we
> can set up a team that gives that access. I agree that people can write
> valuable code without doing .deb packaging for example.

    For Ubuntu, ~ubuntu-universe-contributors might be an appropritate
team for this, but it significantly raises the barrier of entry for
new contributors.  Many current developers (and contributors) started
work because they found a bug that they could fix themselves, and the
majority of this work is packaging related.  They are led through the
process of creating new candidate revisions or new packages by the
developers, and slowly build sufficient experience to become
developers.  If they must join the group prior to submitting patches
(or at least prior to participating in workflow), they may be less
likely to continue contributions due to the difficulty in getting
their fix applied.  (Specifically, the answer to the question "How do
I get my fix to this package uploaded?" becomes more than "Make a
patch or debdiff and ask for a sponsor.").

    The current workflow for contributors is to mark bugs "In
Progress" when they begin work, and mark "Confirmed" when it again
needs the attention of a developer.  The developer will mark "In
Progress" while they review, and mark either "Fix Committed" if the
fix is uploaded, or "Needs Info" where the proposed fix is not
correct, or additional work is needed.

    What is the new proposed workflow for non-developers actively
working on packaging efforts to fix outstanding bugs?  Clearly, the
previous use of "Confirmed" is not ideal, but I'm not sure that
"Triaged" is better for describing work that is done, and only
requires sponsorship (although the sponsor may disagree, and revert to
a previous state).  More to the point, There really doesn't seem to be
a proper status to be set for those working on the fix who are not
developers.  This is very important, as 1) not having a claim
mechanism leads to duplicate work, and 2) assignments are blurry, and
bugs are often misassigned, leading to confusion over whether the
assignment indicates that the person is working on it (or ToDo), or it
is just not appropriately assigned.  Please note that my opinions
about the reliability of the "Assigned" field in no way represent an
endorsement of access restrictions to this field.

-- 
Emmet HIKORY