The process section provides a description of the standards process. The full description
can be found in the following standards document here:
osbos-draft-tegen-rfc-04.pdf
To discuss the process itself go here to the discussion forum on process.
Introduction
The OSBOS RFC (Request for Comment) is a process to developing specifications for
various aspects of the operating system. Anyone can create an RFC but are encouraged
to consult with the RFC committee to ensure that the work is not currently being
performed. Any number of people can co-author a specification and are encouraged to
do so to allow the specification to be balanced and thoroughly designed prior to public
comment.
The RFC would like to embrace all variants of the Be Operating System in its definition.
This includes both open and closed source variations of the operating system. It is
hopped that standardization of basic items within each variant will allow greater
reusability of software and components in addition to providing the consumer with more
quality choices in selecting a variant and software components on top of the operating
system.
A RFC is a written specification that covers various aspects of the operating system. It is
a document that interested members of the public have commented on and contributed
to the formation of the specification. Though there is an author in developing the
specification, once made publicly available, the speciation is owned by the public, but
only the RFC committee can oversee and authorize its change.
The Process:
1. Verification:
The author verifies that a similar RFC does not already exist in any stage of development.
2. Submit Query:
The author submits a query to the committee with the planned RFC with a summary of
the feature. This will reduce the likelihood of repeated efforts and the committee can help to focus or expand the effort.
3. Submittion:
A draft RFC is submitted by the author in the standard RFC format available in the template
section. The draft RFC does not have to be a completed draft. Incremental releases of
the specification are encouraged to solicit constructive feedback.
4. Standards Committee review for entry:
The RFC will be reviewed for content and quality by the Standards Committee. If a large
quantity corrections are needed (formatting, spelling, grammar), will be noted and
returned to the author for corrections. That revision will not be published until it is
suitable and consistent with the standard format. Any minor adjustments will be done
and copied back to the author.
Once validated, the RTF formatted document will be converted to PDF and made
available to the public. Only the latest revision will be made available and previous
revisions (if any) will be archived.
5. Public Review:
There are three stages of an RFC: DRAFT, EXPERIMENTAL, STANDARD. These stages
are to ensure that the specification has been carefully thought out by the author(s), has had
sufficient time for public review and comment, and been validated by prototype, before it
becomes a standard specification.
A discussion group will be created for public discussion of the standard on the
discussion section of the Standards Portal. The document itself will be announced in the New
Standards discussion topic. The document itself will also be placed in the review section
of the Portal. This review period will last for 40 days, after which the review will be closed.
6. Approval:
The Standards Committee reviews all discussion comments, experiements, applications,
and RFCs. Once the RFC is ready for consideration the Committee holds a vote. Of the
15 members of the committee a 2/3rds (10 of 15) margin in favor of adopting the standard
wins the vote and the RFC become a standard. Upon rejection the RFC remains
indefinitely as an EXPERIMENTAL RFC and can continue being developed by the author.
Once the author is satisfied with their modifications it can be resubmitted to the
committee for further consideration.
