Role of the Sponsorship Queue

[Bryce Harrington]

On Fri, Mar 05, 2010 at 02:57:47AM +0900, Emmet Hikory wrote:
> Scott Kitterman wrote:
> > "Emmet Hikory" wrote:
> >> ?? ??Now, I happen to believe that it's worth having a sponsors queue.
> >>I remember when we didn't have one. ??We created it specifically so
> >>that those developers who didn't yet have upload rights to a given
> >>package could get priority for reviews of their candidate packages
> >>(which at the time primarily consisted of collections of the
> >>previously unreviewed patches). ??If we don't wish to fast-track
> >>uploads for developers, that's fine, but I believe that we'll end up
> >>back in the days when people just repeatedly posted on IRC when they
> >>had a debdiff, and I think that's a waste of the submitters time and
> >>the time of anyone reading iRC (either in real-time or in logs).
> >
> > This leaves out the class of submitter that is currently very motivated around one or two bugs, but has no current intent to become an Ubuntu developer. ?? I think this unfortunate for two reasons:
> >
> > 1. ??It misses a good chance to get a fix into the archive.
> 
>     I'm not convinced this doesn't apply to a significant proportion
> of the outstanding patch list currently, and I don't think that the
> subscription of a special magic team necessarily has any relation to
> the quality of a patch.  Yes, we're losing track of patches, but the
> outstanding number of patches has been fairly constant for the past
> year, and is lower than it has been.  This gives me confidence that
> we're making progress, and can get the total available patches down to
> a manageable level soon, especially if we encourage lots more folk to
> help review the outstanding patches.

The underlying concern here seems to be for ensuring mid-level community
contributors to get visibility onto their non-sponsor-ready
(non-debdiff) patches.  The implication here is that these are lost in
the noise, and no one is paying attention to the problem of getting
attention onto these patches.  This is not true.  People *are* concerned
about this, which is entirely why so many of us have been helping make
the +patches view in launchpad a reality.

This new feature is based on a patch report tool I've been using for
X.org for several months now, and I can attest it's made a great impact
both in increasing the sponsorship time for X patches and has made
inroads at clearing the stale patch backlog, and this is with only an
hour or two of my time each week.

Even if no special patch review process were in place, I strongly
believe that just exposing the patches via +patches is going to
stimulate a lot of needed attention on patches.  The ability to sort
them by age is explicitly designed to help make it easy to give patches
timely attention.  The feature of being able to use +patches on teams as
well as on specific source packages is with the intention of giving
visibility to patches in infrequently reviewed source packages.

Coupled with the patch review that Brian's team will be doing, I think
this is almost guaranteed to improve a lot over the next year.  In the
process, it's likely going to generate a lot more demand for sponsoring
of sponsor-ready patches.  Given the limited number of people who can do
sponsoring, I think it is right to raise the bar so the sponsor team can
efficiently use their time for the sponsor-ready stuff.

Emmet is right that if people are subscribing sponsors to unready
patches as a special incantation to get some attention to them, that is
just adding bureaucracy for patch authors, and misusing limited time of
sponsors which we really need for doing real sponsoring work.  Lets
solve the need for patch reviews with patch review tools and procedures,
not force-fitting them into the sponsorship process.

 
Bryce