FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Advisory Board

 
 
LinkBack Thread Tools
 
Old 05-14-2008, 10:03 PM
"Jeff Spaleta"
 
Default Let's re-start a discussion about role-based SIGs

Okay now that F9 is out the door, and before I've voted out of office,
its time to take another stab at a discussion about building and
strengthening the abilities of role based SIGs inside the Fedora
projects moving forward.

I've come to picture the work the Fedora project needs to do as
structured in terms of two types of communities (I have to credit Greg
for some of the refinement on the image from the last round of
discussion about this a few months back). One such type of community I
would name "Subprojects". A subproject would be a group of peers who
are doing roughly the same things, and could be considered a guild for
a particular type of skilled labor. The other type of community I
would name "Special Interest Groups" (SIGS), and each SIG would
encompass all roles from users to developers that are needed to
sustain the growth of software usage and development for a particular
purpose.

Common tasks or experience define the membership of a Subproject
Common interests but different tasks and experience define the
membership of a role-based SIG.

SIG roles would map directly to subprojects. The idea being that
people from different SIGS who are doing the same sort of tasks can
establish best practices through discussion in the subprojects
associated with that role. For example we'd have a packaging
subproject, and each SIG should have members filling the package
maintainer role who were also participating in the packaging
subproject to learn and refine best practices. Same goes for
documentors, triagers and so-on.

But its not a one-to-one mapping. There would be needed Subprojects
which don't necessarily map to a common SIG role, but they would still
exist to get specific work done or to establish a peer group of
experts. I would hold up our infrastructure,translation and marketing
teams as an example of this type of Subproject construct, a Resource
Subproject.

They key idea is that for the role-based SIGs idea I am putting
forward, we turn the SIG concept deliberately into a construct that
encourages direct user participation, so that SIGs can more easily
recruit for their own expanding workforce needs their own by
connecting with users who are already interested in and using the
software in the scope of the SIG. Experienced, veteren SIG members
take on the role of mentoring and sponsoring new recruits.. and the
SIG becomes a self-sustaining community with the goal of growing the
capabilities of open software for a particular area of interest.

It is my very fervent belief that we need to build a recruitment and
retention program inside of the Fedora Project that encourages
enthusiastic users to become active contributors, and I think the
role-based SIG construct has the best potential of doing that.. we
just have to shake-up and tighten-up what we mean we we talk about a
SIG. And that is exactly what my role-based approach to SIG building
is meant to do.

Okay so I think that was close enough to a thousand words. Here's the
updated cartoon diagram of what I mean when I'm talking about
role-based SIGs:
http://jspaleta.fedorapeople.org/role-based-sigs/sig-teams.png


How would this impact our current teams? Some current SIGs would
simply be rebranded as Subprojects.
Some would decide they really are both a SIG and a subproject (Art for
example could easily be both)
For the SIGs that remain, they start identifying roles and 'we' find a
way to recruit poeple to fill those roles, and we start building ways
to connect users directly with SIGs.

But people have to want to run SIGs this way. They have to want to
turn SIGs into this sort of meeting places that encourages user
participation. Once people agree this is the way to structure things,
then we can start to re-enforce that structure.

-jef

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 05-14-2008, 10:52 PM
"Stephen John Smoogen"
 
Default Let's re-start a discussion about role-based SIGs

On Wed, May 14, 2008 at 4:03 PM, Jeff Spaleta <jspaleta@gmail.com> wrote:
> Okay now that F9 is out the door, and before I've voted out of office,
> its time to take another stab at a discussion about building and
> strengthening the abilities of role based SIGs inside the Fedora
> projects moving forward.
>
> I've come to picture the work the Fedora project needs to do as
> structured in terms of two types of communities (I have to credit Greg
> for some of the refinement on the image from the last round of
> discussion about this a few months back). One such type of community I
> would name "Subprojects". A subproject would be a group of peers who
> are doing roughly the same things, and could be considered a guild for
> a particular type of skilled labor. The other type of community I
> would name "Special Interest Groups" (SIGS), and each SIG would
> encompass all roles from users to developers that are needed to
> sustain the growth of software usage and development for a particular
> purpose.
>

To help me work on a conversation... would

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

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.

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




--
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 05-15-2008, 12:58 AM
"Jeff Spaleta"
 
Default Let's re-start a discussion about role-based SIGs

On Wed, May 14, 2008 at 2:52 PM, Stephen John Smoogen <smooge@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

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 05-15-2008, 05:33 PM
"Jeffrey Tadlock"
 
Default Let's re-start a discussion about role-based SIGs

On Wed, May 14, 2008 at 6:03 PM, Jeff Spaleta <jspaleta@gmail.com> wrote:
> They key idea is that for the role-based SIGs idea I am putting
> forward, we turn the SIG concept deliberately into a construct that
> encourages direct user participation, so that SIGs can more easily
> recruit for their own expanding workforce needs their own by
> connecting with users who are already interested in and using the
> software in the scope of the SIG. Experienced, veteren SIG members
> take on the role of mentoring and sponsoring new recruits.. and the
> SIG becomes a self-sustaining community with the goal of growing the
> capabilities of open software for a particular area of interest.
>
> It is my very fervent belief that we need to build a recruitment and
> retention program inside of the Fedora Project that encourages
> enthusiastic users to become active contributors, and I think the
> role-based SIG construct has the best potential of doing that.. we
> just have to shake-up and tighten-up what we mean we we talk about a
> SIG. And that is exactly what my role-based approach to SIG building
> is meant to do.

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?

Thanks!
Jeffrey

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 05-15-2008, 11:56 PM
"Jeff Spaleta"
 
Default Let's re-start a discussion about role-based SIGs

On Thu, May 15, 2008 at 9:33 AM, Jeffrey Tadlock
<jeffreyt@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

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 05-17-2008, 02:56 AM
"Jeffrey Tadlock"
 
Default Let's re-start a discussion about role-based SIGs

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

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 05-17-2008, 04:32 AM
"Jeff Spaleta"
 
Default Let's re-start a discussion about role-based SIGs

On Fri, May 16, 2008 at 6:56 PM, Jeffrey Tadlock
<jeffreyt@fedoraproject.org> wrote:
> 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.
My strawman cartoon includes mentors! and sponsors!

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

The processes are actually key. Because its the processes that we will
rely on over time. If we aren't building processes which reinforce
recruitment, then recruitment isn't going to happen in a serious way.

-jef

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 05-19-2008, 07:51 PM
"Paul W. Frields"
 
Default Let's re-start a discussion about role-based SIGs

On Fri, 2008-05-16 at 20:32 -0800, Jeff Spaleta wrote:
> On Fri, May 16, 2008 at 6:56 PM, Jeffrey Tadlock
> <jeffreyt@fedoraproject.org> wrote:
> > 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.
> My strawman cartoon includes mentors! and sponsors!
>
> > 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.
>
> The processes are actually key. Because its the processes that we will
> rely on over time. If we aren't building processes which reinforce
> recruitment, then recruitment isn't going to happen in a serious way.

Right, as in every other subproject, the key is finding enough process
to make sure we can scale this effort meaningfully, without creating so
much that people are bogged down to the point they can't do the work.
Interestingly, I think the recent reorientation of the Docs Project[1]
fits neatly into the role-based organization.

= = =
[1] http://www.redhat.com/archives/fedora-docs-list/2008-May/msg00032.html

--
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/
irc.freenode.net: stickster @ #fedora-docs, #fedora-devel, #fredlug
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 05-19-2008, 08:11 PM
"Jeff Spaleta"
 
Default Let's re-start a discussion about role-based SIGs

> Right, as in every other subproject, the key is finding enough process
> to make sure we can scale this effort meaningfully, without creating so
> much that people are bogged down to the point they can't do the work.
> Interestingly, I think the recent reorientation of the Docs Project[1]
> fits neatly into the role-based organization.

I wish I could make it to fudcon to have a pizza and beer session with
SIG and subproject reps concerning this. There really isn't a lot
here in terms of mandates or policies. I don't even need all of
projects to get on board initially for this to be profitable. I just
need enough people to be willing to try to work this way. And if its
beneficial then I expect other groups to try the role based idea.

-jef

_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 
Old 05-21-2008, 05:27 PM
"Karsten 'quaid' Wade"
 
Default Let's re-start a discussion about role-based SIGs

On Mon, 2008-05-19 at 12:11 -0800, Jeff Spaleta wrote:
> > Right, as in every other subproject, the key is finding enough process
> > to make sure we can scale this effort meaningfully, without creating so
> > much that people are bogged down to the point they can't do the work.
> > Interestingly, I think the recent reorientation of the Docs Project[1]
> > fits neatly into the role-based organization.
>
> I wish I could make it to fudcon to have a pizza and beer session with
> SIG and subproject reps concerning this. There really isn't a lot
> here in terms of mandates or policies. I don't even need all of
> projects to get on board initially for this to be profitable. I just
> need enough people to be willing to try to work this way. And if its
> beneficial then I expect other groups to try the role based idea.

My prediction -- you'll be surprised how many people will like the idea.

As much as we'd love to see ya at FUDCon, I don't think this is a
requirement for the role-based SIGs idea to move ahead.

People are always interested in making less mess and more grokking from
the chaos.

- Karsten
--
Karsten Wade, Sr. Developer Community Mgr.
Dev Fu : http://developer.redhatmagazine.com
Fedora : http://quaid.fedorapeople.org
gpg key : AD0E0C41
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board@redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
 

Thread Tools




All times are GMT. The time now is 09:18 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org