#34 Differentiate between "SIGs" and "Teams"
Closed 2 years ago by rbowen. Opened 2 years ago by quaid.

We seem to have two different ways people need to organize, and only one term for them.

  1. A broad group of people looking to add or affect technical change in the project in some way. This group more closely adheres to the Wikipedia definition of a SIG as a "community within a larger organization with a shared interest in advancing a ... technology where members cooperate to affect or to produce solutions... and may communicate, meet, and organize..."

  2. A focused group of people working on a functional area of the project, who create processes and get things done. These might be called "teams" or something similar. There is a project history with that, the "Core Team" was used to describe the central group of people creating processes/`tools, and getting things done.

I'm thinking of this from a community architect perspective. Right now it's confusing how the one term fills two things. A SIG is "bring your own technology to integrate with CentOS" and also "the way we to contribute with skills to the project." It looks like a pretty high bar for someone who wants to help write some documentation or operate some infrastructure.

The intention is for potential contributors to more clearly see how they can get involved.

The actions here would be:

  • Agree there is a distinction.
  • Write up the distinction into the wiki/SpecialInterestGroup page.
  • Add a wiki page that describes what a team is, how to form one, how to join one.
  • Have groups look at themselves as they exist or are chartering, and be(come) the thing they really are.

OR

  • Decide it's not worth worrying about.

@rbowen I'm reassigning this idea to you, as the person who gets to choose what are the more important community architect tasks. I created this in response to some ongoing confusion. I feel a bit of responsibility as the person who suggesed/championed using SIGs as the term for the model in 2014. If I can help move this aspect of project communication and governance forward, let me know. Otherwise, you can archive or close this idea if you don't want to keep it open indefinitely because it's not higher on the priority list.

Metadata Update from @quaid:
- Issue assigned to rbowen

2 years ago

The board discussed this in the June meeting, and decided that this is a WONTFIX issue - we do not feel that any change is needed, and such a change would not clarify anything, and would, further, make historic documents confusing.

Closing.

Metadata Update from @rbowen:
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata