Launchpad bug workflow change

[Emmet Hikory]

On 6/20/07, Henrik Nilsen Omma <henrik at ubuntu.com> wrote:
> ...I can see how that becomes a sensitive change, I also happen to
> think it's useful. I don't agree that someone working by themselves,
> outside of the ubuntu structures, should be able to set the state to In
> Progress (or the new ToDo) because that implies a promise to the
> submitter that a fix _in Ubuntu_ is in the works and that promise can
> really only be made by someone with upload rights.

    Many of those working on these bugs are working within ubuntu
structures (participation on mailing lists, IRC, wiki, etc.), but have
not yet aquired the necessary community trust to upload without
additional work.  Most such submissions are uploaded within hours of
the work being completed.

> If you have to get a change sponsored you can also notify the potential
> sponsor ahead of time and ask for a state to be set. That way the
> responsible sponsor is aware of the work and duplication can be avoided.
> If I file an RFE for an unlikely change to Ubuntu and someone who can
> code and agrees with me might go ahead and start coding, setting the
> status to In Progress, but that change will not likely be accepted when
> it comes time to sponsor it.

    This requires significantly greater effort on the part of
sponsors.  Currently, anyone is welcome to submit a change (with no
promise that it might be uploaded), and request sponsorship through
subscribing the appropriate launchpad team.  Members of the
sponsorship team regularly check the queue, and either upload, reject
as inappropriate, request that it be fixed upstream, or indicate that
community discussion is required.  As a result of the easy workflow,
there are a number of active sponsors, and changes are easily applied
to the archive.  With the proposed model, those known as sponsors will
be deluged in requests to discuss possible fixes, regardless of their
particular expertise or familiarity with the issue in question.
Additionally, such discussion would occur prior to the development of
the proposed fix, and without context, other sponsors may not be able
to easily review the change, causing additional delays while waiting
for the original sponsor to have time to again review the change.

> [The assignee being allowed to change status] would only work if you also limit
> who can assign, otherwise you can just assign a random bug to yourself and mark it
> Fix Released (as you can do now). Under that model, if you ask to have it assigned to
> you, then you should be able to set any state up to Fix Committed. That
> should work.

    I'd like to point out that the majority of bugs I've marked "Fix
Released" were not fixed through any action of an Ubuntu Developer,
rather being fixed upstream or in Debian, and that such work should
not require developer status: there are currently around 300 bugs per
developer, and any that can be marked Fixed before they come to the
attention of a developer reduce the developer workload considerably.
In order to preserve the valuable triage work being done by the
community, it is essential that the "Fix Released" category not be
excluded from those available.

-- 
Emmet HIKORY