[Strawman] Sponsoring after Permissions Reorg

[Emmet Hikory]

Daniel Holbach wrote:
>      * instead of the person who seeks sponsorship having to find out
>        about ubuntu-{main,universe}-sponsors, they just use
>        ubuntu-sponsors
>      * (we unify the mailing lists too)
>      * http://people.canonical.com/~dholbach/sponsoring/ gets split up
>        by package sets, so it's easier to see what you can sponsor
>      * The new Harvest (https://wiki.ubuntu.com/Harvest/NewUI) will
>        have the possibility to select certain package sets too, and
>        will obviously have sponsoring as an opportunity list too.

    One nice feature about the teams not being unified is that one can
get realtime updates of stuff needing sponsoring through the LP
queues.  Your sponsoring page is sometimes useful, but often hours out
of date, which can be a factor on those (currently unfortunately rare)
occasions when several people are reviewing stuff in parallel.
Another nice feature is that it encourages integration and
coordination within a team covering a given package set.  For example,
if one is working on a package for Kubuntu Destkop, it makes sense to
work with the Kubuntu Devs to get something reviewed, rather than just
some random sponsoring team.

    When designing a new sponsoring process, we should try to have
something that encourages close coordination with various teams within
Ubuntu, rather than a faceless group, especially as we can expect the
proactices and preferences for various teams to diverge over time (for
example, one team may decide that they have a lot of time to maintain
their packages, and so be willing to carry large variance from Debian
or upstream (while still submitting patches there), whereas another
team may decide they want to have the vast majority of patches
accepted upstream before being applied).  Typically, those seeking
sponsorship have already engaged with Ubuntu to a sufficient degree to
contact some developers or read some documentation, and so I'm unsure
we need to completely automate things, as long as the correct
procedure is clearly documented.  By encouraging processes that
reinforce the teams that are supporting specific package sets, we get
three benefits: firstly that new developers are likely to more closely
integrate with existing members of the team, secondly that sponsorship
requests are likely to be reviewed by those most qualified to do so,
and thirdly that sponsors in teams supporting package sets will
receive sponsorship requests in the form they find most convenient for
their internal workflows (for instance, some teams (not currently
delegated) tend to strive for identity between Debian and Ubuntu
source packages and will commit patches submitted to Ubuntu to alioth
and upload to Debian).

    Implemetnation is a bit trickier.  I'm not sure how the package
sets are exposed by LP, but perhaps there could be a list of the teams
supporting a given package presented somewhere (either as part of LP,
or on some reference site that uses the API to extract it), and those
seeking sponsoring could be encouraged to contact the relevant team to
seek sponsorship.  While subscribing some LP group has worked in the
past, I'm unsure that there is a direct need for a unified process for
all development teams, so long as there is a unified way to easily
determine who to contact and how for any given package.  If such a
resource was available, the sponsoring process could look like this:

Sponsor Request:
 * Prepare a candidate revision
 * Check ${SITE} to see what team(s) support the package
 * Contact (one of) the development team(s) to request sponsorship as
documented on ${SITE} for that team

Sponsor Upload:
 * Check some resource (Daniel's page, LP subscription queue, or
other) to see what can be sponsored for your team
 * Pick one and do whatever is normally done by your team to review it
(this should remove it from the queue)

    I have heard a fair amount of anecdotal reports that this is
essentially the process that a number of people follow now, for
packages with supporting teams: specifically that they contact the
team (or a team member) directly and provide the candidate revision in
some way, rather than using the ubuntu-main-sponsors or
ubuntu-universe-sponsors queues.  This can be viewed as either someone
circumventing the process, or an alternate process that more closely
coordinates with interested parties (of which I prefer the latter).
Rather than attempting to concentrate the exsting (sometimes ignored)
process, let's document the emerging more effective process, and
delegate sponsorship within package sets to groups responsible for the
package sets.

    As in my note on merge proposal subscribers, I think we should
exclude package sets with a single developer from this model, as that
needlessly creates a potential block on a single individual (avoidance
of which is part of why Ubuntu exists).  As sponsorship requests take
the form of bugs, and per-package uploaders are expected to be
following bugs for specific packages closely, this oughtn't be a
significant blocker.  We also need to retain a team that is
responsible for sponsoring packages that belong to no package set,
which team we can expect to be an increasingly small proportion of
Ubuntu Developers as we proceed with Archive Reorganisation.  I don't
believe that "ubuntu-universe-sponsors" is the correct team, simply
because we are detaching the semantic values of "the universe
component" and "packages belonging to no package sets", but again,
restoring the old "MOTU Reviewers" team may be an appropriate
solution.

    Note that both Daniel and my proposed processes serve those who
can upload packages in several package sets poorly, in that one
discovers packages available to be sponsored based on the supporting
team or the package set, rather than having an easy way to discover
packages available to be sponsored that one is able to upload.  While
I can't speak for Daniel, I know that this is in part intentional in
my model: I think there is inherent value in doing sponsoring *as a
team*, rather than as an individual (and know I personally am more
motivated to sponsor when sponsoring stuff at the same time as others
in a given area), and I suspect that many of those of us who belong to
several teams are likely to organise our work to focus on stuff for
one or another team in discrete blocks of time, rather than just
randomly doing stuff (and so, when sponsoring, ought sponsor stuff for
each team, as appropriate).  Least well served are those who can
upload to the entire archive, but I expect that they would do best to
concentrate on package sets in which they have specific familiarity
or, if that runs out, on packages that do not belong to any package
set.

    I don't think the mailing lists matter much.  I'm not familar with
the use of the ubuntu-main-sponsors mailing list, but the
ubuntu-universe-sponsors mailing list was created as a blind dump for
bugmail for sponsor requests so that those signing up to be sponsors
didn't end up swamped with bugmail.  Some people have used it at
various times, and often run into timing collisions when revisiting LP
(unless they have particularly effective mail management systems
and/or good luck).  In general, I think that there is little benefit
to a mailing list for sponsoring requests, just because of the
inherent lag of email and the relatively rare need to closely track
history (although perhaps it may be of interest insofar as it may
provide a measure of transparency).

    Adding package set support to Harvest sounds excellent, but I
believe it to be only tangentally related to sponsoring (in that when
one happens to pick a package from Harvest, one is very likely to want
to review the available sponsor requests as part of generally
improving the state of the package), but I would hope that Harvest is
not the primary source of information about patches available to be
sponsored for those interested in sponsoring.

> I think this is unrelated to what James asked for in his email. I
> personally see the sponsoring process as a stop-gap measure until we
> move to Distributed Development completely... one day. :)

    I agree it's unrelated.  I'd like to request that we keep the
discussions about distributed development and merge proposal
management separate from the discussions about changes to the current
sponsoring process.  We've started this thread inconclusively a few
times, and tend to drift into a discussion of distributed development,
which may solve all of these issues differently, but upon which we
shouldn't block discussion of sponsoring.

-- 
Emmet HIKORY