Fedora API Specification Charter

Esmé Cowles edited this page Jun 24, 2017 · 3 revisions

Fedora API Specification Charter

The objective of this charter is to institute a Fedora API Specification editorial team in order to establish and maintain the Fedora API Specification.

This specification will:

  1. Define the characteristics and expectations of how clients interact with Fedora implementations
  2. Define such interactions such that an implementation’s conformance is testable
  3. Enable interoperability by striving to minimize the need for modifications to client applications in order to work with different implementations of the Fedora API specification

The Fedora API Specification editors are responsible for facilitating discussions across the Fedora community, ensuring those discussions are captured as use cases, and reflecting those use cases into new and revised specifications for the community to implement. This process is intended to be as transparent as possible. This document exists to further that intention by defining the Fedora API Specification editorial process and the responsibilities and expectations of the editorial team.

Editorial Team Membership and Selection

The editorial team shall consist of no more than five members, representing key community constituencies, and with the mandate to value compromise in the absence of consensus.

The editorial team represents various constituencies, but is accountable to the Fedora Leadership Group (FLG).

If the number of editors drops below five, the editors may nominate additional editors. All current editors must agree before an invitation is issued; Fedora Steering Group (FSG), acting on behalf of Fedora Leaders, must confirm any nominations before they take effect. Editors will choose from participants within the community and/or experts willing to lend their knowledge and experience to new specifications. Opportunities to better the gender, race, and age balance of the existing editorial team will also be a consideration.

Editors must agree to all of the processes set out in this document, including attendance at meetings, and to the publishing of the specification under a CC-BY license. They are responsible for confirming that these conditions are also acceptable to their employer, where applicable. It is not expected that every editor comment on every issue, though they should make every effort to do so.

Editors are expected to serve one-year terms, and to step down or renew after one year. Editors may be dismissed from work on a specification, or the editorial group altogether, for lack of participation or lack of consensual progress with the larger group.

The initial editorial team has been consensually appointed by the FSG:

  • Ben Armintor
  • Esmé Cowles
  • Danny Lamb
  • Simeon Warner
  • Andrew Woods

The editorial process and workflow is subject to change by the editors; material changes must be approved by the FLG.

Deliverables and Timeframe

Per the “Specification Workflow” defined below, the editorial team is charged with releasing the First Public Working Draft of the specification by June 20, 2017.

The First Public Working Draft will be available for community input from specification clients and implementers for a period of four months from publication. During this period there will be monthly process updates to the FLG in which:

  • Progress is assessed
  • Obstacles are identified
  • Changes to the charter are evaluated

At the end of this period, in the absence of unresolved issues, the Working Draft will progress to a Candidate Recommendation release. In any case, outstanding issues should not delay the release by more than one month.

From the time a Candidate Recommendation is published, if there are no significant changes within two months, the Candidate Recommendation will become the Recommendation.

Once the Recommendation is released, the Editors and FSG will evaluate and formalize the process by which work will continue towards maintaining the specifications and aligning with community use cases and implementations.

Specification Workflow

The following steps define the workflow for advancing the Fedora API Specification to recommendation.

  1. Publication of the First Public Working Draft
  2. Publication of zero or more revised Public Working Drafts
  3. Publication of a Candidate Recommendation
  4. Publication as a Recommendation

Maturity Levels

Working Draft

A Working Draft is a document that has been published for review by the Fedora community.

Candidate Recommendation

A Candidate Recommendation is a document that satisfies the editorial team's technical requirements, and has already received wide review. This phase establishes a deadline for the Fedora Leadership and broader Fedora community review. Substantive changes must not be made to a Candidate Recommendation except by publishing a new Working Draft.

Recommendation

A Recommendation is a document that has been accepted by the FLG as of sufficient quality to become a Recommendation.

You can’t perform that action at this time.
You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.
Press h to open a hovercard with more details.