RfC (Wording changes)

[ RfDs/CfVs | Other proposals ]

Poll Standings

See below for voting instructions.
[ ] I agree with the proposed alteration to the document text.
Peter Knaggs
Leon Wagner
Bernd Paysan
George Hubert
Mark Wills
Hans Bezemer
David N. Williams
[ ] I do not agree with the proposed alteration to the document 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

  1. 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 system implementor to implement, or a programmer to use. In such a case, 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.
  2. In section c) replace "RfD" with "RfD/RfC".
  3. 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 why they should adopt (and vote for) it. The proposal should include the following sections, where appropriate.

Change History

2010-03-26
Original text

Author

Peter Knaggs
Engineering, Mathematics and Physical Sciences,
University of Exeter, Exeter, Devon EX4 7QF, England

Voting Instructions

Fill out the ballot below and email it to <vote@forth200x.org>. Your vote will be published (including your name, without email address) here. You can vote (or change your vote) at any time and the results will be published here.

Ballot

Please mark the statements that are correct for you (e.g., by putting an "x" between the brackets).
[ ] I agree with the proposed alteration to the document text.
[ ] I do not agree with the proposed alteration to the document text.
If you feel that the text does not cover all the aspects you would expect, then please make an informal comment. These will be reported in addition to the formal votes. Note that the best time to voice such issues is the RfD stage. Alternatively, you could propose a counter RfD.

Credits

Proponent: Peter Knaggs
Votetaker: Peter Knaggs