Call for votes: Developer Membership Board restaffing

[Iain Lane]

Hi Steve,

On Wed, Jan 30, 2013 at 04:22:58PM -0800, Steve Langasek wrote:
> Hello,
> […]
> 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?

[ Disclaimer: I'm currently on the DMB but I wasn't at that particular
  meeting, so I won't comment on these particular cases. ]

I think you're right in identifying this as an area of concern, and I
tried to address this briefly in my election statement [1]. I'll try to
restate it a bit now.

As others have said, it's probably not going to be possible to reduce
the process to going through a checklist. What we can do is to be
responsive /and proactive/ when applications first come in (or even
before then, if applicants contact the DMB speculatively or if teams
like the DAT want to link up with us which I think would be a good
idea). It's true that most of the information required to make a
decision is often available before the meeting in which the decision is
ultimately taken.

Given that, if a DMB member feels sure that they would want to vote
negatively on an application, they should feel able to act on their own
initiative and contact the applicant explaining so. I expect this to be
rather less negative than a similar outcome after a full round of voting
at a meeting.

It occurs to me now that if this would actually be slightly more opaque
if it were implemented as such feedback would be in private. [1] talks
about providing feedback after applications fall at a meeting, but this
could also be extended to situations where applicants defer themselves
after correspondence with the DMB prior to a meeting. There are a few
avenues that members can use, depending on the situation, to communicate
their recommendations. [2] and [3], public mail to devel-permissions or
private mail to the endorsers. These would help to build up a body of
case law.

The "how do I know when I am ready" question is one I recognise as one
of the toughest for applicants. It's tough for the DMB to articulate it
too. I recognise that it can feel like the DMB is making arbitrary
decisions or is too quick to defer applications. Greater transparency
would, in my opinion, be the best antidote to ill-will that
unfortunately can sometimes breed.

Finally I want to state that while deferrals are contentious decisions
that sometimes generate a lot of discussion, the vast majority of
candidates the DMB evaluates are approved for the upload rights they
seek (sometimes they are granted even broader permissions if that seems
appropriate). I feel pleased and proud when I look back on the excellent
developers that have been approved during my time on the DMB.

Cheers,

-- 
Iain Lane                                  [ iain at orangesquash.org.uk ]
Debian Developer                                   [ laney at debian.org ]
Ubuntu Developer                                   [ laney at ubuntu.com ]

[1] https://wiki.ubuntu.com/IainLane/DMB2013
[2] https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess
[3] https://wiki.ubuntu.com/UbuntuDevelopers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20130131/d7672170/attachment.pgp>