Sponsorship Process (Was: Re: Packaging Help)
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:
>> 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.
> How is the Sponsorship Process unfriendly and obscure? Can you
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