Helix Community Process


Helix Community Process

Process Document Date: January 30, 2003

Table of Contents

3 Process Building Blocks

3.2 Projects 3.3 Technology Charter 3.4 Interest Group3.5 Advisory Board

3.6 Coordinator 4. Technology Creation Process for the Helix Community

4.2 Operating Guidelines for Specification Replacement5. Revising the Process6. Effecting the ProcessAppendix A - Glossary

1 Introduction

This document outlines the Helix Community Process, a process designed to allow the digital media delivery community to collaborate on building a standard media delivery layer for industry-wide adoption. The goals of this process are to maximize visibility into the development process, ensure well-timed feedback into the development process, and to ensure that a broad community of stakeholders has the appropriate ownership and control of their destiny. The process is streamlined to move as quickly as possible, while ensuring quality and compatibility.

The decision making process outlined in this document closely aligns with existing practice in creating specifications and technology. Engineers are brought together into a group, with a specific charter outlining scope and deliverables. The group produces specifications, which have defined periods for public review to ensure that ideas are properly vetted. Once reasonable review occurs, a specification is released, and a reference implementation and compatibility kit are built to implement the specification. The specification, reference implementation and compatibility kit are revised until deemed mature by the community, at which point the set is finalized, and then a maintenance and upgrade cycle begins.

2 Participating in the Helix Community

This section describes how to participate in the Helix Community, and what r rights and responsibilities one gets as a member

2.1 Community Members

A central part of the community process is the Helix Community. This is made up of many different constituencies:

  • Hardware Manufacturers
  • Commercial software vendors
  • Commercial software customers
  • Researchers
  • Students, hobbyists, and enthusiasts

Anyone can become a member of the community by signing up on the Helix Community website.

Additionally, members of the community may also belong in any of the following categories:

  • Developers
  • Testers
  • Documentation Writers
  • Integrators
  • Business Owners
  • Users

2.2 Community Member Rights

Community members receive the following rights:

  • View Helix DNA source code
  • Read-only access to the source code version control repository
  • Ability to post issues (bugs, patches, features, enhancements) and participate in discussions (mailing lists or Web forums) associated with the Helix DNA
  • Ability to join Helix Community mailing lists
  • License the code pursuant to the terms listed in the Technology Charter for the project

2.3 Community Member Responsibilities

Community Members have certain obligations under the Helix Community Process:

  • Register with the site
  • Explicitly agree to and abide by the licensing terms associated with all given projects
  • Abide by the Helixcommunity.org's Terms of Use policy.
  • Follow community process and the processes defined in the Technology Charters for Projects in the Helix Community.

3 Process Building Blocks

3.1 Expert Groups

An "Expert Group" is a working group in the Helix Community made up of subject matter experts for a given technology, who holds ultimate responsibility for that technology.

3.1.1 Internal Collaboration

  • Each Expert Group will be assigned its own private project web space for collaboration, separate and distinct from the projects used for software development (see Projects, section 2.2).
  • Documents worked upon by the group can be in any format that the Expert Group members are collectively comfortable with, with HTML being the default.
  • Expert Groups will use mailing lists managed by Helixcommunity.org in their projects as the primary means of discussion, documenting all major decisions and resolutions. These archives will be preserved and accessible to all members of the community.

3.1.2 Stages of Expert Groups

Expert Groups have an official status, based on the state of their deliverables:

  • Specification - In this stage, the group is formed and can begin work on a specification, as well as prototypes and the beginnings of Technical Compatibility Kits
  • Implementation - In this stage, the group has released an Implementation Draft Specification, and is now in full swing on a Reference Implementation and on Technical Compatibility Kits
  • Iteration - In this stage, the group has a full Approved Specification, Reference Implementation, and Technical Compatibility Kit, and is iterating on future versions of the technology.

3.1.3 Expert Group Chairs

Expert Group Chairs (EG Chairs) are responsible for leading Expert Groups through the steps listed in the Technology Charter. The EG Chairs are responsible for driving timelines and measuring consensus on specifications.

The EG Chair is selected by the process outlined in the Technology Charter.

3.2 Projects

"Projects" are the homes for the implementation and maintenance of Helix technology. These are collaboration spaces with a set of development and collaboration tools, as well as clearly marked membership and permissions. Each official Project is governed by a Technology Charter (note that a Technology Charter may govern multiple Projects).

3.3 Technology Charter

A "Technology Charter" (or "Helix Technology Charter") is a document which serves as a governance document for an Expert Group.

Any member of the community can propose a charter to create an Expert Group. The following requirements are made of charters:

  • Scope of the group
  • Governance of the group
  • Deliverables from the group
  • Schedule and milestones for the group
  • Public Draft milestones
  • Release Candidate Specification milestone
  • Certified Specification milestone
  • Intellectual property policy for the group

The charter is may be modified subject to approval of the Advisory Board. Additionally, the charter should reflect the current state of the Expert Group:

  • Pre-formation
  • Drafting
  • Implementation
  • Iteration and maintenence

3.4 Interest Group

An "Interest Group" is a group formed to discuss a particular topic, without a specific set of deliverables or charter. Interest Groups serve many purposes:

  • A precursor to forming an Expert Group (and as a facilitator for writing a Technology Charter)
  • A gathering point for members interested in a particular operating system or other platform
  • Other horizontal activities that span the responsibilities of Expert Groups, and are intended to facilitate the work of Expert Groups.

These are formed at the discretion of the Coordinator.

3.5 Advisory Board

The Helix Advisory Board consists of a cross-section of the Helix Community, responsible for guiding the development of the technology and governance of the Helix Community. This group meets periodically to form recommendations and approve new Technology Charters.

3.5.1 Selection process for the Advisory Board

The initial committee will be five members, appointed by RealNetworks. This committee will be selected to represent the broad constituency of stakeholders in the community process.

3.6 Coordinator

The Coordinator performs the following duties

  • Chairs the Advisory Board
  • Final arbiter on process issues

4 Technology Creation Process for the Helix Community

4.1 Operating Guidelines for Specification Creation

This section outlines the process for creating new technology in the Helix Community. The process, in brief, is as follows:

  1. Draft Technology Charter created by someone who wants to initiate a new project.
  2. Draft charter submitted to discuss@open.helixcommunity.org mailing list for community comment.
  3. Draft charter submitted to Advisory Board mailing alias mechanism.
  4. Technology Charter voted on at next Advisory Board meeting. If approved, it is assigned a number (e.g. "Helix Technology Charter 1" or "HTC1")
  5. Expert Group formed around the Technology Charter
  6. A series of Interim Drafts and Public Drafts are issued until Expert Group consensus is reached
  7. An Implementation Draft is issued, and work on Reference Implementations and Technical Compatibility Kits occurs
  8. A Release Candidate Specification is issued, which is a call for final community-wide review
  9. A Certified Specification is issued, along with complete Reference Implementation and specification.

4.1.1 Technology Charter Creation and Approval

Any member of the community may write a Draft Technology Charter. This is a preliminary document created for review by the Advisory Board. Once a charter is created, it will be reviewed by the Advisory Board, and either approved or rejected with stated cause. Upon approval, an Expert Group is formed to create the deliverables enumerated in the charter.

4.1.2 Beginning Work in an Expert Group

Once a charter has been approved by the Advisory Board, the Expert Group can meet on a regular basis. The primary mode of communication should be mailing lists, but periodic teleconferences and even face-to-face meetings should be employed if necessary to move work forward. All teleconferences and face-to-face meetings should have agendas and minutes, and should be posted to the mailing list managed by Helixcommunity.org. It is the responsibility of the Expert Group Coordinator to produce the agenda and meeting minutes. Failure to do so may result in removal of the chair and/or the revocation of the Technology Charter.

4.1.3 Interim Draft Specification

The group should produce periodic working drafts which document the shared understanding of the final deliverable specification. These documents may be issued periodically at the Expert Group's discretion, and are often merely a snapshot of the dated revision from the revision control repository.

4.1.4 Public Draft Specifications

As part of the chartering process, an expert group must designate a timeline within which they will be releasing Public Draft Specifications. By default, this period is every three months, unless the charter specifically exempts such a schedule.

4.1.5 Implementation Draft Specification

A specification is documentation of technology complete enough to build an implementation. This may still change if implementation experience shows deficiencies in the specification, but no new non-critical functionality should be added during this time.

4.1.6 Release Candidate Specification

This specification is a version of the complete specification that the Expert Group, awaiting approval by the community. The issuing of a Release Candidate Specification signals the last call for the community and public to give input on the document.

After a review period of no less than four weeks, the

4.1.7 Certified Specification

This is an officially-approved specification. This document will be assigned a number and published on the Helixcommunity.org website.

4.1.8 Maintenance of a Community Specification

After the specification has reached Certified Specification status, a defect in the specification may become apparent. The defect may be an important omission in the specification, an error in the specification, such as a violation of a referenced standard, etc. In such cases, a Change Request should be submitted to the Expert Group Chair and he/she should ask for a vote of the Expert Group for a change to the specification. Such changes cannot break backward compatibility with existing implementations. A Change Request approved by the Expert Group is then presented to the Advisory Board for approval. Once approved the Specification is updated.

4.2 Operating Guidelines for Specification Replacement

New versions of Certified Specifications are created by replacing older versions. Revisions can be made by Expert Groups in Iteration/Maintenance mode. If an individual or a group wants to replace a specification currently owned by an active Expert Group, the Advisory Board may approve this. However, the Advisory Board should make every effort to ensure that cooperation is occurring prior to approving overlapping Expert Groups.

5 Revising the Process

The Advisory Board will serve as a working group to define future versions of the Helix Community Process. The Advisory Board should identify key constituencies, and devise a mechanism which balances the competing needs of those constituencies in a fair and expedient manner, ensuring rapid forward progress on Helix Community technology.

Revisions to the process occur in a manner similar to the Helix Technology Creation Process. Any Advisory Board member may initiate a process of revision of the Helix Community Process document, wherein the process document is revised or rewritten. A Public Draft must be published, after which point, comments are accepted on the new process. All substantive comments must be addressed, after which point, a Final Draft may be issued. After a review period of no less than = weeks after the public publication of the Final Draft, a vote may be taken by the Advisory Board. Upon receiving a 4/5 vote of the Advisory Board, the new process document is approved.

6 Effecting the Process

Implementation of this process has been postponed.

Appendix A - Glossary

(Ed note: attempting to inline definitions where possible to avoid conflicting definitions)

Expert Group - see section 2.3

Technology Charter - see section 3.1.1

"Technology Compatibility Kit" or "TCK" - see RCSL