Meta-RFC: Future possibilities #2561
Conversation
Centril
added
the
T-core
|
cc @rust-lang/core |
|
I'm in favor of this addition; providing this context can indeed be very important. This may eventually be subsumed by a "staged RFC process", but I don't see harm in adding it to the template for the time being. |
|
I agree that this change seems very reasonable. One addition that I think could help resolve some if the concern over commentary specifically about future work might be to include an explicit sentence in the template that the future work section is not cause for acceptance of the current RFC or future RFCs; i.e. it provides information but does not have any benefits or downsides to said future work. I think being explicit about this could be quite helpful in the short-term. |
|
@Mark-Simulacrum great point, fully agreed! |
|
@Mark-Simulacrum Good idea; I added a paragraph; is that sort of along the lines you were thinking? |
text/0000-future-work.md
Outdated
| > Note that having something written down in the future-work 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. |
There was a problem hiding this comment.
I think this is pretty much exactly what I was thinking though I'd swap this and the next paragraph.
Ideally we'd indicate that this text is likely desirable to leave in the RFC (since it's both for authors and - perhaps even more so - for readers). I'm not sure how or if we should do that, though.
There was a problem hiding this comment.
Moved it around :)
My experience is that it isn't necessary (and it clutters the text) to keep the paragraph in the RFC since in the RFCs I wrote there was never too much unwarranted focus on the future work instead of what was actually proposed. However, if we notice it starts to become a problem, we can always change our minds later on and add a note to keep it.
|
OK, with these revisions in place, I'm going to go ahead and call for full review from the core team: @rfcbot fcp merge |
|
Team member @aturon has proposed to merge this. The next step is review by the rest of the tagged teams:
No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
rfcbot
added
proposed-final-comment-period
|
@rfcbot fcp reviewed I have some mixed feelings about this idea. On the one hand, I appreciate the arguments put forth in the RFC. I approve of authors thinking holistically, of course, and this may be a good way to encourage that. On the other hand, I am nervous. It feels like having this section in the template implies that — if the RFC is accepted — there is a certain amount of "blessing" to the vision that is laid out in the future work. I am aware that the template offers a disclaimer, but that text will not appear in the final RFC. I might be happier if we titled the section "Future possibilities", or something like that, to help make the "speculative" nature of this section clear. I think my concerns are already present in the RFC, in the text that worries about the possibility of "dickering" over the future work overshadowing or just adding on to the main RFC itself. I suppose that if @Centril claims this has not been true in practice I shouldn't worry much. In general, my desire is still that we will move towards something more like the "staged RFC" process that I've proposed before. In that model, I imagine that "future work" would well be described by issues on the repository (probably with appropriate labels). It seems to me that this section could still be useful in that world, though, by proving links and perhaps a bit of context for the team that is not actively participating in that development. |
|
In case it wasn't clear, I decided "all in all" that I'm 👍 — if we want to rename to "Future possibilities" that seems good to me but I don't care to block on that. |
|
Renamed the section to "Future possibilities" to make @nikomatsakis happier and to better reflect the speculative nature of the section's contents. |
rfcbot
added
the
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
rfcbot
removed
the
proposed-final-comment-period
Do all teams have a product vision and roadmap, and if so, how do I find them? |
For 2017, we had the "ergonomics initiative"; Eventually, an RFC will be made that establishes the roadmap for the entire project for 2019. @aturon may be better equipped to elaborate on your question. :) |
|
@Centril Right, so that's a one-year over-all roadmap. Still lacking the vision as well as the subteam split, i e, reading the RFC it sounds like
...and that, I have not found (yet), at least not in some kind of structured and easy-to-find fashion? |
|
@diwic Yeah, the situation isn't ideal; I agree completely. I think for the language team we'll be brainstorming product visions soon, but I don't have anything solid to offer yet, sorry. |
|
@Centril no worries, I'm not demanding anything :-) While I agree that visions and roadmaps would be very nice to have, I was mostly confused by the wording of the RFC: It's hard to comply to a vision that is not defined. |
|
@diwic Ah, hehe :) I think that wording can be ignored while there isn't a well defined roadmap / vision or you can just operate on the previously known roadmap / vision if there is any. |
rfcbot
added
the
finished-final-comment-period
|
The final comment period, with a disposition to merge, as per the review above, is now complete. |
rfcbot
removed
the
final-comment-period
|
Huzzah! This RFC has been merged! Tracking issue: Not available; The RFC is self-executing. |
🖼️ Rendered
📝 Summary
Adds a "Future possibilities" section to the
0000-template.mdRFC 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.💖 Thanks
To @aturon for a fruitful discussion about the evolution of the RFC process.