Sponsorship Process (Was: Re: Packaging Help)

Loïc Martin loic.martin3 at gmail.com
Fri Sep 25 19:44:36 BST 2009

Daniel Holbach wrote:
> Am Donnerstag, den 24.09.2009, 18:07 +0200 schrieb Loïc Martin:
>> The 
>> main problem I'm afraid off when telling new contributors we'd rather 
>> see them working on existing packages is that the sponsorship process 
>> can get really unfriendly and obscure, unlike REVU. Having someone's 
>> patch or diff.gz (that they spent countless hours on) sit for months 
>> unlooked doesn't encourage anyone into contributing, and nagging on 
>> #ubuntu-motu is nobody's idea of fun. Especially if everybody agree 
>> those same "unmaintained" packages are the problem we would want to 
>> solve in the first place[1].
> How is the Sponsorship Process unfriendly and obscure? Can you
> elaborate?

There's no visibility at all. Basically, your patch/diff.gz can be 
uploaded the same week, or go for month without being looked at. Nothing 
in Launchpad tells prospective contributors (or upstreams) which 
packages they have chances to see their work used, and which packages 
they should ignore because no sponsor is interested in seeing them improve.

There's also no timeframe, for example no way to see if a backport 
request that has been tested and reported working by 2 or 3 contributors 
is going to be ACKed in a meaningful time. A backport or a fix to a 
stable release looses much point if it only gets ACKed a few weeks 
before the development release is delivered, because at this point most 
of your users have moved to the newer version (excluding LTS). How do 
you convince upstream it's better to work within Ubuntu (so a better 
release is backported, or a fix done), if they can see that only a PPA 
gives them the possibility to make Ubuntu better?

The sponsorship process doesn't tell you what to do when a patch is 
roting in Launchpad. For contributors, it's just a black box. It's hard 
to plan your work that way.

>> Maybe having clear rules for Launchpad sponsoring would 
>> make it more transparent too, like having fixed time limits for a bug 
>> awaiting sponsorship to be looked at (twice a month, with set dates 
>> maybe? or a countdown thing per bug?).
> Maybe you could branch http://people.canonical.com/~dholbach/sponsoring
> and patch it so that it does that count-down thing? :-)

It doesn't seem like that page would address the issue at hand, which is 
for prospective developers (or upstreams) trying to see if they can 
improve their users experience.

That page wouldn't really give them any idea on which bugs fixes they 
can expect a sponsor to look at. It doesn't help making the sponsorship 
process understandable, nor would it prevent people to spend time on 
work that will be discarded. Thus, it wouldn't lower the perceived entry 
barrier for contributors, which isn't so much the technical aspect (the 
documentation is really helpful) as the "Could I even get my work (PPA, 
etc...) into Ubuntu?" question.

REVU is better because you can see the queue and help reduce it, since 
it allows you to review other people's packages (and once the packages 
are in good shape they get advocated easily). On Launchpad, new 
contributors see nothing, and the documentation doesn't tell them what 
they can do to help - probably because they just can't.

> While it maybe nice to implement something like "days since
> ubuntu-*-sponsors was subscribed" we should not create too tough
> expectations. A lot of us have a lot of other stuff to do and lives
> apart from Ubuntu. We can't simply promise an x-hour-turn-around-time.

I'm not sure it's so dramatic as to be counted in hours, days or weeks. 
We all know everybody has lives apart from Ubuntu, and I'm sorry if I 
sounded like I was advocating patches to be sponsored daily.
However, contributors also have lives, and deciding to invest 20 or more 
hours on a bug is easier if you have a way to know the work can be 
included into Ubuntu, instead of wondering if you're adding to much to 
the sponsor's burden by fixing more bugs.

Even if you know it's part of the game, it's still unsettling (and, 
given the choice, everyone would rather invest time in a useful way). 
For prospective contributors, that's a big entry barrier, because they 
don't have the past experience to tell them it's supposed to work, and 
that what they see isn't the rule. Upstreams would face the same problem 
- can we expect them to set time aside for Ubuntu (only one of their 
users' distributions) without a process ensuring there will be any 
meaning doing so?

Part of the obstacle people see in contributing to Ubuntu is technical, 
and there's already a lot done to ease this part. The other, that makes 
the process look like it's too bureaucratic, is that the whole way to 
get a contribution put to use is a black box - submit the patch, 
subscribe the sponsors, and then nothing. Nothing tells you what to wait 
for, how long, if it's going to depend on the weather or on the price of 
fish, and even less what you can do to help.


More information about the ubuntu-devel mailing list