Site Roles & Collectives

The website infrastructure is designed for flexibility and to better enable collectives to manage themselves. A set of collectives is defined, and within each collective, a set of roles is defined. This information is then used and interpreted by the applications that run on the opensolaris.org website. The 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 and responsibilities 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 previous data sources to the Auth database.

Three types of collectives are supported: Community Group, Project and User Group.^[1] 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. As noted above, other applications running on the site can also assign privileges to the roles for use within that application.

Roles are hierarchical with privileges increasing with your role.  Roles are listed below in reverse order for each collective, starting with the role that offers the least amount of privileges and responsibilities.  You can start with a higher role (such as being a Leader on a new Project) or work your way through the roles over time as you become involved with a collective. 

Refer to the User Guide for specific instructions about how to perform the actions noted below. Also, Refer to the Infrastructure Life Cycle Instructions document for information about acquiring and managing website infrastructure. 

Community Group

Social group whose members engage in open conversations, endorse technical projects, and approve the creation of new Projects. 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. Such Community Groups will be noted in the database as being "associated with" a 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:
  • Comment on Community Group web pages.
• No Source Code Repository privileges (Community Groups do not have source code repositories).
• No Administrative privileges.

AFFILIATE

• Community Group Leader assigns this role via the Auth app.
• Website privileges:
  • Comment on Community Group web pages;
  • Edit Community Group web pages.
• No Source Code Repository privileges (Community Groups do not have source code repositories).
• No Administrative privileges.

LEADER

• Another Community Group Leader assigns this role via the Auth app.
• Website privileges:
  • Comment on Community Group web pages;
  • Edit Community Group web pages;
  • Delete Community Group web pages;
  • Have admin privileges for Community Group web pages.
• Administrative privileges:
  • See existing users and their roles in the Community Group;
  • Add users to the Community Group;
  • Assign/modify Community Group roles;
  • Delete a user from the Community Group.
• No Source Code Repository privileges (Community Groups do not have source code repositories).

Project

Collaborative technical effort. Projects are initially approved by one Community Group at the time of creation.

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:
  • Comment on Project web pages. 
• No Source Code Repository privileges.  
  • This means a Participant can not pull or push (commit to) from any Project source repository.  
  • A Participant MAY pull anonymously from a Project source repository if the repository has the flag set to allow anonymous pull.
• No Administrative privileges.

DEVELOPER

• Project Leader assigns this role via the Auth app.
• Website privileges:
  • Comment on Project web pages;
  • Edit Project web pages.
• Source Code Repository privileges:
  • Have pull and push (commit) privileges to Project source repositories as assigned by a Project Leader (i.e., a Developer might not have access to all Project source repositories).
• No Administrative privileges.

LEADER

• Another Project Leader assigns this role via the Auth app.
• General responsibilities:
  • Ensure all Developers and Leaders on the Project are either Oracle employees or have an OCA on file.
• Website privileges:
  • Comment on Project web pages;
  • Edit Project web pages;
  • Delete Project web pages;
  • Have admin privileges for Project web pages.
• Source Code Repository privileges:
  • Have pull and push (commit) privileges to ALL Project source repositories;
  • Create new Project source repositories;
  • Request deletion of a Project source repository.
• Administrative privileges:
  • See existing users and their roles in the Project;
  • Add users to the Project;
  • Assign/modify Project roles;
  • Delete a user from the Project.

User Group

Independently-run group that advocates for OpenSolaris. 

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:
  • Comment on UG web pages. 
• No Source Code Repository privileges (User Groups do not have source code repositories).
• No Administrative privileges.

AFFILIATE

• User Group Leader assigns this role via the Auth app.
• Website privileges:
  • Comment on User Group web pages;
  • Edit User Group web pages.
• No Source Code Repository privileges (User Groups do not have source code repositories).
• No Administrative privileges.

LEADER

• Another User Group Leader assigns this role via the Auth app.
• Website privileges:
  • Comment on User Group web pages;
  • Edit User Group web pages;
  • Delete User Group web pages;
  • Have admin privileges for User Group web pages.
• Administrative privileges:
  • See existing users and their roles in the User Group;
  • Add users to the User Group;
  • Assign/modify User Group roles in the database;
  • Delete a user from the User Group.
• No Source Code Repository privileges (User Groups do not have source code repositories).

^[1] Within the infrastructure database there remains an entity called an Electorate, which contains the following roles for each Community Group: Facilitator, Contributor, Core Contributor, and OGB Secretary. These were governance roles but they are no longer in use.