Proposal for RFC 1
84 views
Skip to first unread message
dvdrw
Aug 24, 2020, 1:26:53 PM8/24/20
to rfccom...@bitwave.tv
Request for Comments:
1 dvdrw
Proposal
Form and function of RFC documents and proposals
Status of This Memo
This document specifies the required form all valid RFC documents and
proposals must have in order to be accepted. It also describes the process
of submitting and approving a proposal.
Abstract
Until now, features and their implementation(s) on [bitwave.tv]'s services
have been wholly managed and defined by Dispatch. While this system has its
advantages, namely (1) fast idea-to-implementation pipeline, (2) ability to
quickly adapt to change, it has its disadvantages too:
(1) Feature implementation (and impl. details) change as often as Dispatch
invests time and effort into doing so. This can vary from a couple of
days to months[1].
(2) Proposing changes involves influencing the sole project lead manager.
(3) Implementation details change often, and are mostly only documented in
Dispatch's memory, disallowing easy or stable third-party access to
services.
(4) Changes in the development environment regularly spill over to
production, while production is oftenly used as a staging environment.
The existence of a committee and body of specifications hopes to eliminate
these disadvantages by:
(1) Offloading feature detail discussion and specification to multiple
people.
(2) Allowing anyone to submit a proposal or partake in discussion on
existing proposals.
(3) Limiting rate of implementation change and pose a well-defined spec.
(4) Organising updates to [bitwave.tv] according to RFC compliance.
Table of Contents
1. Introduction
2. Overview of RFC Document Format
3. Overview of The Proposal-To-Approval Process
4. Definitions
5. References
1. Introduction
The document and process specification in this document provide a framework
for future RFC submissions and the subsequent review and approval processes.
Approved RFCs pose the reference specification for implementation, and
bitwave.tv and related services as the main referent implementation.
2. Overview of RFC Document Format
For an RFC document to be considered valid, the following must hold true:
(1) The document is written in plain text form.
(2) No line is longer than 80 characters
(3) The document starts with two edge-aligned columns;
The left column contains the RFC number and document status.
The right column is a list of authors.
(4) The document has a center-aligned title, followed by sections 'Status of
This Memo' and 'Abstract', explaining what the document specifies,
followed by a table of contents.
The document should follow these formatting guidelines:
(1) Text under a title (i.e. body text) is indented by 4 spaces. Subsequent
nested text is indented by 2 spaces.
(2) A blank line of spacing exists between title, paragraphs, list items.
Any diagrams necessary (other than screenshots) must also be in text-form.
3. Overview of The Proposal-To-Approval Process
Proposals for RFC documents should be already valid RFCs. As few edits as
possible should be necessary to transform a proposal into a valid RFC ready
to be added to the list.
Proposals should be sent to rfccom...@bitwave.tv -- this starts a new
'topic' on the mailing list/group. Committee members are to respond in a
timely fashion. After discussion has concluded, the members vote to either
APPROVE - bring the proposal in its current state into the list of
approved RFCs and start tracking bitwave's compliance to it.
REQUEST CHANGES - propose changes and request the author submit the
revised document to the same topic before voting for
approval.
REJECT - deny the entry of the proposed RFC into the list of official
RFCs.
After all member have successfully casted a vote, the majority vote is the
official decision, unless it is a vote for APPROVE and there exist
unresolved votes for REQUEST CHANGES.
The members who voted for the majority side are to write a brief opinion
that describes the reasoning behind their vote. These opinions are compiled
into a single document and are paired with the RFC.
4. Definitions
'(The) Request for Comments (RFC) Document' refers to a complete, thought-out
and well formulated specification that describes a behaviour, mechanism or
object that [bitwave.tv]'s services should implement. Every RFC has a unique
assigned serial number.
'(RFC) Proposal' refers to a document of the same form as an RFC that has
not yet gone through the approval phase.
'The (RFC) Committee' refers to the body of members who enjoy the privilege
of casting votes on RFC Proposals.
The following are shorthand expressions that may appear verbatim in RFCs,
and mean the following:
MUST - A compliant implementation must do this.
MUSTN'T - A compliant implementation mustn't do this.
SHOULD - For an implementation to be compliant, it isn't necessary to
do this, but it is highly recommended.
SHOULDN'T - For an implementation to be compliant, it isn't necessary to
avoid doing this, but it is highly recommended.
RFC text may also use combinators:
'{a,b}text' - resolves to - 'atext, btext'
'{a,b}text word {a,b}other' - resolves to:
'atext word aother',
'atext word bother',
'btext word aother',
'btext word bother',
'(a,b)text word (a,b)other' - resolves to:
'atext word aother',
'btext word bother',
5. References
[1] - Most issues on https://github.com/bitwave-tv/bitwave/issues are over a
month old.
Proposal
Form and function of RFC documents and proposals
Status of This Memo
This document specifies the required form all valid RFC documents and
proposals must have in order to be accepted. It also describes the process
of submitting and approving a proposal.
Abstract
Until now, features and their implementation(s) on [bitwave.tv]'s services
have been wholly managed and defined by Dispatch. While this system has its
advantages, namely (1) fast idea-to-implementation pipeline, (2) ability to
quickly adapt to change, it has its disadvantages too:
(1) Feature implementation (and impl. details) change as often as Dispatch
invests time and effort into doing so. This can vary from a couple of
days to months[1].
(2) Proposing changes involves influencing the sole project lead manager.
(3) Implementation details change often, and are mostly only documented in
Dispatch's memory, disallowing easy or stable third-party access to
services.
(4) Changes in the development environment regularly spill over to
production, while production is oftenly used as a staging environment.
The existence of a committee and body of specifications hopes to eliminate
these disadvantages by:
(1) Offloading feature detail discussion and specification to multiple
people.
(2) Allowing anyone to submit a proposal or partake in discussion on
existing proposals.
(3) Limiting rate of implementation change and pose a well-defined spec.
(4) Organising updates to [bitwave.tv] according to RFC compliance.
Table of Contents
1. Introduction
2. Overview of RFC Document Format
3. Overview of The Proposal-To-Approval Process
4. Definitions
5. References
1. Introduction
The document and process specification in this document provide a framework
for future RFC submissions and the subsequent review and approval processes.
Approved RFCs pose the reference specification for implementation, and
bitwave.tv and related services as the main referent implementation.
2. Overview of RFC Document Format
For an RFC document to be considered valid, the following must hold true:
(1) The document is written in plain text form.
(2) No line is longer than 80 characters
(3) The document starts with two edge-aligned columns;
The left column contains the RFC number and document status.
The right column is a list of authors.
(4) The document has a center-aligned title, followed by sections 'Status of
This Memo' and 'Abstract', explaining what the document specifies,
followed by a table of contents.
The document should follow these formatting guidelines:
(1) Text under a title (i.e. body text) is indented by 4 spaces. Subsequent
nested text is indented by 2 spaces.
(2) A blank line of spacing exists between title, paragraphs, list items.
Any diagrams necessary (other than screenshots) must also be in text-form.
3. Overview of The Proposal-To-Approval Process
Proposals for RFC documents should be already valid RFCs. As few edits as
possible should be necessary to transform a proposal into a valid RFC ready
to be added to the list.
Proposals should be sent to rfccom...@bitwave.tv -- this starts a new
'topic' on the mailing list/group. Committee members are to respond in a
timely fashion. After discussion has concluded, the members vote to either
APPROVE - bring the proposal in its current state into the list of
approved RFCs and start tracking bitwave's compliance to it.
REQUEST CHANGES - propose changes and request the author submit the
revised document to the same topic before voting for
approval.
REJECT - deny the entry of the proposed RFC into the list of official
RFCs.
After all member have successfully casted a vote, the majority vote is the
official decision, unless it is a vote for APPROVE and there exist
unresolved votes for REQUEST CHANGES.
The members who voted for the majority side are to write a brief opinion
that describes the reasoning behind their vote. These opinions are compiled
into a single document and are paired with the RFC.
4. Definitions
'(The) Request for Comments (RFC) Document' refers to a complete, thought-out
and well formulated specification that describes a behaviour, mechanism or
object that [bitwave.tv]'s services should implement. Every RFC has a unique
assigned serial number.
'(RFC) Proposal' refers to a document of the same form as an RFC that has
not yet gone through the approval phase.
'The (RFC) Committee' refers to the body of members who enjoy the privilege
of casting votes on RFC Proposals.
The following are shorthand expressions that may appear verbatim in RFCs,
and mean the following:
MUST - A compliant implementation must do this.
MUSTN'T - A compliant implementation mustn't do this.
SHOULD - For an implementation to be compliant, it isn't necessary to
do this, but it is highly recommended.
SHOULDN'T - For an implementation to be compliant, it isn't necessary to
avoid doing this, but it is highly recommended.
RFC text may also use combinators:
'{a,b}text' - resolves to - 'atext, btext'
'{a,b}text word {a,b}other' - resolves to:
'atext word aother',
'atext word bother',
'btext word aother',
'btext word bother',
'(a,b)text word (a,b)other' - resolves to:
'atext word aother',
'btext word bother',
5. References
[1] - Most issues on https://github.com/bitwave-tv/bitwave/issues are over a
month old.
Nexus
Aug 24, 2020, 5:51:01 PM8/24/20
to RFC Committee
TL:DR? for the "walloftext.txt"
NO HOW DO YOU FIT MATH INTO WRITING
'{a,b}text' - resolves to - 'atext, btext'
'{a,b}text word {a,b}other' - resolves to:
'atext word aother',
'atext word bother',
'btext word aother',
'btext word bother',
'(a,b)text word (a,b)other' - resolves to:
'atext word aother',
'btext word bother',
dvdrw
Aug 24, 2020, 5:58:51 PM8/24/20
to rfccom...@bitwave.tv
The file is a copy of the text in the email. The 'combinators' are there so the following examples are well-defined:
- Typing /(un)ignore will (un)ignore a user. - resolves to:
- Typing /ignore will ignore a user
- Typing /unignore will unignore a user
- Typing /{uni, i}gnore will {uni, i}gnore a user. - resolves to:
- Typing /ignore will ignore a user
- Typing /ignore will unignore a user
- Typing /unignore will ignore a user
- Typing /unignore will unignore a user
It's a quick shorthand for all of this, so you don't have to
waste space/time clarifying which pairs are valid, and which
aren't.
Jim
Sep 12, 2020, 9:46:38 PM9/12/20
to rfccom...@bitwave.tv
Vote to adopt this RFC1
--
You received this message because you are subscribed to the Google Groups "RFC Committee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rfccommittee...@bitwave.tv.
0 new messages