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

[Jeff Spaleta]

On Wed, May 14, 2008 at 2:52 PM, Stephen John Smoogen <smooge at gmail.com> wrote:
> EPEL would be a sub-project or a SIG?
EPEL would be a subproject, and quite likely a role that some SIGs
would want to carry.
I could certainly see a Scientific Computing SIG wanting to get EPEL
maintainers roles in place.

> PPC port would be a sub-project or a SIG? [The picture says
> sub-project.. but I want to confirm]

PPC would be a subproject.

>
> The next issue would be can people fill different roles: Mairin Duffy
> would hit multiple areas. I don't see anything in the proposal that
> says they can't but its long and I might have missed it.

No this isn't meant to say people can't wear multiple hats. Let me be
very clear on that. There is no inherent constraint here telling
people they can not be in multiple roles. Nor is there anything saying
that a SIG has to have X number of people in each role or less than Y
number of people in each role.  It's simply meant as a way to better
organize how we match existing human capital and develop potential
human capital to get the Fedora Project work done.  What this project
can do will forever be manpower bound.  There is never going to be a
lack of opportunity to contribute.

But we also have to make sure we don't overburden people by making
them feel they are doing too much of everything that is required for a
SIG to work.  It's real easy high impact people to over-extend and be
too involved as demands rise, and I don't want a project structure
that encourages that.  I want a structure that encourages recruitment
of new contributors to meet rising manpower demands as we raise the
quality and breadth of the work we do.  It's the difference between
positioning things so people feel valued versus feeling burdened. Its
the difference between feeling important and useful and feeling
critical and overworked.  I want to make sure we've got the right
support structures in place so when personal situations change for
individual volunteers and they have to roll back, or change how they
are volunteering their time, the work they were doing can continue
apace without any hard feelings.

We can help with that by defining some broadly common tasks that SIGs
all have to do, defining those tasks as a role, and creating a
subproject that supports the people in that role across all SIGs.

>
> The third issue is management. Each SIG and Sub Project would require
> their own management structure. Are they overlapping or are they
> complementary?  What size should they be and how do they map to an
> overall tree (some people hate trees, others require some knowledge of
> their local ape grooming structure to function.)

There's actually nothing new here in terms of organizational problems.
 We already sort of have this problem if you look across the landscape
now.  Basically I look at SIGs as being implementors of all the best
practices and Fedora project tools as applied to some portion of the
software landscape.  The subprojects are the groups that create those
best practices and tools.

So a documentation subproject would have a set of tools and best
practices on how to communicate important information.  A SIG, such as
a Robotics SIG would want a documenter role internal, whose task it
was to use those practices and tools and generate the release notes or
errata or whatever documentation content the Robotics SIG wants to see
to communicate the absolutely frelling awesomeness inherent in the
software it shepards. One of the inherent responsibilities of that
role would be to work as a member of the documentation subproject.
The same goes for a triager or packager or whatever common role we
want to define.  The SIG as a self-interest in encouraging the person
who takes on one of the roles to grow in expertise in that role by
being active in the subproject associated with that role to bring the
overall quality of the user experience up over time for all the
software the SIG wants to champion.

And th subprojects give a place for people to contribute that isn't
encapsulated as a SIG.  That's okay too.  If someone wants to help
with documentation tools,but doesn't have a particular set of software
they want to write release-notes for...thats absolutely fine.
Certainly we will still have a valid need for packagers who are
working outside of a SIG, but they may want to be involved in the a
packaging subproject or even a language specific subproject like one
for ruby or mono or even the very obscure python language that no one
uses.  But by going it alone, they'll lose the benefit of shared
workload that a SIG provides as they take on more and more packages.

We certainly can't draw nice neat circles around all the software in
the repository.  But we should encourage the formation of sustainable
SIGs when we can draw those sort of circles(overlapping circles are
okay too).  I want to encourage sustainable SIG building as a better
option to spread the work around as the overall amount of work being
done rises.

-jef