Proposal 5.1: OGDI Proposal Guidelines

Author: Frank Warmerdam, 3i, warmerdam@pobox.com
Proposed: 2001/01/03
Last Edited: 2001/02/12
Status: Accepted

Summary

Guidelines for authoring, reviewing, approving, archiving, referencing, maintaining and retiring OGDI related proposals within the venue of the OGDI Working Group. Proposals are intended to include procedural issues (such as this proposal), and technical proposals for changes to OGDI. OGDI Proposals are intended to play a similar (if less formal) role to RFCs within the Internet Engineering Task Force.

Objective

Provide a streamlined, but uniform and transparent methodology for managing procedural and technical proposals within the OGDI Working Group.

Definitions

  1. Proposal: A proposal is a document describing technical changes or clarifications for OGDI as well as procedural definitions for use within the OGDI Working Group (and by 3i staff working on OGDI).

    It is intended that Proposals are for more major changes than bug fixes, and should be prepared for changes and additions for which a permanent record is required.

  2. Proposal Author: The origining person who writes the proposal, and submits it to the OGDI Working Group. This person should be a member of the OGDI Working Group, or have a sponsor on the working group willing to speak on behalf of the proposal.

  3. Proposal Editor: A person responsible for keeping maintaining the OGDI Proposals web page, and keeping track of proposals, their status and so forth. The editor will make minor editorial changes to proposals as necessary, and may be required to make updates as directed by the OGDI Working Group after a proposal has been adopted. This person is designated by the OGDI Working Group, and will usually be a 3i staff member.

Authoring Proposals

Proposals are authored by a Proposal Author. Proposals may be solicited by the OGDI Working Group, or submitted unsolited by interested parties. Proposals authors must be a member of the OGDI Working Group, or have a sponsor on the working group willing to speak on it's behalf.

Proposals are intended to be written in HTML roughly following a provided template (a proposed template is available at http://ogdi.sourceforge.net/prop/template.html).

Once prepared, proposals should be submitted to the Proposal Editor who will place it on the web site, and the author should also distribute the proposal to the OGDI Working Group (and other appropriate public venues) for review and consideration. Ideally there should be at least two weeks for public review before the OGDI Working Group considers accepting the proposal, but this is not a strict requirement.

In response to feedback, or for any reason, the author may revise the proposal and distribute new versions. However, each time this occurs the revision number should be incremented, and the proposal updated on the OGDI Proposal web site.

Proposal Components

Proposals are intended to contain the following items:

  1. Identity: This is a proposal number, followed by a document revision number, and a name. For instance "5.1 OGDI Proposal Guidelines" would be proposal number 5, revision 1, named Proposal Guidelines. The proposal number is assigned by the Proposal Editor. While in the Proposed status the author may produce new revisions at will, but should increment the revision number each time.

  2. Author: The author (and the sponsors if applicable) name and contact information.

  3. Proposed/Last Edited Date: The date the proposal was initially prepared, as well as the date it was last revised.

  4. Status: Initially this is always "Proposed". If accepted by the OGDI Working Group it becomes "Accepted". If not accepted by the OGDI Working Group it becomes "Declined". If withdrawn by the author before a decision it becomes "Withdrawn". If after acceptance it is superceeded by newer proposals, subsumed in a specification, or ended by the OGDI Working Group, the status becomes "Retired".

  5. Summary: This is one or two paragraphs giving a general description of what the proposal is about. This should be the first section of any proposal, and named "Summary".

  6. Compatibility Issues: Any proposed technical changes to OGDI should have a section on what backward compatibility issues the proposal will raise, and it is proposed that they be dealt with.

    This section should also address what reversion of OGDI the proposal applies to, and what extension tags if any indicate support for a proposed extension.

Also, the proposal should try to provide a justification for the proposal, if practical include examples. Technical changes should be spelled out as precisely as possible, as the proposal will become the reference on technical change for future reference. A reasonable effort should be made to keep the proposal document independent of links or reference to other resources likely to have a limited lifespan.

Proposal Approval

Proposals or ammendments may be accepted or declined by a majority vote of OGDI Working Group members present (in person or by proxy) in a meeting of the OGDI Working Group.

At this point, the proposal (with ammendments) is passed on to the 3i Board of Directors for final approval.

Proposals, or amendments to proposals may be approved outside a working group meeting by issuing the proposal on the OGDI Working Group mailing list if there is no opposition within five working days.

Proposals may be accepted with verbal amendments in a meeting. The Proposal Author, or Editor should apply the amendments, and redistribute the amended document for five days review on the OGDI Working Group email list before the document becomes accepted.

The Proposal Editor may revise accepted proposals for clarity without a review period, as long as the changes do not alter the original intent. The Proposal Editor is responsible for only updating accepted proposals if the change has been accepted in accordance with the above procedures.

Proposal Lifespan

Changes and updates to an existing approved proposal are normally accomplished by issueing a new revision of the proposal rather than issuing a whole new proposal. Substantial changes may be accomplished by issuing a new proposal, with a new proposal number. Superceeded proposals should be retired by the OGDI Working Group, with a notation referencing the new proposal that superceeds the old proposal.

Proposals adopted into new revisions of the OGDI Specification document may be retired.

Retired proposals are always kept available for reference. Older proposal revisions should also be preserved (perhaps only within CVS). Proposals withdrawn by the author, or declined by the working group may be kept available for review as the Proposal Editor sees fit.

Intellectual Property

Proposals should not contain restricted intellectual property. Proposals may define ways of integrating, or utilizing proprietary technology, but the proposed interfaces should be open for anyone to implement. In situations where this is impossible, and a proposal is still called for it, should make clear any copyright, patent or other encumberance applying to the proposal.

Approved Proposal Authority

It is intended that proposals be used to establish and documenting working procedures for the OGDI Working Group, and document technical clarifications and improvements to the OGDI technology. In general they would be considered recommendations, and do not carry the same weight as an OGDI Specification document approved by the 3i Board.

Furthermore, approved proposals do not have the power to force 3i to spend money, modify staffing and so forth. However, they should be considered to be strong recommendations for how existing 3i staff resources allocated to OGDI be applied, and how 3i maintains OGDI. Proposals for new projects to be undertaken by 3i, or requests for funding should not be directed through this mechanism.

Compatibility Issues

Previous proposals did not match this proposal, and have been updated to do so. No other compatibility issues are forseen.