# RFC Examples

## Python Enhancement Proposal

### Pros

1. The PEP author is responsible for building consensus within the community and documenting dissenting opinions (ownership).
2. Text files in a versioned repository.
3. A single PEP contains a single key proposal or new focussed idea.
4. If in doubt, split your PEP into several well-focused ones.
5. PEPs are posted to discuss.python.org for comments.
6. Vetting an idea publicly before going as far as writing a PEP is meant to save the potential author time.
7. Once the champion has asked the Python community as to whether an idea has any chance of acceptance, a draft PEP is prepared, formatted, of high quality, and to address initial concerns about the proposal.
8. Proposal should be submitted as a draft PEP via a GitHub pull request. The draft must be written in PEP style.
9. You can lint the PEPs documents.
10. Sample reStructuredText PEP Template. https://peps.python.org/pep-0012/
11. Reasons for denying PEP status include:
a. duplication of effort,
b. being technically unsound,
c. not providing proper motivation or
d. addressing backwards compatibility, or
e. not in keeping with the Python philosophy.
12. Standards Track PEPs consist of two parts, a design document and a reference implementation.
13. It is generally recommended that at least a prototype implementation be co-developed with the PEP.
14. The critera for discussion of a PEP:
a. The forum is appropriate to the PEP’s topic.
b. The thread is publicly available on the web
c. The discussion is subject to the Python Community Code of Conduct.
d. A direct link to the current discussion thread is provided.
15. If a PEP undergoes a significant re-write or other major, substantive changes to its proposed specification, a new thread should typically be created in the chosen venue to solicit additional feedback.
16. If no suitable candidate can be found, then the PEP will be marked as Deferred until one is available.
17. Once a PEP has been accepted, the reference implementation must be completed. When the reference implementation is complete and incorporated into the main source code repository, the status will be changed to “Final”.
18. A PEP may also be marked as “Provisional”. This indicates that the proposal has been accepted for inclusion in the reference implementation, but additional user feedback is needed before the full design can be considered “Final”.
19. Once a PEP is deferred, a PEP editor can reassign it to draft status.
20. A PEP can also be “Rejected”.
21. The “Withdrawn” status is similar to deffered - it means that the PEP author themselves has decided that the PEP is actually a bad idea, or has accepted that a competing proposal is a better alternative.
22. PEP sections:
a. Preamble
b. Abstract (~ 200 words)
c. Motivation
d. Rationale
e. Specification
f. Backwards compatibility
g. Security implications
h. How to teach this
i. Reference implementation
j. Rejected ideas
k. Open issues
l. Footnotes
m. Copyright/license
23. PEPs are UTF-8 encoded text files using the reStructuredText format.
24. The PEP text files are automatically converted to HTML (via a Sphinx-based build system) for easier online reading.
25. Each PEP must begin with an RFC 2822 style header preamble.
26. PEPs may include auxiliary files such as diagrams. Such files should be named pep-XXXX-Y.ext
27. All support files may be placed in a subdirectory called pep-XXXX.
28. It occasionally becomes necessary to transfer ownership of PEPs to a new champion, because the original author no longer has the time or interest in updating it or following through with the PEP process.
29. A PEP editor must be added to the @python/pep-editors group on GitHub and must watch the PEP repository.
30. Have a CI build and lint checks pass without errors, and there are no obvious issues in the rendered preview output.

### Cons

1. Only core developers of the CPython reference interpreter and their elected Steering Council, and developers of other implementations of the Python language specification.
2. Three types:
a. Standards Track (new feature),
b. Informational (design issue, or information),
c. Process (procedures, decision-making process, tools, enviroment and require community consensus).
3. PEP editors are individuals responsible for managing the administrative and editorial aspects of the PEP workflow. It is by invitation only.
4. The PEP author(s) will need to find a sponsor for the PEP. Ideally, a core developer sponsor is identified, but non-core sponsors may also be selected with the approval of the Steering Council.
5. The PEP editors approve it (note that this is not the same as accepting your PEP!), they will squash commit your pull request onto main.
6. Previously appointed PEP-Delegates may choose to step down, or be asked to step down by the Council.
7. Multiple stages of PEP. https://peps.python.org/_images/process_flow.svg.
8. Formal documentation of the expected behavior should be maintained elsewhere, such as the Language Reference for core features, the Library Reference for standard library modules or the PyPA Specifications for packaging.
9.

### References

1. PEP 1: Purpose and Guidelines. https://peps.python.org/pep-0001/
2. PEPs. https://github.com/python/peps/tree/main/peps

## Rust

### Pros

1. Defines what changes are needed for RFC:
a. Any semantic or syntactic change to the language that is not a bugfix.
b. Removing language features, including those that are feature-gated.
c. Changes to the interface between the compiler and libraries, including lang items and intrinsics.
d. Additions to std
2. Some changes do not require an RFC:
a. Rephrasing, reorganizing, refactoring, or otherwise "changing shape does not change meaning".
b. Additions that strictly improve objective, numerical quality criteria (warning removal, speedup, better platform coverage, more parallelism, trap more errors, etc.)
c. Additions only likely to be noticed by other developers-of-rust, invisible to users-of-rust.
3. Guidelines for changes in:
a. language changes
b. library changes
c. compiler changes
4. Define reasons for rejection:
a. Low quality proposals,
b. proposals for previously-rejected features,
c. those that don't fit into the near-term roadmap
d. do not present convincing motivation,
e. demonstrate lack of understanding of the design's impact,
f. are disingenuous about the drawbacks or alternatives
5. Get initial feeback on Zulip server and developer discussion forum.
6. You can post pre-RFCs on the developer forum.
7. Use markdown file.
8. After filing PR, they will rename PR to RFC number.
9. Each pull request will be labeled with the most relevant sub-team, which will lead to its being triaged by that team in a future meeting and assigned to a member of the subteam.
10. Do not allow squash or rebase commits after they are visible on the pull request.
11. At some point, a member of the subteam will propose a "motion for final comment period" (FCP), along with a disposition for the RFC (merge, close, or postpone).
12. An "active" RFC implies nothing about what priority is assigned to its implementation, nor does it imply anything about whether a Rust developer has been assigned the task of implementing the feature.
13. Authors should not expect that other project developers will take on responsibility for implementing their accepted feature (ownership).
14. Only very minor changes should be submitted as amendments.
15. More substantial changes should be new RFCs, with a note added to the original RFC.
16. The sub-team may schedule meetings with the author and/or relevant stakeholders to discuss the issues in greater detail, and in some cases the topic may be discussed at a sub-team meeting. In either case a summary from the meeting will be posted back to the RFC pull request.

### Cons

1. RFC issues on this repo for discussion, are not actively looked at by the teams.
2. Offline discussion will be summarized on the pull request comment thread.
3. They do not require consensus amongst all participants in the RFC thread to accept the RFC.
4. Before actually entering FCP, all members of the subteam must sign off.
5. The FCP lasts ten calendar days, so that it is open for at least 5 business days. It is also advertised widely, e.g. in This Week in Rust.
6. If new arguments or ideas are raised, the FCP is canceled, and the RFC goes back into development mode.
7. Some RFC pull requests are tagged with the "postponed" label when they are closed (as part of the rejection process).

### References

1. RFCs. https://github.com/rust-lang/rfcs
2. Language design RFC. https://github.com/rust-lang/rfcs/blob/master/lang_changes.md
3. Library sub-team RFC. https://github.com/rust-lang/rfcs/blob/master/libs_changes.md
4. Compiler RFC. https://github.com/rust-lang/rfcs/blob/master/compiler_changes.md

## Glasgow Haskell Compiler

### Pros

1. Proposed change to the compiler, the GHC/Haskell language, or the libraries in the GHC.* module namespace.
2. These include:
a. Syntactic change to GHC/Haskell
b. A major change to the user-visible behaviour of the compiler
c. Addition of major features to the compiler
3. Changes to the GHC API or the plugin API are not automatically within the scope of the committee.
4. A significant change may be asked by the maintainers to involve the committee and ask the contributor to write a formal proposal.
5. Principles are defined for the language design and language stability.
6. The proposal stages:
a. Draft
b. Submission to Haskell community for discussion
c. PR review
d. Committee review (one member steps us a shepherd, and generates consensus within the committee within four or five weeks).
e. Accepted | Needs Revision | Rejected | Dormant
f. Implemented
7. Proposals are written in either ReStructuredText or Markdown.
8. Feedback ensures that a variety of perspectives are heard, that alternative designs are considered, and that all of the pros and cons of a design are uncovered.
9. We particularly encourage the following types of feedback,
a. Completeness: Is the proposal missing a case?
b. Soundness: Is the specification sound or does it include mistakes?
c. Alternatives: Are all reasonable alternatives listed and discussed. Are the pros and cons argued convincingly?
d. Costs: Are the costs for implementation believable? How much would this hinder learning the language?
e. Other questions: Ask critical questions that need to be resolved.
f. Motivation: Is the motivation reasonable?
10. The committee members have committed to adhere to the Haskell committee guidelines for respectful communication and are subject to the committee bylaws.
11. Good criteria:
a. It should follow the design principles.
b. It should be self-standing.
c. It should be precise.
d. It should offer evidency of utility.
e. It should be copiously illustrated with examples.
12. Decision criteria:
a. Utility and user demand.
b. Elegant and principled.
c. Does not create a language fork.
d. Fit with the language.
e. Specification cost.
f. Implementation cost.
g. Maintainability.
h. It should conform to existing principles.
i. Backward compatibility.

### Cons

1. The secretary will label the pull request with Pending shepherd recommendation and start the committee process.
2. The secretary drops a short mail on the mailing list, informing the committee about the status change.
3. Discussion among the committee ensues, in two places:
a. Technical discussion takes place on the discussion thread, where others may continue to contribute.
b. Evaluative discussion, about whether to accept, reject, or return the proposal for revision, takes place on the committee's email list, which others can read but not post to.

### References

1. GHC Proposals. https://github.com/ghc-proposals/ghc-proposals
2. Principles. https://github.com/ghc-proposals/ghc-proposals/blob/master/principles.rst