Call for votes: Developer Membership Board restaffing
Scott Kitterman
ubuntu at kitterman.com
Thu Jan 31 03:02:44 UTC 2013
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
More information about the ubuntu-devel
mailing list