Repository navigation
[MNT]: Should we add priority tags to issues / features #28834
Description
Summary
A priority classification may help to sort the topics by what we think is important to work on.
Proposed fix
We could add the following tags:
- prio: release critical - already there only the "prio" prefix is new
- prio: high - features / issues we intend to work on and get done soon.
- (prio: normal) - likely we do not need this tag as all issues not classified should have normal priority by default
- prio: low - features / issues that are worth keeping but we do not intend to work on them in the foreseable future, e.g. "nice to have" or things that we would accept from outside contributors, but won't drive ourselves
High priority features would give a rough guidance, which are relevant next topics (of course everybody can still choose what to work on, but it's a communication of project intent). Low priority, would help me to move topics out of the way. E.g. when somebody requests reasonable but niche feature, we likely don't want to close, but not act on it either.
- are the "high" / "low"
Activity
story645 commented on Sep 18, 2024
I thought we had intended to do this w/ milestoning on issues - anything milestoned for the next release is high priority, anything milestoned for future releases is middle priority, and anything not milestoned but still open is low priority?
I think related but probably more important, b/c I've been bit by it a few times, is how we decide and then communicate that an issue is even ready to be worked on.
timhoffm commented on Sep 18, 2024
Oh, must have forgotten this. I vaguely remember that there was something. Do we have documentation for that? I've only found https://matplotlib.org/devdocs/devel/pr_guide.html#milestones, which I understand is more about where to target basically ready PRs. We may be able to communicate priority via milestones. Though I'm wondering whether it's worth to have a non-timeboxed priority. Targeting an open issue for 3.10 is a much more conret intent than only claiming high-priority.
The one problem I have with this is that new/unclassified issues are the same as low priority. Throwing those two together is problematic because they need different actions: We typically don't want to look at "low priority", but we have to look at new issues. I believe it is important to be able to explicitly mark and downgrade priority, so that they can be filtered out in day-to-day work.
So I belive either fine-tuning and better documenting milestrones or priority tags are reasonable.
story645 commented on Feb 3, 2025
So the GitHub beta has a nice issue classification scheme ,- bug, task, enhancement - that I think could at least help in sorting through the backlog if we turn it on. It's a lot easier to choose between three labels than however many.
timhoffm commented on Feb 3, 2025
I‘m not clear what „task“ would be used for. Bug/enhancement is a useful distinction.
However, I‘m more interested into a classification within those categories: e.g. is it a critical bug, is it something that we want to fix soonish. Is it a bug that would be nice to fix, but no problem if not, or is it maybe a bug that only occurs in exotic circumstances that we basically don’t care about. Similar for features. The exact number and wording of the categories is t.b.d.
story645 commented on Feb 3, 2025
I think of task for all the maintenance stuff - cleanup/refactor/optimize - and enhancement as strictly stuff that doesn't yet exist.
Yeah, but I think the classification is different per category and identifying the categories allows for identifying the decision tree per category:
where want/low effort are probably a good bet for "good first issues" and "want/high effort" are good for like gsocs. - the nice to have but it's not a problem if it fails. Should/could tasks are similar. Which leaves must & need tasks as the priorities. 🤷♀️