Proposals Process

In developing a standard it is necessary for the standards committee to know what the system implementors and the programmers are already doing in that area, and what they would be willing to do, or wish for.

To that end we have introduced a system of consultation with the Forth community:

  1. A proponent of an extension or change to the standard writes a proposal.

  2. The proponent publishes the proposal as an RfD (Request for Discussion) by sending a copy to the forth200x@yahoogroups.com email list and to the comp.lang.forth usenet news group where it can be discussed. The maintainers of the www.forth200x.org web site will then place a copy of the proposal on that web site.

    Be warned, this will generate a lot of heated discussion.

    In order for the results to be available in time for a standards meeting, an RfD should be published at least 12 weeks before the next meeting.

    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.

  3. The proponent can modify the proposal, taking any comments into consideration. Where comments have been dismissed, both the comment and the reasons for its dismissal should be given. The revised proposal is published as a revised RfD/RfC.

  4. Once a proposal has settled down, it is frozen, and submitted to a vote taker, who then publishes a CfV (Call for Votes) on the proposal. The vote taker will normally be a member of the standards committee. In the poll, system implementors can state, whether their systems implement the proposal, or what the chances are that it ever will. Similarly, programmers can state whether they have used something similar to the proposed extension and whether they would use the proposed extension once it is standardized. The results of this poll are used by the standards committee when deciding whether to accept the proposal into the standards document.

    In order for the results to be available in time for a standards meeting, the CfV should be started at least 6 weeks before that meeting.

  5. One to two weeks after publishing the CfV, the vote taker will publish a Current Standings. Note that the poll will remain open, especially for information on additional systems, and the results will be updated on the Forth200x web page. The results considered at a standards meeting are those from four weeks prior to that meeting. If no poll results are available by that deadline, the proposal will be considered at a later meeting.

  6. A proposal will only be accepted into the new basis document by consensus of those present at a standards meeting. If you can not attend a meeting, you should ask somebody who is attending to champion the proposal on your behalf.

Should a contributor consider their comments to have been dismissed without due consideration, they are encouraged to submit a counter proposal.

Proposals which have passed the poll will be integrated into the basis document in preparation for the approaching standards committee meeting. Proposals often require some rewording in this process, so the proponent should work with the editor to integrate the proposal into the document.

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.

Author:
The name of the author(s) of the proposal.

Change Log:
A list of changes to the last published edition on the proposal.

Problem:
This states what problem the proposal addresses.

Solution:
An informal description of the proposed solution to the problem identified by the proposal.

Typical use:
Shows a typical use of the word/feature you propose; this should make the formal wording easier to understand.

Remarks:
This gives the rationale for specific decisions you have taken in the proposal (often in response to comments in the RfD phase), or discusses specific issues that have not been decided yet.

Proposal:
This is the formal or normative part of the proposal and should be as well specified as possible.

Some issues could be left undecided in the initial RfDs, leaving the issue open for discussion. These issues should be mentioned in the Remarks section as well as in the Proposal section.

If you want to leave something open to the system implementor, make that explicit, e.g., by making it an ambiguous condition.

For the wording of word definitions, it is normally a good idea to take your inspiration from existing word definitions in the basis document. Where possible you should include the rationale for the definition. Should a proposal be accepted where no rationale has been provided, the editor will construct a rationale from other parts of the proposal. The proponent should work with the editor in the development of this rationale.

Reference implementation:
This makes it easier for system implementors to adopt your proposal. Where possible they should be provided in standard Forth, as defined by this document. Where this is not possible, system specific knowledge is required or non standard words are used, this should be documented.

Testing:
This should test the feature/words you propose, in particular, it should test boundary conditions. Where possible test cases should be written to conform with John Hayes tester.f test harness.

Experience:
Indicate where the proposal has already been implemented and/or used.

Comments:
Initially this is blank. As comments are made on the proposal, they should be incorporated into the proposal. Comment which can not be incorporated should be included in this section. A response to the comment may be included after the comment itself.

Instructions for responding to the poll:
Once the proposal enters the CfV stage, the vote taker will add these instructions to the proposal.

ContributeContributions

PeterKnaggsavatar of PeterKnaggs Revised Proposal ProcessProposal2018-09-21 06:49:42

Authors

  • Andrew Haley
  • Peter Knaggs
  • Leon Wagner
  • Gerald Wodni

Change Log

  • 14/09/2018 Text worked out in workshop at the 2018 Forth Standards Meeting

Problem

Now that the proposal process has been moved onto forth-standard.org the Proposal Process no longer describes the process.

Solution

Replace the Proposal Process in the front-matter of the document with a new process that correctly describes the revised process of proposing change via this site.

Proposal

Replace the text of the Proposal Process in the front-matter with the following:

Proposals Process

This section documents the official process for submission of proposals for changes to the standard.

  1. A proponent of an extension to the standard writes a proposal (previously known as a request for discussion or RfD).

    If the proposal only proposes the rewording of the document, without requiring implementation changes, the proposal should be published as a wording change (previously known as a request for comment or RfC).

  2. The proponent publishes the proposal on forth-standard.org by contributing to a word definition or chapter if applicable, or directly to the proposals section.

    Be warned, this will generate a lot of heated discussion.

    In order for the results to be available in time for a standards meeting, an proposal should be published at least twelve weeks before the next meeting.

  3. Proponents can submit updated proposals, taking any comments into consideration, by replying to their own proposals and marking them as new versions.

  4. Once a proposal has settled down, the proponent submits it to the committee for review by selecting the "Submit for review" button on the proposal's web page.

    The committee reviews the proposal and either requests changes or takes it to the next stage. For a simple change of wording the proposal is frozen and considered at the next committee meeting. For an extension proposal a poll is conducted (previously known as a Call for Votes or CfV).

    The poll allows system implementors to state whether their systems implement the proposal or if it ever will. The poll also allows programmers to state whether they have used something similar to the proposed extension and if they would use it once it is standardized.

    The results of the poll are used by the standards committee when deciding whether to accept the proposal into the standards document. In order for the results to be available in time for a standards meeting, the poll should be started at least six weeks prior to that meeting.

  5. A proposal is only accepted into the new document by consensus of those members present at a standards meeting. If the proponent cannot attend the meeting, they should ask somebody who is attending to champion the proposal on their behalf.

    There are three possible outcomes from the committees consideration:

    • If the committee feels the proposal has merit and wants to encourage experimentation the committee can promote it to an experimental proposal.

    • If the proposal is accepted, it is incorporated into the document. The editor may request clarification from the proponent. Any further discussion requires a new proposal.

    • If the proposal is not accepted, the committee may refer it back to its proponents.

Should a contributor consider their comments to have been dismissed without due consideration, they are encouraged to submit a counter proposal.

The Proposal

In the initial proposal, some issues could be left undecided, leaving them open for discussion. These issues should be mentioned in the Problem or Solution section as well as in the Proposal section.

If you want to leave something open to the system implementor, make that explicit, e.g., by making it implementation dependent.

A proposal should include the following sections.

Author:

The name of the author(s) of the proposal.

Change Log:

A list of changes to the last published edition on the proposal.

Problem:

This states what problem the proposal addresses.

Solution:

A short informal description of the proposed solution to the problem identified by the proposal.

This gives the rationale for specific decisions you have taken in the proposal (often in response to comments), or discusses specific issues that have not been decided yet.

Typical use: (Optional)

Shows a typical use of the word or feature proposed; this should make the formal wording easier to understand.

Proposal:

This should enumerate the changes to the document.

For the wording of word definitions, use existing word definitions as a template. Where possible, include the rationale for the definition.

Reference implementation:

This makes it easier for system implementors to adopt the proposal. Where possible, the reference implementation should be provided in standard Forth. Where this is not possible because system specific knowledge is required or non-standard words are used, this should be documented.

Testing: (Optional)

This should test the words or features introduced by the proposal, in particular, it should test boundary conditions. Test cases should work with the test harness in Appendix F.

Reply