Governance of Community

The REST-* community is still at its early stages so we are very open to changing our governance policies.  We have borrowed ideas from various specification organizations pulling in what we liked, leaving out what we disliked.

Specification Proposals
Anybody may propose a new specification to the REST-* community.  Proposals must be reviewed and approved by the Board of Directors before they become an official effort of the REST-* community.

Specification Criteria
Proposed specifications must not overlap or compete with other active specifications hosted at REST-*.  If it overlaps or competes it must be submitted as an extension to a specification.  (For those in tune with the Java community, we do not want to have another CMP/JDO/JPA debacle.) The Board of Directors must take special care to make sure that the proposed specification fits well within the overall architecture of REST-* specifications.

Specification Openness
Specifications must be discussed in the open on a public mailing list.  Anybody may join and post messages to the public mailing list.  All drafts, source code, and any issue tracking system must be made available for anyone to read.  Specifications, source code, and certification efforts must be licensed under ASL 2.0.  Specification extensions may be exempt from this licensing restriction, but such an exemption must be approved by both a majority of specification members and the Board of Directors.  We do this to provide flexibility where it is not possible to provide an extension under an open source license because of patent or commercial licensing issues.  In general though, it should be very hard to make an extension proprietary given that both the Board and the specification members must approve it. 

Interoperability is a very important feature and something we take seriously. Each specification must have a certification test suite.  An implementation my not claim compliance with a REST-* specification without passing this certification test.  There must not be any field of use restrictions or fees to pass certification.  Anybody should be able to certify their implementation.  All source code for certification tests must be open sourced under the ASL 2.0 license.  Compliant implementations do not have to pass extension test suites to be compliant.

Specification Group Members
Each specification is made up of a group of experts. Any member may nominate somebody to join the group.  A majority vote is acquired by all members to approve the new member.

Spec Leads
Each specification will have a spec lead.  The spec lead is responsible for putting together each draft of the specification and has final say on what goes into the draft.  A spec lead may form the initial expert group.  Spec leads are appointed by the Board of Directors.

Specification Extensions
REST-* wants to keep the base specifications it publishes as simple as possible.  Many times edge cases create too much bloat.  For a good specification its just as important what features it leaves out as what features it defines.  That being said, we need the flexibility to agree upon and define extensions to a specifications.  Any specification member may propose an official extension.  To become official a majority of specification members must approve it.

Board of Directors
The Board of Directors is responsible for approving new specifications and final draft of specifications.  It is their responsibility to ensure the overall quality of our specifications and that their architecture fits seemlessly together.  Red Hat, as the founder of REST-*, gets a permanent seat on the board.  All other board members must be elected by the overall membership once a year.  Any member may nominate an individual or company to be a board member before an election.