On Thu, Jun 2, 2011 at 2:58 AM, Erik Moeller <e...@wikimedia.org> wrote: > An alternative model is to have rotating teams that do this work. I > personally prefer the 20% model because it gives more > consistency/predictability and less churn, but I'm curious what other > folks think, and I'm comfortable with us continuing this discussion > openly on this list. > I don't think our tech dept is big enough to be able to do rotating teams. There are quite a few tasks that are the domain of 3 or fewer people, so some of those people need to be involved with service work all the time and can't really be rotated out of it.
I like the 20% model as well. It goes a little bit further than my suggestion, which was 20, 25 or 33% model for certain senior devs, but if you're volunteering to give me more than what I asked for that's even better :) . For numerous reasons, I think getting /everyone/ involved with service work is a great idea. There are two potential pitfalls that I think we should be aware of: * Since 20% == one day for full-time employees, they will probably tend to do all of their tasks on one day. Which is fine by me, as long as not everyone picks the same day :) (people might want to use their WFH day for this, and for most people that's Wednesday). So we should take care to spread this around a bit * The relative prioritization of service tasks should be focused on "what can you, as a staff member with your skills, do that a random volunteer dev couldn't?". This means review, deployment and shell bugs should be prioritized over bug triaging and fixing, because the former category requires specific skills or permissions that a lot of people don't have. There are more people out there that can triage and fix bugs, so while WMF staff should definitely continue doing that (some bugs are particularly mysterious and need a highly experienced dev to look at them) it shouldn't be at the expense of things like CR Related to resource allocation, and in response to Russ and Chad's comments, I agree that it would be good to have someone take the lead on releases and CR and such. Historically, this person has either been RobLa (general engineering EPM) or Mark H (Bugmeister), and they've only been coordinating as opposed to actively keeping an eye on review queues, merging revs, reviewing things that get left by the wayside, and so on. Maybe it's a good idea to designate one person as the leader and 'default' person (i.e. if you don't know who to assign something to, assign it to them and they'll either do it or get someone else to) for CR and branch management. That person should not be subject to the 20% rule, but should be spending as much time on it as is needed to get stuff done. This position could probably be rotated within the gen eng group. Roan Kattouw (Catrope) _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
