Merge pull request #2561 from Centril/rfc/future-work

Meta-RFC: Future possibilities

0000-template.md

@@ -72,3 +72,24 @@ Please also take into consideration that rust sometimes intentionally diverges f
 - 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 language and 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 and language in your proposal.
+Also consider how the this all fits into the roadmap for the project
+and of the relevant sub-team.
+
+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.

text/2561-future-possibilities.md

@@ -0,0 +1,174 @@
+- Feature Name: `future_possibilities`
+- Start Date: 2018-10-11
+- RFC PR: [rust-lang/rfcs#2561](https://github.com/rust-lang/rfcs/pull/2561)
+- Rust Issue: N/A. The RFC is self-executing.
+
+# Summary
+[summary]: #summary
+
+Adds a *"Future possibilities"* section to the `0000-template.md` RFC template
+that asks authors to elaborate on what natural extensions there might to their
+RFC and what future directions this may take the project into.
+This section asks authors to think *holistically*.
+
+# Motivation
+[motivation]: #motivation
+
+## The benefit for the author
+
+Often times, when an RFC is written, the only thing an author considers
+may be the feature or change proposal itself but not the larger picture
+and context in which the RFC operates in. By asking the author to reflect
+on future possibilities, a larger degree of introspection within the author
+themselves may ensue. The hope is then that they may consider what larger
+effects their proposal may have and what subsequent proposals may be.
+
+[#2532]: https://github.com/Centril/rfcs/blob/rfc/assoc-default-groups/text/0000-assoc-default-groups.md#future-work
+[#2529]: https://github.com/Centril/rfcs/blob/rfc/hidden-impls/text/0000-hidden-impls.md#future-work-1
+[#2524]: https://github.com/Centril/rfcs/blob/rfc/inferred-type-aliases/text/0000-inferred-type-aliases.md#possible-future-work
+[#2523]: https://github.com/Centril/rfcs/blob/rfc/cfg-path-version/text/0000-cfg-path-version.md#possible-future-work
+[#2522]: https://github.com/Centril/rfcs/blob/rfc/generalized-type-ascription/text/0000-generalized-type-ascription.md#possible-future-work
+[#2401]: https://github.com/Centril/rfcs/blob/rfc/mut-pattern-shorthand/text/0000-mut-pattern-shorthand.md#future-work
+[#2421]: https://github.com/rust-lang/rfcs/blob/master/text/2421-unreservations-2018.md#possible-future-unreservations
+[#2385]: https://github.com/Centril/rfcs/blob/rfc/implied-derive/text/0000-implied-derive.md#future-work
+[#2306]: https://github.com/rust-lang/rfcs/blob/master/text/2306-convert-id.md#possible-future-work
+
+The author of this RFC has benefitted personally from writing future-possibilities
+sections ([#2532], [#2529], [#2524], [#2523], [#2522], [#2401], [#2421],
+[#2385], and [#2306]). Said written sections have also caused the current
+author to think more clearly about interactions in each of the written RFCs.
+If for no other reason, these sections offer a permanent space to idea-dump
+while writing an RFC.
+
+## For the team
+
+The holistic perspective that a future-possibilities section can offer may also
+help the relevant sub-team to understand:
+
+1. why something is proposed,
+2. what the long term effects of said proposal is,
+4. how said proposals fit with the product vision and roadmap that the team
+   currently has.
+
+## For readers in general
+
+More generally, the benefits for the teams described above also hold for
+all readers. In particular, a reader can better infer what sort of language
+Rust is turning into given the information in a future-possibilities section.
+Having such a section may also help generate interest in subsequent proposals
+which a different author may then write.
+
+# Guide-level explanation
+[guide-level-explanation]: #guide-level-explanation
+
+This Meta-RFC modifies the RFC template by adding a *"Future possibilities"*
+section after the *"Unresolved questions"*. The newly introduced section is
+intended to help the authors, teams and readers in general reflect holistically
+on the big picture effects that a specific RFC proposal has.
+
+Please read the [reference-level-explanation] for exact details of what an
+RFC author will see in the changed template.
+
+# Reference-level explanation
+[reference-level-explanation]: #reference-level-explanation
+
+The implementation of this RFC consists of inserting the following text to the
+RFC template *after* the section *Unresolved questions*:
+
+> # Future possibilities
+>
+> Think about what the natural extension and evolution of your proposal would
+> be and how it would affect the language and 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 and language in your proposal.
+> Also consider how the this all fits into the roadmap for the project
+> and of the relevant sub-team.
+>
+> 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.
+
+# Drawbacks
+[drawbacks]: #drawbacks
+
+There are three main potential drawbacks:
+
+## The section will be unused
+
+There's some risk that the section will simply be left empty and unused.
+However, in the recent RFCs written by the author as noted in the [motivation],
+this has not been a problem. On the contrary, the very idea behind adding
+this section has come as a result of the experience gained by writing
+such future-possibilities sections in the aforementioned RFCs.
+
+However, some of the RFCs written by the this RFC's author have not had such
+sections. Therefore, if an RFC leaves the newly introduced section empty,
+it is not the end of the world. The section is intended as encouragement and
+recommendation; it is not mandatory as no section in an RFC has ever really been. 
+
+## Higher barrier to entry
+
+[RFC 2333]: https://github.com/rust-lang/rfcs/blob/master/text/2333-prior-art.md#drawbacks
+
+As noted in [RFC 2333], which was the last RFC to extend the template,
+the longer the template becomes, the more work there is to writing an RFC.
+This can raise the barrier to entry somewhat.
+However, we argue that it is worth the minor raise in the bar since
+it is OK for RFCs to leave the section empty.
+
+## Readers reacting negatively on the future possibilities
+
+Another potential drawback is that readers of the RFC will focus too much
+on what is written in the future-possibilities section and not the actual proposal
+that is made in the RFC. This has not been the case in the RFCs mentioned
+in the [motivation].
+
+# Rationale and alternatives
+[rationale-and-alternatives]: #rationale-and-alternatives
+
+1. We could rephrase the section in various ways.
+   It is possible to do such tweaking in the future.
+
+2. We could rename it to "possible future work" or "future work" where the latter
+   is more customary, but we have opted to use a section title that makes it more
+   clear that the contents of the section are not what is accepted but only
+   *possibilities*.
+
+3. We could move the section up and down and around.
+
+4. We could simply not have such a section and leave it up to each author.
+   However, we argue here that it is beneficial to hint at the possibility
+   of providing such a section. It might otherwise not occur to the author
+   that such a section could be written.
+
+# Prior art
+[prior-art]: #prior-art
+
+None of the languages enumerated in [RFC 2333] have such a section proposed
+in this RFC. However, there are plenty of academic papers published which
+do contain sections pertaining to future possibilities. It is customary for
+such sections to be at the end of papers so as to not bore readers and keep
+them reading.
+
+# Unresolved questions
+[unresolved-questions]: #unresolved-questions
+
+None as of yet.
+
+# Future possibilities
+[future-possibilities]: #future-possibilities
+
+[staged]: http://smallcultfollowing.com/babysteps/blog/2018/06/20/proposal-for-a-staged-rfc-process/
+
+It may be the case that we would overhaul the RFC template completely if we
+undertake larger changes to the RFC process itself as is proposed in the
+[staged]-RFCs idea. However, we'll likely want to determine the answers and
+get the information that each section in the current template provides at
+some point during the lifecycle of a proposal.