Announce tracking issues in FCP #2449
Conversation
| # Guide-level explanation | ||
| [guide-level-explanation]: #guide-level-explanation | ||
|
|
||
| TWiR (This Week in Rust) shall announce tracking issues which are currently in |
There was a problem hiding this comment.
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.
|
|
||
| Actively seeking out nightly features has the downside one doesn't know to which | ||
| ones to pay attention, as there are too many and it is better to play with the | ||
| ready ones. |
There was a problem hiding this comment.
Nit: This sentence should be reworded :) You are missing "that" between "downside" and "one" as well as missing a "to" after "attention".
| 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Here's an example of a standard library addition that hasn't had much discussion in the FCP for stabilization:
- Tracking issue for std::iter::repeat_with rust#48169 , everyone who has reacted save for me and scott are lib team members..
- Stabilize Box::leak rust#48110 , this one had even fewer reactions...
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...).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.".
| * 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 FPC and mandate that it can't proceed unless it gets a certain |
There was a problem hiding this comment.
Fixed. Seem's like I'm old school, still remembering good old pascal 😇
Centril
added
the
T-core
Centril
changed the title
|
I'm thinking about one thing. Most of the RFC is out of the jurisdiction of the core team ‒ as TWiR is not official project. There's this one point about policy about lack of feedback ‒ but as I wrote above, I'm maybe just stating the obvious, that if there's less feedback than expected that it's out of ordinary. So, my question is, should this be left open for the team to have a look at it, or would that be only waste of time and I'd do better by closing it? |
|
This has been suggested multiple times [1] [2] and I'm happy to include this list in TWiR, starting next issue. |
|
I think it'll be helpful if the contents of http://rusty-dash.com/ can be displayed in an <iframe> on /r/rust (with some CSS added, of course). But i don't know if that's possible at all. |
|
🎉 https://this-week-in-rust.org/blog/2018/06/05/this-week-in-rust-237/#tracking-issues-prs 🎉 Since it has started happening, I'm going to close this. |
Summary
Announce unstable features close to stabilization or needing community attention
through TWiR.
Full text
Meta
(not part of RFC text)
I'm not sure this needs a full RFC. It was suggested I go for one, but if it is already agreed on and happening, it probably isn't worth the process overhead.
Also, this is my first attempt at any RFC, so if I missed something important, tell me, I'll fix it.