Let's re-start a discussion about role-based SIGs

[Jeff Spaleta]

On Thu, May 15, 2008 at 9:33 AM, Jeffrey Tadlock
<jeffreyt at fedoraproject.org> wrote:
> I want to be sure I understand the problem trying to be solved before
> commenting.  Is the problem trying to be solved encouraging and
> increasing direct user participation and contributions?  And then once
> we have that, a method in place to retain our contributors?

Yes the underlying goal for me is to structure how we do work so we
can more easily recruit and retain contributors.  And I think
restructuring how we expect our project to interact with users so that
users can more easily connect with people with the same software
interests is going to be the way to do it.

Let me harp on recruiting for a second.  So far we've been relying
significantly on people with a certain level of pre-existing
experience. I think to grow further we must start the process of being
able to train a larger pool of inexperienced but enthusiastic people
into become effective contributors and taking on some of the workload
we know we need to get done day-to-day and release-to-release.  And I
think we most easily do that by capitalizing on a new person's
particular software interests and make room for them inside a work
group (a SIG) organized around all the tasks associated with managing
the user-experience for a subset of software that matches why they are
using Fedora.  I want to build a structure that works like this:
Users find software they like or need, then they join the community
based around that software (the SIG) looking for help or advanced
training or just new information about upcoming versions, then they
start contributing to that community's effort to push that software
forward by responding to a SIGs specific need to fill one of the
easily defined roles. Experienced SIG members act as mentors and
sponsors for the new contributors.  The subproject that supports that
role participates in the training of the recruits across the different
SIGs.  As they get comfortable with that role the new person can
choose to become more involved in development of policies and tools as
part of the subproject that defines the best practices for  that role.
  If they find out their particular talents aren't suited for that
role, they can continue to work inside the SIG where there interests
lie, but take on a different role.  if there interest grows beyond a
specific SIG and wants to take on tasks with Project wide impact, they
can then look into participating in one of the support subprojects
like infrastructure, or translation.

For example, It'll be a lot easier to sucker someone into helping with
QA, if we make the QA effort a role that each SIG is encouraged to
fill internally from its userbase. Once SIGs establish a
user-communication aspect, a particular SIG should have an easier time
of asking its users to fill a QA role specifically for software the
SIG shepards.  Instead of the pain of asking users on a  project wide
to jump into a project wide QA effort spanning all software that they
are unfamiliar with.  Looking at things project-wide becomes daunting.
   But if we set things up in such a way that we can ask users to take
on a piece of the responsibility for the relatively small subset of
software they care about, through a SIG role, then its going to be a
lot easier to get them to take that first bite.  The same with
documenters, and maintainers and so on and so on.

The structure of the role based SIG also gives us the ability to start
looking at retainment issues, which we have put exceedingly little
thought into.  Formalizing the roles should make it easier for people
to move around and do new jobs, gaining new skills, when they are
getting burned out doing the same thing...but still within the scope
of software they are most interested in working with.

-jef