OGB 2008/010
From Genunix
Contents |
Community Simplification (draft)
The OpenSolaris community has asked the OGB to simplify governance so operations can move faster and better reflect how work actually gets done. There have been a few attempts at reorganization in the past, but the process is moving forward more consistently now with regular conversations taking place on ogb-discuss and in OGB meetings. The timing for this is perfect. The OpenSolaris Infrastructure Engineering Team is getting ready to start implementing a substantial upgrade of opensolaris.org involving a new webapp that will also support the OS/Net SCM gate migration. This infrastructure upgrade will take place in a series of steps, obviously, so governance changes ought to follow the same pattern and emerge over time.
So, to simplify governance and take advantage of the flexibility we'll soon have with the new opensolaris.org webapp, we suggest the initial community organization below. This is just a start, and we are intentionally starting small. We don't want to create too much structure where it's not needed because we'll have the ability to make adjustments as we see the effect of moving the development infrastructure outside. The proposal below pulls development and operations to the front, it decouples governance voting from community operations, and it cuts bureaucracy substantially.
Proposal 1: Community Group Clarification
Old Groups: Community Groups and Projects in a hierarchical relationship where CGs sponsor Projects.
New Groups: The new structure has four groups with no hierarchical relationships required. Also, we are simplifying "Community Group" to just mean "Group" as a general term describing all collectives. The four Groups include:
- Communities (may change this to SIGs): Social groups gathered around issues or technologies.
- User Groups: Groups of users gathered around issues or technologies in a specific geography.
- Projects: Development groups gathered around code repositories and integration tools.
- Electorate: Group of voting members of the overall OpenSolaris community.
New Groups are created using the Group Creation Process (specific proposal to be completed below in section 3).
Proposal 2: Governance Related Roles for People
Old Roles: Participant, Contributor, Core Contributor, Emeritus Contributor, Member, Facilitator.
New Roles: The new roles below are considered within the context of their particular collective type, or Group. Also, each person has one role within a Group.
1. Communities: Social groups gathered around issues or technologies. All roles except Participant have edit rights to web pages in their Community.
* Participant: Someone who participates in the activities of the Community. * Contributor: A Participant who has been acknowledged by the Community as having substantively contributed towards accomplishing the goals of that Community. * Leader: A Contributor elected by a Community to lead the Community.
2. Projects: Development groups gathered around code repositories and integration tools. All roles except Participant have edit rights to web pages in their Project.
* Participant: Someone who participates in the activities of a Project. * Contributor: A Participant who has been acknowledged by the Project as having substantively contributed towards accomplishing the goals of that Project and who has commit rights to any code repositories owned by the Project. * Leader: A Contributor elected by a Project to lead a Project.
3. User Groups: Groups of users gathered around issues or technologies in a specific geography. All roles except Participant have edit rights to web pages in their User Group.
* Participant: Someone who participates in the activities of a User Group. * Leader: A participant who leads and coordinates the activities of a User Group.
4. Electorate: The group of voting members of the overall OpenSolaris community.
* Member: Member of the Electorate group. By definition, a voting member of the OpenSolaris community. * Leader: A Participant of any of the above entities who has been elected to the OpenSolaris Governing Board (OGB) by the Members.
Proposal 3: Group Creation Process
The new Group creation process is unified (one process for all Groups) and simplified (one place to go to get a Group). Also, since the voting aspect of governance is now decoupled from community operations, there is no need for Core Contributor voting for Projects. Groups can associate with each other on their pages for the purposes of communication, but development Projects are no longer sponsored by Community Groups in a required hierarchical governance relationship.This change offers maximum flexibility for the community to self organize to get work done, and it offers new opportunities for people to create Groups quickly. So, if people want infrastructure for a new Group, they send mail to the OGB Resource Committee with a request, and if it's not rejected in a week, it's automatically created. The OGB will appoint volunteers to staff a Group creation alias (which is currently staffed by Linda, Eric, Jim). Proposals need to include the following: [insert x, w, and z requirements]. And all Groups are subject to all the opensolaris.org website policies [add links].
Proposal 4: Membership Process
If Groups want to promote Participants to Contributors, or if those Contributors desire to become Voting Members in the affairs of the overall community, they will have to follow the OGB Membership Committee's (TBD) specification for what that entails. In general, the question to become a Contributor is "What have you substantively contributed toward accomplishing the tasks of that Group?", and the question to become a Member is "Do you wish to play an active role in the governance of the community as a whole?"
Unfortunately, there is no one-size-fits-all definition for what it means to substantively contribute that works across every kind of Group - which is why we expect each group to define what "substantively" means in their context and have a way of acknowledging that someone has indeed done so.
The OGB Membership committee will have the final say on each group's definition because we want there to be equivalent levels of effort across the various Groups and we want their measures to be objective and repeatable. (And, yes, we expect there to be substantial sharing and reuse of definitions across the various Groups)
Once a group has an approved membership policy, the OGB (which does not at all want to be in the clerical business) is willing to delegate the "please make me a contributor and/or member of your Group" authority and ability to the facilitator(s) of that group. It will do that by adding the group's facilitator(s) to the Membership Committee, and by giving all of that committee's members the authority to use the make-a-new-contributor-or-member webapp tools.
Proposal 5: Group Management Processes
In order to be as consistent as possible across the community, the OGB requests that all groups have well defined public processes for managing the activities of their groups. These processes may include development methodologies, voting procedures, participation guidelines, record keeping, etc. The OGB publishes some key process documents outlining some key issues that groups can use or build from. These documents can be found at the OGB's website and they may be updated as the community's needs evolve.
Proposal 6: OpenSolaris Constitution 2009
A draft of the new OpenSolaris Constitution that brings together all the elements of the reorg and the new OGB processes.
