Add issue triage guidelines #463
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.
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.
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.
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.
|
is this content superseded by the current version of the triage documentation? Is there anything that can be cherry-picked or can this be closed? Thanks cc @rust-lang/wg-triage |
| @@ -296,7 +331,7 @@ if they require assistance, and inform them that after 14 days this issue will | |||
| be made available to anyone. After 14 days re-add the help tag and deassign them | |||
| if necessary. | |||
|
|
|||
| [list of untagged issues]: https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20sort%3Acreated-asc%20-label%3AC-feature-request%20-label%3AC-enhancement%20-label%3AC-cleanup%20-label%3AC-bug%20-label%3AC-tracking-issue%20-label%3AC-future-compatibility%20-label%3AC-question%20-label%3AC-feature-accepted | |||
| [untagged issues]: https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20sort%3Acreated-asc%20-label%3AC-feature-request%20-label%3AC-enhancement%20-label%3AC-cleanup%20-label%3AC-bug%20-label%3AC-tracking-issue%20-label%3AC-future-compatibility%20-label%3AC-question%20-label%3AC-feature-accepted | |||
There was a problem hiding this comment.
| [untagged issues]: https://github.com/rust-lang/rust/issues?utf8=%E2%9C%93&q=is%3Aissue%20is%3Aopen%20sort%3Acreated-asc%20-label%3AC-feature-request%20-label%3AC-enhancement%20-label%3AC-cleanup%20-label%3AC-bug%20-label%3AC-tracking-issue%20-label%3AC-future-compatibility%20-label%3AC-question%20-label%3AC-feature-accepted | |
| [untagged issues]: https://github.com/rust-lang/rust/issues?q=is%3Aissue%20is%3Aopen%20sort%3Acreated-asc%20-label%3AC-feature-request%20-label%3AC-enhancement%20-label%3AC-cleanup%20-label%3AC-bug%20-label%3AC-tracking-issue%20-label%3AC-future-incompatibility%20-label%3AC-discussion%20-label%3AC-feature-accepted%20-label%3AC-optimization |
fixed link
|
@lolbinarycat would you like to lead this patch to completion (or close it if not relevant anymore)? I think by now it's totally fine it you want to take over |
| Frequently, issues are filed against the wrong repository. In that case, you can | ||
| use GitHub's "Transfer issue" function to move it to the right place. When you | ||
| do that, please also leave a comment explaining why you moved it. |
There was a problem hiding this comment.
We should direct people to the triagebot issue transfer feature, which requires a bit less permissions, although it does require the source repository to have it set up.
|
@apiraino I can try to get around to it, although I'll need someone else to sign off on it since wg-triage hasn't been given write access to the forge yet. |
|
@lolbinarycat I will |
|
Alright, looking at this with fresh eyes, it looks like almost everything that is here already exists in the existing issue triage documentation. The main things I see is that this PR goes into slightly more detail about what to do with feature requests. I do think this could be expanded a bit more, and it would be nice if someone could check the current docs to make sure they aren't missing some team process for feature requests. |
Do you think the documentation about contributing sufficiently expands on this? Maybe linking the new "how to start contributing" for contributors? If you see useful snippets here that are not in other parts of our documentation and want to extract them into a new patch, I am happy to review. |
No description provided.