Re: New MOTU: Martin-?ric Racine (q-funk)
On Thu, Sep 10, 2009 at 05:20:21PM +0200, Daniel Holbach wrote: > Hello everybody, > > please join me in welcoming Martin-??ric Racine to the MOTU team. > > Have a great day, > Daniel Congrats Martin! -- 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 08, 2009 at 11:04:35AM -0800, Jordan Mantha wrote:
> On Thu, Jan 8, 2009 at 10:25 AM, Dustin Kirkland wrote:
> > On Thu, Jan 8, 2009 at 11:11 AM, Jordan Mantha
> > 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
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=0&sc=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
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=0&sc=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
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
Mutt launchpad bug coloring
Last week pitti gave a talk on setting up bug filters to get more use out of launchpad's emails. I've been following his method for some time, using the Mutt email client. One of Mutt's features is the ability to colorize bug titles based on sender, subject, or even body contents. I've found this quite handy for going through large queues of bug emails and quickly spotting important ones. Lines look like this: color index default green '~b "Status: .+ .+> Fix Released"' ^ ^ ^ ^-- regular expression | | +-- b=body, f=from, s=subject, etc. | +-- background color +-- foreground (font) color Here's an example .muttrc file similar to what I use: http://bryceharrington.org/files/lp-mutt-colors When using mutt's threaded view, you can quickly spot "patterns", like a series of emails ending in one green one usually means that bug got fixed, so you can skip over it. It's also useful in spotting replies on bugs you've worked on. Bryce -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Hosting and Vcs-* fields in packages modified from Debian
On Wed, Aug 20, 2008 at 10:51:58PM +0200, Loïc Minier wrote: > So where do you people host your branches? >* I could push to Alioth [2], but it's disturbing for many > reasons: > - not all Ubuntu people have accounts, and we would miss the >groups anyway > - use of Debian resources for Ubuntu; I feel I need permission >of the packaging project I'm forking from; not really >possible for packages in Ubuntu alone > - causes a dependency between Ubuntu data and Debian >infrastructure: e.g. Alioth is down and you can't commit :-/ For X, we're maintaining a git repos for xorg and xorg-server at Alioth. The Debian X folk have been helpful at sorting it out, and I gather are reasonably happy to have us on board using their VCS. They've even stepped in to help when there's been problems (and there's been a few, mostly due to my own lack of advanced git-fu). The only significant infrastructure interruption so far with Alioth that impacted my own work was back with that ssh key issue, but that was a pretty exceptional situation. Also note with git you can commit locally, and just hold off pushing if Alioth happened to be down. Bryce -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: About forwarding bugs and patches to Debian and documenting your changes
On Wed, Jun 18, 2008 at 09:44:56AM +0200, Lucas Nussbaum wrote: > For example, instead of: > + * debian/control: add missing libxext-dev build-dependency (fixes FTBFS). > You could write: > + * debian/control: add missing libxext-dev b-dep. See > +http://wiki.ubuntu.com/Changes/libext-dev > +Should be merged in Debian. For this last line, something terser would be preferrable and easier to synthetically parse (i.e. something that won't be likely to word-wrap). Bryce -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: A bug checklist
On Wed, Jun 04, 2008 at 01:30:25PM -0700, Brian Murray wrote: > I thought it might be helpful if we were to have a bug checklist of > > things to do with bug reports in any given state. Subsequently, Leann, > > Pedro and I drew one[0] up. My thought is that this is something that > anyone could have at their side when triaging bug reports. So while > there are a phenomenal number of things that could be done to a bug > > report our hope was to capture the most common ones. > > > > Please try using it as you are working on bug reports and provide > > feedback here or on the wiki page itself! > Looks pretty good. My only suggestion is that I'd like to see clarification of cases where bugs should be closed as Invalid. Bryce -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Till Kamppeter joined the MOTU team
Welcome aboard Till, great to have a printing guru in MOTU! :-) On Wed, Dec 12, 2007 at 08:22:40AM +0100, Daniel Holbach wrote: > Hello everybody, > > I'm please to let you know that Till Kamppeter, our printing guru joined > the MOTU team! > > Please give him a warm welcome to the team! > > Have a nice day, > Daniel > > > > -- > ubuntu-devel mailing list > [EMAIL PROTECTED] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
