Website Transition: Roles & Collectives

 The new website infrastructure is designed for flexibility so changes can be made if/when a new Constitution is ratified and to better enable collectives to manage themselves. A set of collectives is defined, and within each collective, a set of roles is defined. The information is then used and interpreted by the applications that run on the opensolaris.org website. And the new user management application (auth.opensolaris.org) allows for Single Sign On across those applications.

 The role a person has within a collective will determine his/her privileges related to different functional areas of the community. The roles and privileges outlined below are associated with primary functionality on the site: access to website pages, access to source code repositories and the administration of collectives. Other applications running on the site can also use and interpret the roles.

 See the Data Migration page for detail about how data was migrated from existing data sources to the new Auth database.

Three types of collectives are supported:

  • Community Group: Social group whose members engage in open conversations, that endorses technical projects and that has representation in the governance process. Defined in detail in the OpenSolaris Constitution. A Community Group approves the creation of a new Project. The Community Group that approves a Project's creation is noted in the database as the Community Group that "sponsors" the Project. Only one Community Group approves a Project's creation. Note that other Community Groups will be able to associate with a project for communication, overlap of technologies or work, demonstration of associated technologies, etc. This association will preserve the current situation where multiple Community Groups 'endorse' a single project. Such Community Groups will be noted in the database as being "associated with" a Community Group.
  • Project: Collaborative technical effort. Mentioned briefly in the OpenSolaris Constitution. Projects are initially approved by one Community Group at the time of creation.
  • User Group: Independently-run group that advocates for OpenSolaris. Not mentioned at all in the OpenSolaris Constitution.

 Within the database, there is also an entity called an Electorate. Within that entity, governance data (currently people with voting privileges, Community Group Facilitators, and grant data about Community Group Contributors and Core Contributors) is stored for each Community Group Electorate.

Website Infrastructure Architecture

 The following outlines the implementation detail with regard to roles and the associated primary privileges for editing the website (XWiki), accessing source code repositories (SCM console) and administering collectives. In addition, the detail associated with Community Group Electorates is outlined. As noted above, other applications running on the site can also assign privileges to the roles for use within that application.

Community Group

PARTICIPANT

  • Anyone registered on the site who declares him/herself to be a Participant of the Community Group via the Auth app. A Leader in the Community Group can also assign this role.
  • Website privileges:
    • Person can comment on Community Group web pages.

AFFILIATE

  • Community Group Leader assigns this role via the Auth app.
  • Website privleges:
    • Person can comment on Community Group web pages;
    • Person can edit Community Group web pages.

LEADER

  • Another Community Group Leader assigns this role via the Auth app.
  • Website privileges:
    • Person can comment on Community Group web pages;
    • Person can edit Community Group web pages;
    • Person can delete Community Group web pages.
    • Person has admin privileges for Community Group web pages.
  • Administrative privileges:
    • Person can assign/change Community Group roles in the database.

Project

PARTICIPANT

  • Anyone registered on the site who declares him/herself to be a Participant of the Project via the Auth app. A Project Leader can also assign this role.
  • Website privileges:
    • Person can comment on Project web pages. 

DEVELOPER

  • Project Leader assigns this role via the Auth app.
  • Website privileges:
    • Person can comment on Project web pages;
    • Person can edit Project web pages;
  • Source Code Repository privileges:
    • Person can have commit rights to any Project source repo if granted by a Project Leader.

LEADER

  • Another Project Leader assigns this role via the Auth app.
  • Website privileges:
    • Person can comment on Project web pages;
    • Person can edit Project web pages;
    • Person can delete Project web pages;
    • Person has admin privileges for Project web pages;
  • Source Code Repository privileges:
    • Person has commit rights to all Project source repositories;
    • Person can grant Developers commit rights to Project source repos;
    • Person can create new Project source repositories;
  • Administrative privileges:
    • Person can assign/change Project roles in the database.

User Group

PARTICIPANT

  • Anyone registered on the site who declares him/herself to be a Participant of the User Group via the Auth app. A User Group Leader can also assign this role.
  • Website privileges:
    • Person can comment on UG web pages. 

AFFILIATE

  • User Group Leader assigns this role via the Auth app.
  • Website privileges:
    • Person can comment on User Group web pages;
    • Person can edit User Group web pages.

LEADER

  • Another User Group Leader assigns this role via the Auth app.
  • Website privileges:
    • Person can comment on User Group web pages;
    • Person can edit User Group web pages;
    • Person can delete User Group web pages.
    • Person has admin privileges for User Group web pages;
  • Administrative privileges:
    • Person can assign/change User Group roles in the database. 

Community Group Electorate

CONTRIBUTOR

  • Anyone recognized as such by a Community Group.
  • No governance privileges noted.

CORE CONTRIBUTOR

  • Anyone recognized as such by a Community Group and who accepts the recognition.
  • Governance privileges:
    • Core Contributor can vote in community-wide elections;
    • Core Contributor can vote in Community-Group-specific elections.

EMERITUS CONTRIBUTOR

  • Anyone for whom all Core Contributor grants have expired or who has voluntarily resigned from being a Core Contributor.
  • No governance privileges noted.
  • NOTE: Role not directly implemented in the database, meaning that there is no role defined with this name within the database. This implementation means that a query for people with the role name can not be performed. However, the set of people with Emeritus Contributor status can be obtained by querying the database for people who no longer have any valid grants but who have had them in the past, as historic member status is retained in the database.

FACILITATOR

  • One Core Contributor is appointed Community Group Facilitator by the OGB.
  • Organizes assignment of Core Contributor grants and sends results to OGB secretary for entry into the Community Group Electorate data in the database.
  • Person has the governance privileges of a Core Contributor. No additional governance rights related to Facilitator role.

OGB SECRETARY

  • Appointed by the OGB.
  • Has access to all the Community Group Electorates for the purpose of updating grant data.

Version 1.10, October 1, 2009

last modified by bjc on 2009/10/27 12:59
Collectives
Project


© Sun Microsystems Inc. 2009
XWiki Enterprise 1.8.2.19075 - Documentation
Terms Of Use | Privacy | Trademarks | Copyright Policy | Site Guidelines | Site map | Help
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Use.