Re-aligning the Ubuntu Developer Process

[Martin Pool]

On 11 July 2011 03:14, Michael Bienia <michael at bienia.de> wrote:
> On 2011-07-09 08:10:30 +1000, Martin Pool wrote:
>> On 9 July 2011 03:44, Michael Bienia <michael at bienia.de> wrote:

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

You can look at say https://code.launchpad.net/~mbp/+merges to see
merges someone has done in the past.  I hope lp will add a full
timeline view at some point, but that probably won't happen soon.  If
there are things that Launchpad could do to help Ubuntu, please file
bugs.

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

Perhaps it would be good to identify what information is gained by the
meeting and the voting.  If the board almost always votes in line with
the endorsements, it's not necessarily worth having a delay and a
meeting.

One possible issue with relying mostly on endorsements is that people
probably self-censor concerns or negative experiences from the wiki
page; perhaps they raise them in private with the membership board,
and there needs to be a space for this to happen?  On the other hand,
if the person really is a jerk and persists with this after they get
access, it is always possible to censure them or in the worst case
withdraw access.

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

+1

> 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

Still, those are fairly positive comments from two very well respected
people, and to me the word of Loïc and Steve would be conclusive to at
least give him a try.  We need to distinguish:

 * he could get more testimonials but because they're not the centre
of this process people don't realize it helps to get more
 * he doesn't know that many people in Ubuntu yet but is trusted by
those who do know him
 * he hasn't done enough work to judge (doesn't seem true if you
include work outside Ubuntu)
 * (purely hypothetically) he knows people but they don't like or trust him
 * ..?

Like in the patch pilot process I think it's really good to make a
decision and not leave people hanging.  For instance we could say "ok,
access granted, but please have someone mentor/review your work
first", or "please get one more endorsement", or whatever.

m