RFC: Organizational Changes – Engineering Service

Paul W. Frields stickster at gmail.com
Wed Feb 10 22:25:14 UTC 2010


On Mon, Feb 08, 2010 at 10:12:35AM -0600, Mike McGrath wrote:
> On Sun, 7 Feb 2010, Paul W. Frields wrote:
> 
> > On Fri, Feb 05, 2010 at 12:21:38PM -0900, Jeff Spaleta wrote:
> > > On Fri, Feb 5, 2010 at 9:07 AM, Mike McGrath <mmcgrath at redhat.com> wrote:
> > > > The obvious flaw here is “will people volunteer?” I think they would.  I
> > > > know I will.
> > >
> > > This is very good...and its straight out of the volunteer coordination
> > > handbook I was pimping a few FPL's back.
> > >
> > > A few comments.
> > >
> > > When people sign up... don't just ask for hours a week.. ask for a
> > > specific long term time commitment...like a 6 month tour of duty.
> > > Make a huge deal out of new people signing up for their first tour of
> > > duty. Make a huger deal of team veterans reaffirming their role as
> > > engineering task monkey for additional tours.  Since this team is a
> > > service team and won't be as self-directed..its important to shift the
> > > reward balance to overt recognition.  We tend to reward our current
> > > volunteers groups with self-directed control of their area of work and
> > > we can't do that effectively for a service team that reports to fesco.
> > >
> > > Also...try to communicate the initial skillset needed in the team. If
> > > fesco could sort of roadmap what they think they'd like to see built
> > > in say the next 6 months...break that down into anticipated skills and
> > > manhours.. you can try to recruit for that anticipated need to fill in
> > > the skill gaps for a new project.  You can't anticipate all desirable
> > > skills and experience ahead of all possible tasking of course. But you
> > > want to recruit a certain baseline of experience and keep the tasking
> > > inside that skillset pool as much as you can. Big new tasks with
> > > unanticipated skill needs can be pushed back into the next tour of
> > > duty and highlighted in a recruitment call-to-arms.
> > >
> > > And...along the way create some opportunities to broaden the skillset
> > > of team members. A service team like this could be the perfect target
> > > for specialized team members only classroom skills training.
> >
> > The crux of the biscuit[1] is breaking down a task in a way that lets
> > a volunteer know whether they have the skills needed to work on that
> > task.  That's not impossible or even that difficult, but it does
> > require some work -- which is why having someone managing that
> > process, i.e. responsible for the breakdown -- is important.  Saying
> > "I need help accomplishing this large task" is not as helpful as
> > saying, "I need help accomplishing this large task, which consists of
> > the following four procedures, listed below with the knowledge,
> > skills, and abilities you'll need to have to do them."  The investment
> > of time to list those elements out is worthwhile if the task is
> > honestly something that really needs to be managed over a period of
> > time.
> >
> > I like the idea, Mike; does this thinking jibe with what you had in
> > mind?
> >
> 
> It does.  I think for the volunteers to actually feel valuable in a team
> like this they need to be given tasks they can complete on their own but
> also challenges them to apply new skills.  You can't do that by dumping
> some large task on them.  To judge such things communication is just as
> essential as planning the parts that make up the whole task.  I suspect,
> though, that there will also be lots of tiny tasks to do.

Mike and I talked about this very briefly on IRC and we both agree
this is an idea worth trying, and that it's just a matter of "JFDI."*

I have to say, if I was a contributor to Fedora who had more of a free
reign on how I spent my time, this is the sort of thing I'd love to be
involved in.

* Jedis are Free to Dive In. ;-)

-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
          Where open source multiplies: http://opensource.com


More information about the advisory-board mailing list