Issues are not feature requests #2299
Conversation
Centril
added
the
T-core
I have admit that I'm guilty of this too... |
|
I'm definitely 👍 on making a change here, but until we have any team process around the issue tracker, I'd avoid recommending any use of it tbh. cc @rust-lang/core |
|
GitHub does let you turn off issues entirely, so that would be convenient. |
|
@Manishearth We have certain pull as a community (?). Can we ask GitHub for this ability perhaps? |
|
No, I'm saying GitHub already has this feature; so it is certainly easier to just close all issues and turn the tracker off instead of inventing a more specific set of criteria. |
Oh, my bad - misread your comment as the negation of what you said ;) We should change the
|
|
Yep. Will do once we come to a rough consensus on what we wish to do here.
…-Manish Goregaokar
On Wed, Jan 17, 2018 at 11:10 PM, Mazdak Farrokhzad < ***@***.***> wrote:
No, I'm saying GitHub already has this feature; so it is certainly easier
to just close all issues and turn the tracker off instead of inventing a
more specific set of criteria.
Oh, my bad - misread your comment as the negation of what you said ;)
We should change the README.md to reflect this change in recommendation
as it currently says
<https://github.com/rust-lang/rfcs/blob/master/README.md#before-creating-an-rfc>
:
The most common preparations for writing and submitting an RFC include
talking the idea over on #rust-internals, filing and discussing ideas on
the RFC issue tracker, and occasionally posting "pre-RFCs" on the developer
discussion forum for early review.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#2299 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABivSGc_Z5mZpzi5HJjrZ8xykKFDqyQZks5tLjB7gaJpZM4RhtUp>
.
|
|
It would be a pity to lose all of the discussions that already exist in the issue tracker, though... Perhaps the following approach might help:
|
Does turning off the issue tracker remove the issues? Doesn't it just make it impossible to start new ones? |
Yeah. Either way, I plan to triage all of the issues. If we choose a policy, I'll close everything that doesn't satisfy whatever criteria we pick. If we choose to close it down entirely, I'll comb through it for valuable discussions and try to migrate them to internals myself, or ensure someone else does it. We would wait a while before closing the tracker entirely. (Goes without saying that all closed issues will get a comment suggesting they move to internals, probably from a bot)
I believe the issues still exist, but can't be found without a link. |
|
Perhaps all of the issues that were opened before this decision could be moved to another repo, and then slowly closed as formal RFCs are written? Any new issues open would be closed immediately, perhaps by a bot. This could provide the immediate benefit of removing clutter in this repo while not immediately getting rid of the issues or discussions. I'm personally not in favour of removing everything to internals as there's a lot of discussion already here that could be preserved, even if new discussions should go on internals. |
|
TL;DR: I'm in favor of tracking (major) changes to Rust in issues here. Feature requests that need discussion should begin their life cycle on internals, and then move into an RFC or PR implementing them, and features that don't need discussion should start off as a PR. We should close feature requests on rust-lang/rust and rust-lang/rfcs, asking authors' to move them to internals or PRs implementing them. So this has been a topic that I've thought about somewhat extensively for a while, and I don't think there's a good solution for us today. We currently have 3 main places for discussion/issues for Rust: rust-lang/rust, rust-lang/rfcs, and internals.r-l.o. I believe that the core goals for any solution are:
Search is a non-solved problem anywhere. I think GitHub is better than Discourse at search, but it's hard to say concretely. Neither is great, or really all that good. The current state is that we try to direct people to internals or to the issue tracker here from rust-lang/rust for feature requests. We can certainly aggressively close issues that are feature requests, but then we run into two problems: the definition of feature request and negative impact ("they don't care about my problem"). There are quite a few issues filed on rust-lang/rust that are in a middleground between reporting a bug and requesting a new feature. For example, rust-lang/rust#45838 is an expansion of the existing recursive call lint. We classify it as a feature request today, but arguably, it could be considered a bug that the existing lint doesn't catch this case. Similar cases exist in the other direction. The negative impact problem is perhaps harder to solve, but could be avoided with clearer guidance in the various README and CONTRIBUTING files. A bot that automatically moves the issue could work as well. In general, we can see that based on current tagging, there are 360 feature requests on the rust-lang/rust repository. Moving these elsewhere could be good, but also somewhat harmful to the current guidance to contributors to Rust. It's also true that for many of the standard library feature requests, there's really no particular obvious need for the issue. They request addition of methods or relaxation of bounds that would take 5-10 minutes to put up a PR for (well, at least, for a somewhat experienced Rust developer) and we could discuss on the PR itself. Ideally, we could ask the community to help out with these, put up PRs, allowing the libs team to review and approve. Many of them don't even necessarily need approval, as landing them in an unstable state isn't really a problem. I, personally, would love to see the feature requests that warrant discussion move elsewhere, probably onto internals. If no one other than the author is inclined to discuss, then it seems like there's a relatively low chance that we'll see sufficient momentum to warrant the feature for now; and it's likely we might need an RFC. Feature requests that don't need discussion I believe should be closed in favor of a PR implementing them being put up to streamline the process. |
|
I like to think of issues here as "keeping track of ideas for future reference" (including as a status tracker), which internals is even less suited for. (I'm not saying "therefore it needs to stay exactly as it is", only that "post to internals instead" doesn't feel like an appropriate substitute.) |
|
I think stackoverflow.com might provide a better venue for some issues raised here recently, so maybe users who raise such issues repeatedly could gently be pushed over there. I've no yey/ney feelings on this particular proposal really, but.. If you need new rules then it's okay to grandfather in existing issues. You need not even enforce new rules perfectly consistently or even wait until excessive issues becomes problematic. Internals' software (Discourse) is very slow due to bloated and needlessly interactive javascript. I keep web/icon fonts disabled because they're bad for performance and acts as trackers, but that doesn't help much. Ain't worth your time to migrate software of course, but I wanted to single out Discourse being awful. |
|
I want to agree with that, but I also am not sure that there's much, if any, worth to keeping track of ideas for future reference. That is, unless it's an idea that is relatively large (i.e., custom allocators) and something that we're going to actively discuss from now and into the future, I don't see how keeping an issue around will be helpful. Could you elaborate on why you think that's useful? |
|
'Issue tracker' implies a greater sense of up-to-dateness and...tracking than a forum does. My (uninformed) vague impression is that on forums people will prefer to create new threads linking to old ones, rather than just bumping old ones. It's also trickier to close threads in favour of an older thread. So if you want to watch the single source of truth on where something is up to, it's much better to click subscribe on github. There are also assorted niceties, like github cross-references, that let you see what other things might be related and who's talking about the issue. I dug up #1022 recently and thought it was neat someone had followed up two years after the initial raising of the issue with some thoughts. Looking through the old issues, there's one from 2014 on SIMD that had a comment added when the newer SIMD RFC happened - people were notified about something they were interested in. It makes some sense to me to have them in the same repo because a lot of the feature requests in issues could only possibly be solved by RFCs, so you can more easily tie together any relevant discussion. That said, I wouldn't say no to some cleanup, e.g. with triage every 6 months - if an issue could be reasonably said to have been addressed, it can be closed and if there are aspects that haven't then people can raise new issues. For example #276 mentioned |
|
I'm all for more aggressive triaging, but redirecting people to internals would be a mistake. I'd probably close non-actionable research-related issues (a la "investigate formal verification of Rust code"), library extensions (you can make a crate on crates.io) and unrealistic language extensions (some period of time + judgment of a single lang or compiler team member would be enough). Regarding redirecting to internals. |
|
I've been convinced that we should utilize GitHub for feature request tracking. I think that those issues should still go into rust-lang/rfcs, though. Some will evolve into RFCs, others may be implementable after discussion, but either way, that work I believe should happen away from rust-lang/rust.
So a problem that has arisen in the past with this is that neither lang team nor compiler team members have much time, or inclination, to browse issues looking for things to close. It's likely we can ease the process (e.g., present a queue of "likely closeable" issues), but even then, I have doubts that we'd get sufficient interest from teams (libs for std/test issues, lang and compiler team for additions to the language) to be able to feasibly triage issues. Do you have thoughts on how to fix that problem? Am I wrong about people on these teams not wanting to help close issues? |
|
Would it make sense to have a pre-RFCs repository? Something that's sort of a middle ground between rust-lang/rfcs and internals. Basically, stuff here is specifically about tracking the formal RFC process and postponed RFCs, while that repo holds everything else that would otherwise go here. |
|
I'd be happy to help with some of the cleaning, but I've been unsure of protocol even for things about which I'm fairly certain. Like I'm confident #274 can be closed (because of pending MIRI stuff, size_of being Hmm, this sure doesn't seem to be a new problem: #375 |
|
@Mark-Simulacrum Unless I'm misunderstanding something(?), the whole discussion is about issues on the I already have this repo watched so I'd also be willing to help triage and label things and such if that'd be helpful (as I already do occasionally, but I only have comment privileges), if it doesn't involve any hard commitment. |
|
I certainly am going to help triage this repo based on what we decide here. I've been doing it a bit already but it's kinda hard to tell what should be closed. Part of the problem of using this repo for discussing feature requests is that there aren't folks actually discussing stuff here. Post a feature request on internals and you're probably going to get some discussion. Post a feature request here, and most likely it will go largely unnoticed. So this becomes a place where folks dump random feature requests and nobody really does anything about it. Even if people did discuss, there's no end-goal for these since we don't WONTFIX things. They either close after an RFC, or stay indefinitely open, causing more clutter. The only thing the issues here are useful for is meta-tracking RFCs, and often to track well-known wishlist items that people are generally aware of. Which is why my PR here suggests letting team members use this to keep track of things; but in general it can be looser -- if it's clear that there is a lot of folks wanting a problem to be solved, anyone can list it here in an issue. |
|
@clarcharr
I think it would be okay to reuse this repo.
Some time ago most people didn't even have rights to do anything in this repo! |
Sounds good; I've been doing that for all new RFCs and issues =) |
|
I think this might have already been suggested somewhere, but what if we have a bot that goes around looking at all the issues. If an issue has not received a comment in the last month, the bot makes a warning post "This issue looks inactive and will be closed automatically if it does not received further discussion. Please feel free to discuss further on IRC/discourse or file an RFC if the ideas are fully fleshed-out". If the issue does not receive more comments in the following month, it is closed by the bot. The OP can reopen later if they wish to revive it. |
|
That would force the issue to be triaged at least once a month by someone on the thread. |
|
IME that works well for bug reports since folks need to repro to verify validity. For feature requests, there's never a reason not to keep it alive so folks will just tell the bot "this is still valid, don't close it". I guess making it clear that there has to be discussion (not just an assertion of "this is still applicable") makes sense |
|
@Manishearth There are issues in the issue tracker that haven't been touched since 2014! It's hard to know if these issues are actually still applicable. I imagine there are a lot of issues that have been solved by some other features in the meantime. Moreover, while I think the discussions are meaningful, discussions of features that are unlikely ought to be closed to reduce clutter. A casual reader is extremely unlikely to go through 700 issues many (most?) of which are unlikely to ever happen. But they might glance through the list if it was much shorter and the issues are actually full of active discussions. |
|
So one thing that I'd like to point out here is that foreign language communities often find the RFC repo to be the most direct and open way of asking for feature requests, and I worry that redirecting them to an English-only discussion forum would create more friction and cause them to shy away from discussing their ideas. |
|
I mean, this is a discussion forum too. It's perfectly ok to drop a feature request on internals and let others flesh it out if you don't feel equipped to communicate; we can be clearer about that. |
|
I'm curious why an (English-only) issue tracker is seen as more open/accepting of feature requests than an (English-only) discussion forum. Most issue trackers I've seen at least attempt to have some sort of "confirmed/accepted issues only please" requirement, while forums are rarely stricter than "stay vaguely on-topic and don't be a jerk", so I would've expected the exact opposite. Is this a general social/cultural thing we have no control over, or is https://internals.rust-lang.org/ "doing something wrong"? |
|
The core team discussed this during our last meeting, and we decided that we're not ready to change the status quo here. As such, we'd like to see this PR updated to change the README to indicate that the issue tracker here isn't going to be actively looked at by Rust's teams: the status quo as we understand it. Our reasoning for not changing the status quo currently is that we don't believe that there's a solution that we can come to consensus around today. Of course, people interested in discussing such a solution are welcome to do so, either in an issue here or on internals.r-l.o, as per usual. It's likely that a single place for feature requests will eventually be decided upon, but we believe that today isn't the right time for that. |
|
amended. r? @Mark-Simulacrum I kinda don't like a solution of "we allow issues but won't look at them" -- either we look at them, or we don't allow issues -- this middle ground is going to be confusing since folks are going to file issues and there's no way to redirect them now. I guess we could comment "you may get more attention on the internals repo instead" on each issue but if we're going to do that I don't see why we can't just close the issues (or shut off issues entirely) |
|
Thanks! So to clarify the core team doesn't like this solution either, but we don't have the time currently to figure out how best to resolve this problem of where to discuss and aggregate feature requests. I myself hope that we can do so soon, but it may be some time. I'll start FCP with a disposition to merge soon (need to get rfcbot updated to accept me as a core team member). |
|
@rfcbot fcp merge I believe we're ready to go on this and that the current text represents the consensus of the core team (though we are not happy with the state, and expect more work in this area in the future). |
rfcbot
added
the
proposed-final-comment-period
|
Team member @Mark-Simulacrum has proposed to merge this. The next step is review by the rest of the tagged teams:
No concerns currently listed. Once these reviewers reach consensus, 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. |
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
rfcbot
added
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
rfcbot
added
the
final-comment-period
|
The final comment period is now complete. |
Currently issues get often used as feature requests, where they basically get ignored because nobody is watching the issues.
I'd like to propose we stop allowing issues as feature requests and severely restrict the issues on this repo to tracking issues
and general housekeeping.
We instead encourage feature requests to become discussions on the internals forum.