Issue Triage Workflow RFC #93
Conversation
This RFC proposes expanding functionality to the existing “New Issue” templates in order to allow for more a precise logging and tracking system for GitHub Issues
|
cc @apache/tvm-committers I'll probably send this for a vote in 1 or 2 days since it's been active on the discuss forum for a week without comment. Please take a look. |
I support this. Thanks @hpanda-naut @areusch @denise-k for this RFC. |
|
|
||
| Firstly, this RFC proposes to deprecate a number of the labels we currently use to identify codebase components and add a new set. The new set is much larger than the previous set; however, we believe the new set corresponds to the logical structure of TVM with more granularity. As discussed above, we think it’s important that folks volunteering to maintain a component have an easy way to identify the set of tasks/issues that need their attention. | ||
|
|
||
| To that end, we suggest the a new set of labels. We also suggest to modify `[CONTRIBUTORS.md](http://CONTRIBUTORS.md)` to reflect each Reviewer and Committer’s expertise in terms of these labels. As future work, the Auto-CC subscription tracker can then automatically better tag those with relevant expertise on relevant issues. |
There was a problem hiding this comment.
Thanks @hpanda-naut, I think this proposal is a great improvement to how we handle issues in TVM!
I've got some clarifying questions about the triage-bot:
- Does the
triage-botrun automatically on every created issue, even if the reporter has already provided tags? - Does the
triage-botrun automatically on tracking issues? I think tracking issues are a bit different from bug reports in a sense that a reporter of a bug might not be sure what's causing the issue and therefore what might be the right label, but a reporter of a tracking issue usually knows very well what the work tracked is about.
Another thing regarding to the scopes for the labels - have you thought about including the relevant test directories as well, e.g. tests/python/contrib/test_ethosu/? A lot of the issues reported are in a form "this tests fails in CI and I have no idea why".
|
|
||
| Issues can have multiple labels tagged, although we ask community members to exercise their judgement and file issues in as few components as the situation necessitates. | ||
|
|
||
| Contributors can propose a new label by posting on the Discuss forum. Requests should include adequate scoping to justify the label, as was done in this doc. Labels can similarly be retired via a proposal on Discuss. |
There was a problem hiding this comment.
What if the contributor wants to extend the scope of a label (e.g. when they have recently added another relevant file), would they have to go through forum as well?
There was a problem hiding this comment.
In general, I think this should be at the discretion of the project--right now, I think that means at the discretion of triagers/committers. For minor extensions of scope (i.e. adding a new file as you say), I think a committer could exercise this discretion independently. For major extensions of scope (i.e. expanding "ir" sub-label to include a new class of IR), this could be posed on the forum.
Additionally, right now there isn't any sort of division of responsibility over the created set of labels. This is covered under Future Work (and in my mind, would be actuated by modfiying CONTRIBUORS.md to state areas of committer/reviewer focus in terms of these labels rather than the somewhat arbitrary set that exist there now). Given all of these factors at play now and that the RFC vote passed, I'd like to suggest we proceed with committer discretion for now. I'd be happy to keep discussing this on a follow-on Discuss thread or RFC PR if that seems problematic to you.
There was a problem hiding this comment.
Thanks @areusch for getting back on this! I've got no problem with the label scopes being in the discretion of committers, makes sense to me.
I believe my questions about what's the point of a bot triaging tracking issues have not been addressed, but I reckon I was very late with commenting here and that's really a minor issue, so no objections to this having been merged :)
This RFC proposes expanding functionality to the existing “New Issue” templates in order to allow for more a precise logging and tracking system for GitHub Issues