Website Infrastructure Life Cycles

NOTE: As of December 18, 2009, this document became archive only. Go here for the active Infrastructure Life Cycle Instructions document.

Introduction

This document outlines the policies and procedures for managing website infrastructure on opensolaris.org .

The website currently supports four types of infrastructure -- Community Groups, Projects, User Groups, Subsites -- and the leadership models and decision making mechanisms to acquire each type is different. During regular operations, members of the community propose and manage their own groups on the site, but the processes for activating, deactivating, reactivating, transitioning, and terminating the infrastructure are managed by administrators from the Website Engineering Team [1]. In the sections below, all of the interactions between the community and the website administrators will be described, and all of the other reference materials community members need to properly manage their  groups will be documented. Each section is designed to be self contained, so the document need not be read in its entirety.

Mailing Lists & Contact Information

  • For all implementation interactions concerning all infrastructure types, post to project-setup AT opensolaris DOT org.
  • For general community discussions about the website, post to website-discuss AT opensolaris DOT org. Subscribe here.
  • For website user account issues, post to website-admin AT opensolaris DOT org.

1. Community Groups

Activation

The OGB approves the creation of Community Groups and formally sponsors [2] those groups throughout their life cycle. Review the OpenSolaris Constitution for guidance about proposing new Community Groups. After the Community Group is approved by the OGB, forward the following information to project-setup:

  • The approval thread from the OGB.
  • The full title [3] of the Community Group and the abbreviation name [3] for the group's URL (For example: Full title: Installation and Packaging. Abbreviation name for URL: install). Do not use "Solaris" or "OpenSolaris" in the Community Group's name. Solaris and OpenSolaris are trademarks [4] of Sun Microsystems and will not be used in group names without Sun legal approval. Use a generic name instead.
  • A brief public description of the Community Group.
  • The opensolaris.org user names and email addresses of the Community Group's Facilitator and Leaders.
  • If the Community Group requires a mailing list, the name of the list [3], and the names of Leaders who will administer the list. Names for Community Group lists should be in the following format: [name]-discuss AT opensolaris DOT org

If everything is in order, a Community Group space will be set up on the site and Leaders will be added to the Community Group in the Auth database. The OGB Secretary will add the Facilitator to the Community Group's Electorate in Auth since that is a governance role. Leaders are expected to populate their pages with content and announce their new group on opensolaris-announce AT opensolaris DOT org (subscribe here). To properly maintain their website infrastructure, Community Group Leaders are also responsible for following these three documents:

  1. OpenSolaris Website Guidelines
  2. OpenSolaris Trademarks Policy
  3. Website User Guide

Deactivation and/or Termination

There are three ways a Community Group's website infrastructure can be deactivated and/or terminated:

  1. The OGB can deactivate and/or terminate a Community Group as per the OpenSolaris Constitution (Section 7.12. Termination).
  2. The Website Team can deactivate and/or terminate website infrastructure if it is not well maintained (filled with spam, violations of the TOU, etc) or abandoned for 3 months based on the OpenSolaris Website Guidelines.
  3. Community Group Leaders can request that their group be deactivated and/or terminated.

In these cases, the procedures below will be followed:

  • The OGB can initiate this action by posting mail to project-setup with the Community Group name and URL, the names of any mailing lists and forums, and a link to the public thread with the OGB's decision.
  • If the Website Team initiates this action, the team will post mail to the Community Group's and/or the OGB's list requesting that action be taken to maintain the site's infrastructure properly. If a Community Group's website infrastructure becomes completely abandoned, the Website Team will post mail to the OGB requesting that action be taken to replace the Leaders and/or deactivate/terminate the Community Group. If a decision is not made within 3 months, the Website Team can deactivate and/or terminate the Community Group.
  • In the case of deactivation, mailing lists and forums will be reset to disable new subscriptions and new postings but archives will be saved. If there has been no activity to archive, the lists and forums will be deleted. In the case of termination instructions from the OGB, the mailing list infrastructure will be deleted.
  • In the case of deactivation, the Community Group's web pages will be tagged with text indicating that the group is no longer active, and the members of the Community Group who have website edit privileges will no longer have the ability to edit the group's web pages unless the Community Group is reactivated. However, any governance privileges among Community Group members will remain unless the OGB specifies otherwise. In the case of termination instructions from the OGB, the Community Group space on the site will be deleted.
  • Project sponsorship by an deactivated or terminated Community Group can be reassigned to another Community Group as specified by the OpenSolaris Constitution (7.12. Termination).

Reactivation

To reactivate Community Groups, check with the OGB for reactivation procedures and forward the approval thread to project-setup with the following information:

  • The names of the Community Group and mailing list.
  • The opensolaris.org user names and email addresses of the Community Group's Facilitator and Leaders.
  • The opensolaris.org user names and email addresses of the Leaders who will administer the mailing list.

Transition to a Project

If a Community Group decides to become a Project, follow the instructions for requesting a new Project below. Once approved, the Project will be created. Before removing the old Community Group, governance roles associated with the old Community Group will be transferred to the Community Group that is sponsoring the new Project.

2. Projects

Activation

Community Groups approve the creation of Projects and formally sponsor [2] those Projects throughout their life cycle. Refer to the OGB's OpenSolaris Project Instantiation Policy for policy guidance about proposing new Projects and voting procedures, but also check with the sponsoring Community Group for any modifications or additions to the OGB policy. Also note that the OGB's Project Instantiation document does not contain enough information to get a project setup on the site. Please follow the instructions below, and forward the following information to project-setup:

  • The approval thread from the sponsoring Community Group.
  • Full Project title [3] and abbreviation name [3] for the Project URL (For example: Full title: Device Manager. Abbreviation name for URL: devicemgr). Do not use "Solaris" or "OpenSolaris" in the Project name. Solaris and OpenSolaris are trademarks [4] of Sun Microsystems and will not be used in Project names without Sun legal approval. Use a generic name instead.
  • A brief public description of the Project.
  • The opensolaris.org user names and email addresses of the Project's Leaders.
  • If the Project requires one or more mailing lists, for each list, provide the word to substitute for [name] in an options below and the names of the Leaders who will administer the list:
    • Options for naming [3] Project lists:
      • [name]-dev AT opensolaris DOT org (developer discussions)
      • [name]-discuss AT opensolaris DOT org (general discussions)
      • [name]-notify AT opensolaris DOT org (notifications for code putbacks)

If everything is in order, a Project space will be set up on the site, Leaders will be added to the Project in the Auth database, and the Community Group <-> Project sponsorship relationship [2] will be set in the Auth database. Leaders are expected to populate their pages with content and announce their new group on opensolaris-announce AT opensolaris DOT org (subscribe here). To properly maintain their website infrastructure, Project Leaders are also responsible for following these four documents:

  1. OpenSolaris Website Guidelines
  2. OpenSolaris Trademarks Policy
  3. Website User Guide
  4. Posting Source and Binaries

Deactivation and/or Termination

There are three ways a Project's website infrastructure can be deactivated and/or terminated:

  1. The sponsoring Community Group can deactivate or terminate a Project.
  2. The Website Team can deactivate and/or terminate website infrastructure if it is not well maintained (filled with spam, violations of the TOU, etc) or abandoned for 3 months based on the OpenSolaris Website Guidelines.
  3. Project Leaders can request that their group be deactivated and/or terminated.

In these cases, the procedures below will be followed:

  • The sponsoring Community Group can initiate this action by posting mail to project-setup with the Project name and URL, the names of any mailing lists and forums, and a link to the public thread with the Community Group's decision.
  • If the Website Team initiates this action, the team will post mail to the sponsoring Community Group's and/or Project's list requesting that action be taken to maintain the site's infrastructure properly. If a Project's website infrastructure becomes completely abandoned, the Website Team will post mail to the sponsoring Community Group requesting that action be taken to replace the Leaders and/or deactivate/terminate the Project. If a decision is not made within 3 months, the Website Team can deactivate and/or terminate the Project.
  • In the case of deactivation, mailing lists and forums will be reset to disable new subscriptions and new postings but archives will be saved. If there has been no activity to archive, the lists and forums will be deleted. In the case of termination instructions from the sponsoring Community Group, the mailing list infrastructure will be deleted.
  • In the case of deactivation, the Project's web pages will be tagged with text indicating that the group is no longer active, and the members of the Project who have website edit privileges will no longer have the ability to edit the group's web pages unless the Project is reactivated. Additionally, Project sponsorship by a deactivated or terminated Community Group can be reassigned to another Community Group as specified by the OpenSolaris Constitution (7.12. Termination).
  • Source Code Management
    • Access to SCM repositories will be disabled if a Project is deactivated. SCM repositories will be deleted if a Project is terminated.
    • To request that repositories be deleted on active Projects, the Leaders should post to tonic-ops AT sun DOT com and/or project-setup AT opensolaris DOT org and the Website Team will delete the repos. In the future, this feature will be added to the SCM Console so Leaders can delete repositories themselves.

Reactivation

To reactivate Projects, there are a few choices: Check with the original sponsoring Community Group for reactivation procedures or engage a new Community Group if the original Community Group is no longer active or denies the request. Once approved, forward the thread to project-setup with the following information:

  • The names of the Project and mailing list and sponsoring Community Group.
  • The opensolaris.org user names and email addresses of the Project's Leaders.
  • The opensolaris.org user names and email addresses of the Leaders who will administer the mailing list.

Transition to a Community Group

If a Project decides to become a Community Group, follow the instructions for creating a new Community Group above. Once approved, the Community Group will be created. Because a Project has no governance roles, there is no governance data to transfer to the new Community Group. Instead, Community Group roles will be initially populated with people named in the creation request to the OGB.

3. User Groups

Activation

The Advocacy Community Group approves the creation of OpenSolaris User Groups (OSUGs) and formally sponsors [2] those groups throughout their life cycle. Although user groups are a separate Collective on the site, they are not mentioned in the OpenSolaris Constitution. So, to maintain consistency and follow established practice, the Advocacy Community Group will continue to be responsible for approving OSUGs. See Advocacy's (proposal procedures here). After the OSUG is approved by the Advocacy Community Group, forward the following information to project-setup:

  • The approval thread from the Advocacy Community Group.
  • Full User Group title [3] and its abbreviation name [3] for the User Group URL (For example: Full Title: Japan OpenSolaris User Group. Abbreviation name for URL: jposug). Although "OpenSolaris" is a trademark [4] of Sun Microsystems and can not be used in Community Group and Project names, it is considered fair use to use OpenSolaris in the name of a User Group. We encourage this format.
  • A brief public description of the User Group and its location.
  • The opensolaris.org user names and email addresses of the User Group's Leaders.
  • If the User Group requires a mailing list, the name [3] of the list, and the names of Leaders who will administer the list. Names for User Group lists should be in the following format: ug-[name]osug AT opensolaris DOT org.

If everything is in order, a User Group space will be set up on the site, and Leaders will be added to the User Group in the Auth database. Leaders are expected to populate their pages with content and announce their new group on opensolaris-announce AT opensolaris DOT org (subscribe here). To properly maintain their website infrastructure, User Group Leaders are also responsible for following these three documents:

Deactivation and/or Termination

There are three ways a User Group's website infrastructure can be deactivated and/or terminated:

  1. The sponsoring Community Group (Advocacy) can deactivate and/or terminate a User Group.
  2. The Website Team can deactivate and/or terminate website infrastructure if it is not well maintained (filled with spam, violations of the TOU, etc) or abandoned for 3 months based on the OpenSolaris Website Guidelines.
  3. User Group Leaders can request that their group be deactivated and/or terminated.

In these cases, the procedures below will be followed:

  • The Advocacy Community Group can initiate this action by posting mail to project-setup with the User Group name and URL, the names of any mailing lists and forums, and a link to the public thread with the Advocacy decision.
  • If the Website Team initiates this action, the team will post mail to the User Group's and/or Advocacy's list requesting that action be taken to maintain the site's infrastructure properly. If a User Group's website infrastructure becomes completely abandoned, the Website Team will post mail to the Advocacy Community Group requesting that action be taken to replace the leaders and/or deactivate/terminate the User Group. If a decision is not made within 3 months, the Website Team can deactivate and/or terminate the User Group.
  • In the case of deactivation, mailing lists and forums will be reset to disable new subscriptions and new postings but archives will be saved. If there has been no activity to archive, the lists and forums will be deleted. In the case of termination instructions from the Advocacy Community Group, the mailing list infrastructure will be deleted.
  • In the case of deactivation, the User Group's web pages will be tagged with text indicating that the group is no longer active, and the members of the User Group who have website edit privileges will no longer have the ability to edit the group's web pages unless the User Group is reactivated. In the case of termination instructions from the Advocacy Community Group, the User Group space on the site will be deleted.

Reactivation

To reactivate User Groups, check with the Advocacy Community Group for reactivation procedures and forward the approval thread to project-setup with the following information:

  • The names of the User Group and mailing list.
  • The opensolaris.org user names and email addresses of the Community Group's facilitator and leaders.
  • The opensolaris.org user names and email addresses of the leaders who will administer the mailing list.

Transition to Another Infrastructure Type

There are no transition procedures for OSUGs. If OSUG Leaders want to form a new Community Group or Project, they can follow the procedures above. The status of their OSUG will be determined at that time (whether to continue or deactivate/terminate).

4. Subsites

Subsites are web applications running on opensolaris.org and they offer developers advanced services, such as testing, code review, package management, defect tracking, etc. Subsites do not live under the hub.opensolaris.org domain along with Community Groups, Projects, and User Groups, and they are not mentioned in the governance system. Instead, Subsites use a separate sub domain on the site, and most of these applications are owned and managed by the Website Team. However, some Subsites are managed by other organizations at Sun, and the Website Team may be able to provide infrastructure on a limited basis to offer new services to the OpenSolaris community. The application process is rigorous. If interested, developers can contact the Website Team at website-admin AT opensolaris DOT org to apply.

References

Governance Documents

Website Documents

Notes

[1] The Website Engineering Team, which is part of Sun's OpenSolaris Open Development Engineering Team, builds and supports opensolaris.org on behalf of Sun Microsystems and the OpenSolaris Community. The team also leads the Website Community Group and updates the Infrastructure Life Cycle Documentation regularly to reflect changes in the OpenSolaris community and/or program.

[2] Projects can be "sponsored" by only one Community Group, but any number of Community Groups can "associate with" any number of Projects. These relationships will be recorded in the Auth database when the Collectives are set up, but Collective Leaders can change the relationships. Note that the sponsor relationship between User Groups and Advocacy is not recorded in the Auth database because User Group are not mentioned in the OpenSolaris Constitution.

[3] The "title" of any Collective on the site is the text appearing at the top of a group's home page and also in the left drop-down navigation bar. That text can be edited. The "name" of any Collective on the site is the text that appears at the end of the URL. That text can not be edited once chosen and it must be unique to all the Collectives on the site. Also, regarding names for mailing lists, most groups choose to name their lists using the same name as as they use for their Collectives. This is not required but it is highly recommended for consistency.

[4] OpenSolaris Trademarks Policy 

Tags:
Created by admin on 2009/10/26 12:11
Last modified by jimgris on 2010/01/25 04:40

Collectives

Project


© 2010, Oracle Corporation and/or its affiliates
XWiki Enterprise 2.1.1.25889 - 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.
Oracle