Re: Developer Application Criteria - Was Re: New Application processes
On Wed, Jan 7, 2009 at 3:46 PM, Bryce Harrington br...@canonical.com wrote: For improving the process just for the skill-level consideration, what I would like to see is sort of a self-directed exercise workbook, with sets of packaging, bug triage, testing, documentation, etc. tasks. For sponsorees with limited skill, this would provide guidance in gaining it. For sponsorees already with more than adequate skill, this would help them calibrate their own expectations. For sponsors, knowing that a candidate has gone through the workbook would help to answer that last bulletpoint, so they can focus on judging the others. Good idea, Bryce. I think this is along the lines of what I was suggesting, or at least certainly achieves the notion of 'self validation' before applying. :-Dustin -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Developer Application Criteria - Was Re: New Application processes
On Wed, Jan 7, 2009 at 6:22 PM, Robert Collins robe...@robertcollins.net wrote: I completely agree. MOTU and core-dev membership is a combination of * technical knowledge [for which two key points apply: arbitrary have-done-X metrics don't assess any more reliably than peer assessment of the work done, and the knowledge ages rapidly as technologies change. Packaging of python today is not the same as it was 5 years ago]. * trust - which is entirely subjective * fitting in the team - which can be assessed by who objects :) Okay, so I'll restate my point in another way ... If there is *no* objective component to MOTU/CoreDev application assessment, then I don't think it's fair to make arbitrary, *quantitative* criticisms on an application. Criticisms of the form: * You haven't done enough merges * You haven't touched enough Universe packages * You haven't been a MOTU or Developer long enough * You haven't ... enough ... should be invalid. These things are actually measurable, and we could very well set the value of enough. If we are consciously choosing *not* to set these values, I think it's totally unfair to criticize someone for not achieving these arbitrary, dynamic, mystery thresholds. :-Dustin -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Developer Application Criteria - Was Re: New Application processes
On Thu, Jan 8, 2009 at 11:16 AM, Dustin Kirkland kirkl...@ubuntu.comwrote: On Wed, Jan 7, 2009 at 6:22 PM, Robert Collins robe...@robertcollins.net wrote: I completely agree. MOTU and core-dev membership is a combination of * technical knowledge [for which two key points apply: arbitrary have-done-X metrics don't assess any more reliably than peer assessment of the work done, and the knowledge ages rapidly as technologies change. Packaging of python today is not the same as it was 5 years ago]. * trust - which is entirely subjective * fitting in the team - which can be assessed by who objects :) Okay, so I'll restate my point in another way ... If there is *no* objective component to MOTU/CoreDev application assessment, then I don't think it's fair to make arbitrary, *quantitative* criticisms on an application. Criticisms of the form: * You haven't done enough merges * You haven't touched enough Universe packages * You haven't been a MOTU or Developer long enough * You haven't ... enough ... should be invalid. These things are actually measurable, and we could very well set the value of enough. If we are consciously choosing *not* to set these values, I think it's totally unfair to criticize someone for not achieving these arbitrary, dynamic, mystery thresholds. I agree. In the same spirit of having a workbook, we could set guidelines and not hard fast rules. If we're going to have a workbook, we're setting some numbers anyhow. :-Dustin -- ubuntu-devel mailing list ubuntu-de...@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Cody A.W. Somerville Software Systems Release Engineer Custom Engineering Solutions Group Canonical OEM Services Cell: 506-449-5899 Email: cody.somervi...@canonical.com -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Developer Application Criteria - Was Re: New Application processes
On Thu, 8 Jan 2009 11:28:25 -0400 Cody A.W. Somerville cody-somervi...@ubuntu.com wrote: I agree. In the same spirit of having a workbook, we could set guidelines and not hard fast rules. If we're going to have a workbook, we're setting some numbers anyhow. We aren't and we shouldn't. The Debian NM question are interesting for people who want to self-assess, but we have a fundamentally different process in Ubuntu and that's a feature, not a bug. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Developer Application Criteria - Was Re: New Application processes
On Thu, Jan 8, 2009 at 7:16 AM, Dustin Kirkland kirkl...@ubuntu.com wrote: On Wed, Jan 7, 2009 at 6:22 PM, Robert Collins robe...@robertcollins.net wrote: I completely agree. MOTU and core-dev membership is a combination of * technical knowledge [for which two key points apply: arbitrary have-done-X metrics don't assess any more reliably than peer assessment of the work done, and the knowledge ages rapidly as technologies change. Packaging of python today is not the same as it was 5 years ago]. * trust - which is entirely subjective * fitting in the team - which can be assessed by who objects :) Okay, so I'll restate my point in another way ... If there is *no* objective component to MOTU/CoreDev application assessment, then I don't think it's fair to make arbitrary, *quantitative* criticisms on an application. I don't think that's necessarily a logical conclusion. You're saying that if the +1/-1 of a MOTU Council member is based on a subjective decision that they can't use objective data in making that decision. Criticisms of the form: * You haven't done enough merges * You haven't touched enough Universe packages * You haven't been a MOTU or Developer long enough * You haven't ... enough ... should be invalid. Why? There's no a priori reason to reject such reasons just because they are objective data. What you're really arguing against is that objective data is being used to make subjective decisions and I don't know why that would be a problem pre se. These things are actually measurable, and we could very well set the value of enough. If we are consciously choosing *not* to set these values, I think it's totally unfair to criticize someone for not achieving these arbitrary, dynamic, mystery thresholds. I very much doubt that enough could be easy to set. The fact of the matter is that each MOTU will see that differently, and the point of having a MOTU Council is to take in all the data and determine if enough has been met. If it was easy to do we'd just have a secretary go down a checklist to make MOTUs. My overall feeling with this thread is that perhaps we're attacking the wrong problem. People are wanting to reject the criteria and the subjectivity of a mostly subjective decision. I think rather the problem is that the MOTU team has lost its collective understanding of what being a MOTU is. The main argument has been my sponsors told me I was ready and I got rejected. I think there are some reasons why this could be happening: 1) as MOTU has scaled we've lost a lot of the connection to the whole. 2) contributors are perhaps not seeing as much of what does a MOTU actually do as it has gotten into a lot of paperwork type tasks rather than tackling tough packaging problems. 3) there is quite a bit of variability in the skill and experience level of MOTUs. We have old school MOTU who may have a fairly different view of what a MOTU should be from what a newly minted MOTU might think, for instance. 4) people seem to take the MOTU applications much more personal these days. rejected criticized seem to come up a lot when it's always been not yet, but keep trying. This perhaps is due to losing some of that Ubuntu Ethos Jono has been talking about. I think perhaps effort would be better spent trying to figure out how to make MOTU a *real* team again rather than trying to figure out how to objectify an essential subjective decision. People should be tapping into collective knowledge and understanding rather than reading page after page of docs and running through checklists. We should be a community rather than a MOTU mill. The self-assessment checklist might help people figure out what we're looking for but I'm afraid it would quickly turn into but I can do the checklist, you have to let me in. -Jordan -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Developer Application Criteria - Was Re: New Application processes
On Thu, Jan 8, 2009 at 10:25 AM, Dustin Kirkland kirkl...@ubuntu.com wrote: On Thu, Jan 8, 2009 at 11:11 AM, Jordan Mantha jordan.man...@gmail.com wrote: I don't think that's necessarily a logical conclusion. You're saying that if the +1/-1 of a MOTU Council member is based on a subjective decision that they can't use objective data in making that decision. That is not at all what I'm saying. I'm saying that if a given Council Member (or even an existing MOTU who feels compelled to give feedback on an application) makes a criticism of a given candidate, and that criticism is based on measurable, quantitative, objective data, then such an objective threshold should be established. If it's not going to happen at on a MOTU-wide basis, then, I'd hope the voting individual would take the initiative to define the threshold by which *they* are assessing applications. My issue is that threshold may be different on a case-by-case basis and from MC member to MC member. For instance a lack of experience in packaging from scratch could be compensated by a wealth of merge/sync experience and vice versa. However, I do think being more verbose as to why you think a person is not ready would be a good thing to do. Perhaps something more like: I'm giving this individual a -1 because they simply have not been a MOTU long enough to be considered for Core Dev. I believe that such an individual should be a MOTU for X months before applying for Core Dev. At that time, I will reconsider my vote. I don't think we can tell people how long they have to be a MOTU before applying to Core dev, it just depends on too many variables. On the other hand, a more subjective criticism would be: I believe this individual lacks maturity. or So-and-so is difficult to work with. Criticisms of the form: * You haven't done enough merges * You haven't touched enough Universe packages * You haven't been a MOTU or Developer long enough * You haven't ... enough ... should be invalid. Why? There's no a priori reason to reject such reasons just because they are objective data. What you're really arguing against is that objective data is being used to make subjective decisions and I don't know why that would be a problem pre se. It's a problem because different people are held to different standards (see ScottK's poignant comments). That's not a problem as I see it. That's why we elect the MOTU Council in the first place, we don't have nor should have an across the board, objective standard. If we see wildly different views of what it takes to be a MOTU lets hash that out, but it's still a personal decision on the part of each MOTU Council member. These things are actually measurable, and we could very well set the value of enough. If we are consciously choosing *not* to set these values, I think it's totally unfair to criticize someone for not achieving these arbitrary, dynamic, mystery thresholds. I very much doubt that enough could be easy to set. The fact of the matter is that each MOTU will see that differently, and the point of having a MOTU Council is to take in all the data and determine if enough has been met. If it was easy to do we'd just have a secretary go down a checklist to make MOTUs. I have never suggested that MOTU privileges be reduced to completing a checklist. That's ridiculous. Great, we agree. :-) I have suggested that a minority component of MOTU/CoreDev applications be based on some objective criteria. In place of such a process, I also believe that Bryce's suggestion of a workbook would mostly serve the same purpose. My problem is that this minority component will become the majority component because it will be the only objective criteria. Bryce's suggestion is probably helpful but we need to be careful about how we word/suggest it. My overall feeling with this thread is that perhaps we're attacking the wrong problem. People are wanting to reject the criteria and the subjectivity of a mostly subjective decision. I think rather the problem is that the MOTU team has lost its collective understanding of what being a MOTU is. The main argument has been my sponsors told me I was ready and I got rejected. I think there are some reasons why this could be happening: ... 4) people seem to take the MOTU applications much more personal these days. rejected criticized seem to come up a lot when it's always been not yet, but keep trying. This perhaps is due to losing some of that Ubuntu Ethos Jono has been talking about. These application process are inherently personal, when you're judged by your peers on entirely arbitrary and changing criteria. It should be neither arbitrary nor constantly changing. If what the MC is looking for is unclear please ask them for clarification. That is an orthogonal discussion to creating purely objective criteria for MOTU membership. I think perhaps effort would be better spent trying to figure out how to
Re: Developer Application Criteria - Was Re: New Application processes
On Thu, Jan 8, 2009 at 11:11 AM, Jordan Mantha jordan.man...@gmail.com wrote: I don't think that's necessarily a logical conclusion. You're saying that if the +1/-1 of a MOTU Council member is based on a subjective decision that they can't use objective data in making that decision. That is not at all what I'm saying. I'm saying that if a given Council Member (or even an existing MOTU who feels compelled to give feedback on an application) makes a criticism of a given candidate, and that criticism is based on measurable, quantitative, objective data, then such an objective threshold should be established. If it's not going to happen at on a MOTU-wide basis, then, I'd hope the voting individual would take the initiative to define the threshold by which *they* are assessing applications. Perhaps something more like: I'm giving this individual a -1 because they simply have not been a MOTU long enough to be considered for Core Dev. I believe that such an individual should be a MOTU for X months before applying for Core Dev. At that time, I will reconsider my vote. On the other hand, a more subjective criticism would be: I believe this individual lacks maturity. or So-and-so is difficult to work with. Criticisms of the form: * You haven't done enough merges * You haven't touched enough Universe packages * You haven't been a MOTU or Developer long enough * You haven't ... enough ... should be invalid. Why? There's no a priori reason to reject such reasons just because they are objective data. What you're really arguing against is that objective data is being used to make subjective decisions and I don't know why that would be a problem pre se. It's a problem because different people are held to different standards (see ScottK's poignant comments). These things are actually measurable, and we could very well set the value of enough. If we are consciously choosing *not* to set these values, I think it's totally unfair to criticize someone for not achieving these arbitrary, dynamic, mystery thresholds. I very much doubt that enough could be easy to set. The fact of the matter is that each MOTU will see that differently, and the point of having a MOTU Council is to take in all the data and determine if enough has been met. If it was easy to do we'd just have a secretary go down a checklist to make MOTUs. I have never suggested that MOTU privileges be reduced to completing a checklist. That's ridiculous. I have suggested that a minority component of MOTU/CoreDev applications be based on some objective criteria. In place of such a process, I also believe that Bryce's suggestion of a workbook would mostly serve the same purpose. My overall feeling with this thread is that perhaps we're attacking the wrong problem. People are wanting to reject the criteria and the subjectivity of a mostly subjective decision. I think rather the problem is that the MOTU team has lost its collective understanding of what being a MOTU is. The main argument has been my sponsors told me I was ready and I got rejected. I think there are some reasons why this could be happening: ... 4) people seem to take the MOTU applications much more personal these days. rejected criticized seem to come up a lot when it's always been not yet, but keep trying. This perhaps is due to losing some of that Ubuntu Ethos Jono has been talking about. These application process are inherently personal, when you're judged by your peers on entirely arbitrary and changing criteria. I think perhaps effort would be better spent trying to figure out how to make MOTU a *real* team again rather than trying to figure out how to objectify an essential subjective decision. People should be tapping into collective knowledge and understanding rather than reading page after page of docs and running through checklists. We should be a community rather than a MOTU mill. The self-assessment checklist might help people figure out what we're looking for but I'm afraid it would quickly turn into but I can do the checklist, you have to let me in. I disagree. Here's an analogy... You want to attend XYZ private university. They're a private institution, so they can accept whoever they want. In fact, most of the decision will be subjective. However, before you get to that point, you have to meet some objective goals. * You have to have a high school diploma. * You have to have some minimum SAT/ACT test score * You must have earned some minimum GPA. Meeting the minimum objective criteria is clearly not enough. That expectation is well established by your high school guidance counselors (ie, mentors). But, you know what you have to do before you even apply. And once you've met these minimum expectations, the university's admissions board will evaluate the application in toto, taking into account all sorts of qualitative considerations (extracurricular activities, sports, essays, family history with the school,
Re: Developer Application Criteria - Was Re: New Application processes
On Thu, Jan 8, 2009 at 1:14 PM, Bryce Harrington br...@canonical.com wrote: On Thu, Jan 08, 2009 at 11:04:35AM -0800, Jordan Mantha wrote: On Thu, Jan 8, 2009 at 10:25 AM, Dustin Kirkland kirkl...@ubuntu.com wrote: On Thu, Jan 8, 2009 at 11:11 AM, Jordan Mantha jordan.man...@gmail.com wrote: I don't think that's necessarily a logical conclusion. You're saying that if the +1/-1 of a MOTU Council member is based on a subjective decision that they can't use objective data in making that decision. I didn't read Dustin's comments that way. I took it to mean, if the council members are making decisions based on objective data, they should be utilizing that data more consistently and predictably. OK, I can understand that desire. If I understand his point correctly, it's that if I tell person A, You need to hit the ball into the outfield 10 times before you can be on the team, and person B, Nevermind hitting the ball, I like you, you're on the team, that's inconsistent. It could also undermine the establishment of team mentality - A will always wonder why they had to meet this arbitrary critera when B didn't. Even B may feel some inferiority because they got in through favoritism rather than proving themselves like A. It could affect the other teammembers too - if you know all your teammates have proven they have the same level of confidence, you'll have more trust in them than you would otherwise. OK, right. I think that is a very valid concern and something I feel is an existing issue. However, I feel like proposal in the thread is the way to fix that. The issue is not making things more objective but in making the decisions more transparent. I would completely support a push to make the MOTU Council be more verbose when issuing a -1 (and even +1 votes). Perhaps the MOTU Council could use a voting template where they can comment on specific areas of the application. My objection is about trying to objectify and/or quantify an inherently subjective process. The point (as I see it) is not so much whether you have to hit a ball so many times to get on the team, but rather if such criteria are being applied, that they be done consistently and predictably. If I want to become a MOTU and I saw that person A had to do 10 ball hits, and I practice up to 12, then if I apply and they surprisingly ask me to do *20*, I'm obviously going to be upset. And on the other hand, if they ask me to only do 5, I might not be upset but might wonder WTF is up. In this case it may depend on whether they were balls thrown by a Little League pitcher, pitching machine, or MLB pitcher. People shouldn't be comparing numbers unless they have the whole picture. However, if you had to hit 20 balls from the same pitcher that sombody else only had to do 10 then yeah, that's an issue. That's the sort of thing we need to address, not arguing over how many balls to hit. Where I think Dustin and I differ slightly, is he'd like to see the number more explicitly stated, whereas I'd favor being more hand-wavy and say, Demonstrate that you know how to play ball, and provide some generic tips on how one would do that. My issue is that threshold may be different on a case-by-case basis and from MC member to MC member. For instance a lack of experience in packaging from scratch could be compensated by a wealth of merge/sync experience and vice versa. This is my thinking exactly. If someone is a great pitcher, it may be okay if they can't hit the ball as well as others. They know how to play ball. Or, someone may not have the greatest game play skill, but they have great team spirit and their presence on a team just makes that team pull together and work that much better. That individual may not be able to hit the ball well, nor pitch, but when they're playing, the team wins much more often than not. Even in this case you'd still expect them to demonstrate that they know how to play. The main thing is being trustworthy with the archive (know how to play). We don't expect people to be packaging geniuses or uber programmers, but we expect people to know the basics and know when to get help/ask. But of course it's not easy to quantify these social/subjective things. I have suggested that a minority component of MOTU/CoreDev applications be based on some objective criteria. In place of such a process, I also believe that Bryce's suggestion of a workbook would mostly serve the same purpose. My problem is that this minority component will become the majority component because it will be the only objective criteria. Bryce's suggestion is probably helpful but we need to be careful about how we word/suggest it. This would also be my concern. When you have to make a decision on both factual and emotional data, and the facts are clearly stated, it can be easy to be mentally lazy and make a snap decision on just that set of data. But I think this is not an argument against
Re: Developer Application Criteria - Was Re: New Application processes
On Thu, Jan 08, 2009 at 11:04:35AM -0800, Jordan Mantha wrote:
On Thu, Jan 8, 2009 at 10:25 AM, Dustin Kirkland kirkl...@ubuntu.com wrote:
On Thu, Jan 8, 2009 at 11:11 AM, Jordan Mantha jordan.man...@gmail.com
wrote:
I don't think that's necessarily a logical conclusion. You're saying
that if the +1/-1 of a MOTU Council member is based on a subjective
decision that they can't use objective data in making that decision.
I didn't read Dustin's comments that way. I took it to mean, if the
council members are making decisions based on objective data, they
should be utilizing that data more consistently and predictably.
I should point out that my own opinion on this is probably not very
valuable, as I've not been much involved in the MOTU process. I'd also
add that in my own application and those I've sponsored, I never saw a
problem with how decisions were being made. However, I'm assuming from
the existance of this thread that others have seen an actual problem,
and so all my comments should be taken as a completely outsider
viewpoint.
If I understand his point correctly, it's that if I tell person A, You
need to hit the ball into the outfield 10 times before you can be on the
team, and person B, Nevermind hitting the ball, I like you, you're on
the team, that's inconsistent. It could also undermine the
establishment of team mentality - A will always wonder why they had to
meet this arbitrary critera when B didn't. Even B may feel some
inferiority because they got in through favoritism rather than proving
themselves like A. It could affect the other teammembers too - if you
know all your teammates have proven they have the same level of
confidence, you'll have more trust in them than you would otherwise.
The point (as I see it) is not so much whether you have to hit a ball so
many times to get on the team, but rather if such criteria are being
applied, that they be done consistently and predictably. If I want to
become a MOTU and I saw that person A had to do 10 ball hits, and I
practice up to 12, then if I apply and they surprisingly ask me to do
*20*, I'm obviously going to be upset. And on the other hand, if they
ask me to only do 5, I might not be upset but might wonder WTF is up.
Where I think Dustin and I differ slightly, is he'd like to see the
number more explicitly stated, whereas I'd favor being more hand-wavy
and say, Demonstrate that you know how to play ball, and provide some
generic tips on how one would do that.
My issue is that threshold may be different on a case-by-case basis
and from MC member to MC member. For instance a lack of experience in
packaging from scratch could be compensated by a wealth of merge/sync
experience and vice versa.
This is my thinking exactly. If someone is a great pitcher, it may be
okay if they can't hit the ball as well as others. They know how to
play ball.
Or, someone may not have the greatest game play skill, but they have
great team spirit and their presence on a team just makes that team pull
together and work that much better. That individual may not be able to
hit the ball well, nor pitch, but when they're playing, the team wins much
more often than not. Even in this case you'd still expect them to
demonstrate that they know how to play.
I have suggested that a minority component of MOTU/CoreDev
applications be based on some objective criteria. In place of such a
process, I also believe that Bryce's suggestion of a workbook would
mostly serve the same purpose.
My problem is that this minority component will become the majority
component because it will be the only objective criteria. Bryce's
suggestion is probably helpful but we need to be careful about how we
word/suggest it.
This would also be my concern. When you have to make a decision on both
factual and emotional data, and the facts are clearly stated, it can be
easy to be mentally lazy and make a snap decision on just that set of
data. But I think this is not an argument against having clear facts,
but rather an argument against being mentally lazy. ;-)
But I definitely agree that care in phrasing is important. You're not
going to be tested on any of this, and we certainly don't expect you to
know *everything*, but we think the more familiar you are with the
following, the better a MOTU/CoreDev you'll make...
A final point that I'm wondering is how often are people rejected
because of purely objective criteria? It seems to me that most people
are rejected based on things more like:
* immature understanding of Ubuntu
* doesn't play well with others
* lacks overall packaging experience
As someone who has not really been involved with the MOTU decisions, I'd
love to see some data on this. Not names or specific instances, just a
summary of like, # times someone was explicitly critiqued/judged on
{time involved, amount of uploads, packaging tasks done, etc.},
regardless of whether they ended up being accepted or not.
If it turns
Developer Application Criteria - Was Re: New Application processes
On Wednesday 07 January 2009 13:22, Daniel Holbach wrote: Dustin Kirkland schrieb: I really believe the MOTU and Core-Dev application processes would greatly benefit from some minimal, objective criteria. It should be perfectly clear that meeting these objective criteria will not be sufficient, alone, to achieve MOTU/Core-Dev. However, I think there absolutely must be something more objective for an aspiring MOTU/CoreDev to achieve before taking the time/effort to apply. Please let's have a separate discussion about the criteria, requirements and expectations of new Ubuntu developers. The proposal the MOTU Council put on the table is only about how we deal with applications that come in. Thanks in advance, Daniel OK. Now it's a separate discussion. I concur with Dustin's observations about some people getting caught up in arbitrary requirements. I'd go the other way though. I don't think there is any need for X uploads, Y months as a MOTU before applying for core-dev, etc. I think applicants should be judged on what they've done, how well they are integrated into the community and trusted to do the right thing, and what they potential for future contribution is. I think that the problem is people making up criteria that aren't actually rules and then treating them like rules. Using Dustin's case as an example, how can we possibly set a fraction of uploads that must be Universe packages? If you have 30% Universe uploads you may not apply for MOTU and must wait until you are ready to apply for core-dev People like quantitative criteria because they can be applied without judgement and with no perception of bias. Everyone has to wait 6 months, so it's not unfair we say you need to wait too. I really think that our process is about developers judging the person ready to become a developer and anything more specific we try to require will end up being problematic. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Developer Application Criteria - Was Re: New Application processes
On Wed, Jan 07, 2009 at 02:18:09PM -0500, Scott Kitterman wrote: On Wednesday 07 January 2009 13:22, Daniel Holbach wrote: Dustin Kirkland schrieb: I really believe the MOTU and Core-Dev application processes would greatly benefit from some minimal, objective criteria. It should be perfectly clear that meeting these objective criteria will not be sufficient, alone, to achieve MOTU/Core-Dev. However, I think there absolutely must be something more objective for an aspiring MOTU/CoreDev to achieve before taking the time/effort to apply. I concur with Dustin's observations about some people getting caught up in arbitrary requirements. I'd go the other way though. I don't think there is any need for X uploads, Y months as a MOTU before applying for core-dev, etc. I think I understand where Dustin is coming from - I too had a similar reaction when going through the MOTU/CoreDev processes. It has sort of a You're ready when you know you're ready zeitgeist, which is fine and good, but come on, how do I know when I'm ready? :-) Now as a sponsor, if I had to explicitly list give considerations for a candidate, it might look something like this: * Trustworthiness * Carefulness * Experience * Maturity * Desire * Skill The first five are obviously subjective, and not something that can really be boiled down to a checklist of requirements or anything. Indeed, a set of rules could end up overweighting considerations of skill vs. the other items. In my own case, I put much higher expectations on myself for packaging skill level than probably were necessary in hindsight. I really had no idea what my sponsors or the board would be expecting in terms of skill, so went way overboard in studying packaging intricacies and esoteric details (which subsequently has helped me quite a bit in my work, but added a lot of delay in my process, particularly coupled with the lengthy application process itself). For improving the process just for the skill-level consideration, what I would like to see is sort of a self-directed exercise workbook, with sets of packaging, bug triage, testing, documentation, etc. tasks. For sponsorees with limited skill, this would provide guidance in gaining it. For sponsorees already with more than adequate skill, this would help them calibrate their own expectations. For sponsors, knowing that a candidate has gone through the workbook would help to answer that last bulletpoint, so they can focus on judging the others. Bryce -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Developer Application Criteria - Was Re: New Application processes
On Wed, 2009-01-07 at 14:18 -0500, Scott Kitterman wrote: People like quantitative criteria because they can be applied without judgement and with no perception of bias. Everyone has to wait 6 months, so it's not unfair we say you need to wait too. I really think that our process is about developers judging the person ready to become a developer and anything more specific we try to require will end up being problematic. I completely agree. MOTU and core-dev membership is a combination of * technical knowledge [for which two key points apply: arbitrary have-done-X metrics don't assess any more reliably than peer assessment of the work done, and the knowledge ages rapidly as technologies change. Packaging of python today is not the same as it was 5 years ago]. * trust - which is entirely subjective * fitting in the team - which can be assessed by who objects :) Someone having done a certain number of bug reports or new packages or merges is not a replacement for peer assessment; if anything it makes joining MOTU harder because rather than just demonstrating the required capabilities and personal attributes folk interested in joining would now have a number of tick-box things to complete, which are neither necessary nor sufficient for demonstrating that they are ready to become a MOTU or core dev. -Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Developer Application Criteria - Was Re: New Application processes
On Wed, 2009-01-07 at 13:46 -0800, Bryce Harrington wrote: For improving the process just for the skill-level consideration, what I would like to see is sort of a self-directed exercise workbook, with sets of packaging, bug triage, testing, documentation, etc. tasks. For sponsorees with limited skill, this would provide guidance in gaining it. For sponsorees already with more than adequate skill, this would help them calibrate their own expectations. For sponsors, knowing that a candidate has gone through the workbook would help to answer that last bulletpoint, so they can focus on judging the others. I think this is a good idea. -Rob -- GPG key available at: http://www.robertcollins.net/keys.txt. signature.asc Description: This is a digitally signed message part -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Developer Application Criteria - Was Re: New Application processes
On Wed, Jan 07, 2009 at 07:44:16PM -0500, Scott Kitterman wrote: On Wednesday 07 January 2009 19:24, Robert Collins wrote: On Wed, 2009-01-07 at 13:46 -0800, Bryce Harrington wrote: For improving the process just for the skill-level consideration, what I would like to see is sort of a self-directed exercise workbook, with sets of packaging, bug triage, testing, documentation, etc. tasks. For sponsorees with limited skill, this would provide guidance in gaining it. For sponsorees already with more than adequate skill, this would help them calibrate their own expectations. For sponsors, knowing that a candidate has gone through the workbook would help to answer that last bulletpoint, so they can focus on judging the others. I think this is a good idea. Here's a good list of questions for the workbook: http://svn.debian.org/wsvn/nm/trunk/nm-templates/?rev=0sc=0 Wow, yes that's definitely a good list, exactly the type of questions I'd think should go into such a workbook. Some might be better done as hands-on tasks than as essay questions, but that's pretty much what I was thinking. Even if we didn't put together a workbook ourselves, I think it would be a great idea to reference these Debian pages from the MOTU/CoreDev process docs. Often half the work in climbing the packaging learning curve is knowing what the questions are, and this gives that. Thanks, Bryce -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Developer Application Criteria - Was Re: New Application processes
Scott Kitterman wrote: On Wednesday 07 January 2009 13:22, Daniel Holbach wrote: Dustin Kirkland schrieb: I really believe the MOTU and Core-Dev application processes would greatly benefit from some minimal, objective criteria. It should be perfectly clear that meeting these objective criteria will not be sufficient, alone, to achieve MOTU/Core-Dev. However, I think there absolutely must be something more objective for an aspiring MOTU/CoreDev to achieve before taking the time/effort to apply. Please let's have a separate discussion about the criteria, requirements and expectations of new Ubuntu developers. The proposal the MOTU Council put on the table is only about how we deal with applications that come in. Thanks in advance, Daniel OK. Now it's a separate discussion. I concur with Dustin's observations about some people getting caught up in arbitrary requirements. I'd go the other way though. I don't think there is any need for X uploads, Y months as a MOTU before applying for core-dev, etc. I think applicants should be judged on what they've done, how well they are integrated into the community and trusted to do the right thing, and what they potential for future contribution is. I think that the problem is people making up criteria that aren't actually rules and then treating them like rules. Using Dustin's case as an example, how can we possibly set a fraction of uploads that must be Universe packages? If you have 30% Universe uploads you may not apply for MOTU and must wait until you are ready to apply for core-dev People like quantitative criteria because they can be applied without judgement and with no perception of bias. Everyone has to wait 6 months, so it's not unfair we say you need to wait too. I really think that our process is about developers judging the person ready to become a developer and anything more specific we try to require will end up being problematic. Scott K I currently have an application which has been in progress for about a month now. Perhaps views from someone like me might help. I don't believe that there should be any set criteria based on total uploads, or which archive you upload to. I like what Scott said about the process is about developers judging if the person is ready. On the four points made by Daniel, I can agree with all but the fourth being beneficial. The reason that different Membership Boards were created was to allow those that are unable to attend CC meetings to still apply for membership. Doing something like this isn't quite as reasonable with developer applications, and as such it may become very difficult for people to make it to the meetings. I am in this position. Perhaps what could work is that the process is kept to email. Everything which Daniel suggested can be done here, with links to wiki pages (where sponsorship feedback could be left) etc. From there, the meetings can take place, and the MC can decide whether or not to accept an application there, meaning that the developer who is applying does not have to be there, but of course could be. Thanks, Nick -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Developer Application Criteria - Was Re: New Application processes
On Wed, Jan 07, 2009 at 08:59:24PM -0500, Scott Kitterman wrote: On Wednesday 07 January 2009 20:46, Bryce Harrington wrote: On Wed, Jan 07, 2009 at 07:44:16PM -0500, Scott Kitterman wrote: On Wednesday 07 January 2009 19:24, Robert Collins wrote: On Wed, 2009-01-07 at 13:46 -0800, Bryce Harrington wrote: For improving the process just for the skill-level consideration, what I would like to see is sort of a self-directed exercise workbook, I think this is a good idea. Here's a good list of questions for the workbook: http://svn.debian.org/wsvn/nm/trunk/nm-templates/?rev=0sc=0 Wow, yes that's definitely a good list, exactly the type of questions I'd think should go into such a workbook. Some might be better done as hands-on tasks than as essay questions, but that's pretty much what I was thinking. I don't think we want to recreate the Debian NM process in Ubuntu. Certainly not. Who'd want to grade these after all... But for *self-assessment* purposes, particularly for people who will be serving in a heavily packaging-oriented role, these give good guidance for honing ones' skills. Bryce -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Developer Application Criteria - Was Re: New Application processes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scott Kitterman schrieb: On Wednesday 07 January 2009 20:46, Bryce Harrington wrote: On Wed, Jan 07, 2009 at 07:44:16PM -0500, Scott Kitterman wrote: Here's a good list of questions for the workbook: http://svn.debian.org/wsvn/nm/trunk/nm-templates/?rev=0sc=0 Wow, yes that's definitely a good list, exactly the type of questions I'd think should go into such a workbook. Some might be better done as hands-on tasks than as essay questions, but that's pretty much what I was thinking. Even if we didn't put together a workbook ourselves, I think it would be a great idea to reference these Debian pages from the MOTU/CoreDev process docs. Often half the work in climbing the packaging learning curve is knowing what the questions are, and this gives that. I don't think we want to recreate the Debian NM process in Ubuntu. If people want to look at them, I think it's fine, but I think it should have no part of our process. Definitely agreed. The workbook should help a lot in finding out how well you know our development world. We should refer to it in our documentation a bit more. What I like about Ubuntu and the way we see if someone is ready is a lot about did they get a lot of stuff done? and did they work well with others?. Recreating Debian NM in Ubuntu would probably shift the focus. Have a great day, Daniel - -- My 5 today: #308669 (tomboy), #314367 (gcalctool), #314540 (gnome- session), #314371 (gtksourceview2), #314163 (gedit-plugins) Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkllrhkACgkQRjrlnQWd1etVQgCeI+3SJj/gcj7wJltJPy0R7JWV 2EYAn0kDxGftaTdeRvS84kbnMZlNMJb7 =2t2I -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
