Propose an RFCs Process (#1731)

* Add the RFC RFC

* Fix some small typos

* Update PR link

* architected -> designed

rfcs/0000-rfc-process.md

@@ -0,0 +1,71 @@
+- Feature Name: `rfc_process`
+- Start Date: 2022-05-03
+- RFC PR: [microsoft/windows-rs#1731](https://github.com/microsoft/windows-rs/pull/1731)
+
+# Summary
+[summary]: #summary
+
+The "RFC" (request for comments) process is intended to provide a consistent and controlled path for new features to enter the windows-rs library ecosystem, so that all stakeholders can be confident about the direction the library is evolving in.
+
+# Motivation
+[motivation]: #motivation
+
+The `windows` crate has experienced rapid change and experimentation in the past 2 years. This experimentation has been
+invaluable, but it is important to start solidifying design. The outcome of following the RFC process should ultimately be:
+
+- less churn - once features are integrated they typically change very little, especially to outside users
+- features are generally of higher quality
+- there is a shared design ownership stewarded by all windows-rs stakeholders
+
+# Guide-level explanation
+[guide-level-explanation]: #guide-level-explanation
+
+Introducing new features or new internal architecture to the windows-rs ecosystem requires creating an RFC (request for comments) which allows others to comment on and suggest improvements to proposals for changes.
+
+An RFC should be opened when the following criteria are met:
+
+- The author has a fully formed idea of the feature and can express in detail how it will work.
+- There has been at least some discussion of the feature beforehand (i.e., the RFC should not be a surprise to contributors).
+- The feature has far reaching consequences to users or contributors of the windows-rs ecosystem, and it would be difficult to reverse. This criterion should be applied more strongly for user facing changes than for internal architecture.
+- There is potential for disagreement among contributors or users for how the change should be designed.
+
+The process for opening an RFC is simple:
+
+- Ensure there is an existing issue on the windows-rs repo where the feature has at least been discussed and there seems to be some consensus that an RFC would be appropriate.
+- Fill out the [RFC template](./0000-template.md) with sufficient information to address all concerns.
+- Engage in conversation on the RFC and revise it until concerns are addressed (either by changing the RFC or justifying why the concern is not relevant).
+- Once conversation on the RFC has reached a steady state and all concerns have been addressed, windows-rs maintainers will either accept the RFC and merge it or provide a reason for why it should be closed.
+
+# Reference-level explanation
+[reference-level-explanation]: #reference-level-explanation
+
+**Accepting an RFC**: an RFC will be accepted when there is no longer meaningful conversation left on the RFC, and all concerns have been sufficiently addressed. All core maintainers of the windows-rs ecosystem should be consulted on whether they believe the previous criteria has been met. Since maintainers of the RFC are also engaging in the meaningful conversation, there is no need for a written justification for why the RFC has been accepted.
+
+# Drawbacks
+[drawbacks]: #drawbacks
+
+The RFC process require a certain amount of energy to maintain and also limits the amount of open experimentation that can be done in production releases. This ultimately means that development of windows-rs will slow some. However, this should be acceptable as the quality of features that do land will generally be much higher and the likelihood of needing to revert large changes will be much smaller.
+
+# Rationale and alternatives
+[rationale-and-alternatives]: #rationale-and-alternatives
+
+The [RFC process](https://github.com/rust-lang/rfcs) has had proven success in the Rust community. While the Rust language RFC process is not perfect it has successfully ensured properties that we deem as desirable including stability, high-quality features, and wide consensus from many stakeholders.
+
+As an alternative, we could continue to allow experimentation in code, discussing changes as PRs. However, such a process is generally much less rigorous than the RFC process and requires implementation work before ensuring that the design itself has wide support. Such a process is generally much more wasteful than trying to arrive on design consensus before implementation begins.
+
+The other alternative is to continue to iterate by introducing changes, cutting releases, and gathering feedback. This process leads to a lot of churn and not only makes it hard to arrive at good designs, but also actively hinders our goals of working towards stabilization.
+
+# Prior art
+[prior-art]: #prior-art
+
+As discussed, the Rust language has used the RFC process to great success, and most of the [criticisms](https://www.ncameron.org/blog/the-problem-with-rfcs/) of the process deal with problems that become much more apparent at scale. However, the goals for the windows-rs RFC process defined in the motivation section are very much achievable despite some of the drawbacks of the RFC process experienced by the Rust community.
+
+# Unresolved questions
+[unresolved-questions]: #unresolved-questions
+
+- We may have to experiment with what constitutes a trivial change and what requires an RFC and how this differs for user facing changes vs internal changes.
+
+# Future possibilities
+[future-possibilities]: #future-possibilities
+
+Much like the Rust project, we may in the future want to adopt additional processes around stabilization and lightweight process for internal changes (e.g. [major change proposals](https://github.com/rust-lang/rfcs/blob/master/text/2904-compiler-major-change-process.md)). Whatever we may wish to adopt in the future, it should be compatible with this RFC proposal.

rfcs/0000-template.md

@@ -0,0 +1,79 @@
+- Feature Name: (fill me in with a unique ident, `my_awesome_feature`)
+- Start Date: (fill me in with today's date, YYYY-MM-DD)
+- RFC PR: [microsoft/windows-rs#0000](https://github.com/microsoft/windows-rs/pull/0000)
+- Issue: [microsoft/windows-rs#0000](https://github.com/microsoft/windows-rs/issues/0000)
+
+# Summary
+[summary]: #summary
+
+One paragraph explanation of the feature.
+
+# Motivation
+[motivation]: #motivation
+
+Why are we doing this? What use cases does it support? What is the expected outcome?
+
+# Guide-level explanation
+[guide-level-explanation]: #guide-level-explanation
+
+Explain the proposal as if it was already an existing feature being explained to an end user. That generally means:
+
+- Introducing new named concepts.
+- Explaining the feature largely in terms of examples.
+- Explaining how users should *think* about the feature, and how it should impact the way they use windows-rs ecosystem. It should explain the impact as concretely as possible.
+- If applicable, provide sample error messages, deprecation warnings, or migration guidance.
+- If applicable, describe the differences between teaching this to Windows programmers new to Rust and Rust programmers new to Windows.
+
+For implementation-oriented RFCs (e.g. for internals), this section should focus on how contributors should think about the change, and give examples of its concrete impact. For policy RFCs, this section should provide an example-driven introduction to the policy, and explain its impact in concrete terms.
+
+# Reference-level explanation
+[reference-level-explanation]: #reference-level-explanation
+
+This is the technical portion of the RFC. Explain the design in sufficient detail that:
+
+- Its interaction with other features is clear.
+- It is reasonably clear how the feature would be implemented.
+- Corner cases are dissected by example.
+
+The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work.
+
+# Drawbacks
+[drawbacks]: #drawbacks
+
+Why should we *not* do this?
+
+# Rationale and alternatives
+[rationale-and-alternatives]: #rationale-and-alternatives
+
+- Why is this design the best in the space of possible designs?
+- What other designs have been considered and what is the rationale for not choosing them?
+- What is the impact of not doing this?
+
+# Prior art
+[prior-art]: #prior-art
+
+Discuss prior art, both the good and the bad, in relation to this proposal. Does this feature exist in other libraries and what experience have their community had?
+
+This section is intended to encourage you as an author to think about the lessons from libraries, provide readers of your RFC with a fuller picture.
+If there is no prior art, that is fine - your ideas are interesting to us whether they are brand new or if it is an adaptation from other libraries.
+
+# Unresolved questions
+[unresolved-questions]: #unresolved-questions
+
+- What parts of the design do you expect to resolve through the RFC process before this gets merged?
+- What parts of the design do you expect to resolve through the implementation of this feature before stabilization?
+- What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC?
+
+# Future possibilities
+[future-possibilities]: #future-possibilities
+
+Think about what the natural extension and evolution of your proposal would be and how it would affect the project as a whole in a holistic
+way. Try to use this section as a tool to more fully consider all possible interactions with the project in your proposal.
+Also consider how this all fits into the roadmap for the project.
+
+This is also a good place to "dump ideas", if they are out of scope for the RFC you are writing but otherwise related.
+
+If you have tried and cannot think of any future possibilities, you may simply state that you cannot think of anything.
+
+Note that having something written down in the future-possibilities section is not a reason to accept the current or a future RFC; such notes should be
+in the section on motivation or rationale in this or subsequent RFCs. The section merely provides additional information.