Call for votes: Developer Membership Board restaffing

Scott Kitterman ubuntu at
Fri Feb 1 04:42:52 UTC 2013

On Thursday, January 31, 2013 04:12:25 PM Steve Langasek wrote:
> Hi Scott, Bhavani,
> On Thu, Jan 31, 2013 at 03:02:44AM +0000, Scott Kitterman wrote:
> > 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 agree with that principle.  What concerns me is that the needs of the
> project are harmed not only by granting upload rights to people who are not
> ready for them (or who may never be ready for them); they are also harmed if
> we raise so high a bar to membership that the community withers, or if
> existing developers have to spend excessive time on sponsorship of
> contributors that they believe are ready to have the training wheels come
> off.  I fear that the DMB is dealing with the problem on one end at the
> expense of the other end, and think it's important that a better balance be
> struck.
> I am specifically not arguing that the DMB should reverse their decision
> about the two applications in question - I don't think it's my place to
> second-guess the DMB.  What I /am/ arguing is that there is too much
> uncertainty leading /up to/ the meetings about whether a given applicant is
> ready.  I mean, come on - Adam and Björn are both sharp guys, and
> contributing to Ubuntu is part of their day job.  There's no reason they
> shouldn't have both been able to work towards the DMB's standards over the
> course of, say, six months, and get approved for upload rights on the first
> go... /except/ that no one really knows what the DMB's standards are, so
> it's not possible for other developers in the community to reliably guide
> them.

I don't find anything to disagree with here.  There are (at least) two problems 
that lead to this:

 - The first order problem is that standards aren't quantified.  This makes it 
difficult to know if one is qualified or not.  It also makes it difficult for there 
to be a common standard among all DMB members.

 - The second order effect is that there is no "DMB standard", there is only 
the collection of the standards of the individual members of the DMB.

I recall experienced Kubuntu contributors being denied MOTU specifically on the 
basis of most of their experience was with KDE based packages.  IMO, this was 
nonsense.  There are many KDE packages in Universe that need MOTU to watch 
after them and in any case KDE packages aren't notably different than others.

As I have watched the process, DMB members roughly fall into two camps:

1.  The applicant should know enough to contribute usefully without the 
supervision of the sponsorship process and be experienced enough and socially 
responsible enough to ask for help if they need it and to fix stuff if they 
break it.

2.  The applicant should be broadly versed within the scope of the rights 
being applied for to handle anything that might come up.

Some people might think it's obvious which of these is correct, but there is a 
diversity of opinion.  I know one person that declined to apply for core-dev 
until they knew kernel packaging well enough to be comfortable uploading the 
kernel because they thought a core-dev should be ready to deal with every 
package in the archive.  I believe an election is the perfect time to find out 
how candidates feel about this and vote for ones that you agree with.  IMO, I 
have seen some DMB members be very strongly in camp #2 and vote people down 
who I thought were reasonably qualified.

If you think that the DMB is being to parsimonious with upload rights, then 
find out how the candidates view this question.  I think it will tell more than 
any wiki page.  For avoidance of doubt, I'm firmly in camp #1.

> > 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.
> Yes, there's no way to make this 100% quantifiable.  Do you agree, though,
> that the current wiki guidance is too vague, and doesn't adequately map to
> the DMB's existing decision-making process?  Do you agree that this is
> something that should be addressed, to improve the reliability (and speed)
> of the approval process - not by compromising our technical standards, but
> by making clear what those are so applicants can prepare for them
> appropriately?
> Taking Adam as an example again, I understand that the feedback he was given
> was that the DMB wanted to see some merges from Debian before they would
> consider him ready.  This was very surprising to me, because Adam had
> already done quite a bit of SRU work - which I think is the more difficult
> process to get right.  And whereas SRUs are mentioned on
>, merges
> are not.  Do you agree that if there are specific areas of involvement that
> the DMB are going to consider prerequisites for uploader status (such as
> package merges), that these should be called out in the wiki documentation?

I'm not sure how to make the wiki page less vague in a useful way.  I think 
the most useful metric to use in determining if you should apply is developers 
telling you that you should.

Speaking generally, if someone it lacking in one area, such as doing merges, 
I'd rather approve them and work with them afterwards to fill that hole in 
their background if they are otherwise qualified.  I don't expect new 
developers to know everything.  Also, I think far to many new prospective 
developers spend too much time too soon on merges and so I'd actually be a bit 
relieved to see someone that hadn't done them.  Done right, they are semi-
advanced work.

> > 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.
> When an applicant is rejected, what do you think the DMB's responsibility is
> wrt making sure future applicants are available to avoid being rejected for
> the same reasons?

I think we should try to praise in public and criticize in private.  I think 
part of the reason people are reluctant to apply is fear of looking bad.  
Every case is different, so it's difficult to generalize, but if I saw a pattern, 
I think that would be a clue to improve the wiki page on applications to tell 
people how to avoid a particular recurring issue.

> On Thu, Jan 31, 2013 at 11:36:38AM +0530, Bhavani Shankar R wrote:
> > What I believe is a perspective developer gets ready for applying at a
> > particular level when a minimum of one developer of ranks of core dev
> > believes that the applicant is ready for a particular level of upload
> > rights and having more than one of them vouching for the applicants'
> > skills does no harm.
> > 
> > I have been working with the ubuntu developer advisory team a fair
> > bit, reaching out to contributors, helping them by providing pointers
> > in their interested area of ubuntu development, helping contributors
> > in preparing their wiki page for the DMB meeting once they seem to be
> > ready and also reaching out to contributors who have gone inactive
> > over a period of time (maybe due to lack of time or lack of motivation
> > due to rejection of application by DMB for instances) and collecting
> > their feedback and motivating them.
> > 
> > Ofcourse, as you mentioned, the developers who are on the board would
> > have their own thoughts about the applicant and what I would not do is
> > to point out any shortcomings on a public list (which I am presuming
> > that it would be viewable to the entire world), simply because it
> > would give raise to the concern of motivation level drop for an
> > applicant (if feedback given is not taken in the right sense and right
> > manner).
> FWIW this concern that feedback on specific applicants not be made public
> does not resonate with me.  I think the greater drain on motivation is from
> putting oneself forward at all (at the prompting of one's peers) only to
> have the DMB tell them they aren't ready.  I think it's far more important
> to make sure Ubuntu developers understand the DMB's thinking, so that we
> collectively are able to give applicants the guidance they need to be
> successful.

I think it's fine for the application feedback to be public, but it ought to be 
the applicant that decides.  I think that feedback from the DMB to the broader 
Ubuntu community is important, but that should be on the basis of aggregate 
information, not on specific applications.

> > What I would do is if I deem to see an application incomplete or
> > perhaps a bit early to apply to the particular set of upload rights, I
> > would simply abstain with a short explanation and then catch up with
> > the applicant privately on a detailed view of what I thought of his
> > application, his positives and why I exactly thought his application
> > was incomplete, So that it enables him to focus on the shortcomings
> > and hone his strengths even better.
> > 
> > In short, I would rather prefer to a soft redirect, considering the
> > applicants' work with the passion and motivation factor that comes
> > into picture when contributing to an open source environment.
> Do you agree with my argument that if such soft redirects are happening in
> large numbers, this is a problem?

Large numbers of rejects are a problem.  It could be either too many of the 
wrong people applying or the wrong approval standards.

Scott K

P.S. Thanks for starting the thread.  It makes for a more interesting DMB 

More information about the ubuntu-devel mailing list