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 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 https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess, 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 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? 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. > 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? Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
-- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
