RFC: Organizational Changes – Engineering Service

Toshio Kuratomi a.badger at gmail.com
Fri Feb 5 19:07:20 UTC 2010


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.
> 
+1

> 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?

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.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/advisory-board/attachments/20100205/0faf363c/attachment.bin 


More information about the advisory-board mailing list