Role of the Sponsorship Queue

[Emmet Hikory]

Scott Kitterman wrote:
> On Tuesday 02 March 2010 08:50:27 am Daniel Holbach wrote:
>> Emmet and I had a number of discussions about the nature of the
>> Sponsorship Queue and we'd like to have your input on it.
<...>
> I thought one of the drivers behind merging Main/Universe processes was to
> make it easy for potential contributors by removing the requirement for them
> to understand which component a package was in and subscribe the 'correct'
> sponsorship team.

    Very much so.  Daniel and I both agree that there should be one
and only one sponsoring team to which sponsorship requests are to be
subscribed.  There's another thread about this where the main point
remaining is whether or not we need TB approval to complete the merge
of the current teams (although an increasing number of the TB seem to
be in favor anyway, so it may become moot soon).

> It seems to me that if we split "sponsorship" and "review" into two processes
> we've just reinvented a different way to divide the problem and enable new
> contributors to pick the wrong one and get frustrated.
>
> Given (if I understand it correctly) we've already made the process design
> decision that we want developers to be the ones dealing with process
> complexity because they will understand the requirements better, then I think
> we ought to remain consistent with that design decision and keep the
> sponsorship queue as the general input point for things people who don't have
> upload rights would like to get into the archive.

    See, this is where I differ.  My contention is that people who
don't want to learn any process should not need to learn any process
in order to submit arbitrary patches: LP has perfectly good way to
mark any uploaded attachment as a patch, there exists an automated
script that automatically adds the "patch" tag in these cases (which
bugsquad also may add manually for other types of patches (e.g. inline
or URI of patch, etc.)), and LP makes finding bugs with the patch tag
trivial (in fact there's been lots of recent UI changes to make random
patches *more* visible so that one doesn't need to subscribe any team
for review, etc.

    So, I think there should be two processes.  One is "do the
intuitive thing with LP and forget about it".  The other is "learn
about how Ubuntu Development works, learn which (single) team to
subscribe to get candidates uploaded, etc.  Given that the first
"process" involves the absolute minimum prior education on the part of
the patch submitter, I don't believe this will lead to process
confusion: we just need to reduce the number of places we tell people
to seek sponsorship to those more likely to be found by prospective
developers, and promote doing arbitrary patch review more aggressively
rather than just asking folk to "sponsor".

-- 
Emmet HIKORY