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.

I thought we had intended to do this w/ milestoning on issues

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.

anything not milestoned but still open is low 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.

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.

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.

I‘m not clear what „task“ would be used for. Bug/enhancement is a useful distinction.

I think of task for all the maintenance stuff - cleanup/refactor/optimize - and enhancement as strictly stuff that doesn't yet exist.

I‘m more interested into a classification within those categories:

Yeah, but I think the classification is different per category and identifying the categories allows for identifying the decision tree per category:

• bugs - critical, not critical, exotic but like all bugs should probably be fixed
• tasks - I like the "must/should/could" scheme here, where effort is kinda built into if it's a should or could
• enhancements - I think this is probably a need-want X effort matrix: need/high effort, need/low-effort, want/high, want/low

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. 🤷‍♀️