2010-03-26 Original text

Problem
=======
A number of non-substantial changes have been made using a "fast
track" RfD process.  Some people have found it difficult to
differentiate the "normal" RfDs, with substantive changes, from these
"fast track" RfDs.

Solution
========
Change the "fast track" Request for Discussion to a Request for
Comment (RfC).  Thus the non-substantial changes are clearly
identified.

Discussion
==========
The standards process brings up a number of changes to the text of
the document that are intended to clarify the text rather than
changing the intention of the text.  Such proposals are considered to
be non-substantive as they do not ask a systems implementer if they
support a feature, nor do they change any entitlements of the
application programmer.  As such these proposals, although released
as RfDs, do not progress to the CfV stage.

Although these RfD do not progress to a public CfV, they are subject
to vote at the committee meeting before being integrated into the
document.  Such changes are also listed in the change log (annex H).

A substantive change is one that effects either the programmer or the
systems implementer.  Thus adding or removing a constraint would be
considered a substantive change, while a change in the wording to
clarify the text would be considered a non-substantive change.

Proposal
========
Remove the last paragraph of section d) in the "Proposals Process"
preface:

     If a proposal does not propose extensions or changes to the Forth
     language, but just a rewording of the current document, there is
     nothing for the system implementors to implement, and for
     programmers to use, so a CfV poll does not make sense and is not
     performed.  The proposal will bypass the CfV stage and will simply
     be frozen and go directly to the committee for consideration.

Add the following paragraph to the end of section b):

     If a proposal does not propose extensions or changes to the Forth
     language, but a rewording of the current document, there is nothing
     for a systems implementor to implement, or a programmer to use.
     In such cases the proposal should be published as a Request for
     Comment (RfC).  The proposal will be considered, along with any
     comments, at the next committee meeting.

In section c) replace "RfD" with "RfD/RfC".

In the introduction to the preferred structure to an RfD the text:

     A proposal should give a rationale for the proposal, so that system
     implementors and programmers will see what it is good for and why
     they should adopt it (and vote for it).

     A proposal RfD should include the following sections.

should be replaced with:

     A proposal should give a rationale for the proposal, so that system
     implementors and programmers may see the relevance of the proposal,
     and whether they should adopt (and vote for) it.  The proposal
     should include the following sections, where appropriate.