New flow for GitHub issues #496
AprilSylph
started this conversation in
Tech Office
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I was trying to add this to the contributing doc, but given that the current number of collaborators is three (including me), I don't think it's needed. Anyway, I'm thinking about installing Stale here now that I'll probably soon become [SECRET REDACTED], and its options had me thinking about how issue labels are used right now, and how to improve them in a way that is both understandable by people and by Stale.
How issue labels were used before was... not very well-defined outside of the issue templates' automatic labels. So it's time for some clear rules:
First, we should do our best to confirm issues (obviously). If a bug can be reproduced, a feature request seems feasible, or a documentation issue can be understood, it should be considered confirmed. Otherwise, it should be left alone so it can be closed automatically by Stale after extended inactivity.
Next, all confirmed issues should be marked as such. This can be done in one of three ways:
This applies to all issue types. For example, since #234 is realistically doable but not something I want to put on my own plate (at least not yet), I've added the help wanted label.
If you see an issue you want to work on, removing the help wanted label and assigning yourself is a good way to show that you intend to work on it. But if you aren't completely sure about wanting to work on it, leaving it as-is is fine too. You do not need to be assigned to an issue to open a pull request to close that issue, nor will the issue be assigned to you based on your pull request.
I believe this system will work very effectively for communicating intention. Just remember that intention and reality are not always the same; if an issue is assigned to someone else, you are still free to work on that issue yourself.
Beta Was this translation helpful? Give feedback.
All reactions