Call for votes: Developer Membership Board restaffing

[Scott Kitterman]

On Wednesday, January 30, 2013 04:22:58 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'm not a sitting member of the DMB and have not looked into these specific 
cases, so my thoughts should be taken on a general basis and not at all 
related to these individuals or their applications.

I object a bit to your formulation of the situation though.  I think "denied 
upload rights" is backwards.  "Not granted upload rights" would be much 
better.  I've got a fair amount of experience with making the decision about 
if someone should be given upload rights or not.  I do that currently as a 
member of kubuntu-dev and also did so for MOTU applications when I was a 
member of one of the DMB predecessor organizations, the MOTU Council.

Regardless of if it's the DMB or other delegated body, the decision about 
upload rights is on behalf of the Ubuntu project and it needs to be taken with 
the project's needs in mind.  I don't think there is any inherent right to 
upload to the archive.  Generally it is in the project's interest to grant 
upload rights where technically and socially appropriate, so there is rarely 
any conflict between the needs of the project and the desires of the applicant, 
but I do think it's important to remember on whose behalf we act.

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

I usually know how I'm likely to vote before such a meeting starts.  From my 
perspective, the meeting should be largely confirmatory and questioning should 
be to establish what further training someone might need in the short term.  
In cases where I've been one of the people deciding if someone should be 
granted upload rights and I think the person is not ready, I like to seek them 
out and discuss it with them.  That way they can consider if they should apply 
or not or I might learn something new and help them improve their application.

I do not think that it is possible to reduce the decision about if someone is 
ready for upload rights to quantifiable standards that give complete certainty 
about if one is ready or not.  I have recommended people for MOTU/core-dev 
based on varying standards appropriate to the individual.  Some people I trust 
to be well technically versed enough to tackle most Ubuntu development tasks, 
while others have much narrow knowledge, but I trust them to understand the 
limits of their understanding to and ask if needed.  Specifically, I think 
proposals to handcuff the DMB such as [1] are not a good idea.

I want people to succeed.  The way to do that is through communication before 
and after the meeting.  Before the meeting, to try to get any concerns 
addressed and afterwards to make sure that anyone who was not approved 
understands why.

I do not think we need another mailing list to debate the merits of particular 
applications.  People with opinions about an application should document them 
on the applicant's wiki (you can document NOT RECOMMENDED opinions - I've 
never seen anyone else do it, but I certainly have).  I think that specific 
detailed feedback from the DMB should be speedy and private.  If the applicant 
cares to make it public, they can, but since it's their application that's 
been rejected, I think they should decide.

Scott K


[1] https://lists.ubuntu.com/archives/technical-board/2011-July/000957.html