[Strawman] Sponsoring after Permissions Reorg

[Emmet Hikory]

Daniel Holbach wrote:
> On 09.12.2009 11:13, Emmet Hikory wrote:
>>     I don't think that there is an identify between the list of bugs
>> with patches attached and the list of bugs that need to be sponsored.
>> Many patches need testing, or have not been integrated into the
>> packaging.
>
> In my mind there should be no sponsoring process at all. It's hard to
> learn about it if you don't know about Ubuntu development and just want
> to fix a simple bug. I really think that attaching a patch or branch to
> a bug should be all that is involved in getting something uploaded.

    This is probably the core difference of opinion.  I think there is
significant social value to the discussions that happen during and
around sponsoring, and that this is a strong vector for sharing best
practices and values.  If we have a semi-automated system where
arbitrary folk just attach branches and it gets uploaded, how do we
build the social rapport that causes us to welcome new developers?
What incentive exists that encourages people to choose to request
upload permission?

    Note that I don't think that people without an interest in
becoming Ubuntu Developers should have to do anything else, I just
think that having a process that doesn't involve significant human
communication is likely to increase perception of separation between
anonymous (or at least unknown) developers and patch/revision
submitters.  In cases where someone just wants to submit a patch, this
is good.  In cases where someone wants to get involved, I think this
is less good.

> If we fail to implement our processes like what I just described, it
> should be as simple as possible. Figuring out which package set the
> package is in this week, then subscribe some special team or post a
> branch or whatever doesn't really seem fair to me.

    For which audience?  I presume that anyone actively participating
in Ubuntu development is working with some team, even if they're just
getting started.  When working with the team, it's unlikely that the
package happens to change randomly between weeks without some notice
(like the team saying "we're explicitly not handling this anymore"),
which ought be clear to anyone involved.  The exception would be cases
where a package was previously managed by MOTU and newly adopted by a
team, but I'd certainly hope that any team adopting a package would
process any outstanding sponsorship requests, and contact any
individual who seems to have previously made significant contribution
to the package (if nothing else, the team stands to gain someone
already knowledgeable about something the team wants to use or
support).  Each development team should have clear documentation of
their preferred process, and be willing to spend time helping new
developers get up to speed if they expect to grow.

    For those not particularly interested in participating in Ubuntu
Development, I agree that the process should be dead simple.  My
personal preference is "Upload a patch and check the "This is a patch"
box" as the complete and entirety of the process.  How we (internally)
get from patches to candidate revisions within Ubuntu Development
varies considerably by team already, and even within teams varies by a
complex ecosystem of overlapping personal processes.  As much as I'd
like to document it better and make it easier to learn, I think it's
more important that we can communicate well within each development
team than that we have a single simple process that is intended to
work for everyone.

>> It's easy for us to forget, but there's often a
>> significant learning effort to go from being able to produce a code
>> patch (which skill one may have aquired in any of a large variety of
>> contexts) to the ability to prepare a candidate revision of a package
>> for upload: essentially one needs to be able to understand how the
>> packaging is done, which of the many available patch systems is used,
>> how to properly manipulate that patch system, how to ensure that the
>> patch is applied using the selected patch system in the package, etc.
>
> The conclusion I draw from that is that our tools can easily frustrate
> drive-by contributors and we shouldn't try to further frustrate them by
> making the processes more complicated. :-)

    Then I've not been clear.  I believe there is a significant
semantic difference between "patch" and "candidate revision".  I
believe that the process for patches should be pointlessly simple and
that the process for candidate revisions should be optimised to
support social integration of our development teams.  I believe there
is a considerable portion of those that are willing to submit patches
that will never have the interest to be Ubuntu Developers and that we
should not restrict the set of people who are encouraged to review
those patches to the set of people who have upload permission to the
archive.  I believe that there is difference in skills between those
required to create a patch and those required to create a candidate
revision, and that therefore there is a signficant opportunity for
those learning to be Ubuntu Developers to review patches from other
sources (including drive-by submissions), where satisfaction of that
opportunity provides value to Ubuntu.  I do not believe that arbitrary
patch submitters should be expected to learn the Ubuntu Development
toolset in order for their patch to be reviewed or accepted.

    Based on those beliefs, I think there should be distinct processes
for "patches" and "candidate revisions", and that there should be no
requirement for acceptance by any body for those who self-elect to
prepare candidate revisions from patches.  As such, I don't think
"sponsorship" applies to this process, as if there's no acceptance
required, there's no "sponsor", leaving "sponsorship" exclusively
about the uploading of candidate revisions prepared by those who are
not able to upload themselves.  I have no fear of further frustrating
drive-by contributors, as I don't think that they need to bother
learning anything about our internal processes: they should simply
need to check the "This is a patch" box when submitting a bug and such
patches should simply be colleted, tested, and applied by those who
have the skills to do so and interest in the package in question (or
if not, in the general quality of the distribution as a whole):
perhaps by reviewing bugs or using Harvest.

    That said, more of us should spend more time searching for bugs
with patches and reviewing those patches.  I just don't think that our
large backlog in doing so is in any way related to the sponsorship
process, and I'm not convinced that we'll get more people excited
about sponsoring more by placing a larger burden of work on the
sponsor (is this a patch?  Does it work?  Does it apply to the current
version?  Can I port it to the current version? ...).  Instead, I
think that we'll get more patches applied by not exposing any special
"sponsorship" process to those uninterested in such things,
encouraging anyone who either is familiar with the Ubuntu Development
toolset or wishes to be so to test and integrate patches, and only
expect the sponsors to review something in a known state (as then it
becomes simply "Does this look relatively sane? Does this apply?  Does
it build correclty?  Does it solve the bug?  Have the bug and patch
been communicated upstream (if applicable)? Upload!".

-- 
Emmet HIKORY