Understanding the definitions and expectations of our membership processes

[Mackenzie Morgan]

On Wed, Jul 20, 2011 at 4:11 PM, Jorge O. Castro <jorge at ubuntu.com> wrote:
> I am confused as to the definition of the different levels of Ubuntu
> Developers and how that relates to membership in each of the various
> teams (though probably involves overall project membership as well). I
> thought I would bring this up for discussion as it seems to be getting
> more confusing and I'm having a hard time understanding what the level
> of expectations for someone applying for Ubuntu membership for a given
> role is, as well as to what the expected behavior is for endorsements
> from existing members.
>
> According to https://wiki.ubuntu.com/UbuntuDevelopers an "Ubuntu
> Prospective Developer" is someone "who probably just started
> contributing to Ubuntu". The description on the wiki page doesn't list
> anything critical there; the person still needs a sponsor to upload,
> etc. From what I can read it's basically the same as Ubuntu Membership
> but you're interested in eventually going down the development path
> and you have a mentor/sponsor. Ok, that sounds good to me. This feels
> like a position that should be relatively low barrier.

Ubuntu Contributing Developer conveys membership and is therefore the
thing that's "member interested in dev topics."  Prospective is more
like the people who are saying "oh yeah, I just found out about this
LoCo in my area, so I figure I'll get involved with that and then
maybe someday apply for Membership."  Remember, Membership isn't for
people who are "just starting out"--it requires a "significant and
sustained contribution."  Also, there *is no application process* for
prospective. It's a self-declaration thing.

> Ok so that seems to make sense to me too. It is my understanding that
> "significant and sustained" has usually meant "about 6 months", except
> in cases where it doesn't. However some applicants for membership have
> had endorsement from existing members where they do feel that that
> person has had significant and sustained contributions and have had
> their applications for membership declined. So my questions are:
>
>  - How important are endorsements from existing members to the
> membership boards and how much are they taken into account when
> reviewing an applicant?

(And now because I'm on an RMB /and/ the DMB...)

In regular membership applications, I don't care whether the
testimonial writers are members already or not. I'm looking for
eyewitness testimony that this person is helpful. Anyone is welcome to
say "Charlene did an amazing job with getting these Ubuntu booths at
farmers markets organized" or "Luke was really helpful with getting
the last few installfests set up."  If there are no testimonials, the
temptation to vote against the application is high.  We can prod the
person in the meeting to give us *something* to go on, but sometimes
it's like pulling teeth.

In *development* applications, it's a bit different. If you've got
your contributions hooked up to your Launchpad account (we did have
one applicant for whom this was not the case, and they needed to merge
their actual account and the generated one), it's not that hard to
figure out what you've done, though some way to aggregate uploads
*and* successful merge proposals would be very nice.  In this case,
I'm looking for "plays well with others" "understands policy"
"understands freezes" "alerts quickly/fixes-it after uploading
something broken" and "knows their own limits" -type testimonials.

I was talking to Paul Hummer today, and we agree that it'd be really
nice if it was possible to have bzr-commit-access decoupled from
dput-access.  Would I trust Paul to commit to just about any bzr
branch that's full of Python code? Yes.  Would I trust him to upload
packages? No. Programming and packaging are different skillsets.
Kubuntu allows all members of ~kubuntu-members to commit to the
branches maintained by the Kubuntu team, then one of the
dput-accessible people reviews all the changes in the branches and
uploads a package every now and then.  He finds it odd that we refer
to packagers as "developers."  I believe that comes from the idea that
distro developers don't write code, just package upstream's code, or
maybe upstream's code + a patch cherrypicked from who-knows-where (LP,
BTS, upstream git...).

With that, I then wonder why a non-packager would want to apply for
~ubuntu-dev since they don't *need* upload rights to get stuff done. I
suspect part of it is just to be able to say "I'm an Ubuntu
Developer," and I get that. I've got one friend who asks me "so how
many patches do I need to submit and where before I get to call myself
a Linux hacker?"  I think there should be a way to recognise people
who write lots of code for Ubuntu but don't package, but obviously
giving them package-upload-rights isn't it.

Recently, I know there's been some omgdrama with the DMB and some
Canonical teams.  This comes, I believe, from being unsure *which*
Canonical projects are Ubuntu sub-projects (like, say, Ubiquity).
Rick, I believe, described DX as being "upstream" of Ubuntu.  In the
most recent DMB meeting, an applicant who works on Orchestra said they
believe Orchestra to be "in parallel development" but not part of
Ubuntu.  That applicant had uploaded some Orchestra packages, but only
very recently, so for packaging didn't meet "sustained" while for
coding would have (7 months), except that the applicant himself didn't
believe the coding to be a part of Ubuntu.  Again, it's back to "does
this thing Canonical's doing under a name other than Ubuntu still
count as part of Ubuntu, or is it just another upstream?"  That's
where we're getting stuck.  And then I guess you could add "should
Canonical-sponsored upstream projects be treated differently than
other upstream projects for purposes of Ubuntu Developer status?"

>  - And if they're not important than why do we have them? Why not just
> have a list of things you need to get membership for each step?
>  - When endorsing people do we have a hard rule about 6 months of contributions?

I think of "one cycle" as being kind of a minimum. I think most
successful applicants are actually involved for a year or more before
application.  If you're an amazing powerhouse of helpful energy
bouncing around, that might cut the 6 months down, but it'd also
result in board members expressing concern that you're going to
burnout before the next cycle's out. I think "slow & steady wins the
race" is relevant here.

-- 
Mackenzie Morgan