Call for votes: Developer Membership Board restaffing

Thu Jan 31 16:00:44 UTC 2013

On 01/30/2013 07:22 PM, Steve Langasek wrote:
> Hello,
> 
> On Wed, Jan 30, 2013 at 09:36:19AM -0600, Micah Gersten wrote:
>> The Developer Membership Board has started a vote to restaff for the
>> four members whose terms are expiring. The Developer Membership Board is
>> responsible for reviewing and approving new Ubuntu developers. It
>> evaluates prospective Ubuntu developers and decides when to entrust them
>> with developer privileges. There are seven candidates:
> 
>>     Benjamin Drung (bdrung) https://wiki.ubuntu.com/BenjaminDrung
>>     Bhavani Shankar (coolbhavi) https://wiki.ubuntu.com/BhavaniShankar
>>     Cody Somerville (cody-somerville) https://wiki.ubuntu.com/CodySomerville
>>     Dmitrijs Ledkovs (xnox) https://wiki.ubuntu.com/DmitrijsLedkovs/DMBApplication
>>     Iain Lane (Laney) https://wiki.ubuntu.com/IainLane/DMB2013
>>     Scott Kitterman (ScottK) https://wiki.ubuntu.com/ScottKitterman
>>     Stéphane Graber (stgraber) https://wiki.ubuntu.com/stgraber
> 
> At the January DMB meeting, there were two applicants, both of whom were
> rejected.  It doesn't say that on paper; on paper it says that Adam Stokes's
> application was changed to "contributing member" during the meeting and was
> approved.  But the long and the short of it is that two people with a
> substantial history of contributing to Ubuntu in their respective domains
> applied for upload rights in January, were recommended by existing Ubuntu
> developers, and were denied upload rights by the DMB.
> 
> I understand that the DMB won't always agree with their fellow Ubuntu
> Developers about whether a particular applicant is ready for a particular
> uploader status.  But I do think it's important that when the DMB disagrees
> with the developers who are recommending someone for uploader status, there
> be transparency about the reasons for this disagreement.  Currently, the
> wiki says:
> 
>   It can be difficult to know when you are ready to apply for uploader team
>   membership.
> 
>   (https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess)
> 
> That's certainly true, but I think this is something that the DMB has a duty
> to correct.  Frankly, I think there's no reason that Adam and Björn couldn't
> have been ready for upload rights by January, *if* the DMB's expectations
> were made clearer.  If there were documented standards that at least tried
> to be objective, people who are aiming to get upload rights can be working
> to those standards in advance, instead of being told in the DMB meeting that
> the work they've been doing doesn't tick the right boxes on the DMB's
> invisible checklist.
> 
> So my question to each of the candidates is this.  As a member of the DMB,
> what would you do to remove this uncertainty around when people are ready to
> apply, reducing the number of rejections (whether those are hard rejects, or
> soft "redirects") at DMB meetings?

First of all, I'd like to start by looking at some numbers because I
know people on this list love those.
Based on my quick grepping through the IRC logs, over the past year
we've had a total of 29 applications of which 22 were granted, giving
over 75% success rate for our applicants.

Note that those numbers look at what was originally asked for by the
applicant, so any case where the application is "downgraded" by the DMB
isn't part of those 22.

Detailed stats are:
Coredev applications: 6 / 8 => 75%
MOTU applications: 2 / 4 => 50%
PPU: 14 / 16 => 87.5% (of which 5 included the creation of a new set)
UCD: 0 / 1 => 0%

Now to try to improve those numbers a bit, I think we can do a few things:
 - Improve our wiki documentation. I think we've rewritten it from
scratch 2-3 times since I first joined the DMB, but maybe the next time
will be perfect. As others said, we can't and won't publish a checklist
of things to do to become a coredev, MOTU or get PPU, but what we can
publish is a list of important areas of work related to the membership.
   Essentially we'd mention that coredevs work on the whole archive,
have to deal with a variety of different packaging methods, help with
library transitions, SRUs, merges from Debian and coordinate with the
release team. That should give enough pointers as to what we typically
look at when we get one of those applications.

 - I like the idea of having the Developer Advisory Board contact us and
in general I feel that applicants and sponsors should equally feel free
to contact DMB members to check if they feel they are ready or what kind
of work is still expected.
   All DMB members don't always agree with each other, so unfortunately
even if you're being told that you seem ready, it's no guarantee that
you'll be successful at the meeting, but those cases are fairly rare I
think and unfortunately Adam Stokes' application was one of those (where
I was the DMB member contacted pre-meeting).

 - Attempt to better describe what we expect on the social/distro side.
   The DMB doesn't only grant upload privileges, it also grants Ubuntu
Membership along with those privileges. That's one thing that caused
some problems with some applications as they were fine from a technical
point of view, but weren't really involved in the Ubuntu community,
weren't aware of the Ubuntu culture and our processes, which ultimately
led to a deferral.
   We've been doing work lately to come up with a new PPU that doesn't
give Ubuntu Membership as a way around that specific problem.

Another idea I had recently is to maybe publicly document why an
application was successful, either in our reply to
devel-permissions at lists.u.c or in the meeting minutes.
That's basically the other way around to publicly saying why we are
deferring an application but should give roughly the same result without
the negative impact of publicly criticizing someone else's work.

We also need to improve our post-meeting e-mails and make sure we get
those out quickly. We only recently started sending those, so we don't
really have a template yet and we're still figuring out how to work on
those together as a group instead of just having one of the members'
opinion sent to the applicant.

Yet another thing we discussed and I feel we really should implement is
splitting the IRC meeting and the voting process. Currently we have up
to 30 minutes of questioning per applicant, then we have a couple of
seconds to decide what we'll be voting and then vote.
That works fine for around 80% of the applications where they are
nobrainers and we can get them processed very quickly and be done with
it, but in some cases, we realistically need a lot more time to dig
through the details the applicant gave us during the meeting and in such
case, it'd be good to publish the vote results later on.

My suggestion here is that when we do our usual "ready to vote?" round,
DMB members should feel free to say "no" and if we don't get quorum at
that point, then the vote is deferred to e-mail where the DMB gets an
extra week to publish the vote results (but no longer than that).
This should help the DMB make way better informed decisions in those
tricky cases and should only apply to a minority of applications.

Since the DMB was first created, our processes and tools have greatly
evolved and I think overall, we've become more consistent in our
decisions and have made some things a lot easier.
I'm specifically proud of the work we've been doing with the package
sets and PPU, where we are now to a point where adding new packages to
those takes just minutes, without the need for a meeting or any complex
paperwork.
We even have a few self-managed teams that can grant upload rights to
specific package sets (flavours, desktop and soon the kernel) and that's
definitely something we want to continue to do.

We also invested a significant amount of time writing tools scanning the
archive, generating reports (http://people.canonical.com/~stgraber),
automatically managing the many upload teams on Launchpad, we even
extended the Launchpad API to make some of our work possible and I think
all of this hard work will be especially important as we're moving
forward with the archive re-org and working more and more with package sets.

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20130131/a32f350e/attachment-0001.pgp>