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

[Jeffrey Tadlock]

On Thu, May 15, 2008 at 7:56 PM, Jeff Spaleta <jspaleta at gmail.com> wrote:
> 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.
>
> 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.

Okay, I think your plan is starting to become more clear to me.
Essentially break things down into bite sized pieces via the SIGs.
Like you said it is less intimidating to join the Q&A efforts for
software that you know about and understand, than to possibly join at
the greater project level.

I think my concern is seeing things become too wrapped up in the
processes and roles and potentially adding layers of complexity.  In
some ways role based SIGs seem quite rigid.  Maybe they wouldn't be in
practice.

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

I am wondering if renewed work with the Fedora Mentors project could
accomplish some of the same goals in both recruitment and retainment?
The idea here being to get each SIG to have a member be a Fedora
Mentor as well.  The mentor can help new people get acclimated to the
project and help with retainment of contributors as well.

Then, we target the Fedora Mentor mailing list with the message that
its fine to get people to just do Q&A at the SIG level to help get
people used to it.  They can be guidance, but without the formality.

I do think attention needs paid to recruitment and retention issues
for contributors.  I just don't want to see us get too burdened down
with processes and such to accomplish the goals.

Thanks!
Jeffrey