Re-aligning the Ubuntu Developer Process

[Martin Pool]

On 9 July 2011 03:44, Michael Bienia <michael at bienia.de> wrote:
> On 2011-07-05 11:30:09 -0700, Jono Bacon wrote:
> Hello,
>
> first it would be good if this mail also went to the DMB even if it is
> just to collect initial input from the TB. Otherwise it looks like the
> DMB will only get notified about the outcome/decision without any real
> chance to comment.
>
>> I want to propose a few changes to our developer process. Recently there
>> has been concerns expressed that the process is difficult to get
>> through, even for people with extensive knowledge.
>
> Can you be more specific which "requirements" are seen to difficult?
> But I agree that some parts could be improved but I don't any ideas that
> would work out.

I can give my impression, from going through a PPU application myself
last year, and from seeing other people go through membership
applications.

 * There is [or was] a lot of emphasis on looking for contributions
specifically through sponsored uploads to Ubuntu.  People can make
developer-type contributions to Ubuntu in other ways, such as
attaching patches or branches to bugs that are then uploaded by
others.  Even if this isn't actually a requirement, the typical
process of counting uploads makes it look like it is.  Like Jono says,
"good people getting rejected because their body of work was not in
the specific form that a DMB member expects"

 * There seemed to be a thing that just having done extensive work on
one large area of technology was not enough, and you needed to
demonstrate work outside of this.  This is a bit artificial: most open
source developers specialize.

 * You have to attend an irc meeting to be grilled, possibly at an
inconvenient time, and that meeting in my case repeatedly failed to
meet quorum or was rescheduled.  The requirement for the meeting and
the kind of questions that would be asked were not very clear in the
documentation at the start of the process.  It seems a bit like
jumping through hoops just to prove you want access, when the point
should be for us to prove we want developers.

 * Going back to list specific bug numbers you fixed seems a bit
mechanical when you could instead have other experienced developers
testify you've done good work.

 * It ends up with "well, do all this other work of a type or on a
subject you don't really care about so that maybe we'll let you work
on the problems you do care about," and then there's no clear
commitment ticking those boxes will actually succeed.  Why?  I don't
insist people fix bzr gui bugs before I let them commit fixes for
unicode bugs.

I know people are working on this and some of it will have shifted
since last year, which is good.

So, I can see why people would say "why bother?" and either just keep
contributing as a non-member, or spend their time elsewhere.

Personally, I give access by considering

1. do they have a record of technical achievement?
2. will they use their powers responsibly?
3. and in particular are they mature enough to know what they don't
know and to ask for advice rather than rushing in?
4. can they work well with others?

>> Today I feel our process is too focused on showcasing work as opposed to
>> harnessing reputation - I have always felt that a +1 from a respected
>> community member holds more weight than a list of bugs fixed on a wiki
>> page.  I believe that adjusting our process to focus on reputation will
>> streamline it and reduce the risk of good people getting rejected
>> because their body of work was not in the specific form that a DMB
>> member expects.

+1

> I'd be willing to give good testimonials a heigher weight if there were
> more testimonials in the applications. And a lack of comments or
> testimonials can be seen as a bad integration into the development
> community.

Perhaps this is partly because the process (as it was late last year)
seems more interested in data than in testimonials?  If we simplified
it to say that they main thing is to get testimonials from 3+ people
already well respected in Ubuntu, people would probably do it.

>> With this in mind I would like to propose two modifications to the
>> current assess process for each of these areas:
>>
>>      1. Core-Dev Testimonials - for each candidate they should gather
>>         testimonials from core-devs. These testimonials should account
>>         for the vast majority of the assessment. I believe that if
>>         someone gets two core-dev +1s for approval, there should be a
>>         good reason if the DMB wants to reject the candidate.
>>      2. Brief Core-Devs - we should make it clear that getting a +1 from
>>         a core-dev is key part of the assessment, and core-devs should
>>         expect to provide honest and fair testimonials as part of they
>>         work as a core-dev. We could even provide some kind of
>>         application queue for those requesting testimonials.
>
> Doesn't this move the problem towards core-dev?
> Some applicants have a nice long list of testimonals which makes
> processing an application easier but there are also applicants with only
> a few testimonials (2 or 3) which makes it harder to judge how well an
> applicant is integrated into the development community.
>
> I remember a recent case where an applicant for PPU rights considered
> about aborting his applications because he couldn't get any
> testimonials.

It'd be interesting to know why.  Was he just not very connected to
Ubuntu yet?  Or was it that people knew him, but couldn't
wholeheartedly endorse him?  Or were people in fact happy with him,
but they didn't get around to writing an endorsement?

> How should that application queue work? I read in some testimonials that
> the commenter doesn't have an opinion about an applicant because he
> didn't sponsored enough work from the applicant. How should a random
> core-dev who didn't work together with the applicant judge his
> reputation?

If they don't know the person they shouldn't say anything.

Are there people who are doing good work and ought to get more access,
but nobody can vouch for them?  Where are they doing this work such
that nobody else sees it?  Are there perhaps people who are well
trusted but not core devs who could vouch for it (maybe a
bootstrapping problem.)

>> As such, I would recommend that the process would work like this:
>>
>>       * A candidate wishes to apply to be a dev. They outline their body
>>         of work in a wiki page and request testimoniald from core-devs.
>>       * In the meeting the DMB look at the testimonials first and if
>>         there at least are two core-devs who +1 the candidate the
>>         application should be considered approved unless there is a good
>>         reason to suggest this confidence is unwarranted.
>>       * If a candidate can't get testimonials from core-devs, it is the
>>         DMBs discretion if the candidate should be approved.
>
> I think that will make the DMB useless as we don't need a whole team to
> check if an applicant got two +1 from core-devs.

I think the DMB could possibly then move to setting policy and
handling exceptional cases, and that could be more efficient.

> I've always had a hard time when dealing with applications from
> Canonical employees as I had a feeling that an approval is "expected" or
> at least some requirements waived through.
> Perhaps this is just a feeling I've without any real background but it
> makes dealing with those applications not easier knowing that those
> applicants "need" the upload rights for their day work and on the other
> hand don't judge Canonical employees and community members different.

I can see how this would be awkward.

I think upload rights are in a sense 'expected' (not obliged), because
Canonical's already by hiring the person made a considered judgement
that they're technically competent, mature and responsible, and that
they can work well with others.  Ubuntu gets to make its own decision
about this, but if Ubuntu comes to a different decision that's a bit
odd; also it may indicate the criteria are a bit skewed.

Martin