rfcs
rfcs copied to clipboard
rust-lang
Closing issues relevant to T-lang on this repo
My understanding is that T-lang is not interested in following discussion on the RFCs repo that is not actual RFC. Various proposals seem interesting but are unfortunately in the form of issues instead of RFCs. If someone wanted to pursue them as an RFC, they should open it as a PR (following the template where useful, as usual).
@rust-lang/lang I would like to ask that you formally FCP that
- the language team is not going to (formally) take suggestions from GitHub issues on the RFCs repo
- thus T-lang will not act on these GitHub issues as change proposals
- thus that all GitHub issues that are relevant to T-lang on this repo can simply be closed, with a directive to open an RFC or to pursue some other process, as appropriate
FCPing this.
T-lang, do we have consensus that we don't want to have issues on the rfcs repo used to report feature requests? (There are enough other places for feature requests that we actually look at; this isn't one that gets any attention, so we shouldn't give people the impression that it will be effective.)
@rfcbot merge
Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:
- [x] @joshtriplett
- [x] @nikomatsakis
- [x] @scottmcm
- [ ] @tmandry
- [x] @traviscross
Concerns:
- ~~want-to-discuss-nuance~~ resolved by https://github.com/rust-lang/rfcs/issues/3756#issuecomment-3053825480
Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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!
cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns. See this document for info about what commands tagged team members can give me.
I agree with 1 and 2. I don't 3 follows just from those 2. I do however agree with it... specifically the current situation is misleading for people and can create a blessed forum for acrimonious debate, which I'm not a fan of. Put another way, we know github issue threads are not a great forum or technology for discussion, and yet that is the purpose of these issues
@rfcbot resolved
Here's the version I'd agree with:
Issues on the RFC repo are not the place to propose specific changes to the language. That's what PRs to this repo are for. The lang team is never going to review a change proposal submitted as an issue, and such issues can be closed. At the same time, it's fine to use issues in the RFC repo for other reasons. As an example, if someone wanted to create an issue to describe the problem (not the solution) of the orphan rule preventing useful patterns, and use that issue as a place to summarize feedback in preparation for filing an RFC that would then fix that issue, that seems OK, and we'd not want to close that sort of thing.
As an example, I don't really want to see this policy close #3582. The author and those commenting on that issue are not confused about how things work, and it seems fine to read that one as an "ask" for an RFC that fills in the details needed to fully specify this.
There's some gray here, and I'd like a bit more nuance in this policy.
@rfcbot concern want-to-discuss-nuance
I'm going to file a concern as a reminder to discuss this and see if we can either state a consensus on this with a touch of added nuance or agree through discussion that a blanket auto-close policy is right even in light of seemingly-reasonable ones like #3582.
There is a lot of redundancy between this repo’s issues and https://internals.rust-lang.org. This can lead to confusion. Perhaps we should settle on one or the other?
Re-nominating to bring this up again. TBH I think I'd like the blanket "we're just not accepting new T-lang issues for potential features", even thought there are features we agree we'd like, because the overhead of reasonableness-deciding is painful.
Perhaps we could, instead, make a document in the lang repo that people could send PRs to of "lang problem spaces with positive vibes"? Then we could merge or reject those sections (kinda like mini RFC motivation sections) in triage, while still insisting that design and discussion happens in Zulip/IRLO and not in any of these issue trackers.
We discussed this in the lang call today. I agree with @scottmcm that we don't want to be making value judgments on e.g. "whether the feature request in this issue is good enough."
My concerns over this proposal fell into three categories:
One, it seems there are reasonable ways that people could use (and have used) issues in this repository that don't require us to make such value judgments. E.g., as earlier mentioned:
If someone wanted to create an issue to describe the problem (not the solution) of the orphan rule preventing useful patterns, and use that issue as a place to summarize feedback in preparation for filing an RFC that would then fix that issue, that seems OK.
Or, e.g., if someone wanted to file an issue to document a plan of action the person intends to follow through on in a series of RFCs, that sounds OK to me.
Basically, I worry a bit about just seeming too heavy-handed here with closing issues where people might be trying to use them for valid process reasons.
Two, while we take for granted being present on all our platforms -- because we ourselves are on all of them -- I recognize that not everyone in our community is, and that many many people are just on GH. In the call today, a sentiment was expressed that amounted to saying that being on all our platforms is just the minimum bar for interacting usefully with us on these matters, and that consequently we're safe to ignore, for this purpose, those who aren't, but I worry that 1) while it might not seem like a big ask, to us, to require that people leave GH in order to say their piece, that may not be how others experience it, and 2) consequently, I worry that in taking away this relief valve that we might just be pushing the problem elsewhere on GH that we don't want it, e.g. to tracking issues, and that we'll end up needing to lock more of those which causes other problems for us (see e.g. https://github.com/rust-lang/rfcs/pull/3762#pullrequestreview-2999819662).
Three, the goal here is not entirely clear to me. Or, more to the point, it's not clear to me that the goal as I understand it requires this solution. E.g., if we just want people to know that if they have a lang proposal, that it should go in a PR instead, we could solve that by having triagebot autoreply to newly opened issues, or by better crafting our issue templates, or by improving our README, etc. In the meeting, people mentioned other goals, such as the idea that an ever-increasing number of issues represents a kind of tech debt. Probably I just take for granted that all software projects of substance have an ever-increasing set of issues and that whatever underlying debt we have is invariant to this. There's also the matter that we have too an ever-growing number of RFC PRs, and I don't really expect we'll be able to keep that bounded either. There was the thing done, in 2018, of the team going through and summarily closing many things quickly (even where we did eventually maybe want to do those things), but I don't personally look back on that as a successful process to model. It seems OK to me for a PR to remain open as long as it's something we might want to do, just like I think an issue for a bug report should stay open for as long as it's something the project might want to fix.
But, that said, I'm persuaded that others whom I trust aren't too concerned that these will be problems, and in the end, this is a two-way door -- we can always try new and different things -- so I'm happy enough to...
@rfcbot resolve want-to-discuss-nuance @rfcbot reviewed
To give my two cents on those things,
One, I'm fine with issues that are about the state of the repo. For example, "hey this RFC isn't getting included in the book" or something would be a perfectly fine issue. I just don't want "something that may or may not happen in the future", as those are infinite. (And that includes research for an RFC. If someone wants to use GH to collect thoughts for an RFC, I suggest they do that in their fork instead.) For example, I'd keep #3798 because it's a "the process documentation is wrong" issue, not a "here's something that I wish rust would do in the future".
Two, note that both IRLO and Zulip allow one to login with GitHub, so one doesn't even need to make a new account. The extra friction is very low. And really, I don't think one can reasonably drive a feature big enough to need an RFC though implementation and stabilization without being on zulip, these days.
Three, I would say that the reason issue trackers like this show the total number is because anything in an issue tracker like this is tech debt that needs to be dealt with eventually. Contrast IRLO and Zulip, which don't show "total number of threads ever", because it's natural that there's stuff there that just slides into nothingness with no action needed. I suppose the alternative to banning them initially would be to auto-close them after some idle time, but TBH as a user I generally find that more annoying that just saying "no, go elsewhere" initially.
I do think we need an official vibe check place, though, so I'll try to make a proposal somewhere for that.
I do think we need an official vibe check place, though, so I'll try to make a proposal somewhere for that.
I'm rather happy with people just filing and nominating issues in r-l/r for that. That's what we've been doing, and it seems to have been working well. When we accept them, they then just get turned directly into the tracking issue for the lang experiment. E.g. https://github.com/rust-lang/rust/issues/128464.
@traviscross
I'm rather happy with people just filing and nominating issues in
r-l/rfor that.
r-l/r's issue tracker could indeed become the place for "lang vibe checks" (non-RFC proposals). However, I'm worried about some key details. I wonder (1) how you would want to go about communicating the fact that you need to explicitly nominate such a proposal (by labeling it I-lang-nominated with a bot) to a much larger & wider audience and (2) crucially how you would plan on dealing with the resulting increased traffic.
Re. (1): I claim that the majority of ~~"vibe check"~~ non-RFC proposals are one-offs that come from people that are not deeply familiar with the various processes the Rust project uses on GitHub. I'm very much including all preexisting open[^1] r-l/r issues labeled T-lang excluding C-tracking-issue, of course. At the time of writing, they amount to 605 (via). Yes, I'm not only counting the 126 feature requests (via) and the 89 enhancements (via) but also the 177 T-lang bugs (via) since all of them ultimately require a lang nomination to get unblocked[^2].
These Rust users simply don't know about I-lang-nominated and in practice issue triagers and compiler contributors very rarely recommend it unless they're personally interested in the proposal. You've linked to https://github.com/rust-lang/rust/issues/128464 as a success story. However, that's an outlier because its author is not a stranger to the project's processes very likely even before their involvement in R4L). Should we start recommending lang nominations for new T-lang issues[^3]? Let's be realistic, who wouldn't take the offer?
That naturally leads me to (2): Are you accepting of a new influx of nominations? It's hopefully all clear to us that the current processes (I-lang-nominated or meeting proposal over at r-l/lang-team) act as a great filter where IRLO/URLO, the issue tracker of this repo, the one of r-l/r, and somewhat the main T-lang Zulip channel are the honeypots.
[^1]: I'm only counting open ones here to avoid accidentally including T-lang issues that potentially followed different processes (like from a decade ago or so).
[^2]: If the authors gets lucky, someone may someday find the issue and open a PR for it which will then get nominated by a compiler reviewer.
[^3]: r-l/r issues are marked T-lang at the discretion of issue triagers.
Having a dedicated process for "simple" decisions would be useful imo. T-compiler has MCPs and T-libs has ACPs, but T-lang has nothing. That's what led me to opening rust-lang/rust#141704, as it's something that doesn't feel like it needs a full RFC.
I know that the team is relatively backlogged, so perhaps they don't want to open the metaphorical floodgates, but at the very least it would provide a structured process and the potential for improved communication.
r-l/r's issue tracker could indeed become the place for "lang vibe checks" (non-RFC proposals)
To be a bit more constructive, I think it's doable but you might want to employ some new procedures like some kind of two-stage nomination process where "T-lang delegates/triagers" triage / sort / pre-process such r-l/r T-lang issues / non-RFC proposals.
I know that the team is relatively backlogged
no longer backlogged: #t-lang/meetings > Triage meeting 2025-07-09 @ 💬 :)
T-compiler has MCPs and T-libs has ACPs, but T-lang has nothing
T-lang used to have lang MCPs over at https://github.com/rust-lang/lang-team/issues and officially it still has "lang experiments" (https://lang-team.rust-lang.org/how_to/propose.html#proposing-a-change-to-the-language) but it doesn't specify how to find a lang liaison (in practice: Zulip or through a lang-nominated issue).
officially it still has "lang experiments"
Lang experiments still require an RFC at some point, though, whereas ACPs do not (just FCP).
I wonder (1) how you would want to go about communicating the fact that you need to explicitly nominate such a proposal (by labeling it
I-lang-nominatedwith a bot) to a much larger & wider audience and (2) crucially how you would plan on dealing with the resulting increased traffic.[..]
These Rust users simply don't know about
I-lang-nominatedand in practice issue triagers and compiler contributors very rarely recommend it unless they're personally interested in the proposal.
Actually, I think this is OK and is a desirable filter. One of our criteria for accepting a lang experiment has traditionally been that we have an experienced contributor -- someone we trust -- driving or at least mentoring the implementation work. As I see it, the purpose of a vibe check for a feature request is to lead to a lang experiment, and so it's only useful to do this if the experiment is otherwise plausible.
In this way, these r-l/r issues aren't so different from non-feature request issues. We often have other questions nominated for us to ask for our vibes on, e.g., whether we think some probably-wrong behavior is worth fixing and whether we'd be likely to accept the breakage if someone were to start plowing through this. These too tend to be nominated by familiar faces; not all bug reports get immediately nominated for lang. There's a filtering step. Someone around here tends to have to be interested.
The final comment period, with a disposition to merge, as per the review above, is now complete.
As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.
This will be merged soon.
You've linked to https://github.com/rust-lang/rust/issues/128464 as a success story. However, that's an outlier because its author is not a stranger to the project's processes very likely even before their involvement in R4L.
The story behind that issue is that I brought it up during the fortnightly call between R4L and T-lang, and a T-lang member asked me to file it as an issue. I asked where to file it because I was not sure whether T-lang had an MCP/ACP equivalent, and I was told to file it on r-l/r.
