Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Announce tracking issues in FCP #2449

Closed
wants to merge 1 commit into from
Closed

Announce tracking issues in FCP #2449

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
92 changes: 92 additions & 0 deletions text/0000-ready-for-stabilization-announcements.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,92 @@
- Feature Name: ready_for_stabilization_announcements
- Start Date: 2018-08-26
- RFC PR:
- Rust Issue:

# Summary
[summary]: #summary

Announce unstable features close to stabilization or needing community attention
through TWiR.

# Motivation
[motivation]: #motivation

As Rust as a language matures, it is no longer necessary to use nightly features
for a day to day development. This results in less experimentation with features
before they stabilize and in noticeable lack of feedback (or feedback that
arrives after stabilization instead of before).

Actively seeking out nightly features has the downside that one doesn't know to
which ones to pay attention to, as there are too many and it is better to play
with the ready ones.

# Guide-level explanation
[guide-level-explanation]: #guide-level-explanation

TWiR (This Week in Rust) shall announce tracking issues which are currently in
Copy link
Contributor

@Centril Centril May 26, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TWiR is afaik not an official Rust project and is not owned by the organisation.
Therefore, I am not sure that the RFC process can mandate anything to TWiR.
At most we can ask the editors of TWiR, @nasa42 and @llogiq, to include the info we want.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see :-). You mentioned them, so maybe they'll come to have a look here ‒ I'll wait some time after RustFest before trying to contact them in some more direct way.

final comment period, just like with RFC PRs in FCP.

In addition, it's also possible to announce tracking issues of features where
increased attention and input from community is desirable.

# Reference-level explanation
[reference-level-explanation]: #reference-level-explanation

The TWiR newsletter already allows inclusion of „key PRs“ in the „Final Comment
Period“ section.

This RFC asks for inclusion of tracking issues with visible effects in the
„Final Comment Period“ section, and allows also including tracking issues where
there's an explicit call for experimentation and feedback.

Furthermore, it proposes to visually distinguish RFCs from tracking issues and
to explicitly call for experimenting with the features and providing feedback.

When no or very little feedback arrives on a feature, it might be a signal to
either wait longer or consider if the feature is desired by users at all.
Copy link
Contributor

@Centril Centril May 26, 2018 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sentence seems like it is changing process policy. It is not entirely uncommon for an FCP for an uncontroversial feature to go by with little or no feedback. I don't think that little participation in an FCP should be interpreted as a sign that the feature is undesired.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know how much that constitutes a change in policy. I meant it more like soft suggestion, that lack of feedback is kind of feedback too, but I'm not really sure how soft I'd like that suggestion to be (as mentioned in the unresolved questions).

I know some go without the feedback, but:

  • I hope announcing them would bring them more attention and even the small and uncontroversial ones could get some kind of „looks good“ feedback.
  • I feel there's a space in between of „desired“ and „undesired“ ‒ something like „not cared about either way“. The lack of feedback might signal that the feature is neither harmful nor beneficial in the eyes of people ‒ but it probably depends on the feature itself how to understand that.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's an example of a standard library addition that hasn't had much discussion in the FCP for stabilization:

Generally speaking for an RFC, the "big debate" (and excitement / not...) has already been had so it is not surprising that there is less fuss in the stabilization issues. Even with more exposure, I think small features will still not be talked about much in the stabilization issues. I don't think the teams should evaluate "not much response" as "undesired" and thus it should cause no extra delay (we should take care to not make the process more bureaucratic than as is...).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, not „undesired“, but „not cared about“. I wouldn't say that not much feedback would necessarily mean „don't pass it“. But in case the feature would be something high-profile (for example the async fn), I would be surprised if it didn't receive some feedback from the community. If it did not, it would look suspicious ‒ not a signal to close it, but maybe to ask why.

Or maybe in other words, I could say that receiving significantly less feedback that could be expected, depending on the size and popularity of the feature, should hint at some need for investigation if something is amiss. But maybe that's kind of obvious thing ‒ if the effect of announcing the FCPs would be most features get some feedback, than not receiving it would look out of ordinary without any policy.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Truthfully, I don't think no feedback happens on large features, so I don't think it is necessary to state it. I would interpret little feedback on a large feature that has already had feedback on the RFC as "ok, nothing interesting happened since the RFC, proceeding as planned.".


# Drawbacks
[drawbacks]: #drawbacks

* It adds more things into TWiR, making it longer and competing more for
reader's attention.
* People who want to pay attention to things will feel even more overwhelmed
about everything that happens at each one time.
* It makes the FCP potentially longer, if the relevant team decides to wait for
more feedback.

However, as TWiR is not subject to the stability promise, it can be reverted if
any of the above turns out to be a large problem.

# Rationale and alternatives
[alternatives]: #alternatives

* Do nothing.
* Choose a different medium, for example the internals forum (or choose both).
* Be even stricter and mandate inclusion of all tracking issues to be posted
during their FCP and mandate that it can't proceed unless it gets a certain
amount of feedback and testing ‒ for example two snippets of code actively
using it in publicly accessible places (where it can reasonably apply).

# Prior art
[prior-art]: #prior-art

* The same is already done for RFCs to bring attention to them at the crucial
moment of their life.
* Several discussion threads at random places (reportedly more somewhere):
- https://internals.rust-lang.org/t/idea-mandate-n-independent-uses-before-stabilizing-a-feature/7522
- https://internals.rust-lang.org/t/fortifying-the-process-against-feature-bloat/7608
* RFCs in many communities mandate certain amount of feedback before proceeding
to the final stages ‒ for example the IETF RFC process mandates two
independent implementations that manifest interoperability before letting the
RFC from experimental to final stage.

# Unresolved questions
[unresolved]: #unresolved-questions

* Exact wording of the text.
* Should there be a hard rule about what is included, or some rule of thumb is
enough (for example: if it deserves an announcement at release time, it also
deserves to be seen in TWiR), or should all tracking issues go through this?
* How exactly should be lack of feedback handled?