-
Notifications
You must be signed in to change notification settings - Fork 175
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.
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
Add issue triage guidelines #463
base: master
Are you sure you want to change the base?
Conversation
I personally don't see much value in directing people to rust-lang/rfcs, beyond perhaps making people feel like their issue is tracked "somewhere" -- I don't feel like either T-lang or T-libs actively reads either venue. Nor do they do so on internals, but there is more community feedback there generally speaking and we avoid unbounded queues due to its nature as a forum more than just an accumulation of issues. |
Otherwise though this seems great! cc @rust-lang/lang @rust-lang/libs given that policies here affect your queues in some sense, I would like to know if you feel rust-lang/rfcs is worthwhile as a long-term staging ground, of course other thoughts on the proposal here are welcome. |
Yeah, I think I agree. I just tried to the "Transfer issue" workflow on rust-lang/rfcs#3006, and it's quite a bit more work than selecting a saved reply and hitting "Close with comment", so that isn't ideal either. |
Yes, please don't direct people directly to the RFCs repo. Lang folks do read RFCs there, but we'd prefer to see most language changes go through the project process first. Given that libs is currently adopting a similar process, and thus compiler/lang/libs will all use the same process, it'd be nice to have a single description of that process that we can link to, along with the entry points for that process. |
Issues in [`rust-lang/rust`] should be closed in the following cases: | ||
|
||
* **Language Feature Requests** that might require non-trivial design effort | ||
should closed in favor of the [RFC process] or a discussion on [IRLO]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps we should direct folks to https://lang-team.rust-lang.org/proposing_a_project.html instead
should closed in favor of the [RFC process] or a discussion on [IRLO]. | ||
* **Library Feature Requests** that encompass more than just a small addition | ||
to the standard library should likewise be closed in favor of the | ||
[RFC process] or discussion on [IRLO]. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems like @KodrAus (in rust-lang/rfcs#2979) was suggesting that libs team might adpt a lighterweight process here too...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeh, I think what we've all been working out that would apply to Libs too would see these larger additions run through a staged process that doesn't necessarily require an RFC up-front.
No description provided.