Re-aligning the Ubuntu Developer Process

Sun Jul 10 17:14:42 UTC 2011

On 2011-07-09 08:10:30 +1000, Martin Pool wrote:
> On 9 July 2011 03:44, Michael Bienia <michael at bienia.de> wrote:
> > On 2011-07-05 11:30:09 -0700, Jono Bacon wrote:
> >> 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"

I guess this is because LP makes it easier to track development related
contributions through sponsored uploads (just click on "Related software
and packages" on the LP profile) than through (successfully) contributed
patches or branches.

>  * 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.

That is related to "Archive Reorgansition" where it is intended that
applicants with a "specialization" has to only show knowledge in that
specific field (and is implemented through PPU and package sets) while
generalist (MOTU and core-dev) need to show a wide field of knowledge.
If ones applies for core-dev the DMB checks that wide knowledge which we
expect from those applicants.

Unfortunately it's not well documented that one can also apply for a
specific set of packages (even if that package set doesn't exist yet) so
some people who are better suited with a package set apply for a
generalist. The result is that they get disappointed of the
requirements.

>  * 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.

I acknowledge that we failed repeatedly to reach quorum in the past.
One problem is that it's hard to find a suitable meeting time for 7
members located around the world (without considering the applicants).

In the past the MC has tried to process applications by mail but that
didn't work out too well either (so the MC switched to the current
processing in meetings). Processing an application by mail took very
long: first there was some time for questions which can take up to two
weeks (or even longer depending if a discussion is going on). Then the
voting period of one week started. In practice only a few members voted
in that week, so the remaining members got pinged again for the vote.
After two weeks you might have enough votes for a qurom (do you wait
longer for the still open votes or not?). So in total processing an
application took one month or even longer without the applicant knowing
whats going on.
IRC meetings have the benefit of realtime communications with the
applicant and (in most cases) a result of the voting (of course only if
the quorum is reached).

If someone has a good solution how to improve the voting process, please
let us know.

> > 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.

I always read the testimonials of an application first and only look
then at the "data" on LP to check the generalists aspect (for MOTU and
core-dev) or "sustained and significant" contributions (if the
application includes Ubuntu membership).

So I wouldn't object to focus the template more towards testimonials.
I even prefer to have many testimonials instead of reviewing some
contributions myself to judge the quality.

> >> 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?

I don't know. The applicant is a DD, a MOTU and also active in
#ubuntu-motu (the application is for his maintained packages in main).

> 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.)

I see this problem (few testimonials) mostly for specialist applications
(PPU or package sets) for "uncommon" areas without any interested
developers in that area that could add testimonials. For well
established developer "types" like core-dev or MOTU, I don't see that
problem.

Here is a example (not very representive):
- https://wiki.ubuntu.com/MarcCluet/UbuntuContributingDeveloper
  for membership; 4 endorsements
- https://wiki.ubuntu.com/JamesPage/ServerDeveloperApplication
  for server-dev package set; 6 endorsements
- https://wiki.ubuntu.com/ChrisHalseRogers/CoreDevApplication
  for core-dev; 5 endorsements
compare that to
- https://wiki.ubuntu.com/MarcinJuszkiewicz/DeveloperApplication-PPU
  gcc-*-cross PPU; 2 endorsements

And if endorsements get more influence, I guess that those applicants
will have it harder to get their endorsements (but I hope I'll be
wrong).

Michael