General comments and discussion of the sixth draft of the R7RS should be sent to the public discussion list scheme-reports at scheme-reports.org. Working Group 1 has monitored and will continue to monitor this list, responding and issuing tickets for actionable items.
Interested parties are encouraged to use the informal comment process as much as possible, as the formal process outlined below creates additional work for the already overburdened editors. A formal comment should be filed only if the results of the informal process are not satisfactory.
Formal comments should also be sent to the same public discussion list, scheme-reports at scheme-reports.org, to encourage timely feedback from other members of the community.
To distinguish the post as a formal comment, simply say so in the post itself by writing "Formal Comment" as the first line at the top of its body, and provide the additional information listed below. If all of those requirements are met, then a ticket will be issued and the commenter will be notified of its issue, progress, and resolution. A complete list of formal comments and responses will be provided when the final draft is submitted for ratification.
Formal comment requirements
A formal comment is valid and will be approved only if:
- it is submitted to scheme-reports at scheme-reports.org,
- it is not obviously spam,
- it is not a followup to an earlier post, and
- it contains the following required information, clearly marked:
- the submitter's name
- the submitter's email address
- the draft version of the report (draft 6, draft 7, etc.)
- a one-sentence summary of the issue
- a full description of the issue
The following categorization information should also be provided if at all possible:
- The type of issue:
- Other (specify)
- The priority of the issue:
- Name of the relevant chapter or section of the R7RS (optional):
- Lexical conventions
- Basic concepts
- Primitive expressions
- Derived expressions
- Syntax definitions
- Record type definitions
- Equivalence predicates
- Pairs and lists
- Control features
- Input and output
- Formal syntax
- Formal semantics
- Formal derived expressions
- Standard libraries
- Standard features
- Additional material
Posters should also include, where appropriate:
- references to relevant specific page numbers
- proposals for how to fix the issue
- dependencies on other issues
If an editor chooses to reject a formal comment, other than obvious spam, the editor will email the submitter with an explanation of the problem, at which point the submitter may correct the problem and resubmit.
Formal comment tracking
Formal comments will be recorded in working group 1's Trac ticket system under the milestone "Public Review", with the original reporter cc'ed. (If the formal comment fails to supply some or all of the requested categorization information, or supplies information that is plainly incorrect, then the member of the working group who records the comment should supply or correct that information. If the formal comment calls for editorial or substantive changes, then the member of the working group who records the ticket should also file ordinary ballot tickets for those changes. If a formal comment corrects an obvious mistake or requests uncontroversial editorial changes, then the member of the working group who records the formal comment may apply those corrections and/or changes directly to the draft report, subject to the working group's normal internal review).
All formal comments will receive a formal response (marked as such) from the editors before the R7RS small language is finalized. The formal response will describe the action taken and the rationale for that action. Individual editors are encouraged to reply informally, but such notes are not to be taken as formal responses.
If in the view of the WG no action should be taken in response to the comment, it will receive a default formal response such as "The WG has reviewed the comment and decided to take no action on it."
Last updated 14 February 2012.