On Wed, Jul 20, 2011 at 4:11 PM, Jorge O. Castro <[email protected]> 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 -- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
