Re: RFC: Organizational Changes – Engineering Service
mmcgrath at redhat.com
Fri Feb 5 19:20:04 UTC 2010
On Fri, 5 Feb 2010, Toshio Kuratomi wrote:
> On Fri, Feb 05, 2010 at 12:07:19PM -0600, Mike McGrath wrote:
> > The problem is we have no such service organization for our OS. The work
> > gets done by the people that do it (this is good). Still, some things
> > fall through the cracks and you certainly can't mandate work to FESCo as
> > they have no facilities to do it and the FESCo members themselves can't be
> > expected to do it. So what I'm proposing is a new engineering service
> > team. People volunteer knowing they will be told what to do and offer
> > only their time and skill set. Suddenly FESCo has a directable resource.
> > So what would this team look like? There would be a basic signup process.
> > We'd come up with a few types of 'jobs' and possibly some job
> > descriptions. People would also put down exactly how many hours / week
> > they're willing and able to give and they would be accountable for that.
> > Those who can't keep up with what they said they could do get their hours
> > lowered to a level where they can. Those that aren't reliable would get
> > removed altogether.
> > This team would be managed (and I mean that in the literal sense) by a
> > couple of people and assign tasks to those who are free. During a release
> > we could have them do QA, we could have them write patches, we could have
> > them work with upstream. The key here is a couple of people sit at the
> > top and literally assign the tasks that come in to people.
> > We could stick 3 of them together to identify what they think are critical
> > bugs in our netbook installation process, then have 2 others fix it.
> > Infrastructure could provide resources when it's needed and FESCo could
> > help prioritize things that are critical because a freeze is coming up or
> > whatever.
> > The obvious flaw here is “will people volunteer?” I think they would. I
> > know I will.in
> question about implementation. You have heavy emphasis on managing the
> reousrces and people are being told what to work on. But in infrastructure
> which is heavily (but not entirely) service driven, I see more of a mix of
> tasks and people. We could be told to bring up a box to compose spins
> and we do it. We could be told to make a way to mark packages as being part
> of the critical path and we do it. OTOH we could be told that docs needs
> a CMS or our websites need a better search capability and we wait until
> someone with an interest in that work comes up to do it.
> Should we do something similar for this Serivce Branch? And should we have
> more structure around that then Infrastructure has?
I'm thinking in this group more structure in the process would allow us to
handle a wider range of tasks. By that I mean if the people requesting
and doing the work know what to expect from the process, they can both
plan it better. We should be flexable about this though as it very well
might not work.
For example, it's silly to assign a package review to someone that hates
it while someone that would enjoy it does nothing. I think that's sort of
a relationship thing we'd have to create with the team / manager(s).
> Another thought: by number, I think most of the non-OS groups are service
> oriented organizations but not all of them are doing as well as others.
> Infrastructure is pretty robust but we can't handle every service request
> that comes in. The design team does reasonably well. Releng seems like
> a rockstar although jwb gives most of the credit to a single person on the
> team which is not healthy long term. Websites, I think has a lot of
> interest but only a few core people who are doing most of the work. Docs
> produces great product but some of the service initiatives like wiki
> gardening and revamping the Packaging Guidelines are at a lesser level of
> completion. Can we learn something from how our teams are succeeding and
> failing currently so that this becomes a group that has:
> 1) A lot of volunteers that are engaged
> 2) A lot of happy volunteers
> 3) A high rate of success at doing tasks within a timeframe (like QA,
> patches, etc right before release).
> 4) Not dependent upon a single person to sink or swim.
> Talking about success and failure can also help get ideas on how our
> existing groups can improve, not just how to design the new group to be
> better than us.
The above is a good thing to keep in mind for any team and I think 1-4
would be possible for this team.
More information about the advisory-board