Roles and Responsibilities Discussion
From Genunix
Contents |
Membership Levels
The following recognized levels of membership shall exist:
- Users/Everyone
- Community Member (aka: Observer): An observer (not to be confused with subscriber of the mailing list) of a community, a non-contributing (or unrecognized contributor) role.
- Contributer/Developer: A person who has, within his or her community, contributed in some "significant way" as to be worthy of being designated a developer. This role is specific only to a single community and as such a single person could potentially be a Developer in several different communities at the same time.
- Core Contrib/Developer (aka: Leader): A person who has contributed to such an extent as to be a leader of that community, sharing in the responsabilties and direction of that communities efforts.
- Leader: A singular person, one per community, that takes ownership and responsability for that community. This person acts as the interface to the OGB, ultimately approves and enacts any procedures within that community, a delgates responsability (such as an ARC liaison) within that community.
- OGB Member: A group of persons that handle all OpenSolaris responsabilities and duties/delgation that are outside the scope of a singular community. Such duties include despute resolution, approval and enactment of additional communities, etc.
sch: Various discussions I've been in have ended with Contributor being strongly preferred to Developer.
sch: The Leader role is not sufficiently flexible. I think that any Core Contributor can represent their Community in many of these roles.
Organisation
OpenSolaris shall be organised as a series of communities specific to diffrent areas of interest and functional responsability of OpenSolaris. Communities can include projects, commitees, sub-communities, etc. Projects (collaborative development structures) must be assigned to one and only one community. Creation and approval of projects are to be done within the appropriate community, approved by concensus of the Core Developers and the Community Lead. Each project (or subcommunity, etc) must at a minimum define one or more persons as leaders for that effort.
- [plocher]
- It would be good to think about how we can create a structure that reflects our procedural requirement to "develop bugfixes, rfe's and feature additions in a SCM environment that is distinct from a Project's master gate". Without such structure as a first-class concept, it becomes difficult to ensure that we proactively understand and approve all such changes, and processes such as the ARC have a difficult time fitting into the workflow.
- In Sun's internal nomenclature, a single source code repository is called a Consolidation. The collective noun for "the people and artifacts associated with a specific change to a consolidation" is a Project. Thus, the construction of a new version of the ON Consolidation involves the creation, execution, integration and dissolusion of hundreds of Projects. Sometimes, such as when a new feature is added (such as Zones), the effort to create, the resulting source code artifacts, and the team tasked with sustaining it are ALL called Projects; this certainly causes confusion :-)
sch: The restriction on projects isn't justified--why should we add a 1:1 restriction we don't have today? (By which I mean that large efforts have to meet the requirements and advance the position of many themes in the closed model Solaris used in the past, and am not referring to the current site.)
sch: I strongly discourage "sub-communities", at least in the context of arriving at a governance document.
OGB Elections
OGB Elections shall be handled in the following manner:
- The OGB shall be re-elected on an annual basis. No term limits shall exist.
- Nominations:
- Nomination for the OGB ballot shall be open to any person entitled to vote in the OGB election.
- Self-nomination is permitted. [Why not dis-allow self-nomination and skratch the second as redundant? -benr]
- Nominations must be seconded by another person eligible to vote.
- All persons recognized as a Contributor/Developer (or higher) shall have the right to a single vote.
- OGB Composition:
- The OGB shall consist of at least 5 persons.
- No more than 2/3rds of the OGB may be Sun employees.
- In the event that more than 2/3 of the elected OGB are Sun employees, an additional election shall be held among the remaining nominees who are not Sun employees to elect sufficient extra OGB members to correct the ratio. [This is problematic, growth of the OGB needs to be more controlled than this would allow -benr]
sch: Watching some of the long-lived committees at Sun, I would encourage a consecutive term limit (of somewhere between three to five years), because it promotes circulation, both of new people on, but also of former members back into direct contributor roles.
sch: The 2/3 composition restriction will be an issue, whether or not its asymmetry is repaired.
sch: As you note, the growth approach isn't the right way to handle composition. Once the top N seats are filled, the remaining seats go to candidates who are qualified (in this instance, by not being Sun employees).
"Bootstrapping"
Bootstrapping existing (pre-Governance) Communities. At such time that Governance is approved and enacted:
- Existing "Leaders" shall be deemed "Core Developers"
- Observers shall remain unchanged.
- The Core Developers shall elect amongst themselves, by means of a recorded vote which shall be reported to the OGB, a Project Lead.
- Core Developers will then have the ability to promote "Observers" to the designation of "Developer" or "Core Developer" by whatever means they choose, so long as the action is approved by the Community Lead and reported to the OGB.
- Each community shall maintain at all times a current public list of community observers, developers, core developers, the lead, and any other note-worthy persons within that communty. Maintaining such a list shall fullfill your need to report to the OGB.
sch: I believe that the various communities and consolidations will have to generate a list of Contributors; the existing Observer population isn't representative (because there is no functionality other than the declaration).
sch: Will probably want to have provisional dates relative to the election date. That is, all Contributor identifications must be in place 60 days prior to the election. Or somesuch.
sch: Will want a Committee for Contributiorship and Elections, rather than direct OGB reporting.
plocher: However the selection process is done, the roster of Core and regular contributers needs to be in formal lists maintained by the site tools similar to the way that leaders and observers are done today. The ARC community is going to need to include these people by reference in its discussions (i.e., the leaders of the Zones community instead of a hardcoded "joe, jack, brian, amy, sue...")
OGB Responsibilities
Responsabilities of the OGB:
- Approving and Bootstrapping new communities
- Resolving inter-community conflict
- Veto power, but only in the event that the OGB is unanimous in enacting such a veto.
- In general, handling all issues that are inappropriate for Community Leads.
- Fostering and promoting interaction, collaboration, and general direction within OpenSolaris as a whole.
- Fostering and sustaining appropriate relationships with other organisations
- Acting as the authritative and official interface between Sun and OpenSolaris
sch: Community management should be a committee.
sch: Scope of veto? Traditionally, the various development process entities rarely "reach down" to fix something; they get involved when an issue is escalated.
sch: I would expect the Board to handle most demotions and expulsions, as well.
