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