rfc, future-work: initial version.

Author: Centril

text/0000-future-work.md

@@ -0,0 +1,166 @@
+- Feature Name: `future_work`
+- Start Date: 2018-10-11
+- RFC PR: _
+- Rust Issue: N/A. The RFC is self-executing.
+
+# Summary
+[summary]: #summary
+
+Adds a *"Future work"* 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 work, 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-work
+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 permantent space to idea-dump
+while writing an RFC.
+
+## For the team
+
+The holistic perspective that a future work section can offer may also
+help the relevant subteam 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-work 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 work"* 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 work
+>
+> 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 subteam.
+>
+> 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 work, you may simply state
+> that you cannot think of anything.
+
+# 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-work 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 inteded 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 work
+
+Another potential drawback is that readers of the RFC will focus too much
+on what is written in the future-work 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 but the proposed name is customary.
+
+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 work. 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 work
+[future-work]: #future-work
+
+[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.