Draft procedure for processing the Universe Sponsor Queue

[Emmet Hikory]

All,

    A draft procedure (1) for processing the Universe Sponsor queue
was discussed at the recent MOTU Meeting, and it was determined that
it would be appropriate to post here for further discussion.  It was
also considered that a similar procedure might be appropriate for use
when processing the Main Sponsor queue.  During the meeting, several
discussion points were raised, which I list below along with my
comments regarding them.

* Is the initial unsubscription from the sponsorship queue necessary?

    This was chosen to ensure that any request that received a review
would not again appear in the sponsorship queue unless additional
sponsorship was requested for the same bug, and to move towards a goal
of an empty sponsorship queue.  As an added benefit, the bugmail
volume for the sponsorship teams should be reduced.

* Why set "In Progress" and self-assign when beginning a review

    This acts as both a marker that the bug is under review (to
prevent duplication of work), and sends a stock message to bug
subscribers, which message is easily translated, does launchpad
support native-language status messages in the future.  The effort
involved in marking "In Progress" and self-assigning is no more than
that of leaving a comment indicating one is currently reviewing it,
and does not clutter the comment thread.

* Why not use "In Progress" rather than "Needs Info" when a debdiff is
insufficient?

    The "In Progress" status implies that someone is actively working
on (or has at least reserved) the bug.  The "Needs Info" status more
accurately captures that additional input is required on the bug in
order to progress further.  The debdiff submitter is expected to set
to "In Progress" if they resume work, and if this is not done within a
reasonable time, others are expected to hijack the patch (during
regular patch trolling).

* Why use "Fix Committed" rather than "Fix Released" when the upload occurs

    When an upload happens, the fix is not actually released, just
submitted to the archive.  It is the responsibility of the sponsored
to watch the builds, and if they fail, adjust the package to build or
request a give-back from the buildd administrators.  Once the package
is built and released on all architectures, the bug should be marked
"Fix Released".  As sponsors will remain the Assignee of the bug, they
may check up to make sure that those they have sponsored are closing
their bugs by using their +assignedbugs page.

* Should both the Uploader (determined by the Changed-By: header) and
the Sponsor (determined by the GPG key) receive feedback when there is
a build failure?

    This would certainly reduce the likelihood of bugs not being
closed properly, although it does increase the workload of the
sponsors, as they then share responsibility for any build failures.
It would furthermore require changes to Soyuz, and therefore may not
be able to be implemented in a short timeframe.

Please note that there is currently no standard procedure for
processing the Universe Speonsor queue, and so any parties wishing to
adopt this draft or variations thereupon prior to approval are welcome
to do so.

(1) https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue

Thank you.

-- 
Emmet