Discussion about using a backlog milestone for older issues and PRs

[echoix]

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is.
I noticed that a lot of issues and some PRs have been here for a long time, and their milestones get bumped at each release, many times. It also makes that when looking at what we want to have finished and working for a release, we are overwhelmed by about 250 active issues to address, but for a large number of these, there doesn't seem to have an intention of working on them for that release, no one really works on it or would work on it in the quantifiable future.

Describe the solution you'd like
A clear and concise description of what you want to happen.
I want to start a discussion about the project's opinion on using an additional milestone (or in a lesser case, a label) to mark some older, long-standing issues that need to be fixed, or PRs that should get merged at a point, but they are stalled and missing the bandwidth to be finished. These would be for issues/PRs that don't deserve to be closed, but aren't the current focus for the release.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features
you've considered.

A label could also be used, to mark these kind of issues, or we could explore a bit more the usage of the "projects" feature.

Additional context
Add any other context or screenshots about the feature request here.
Narrowing a bit more the scope for a release might give us a clearer picture of what there is to do, and maybe allow us to do releases a bit more quickly, before it becomes sooooo big, and that users have to wait months or maybe a year before getting a new release. It lessens the chance that we miss some bigger breaking changes, since I've got the impression that an important part of the userbase stays in touch with the grass community, either here, from the mailing lists or more, so that makes them more susceptible to always use beta or unreleased-but-from-a-release-branch version since they need to use some feature that they contributed to/got fixed at some point.

Note that the release cadence isn't the driving force here, I'm trying to see if there are some frictions points that make imagining a release a too big goal to simply be an obvious thing that could be done in the span of a couple of weeks when we feel like it. I didn't dig out all the documentation that could answer if the releases are at a fixed date/interval, but I want to see if it is that release cadence that causes us to have that project organization/management, or it is the current organization/management that makes the current release cadence the only reasonable one.

This is like a long-term vision discussion.

[echoix]

Is there an objection that I create a milestone either named "Backlog" or "Future" (as some Microsoft repos use)? It's been two months without any discussions.

I'd start triaging low activity/abandoned issues/PRs that aren't really planned soon.

[echoix]

@neteler opinions?

[neteler]

Sorry, this fell behind the event horizon in my mailbox...

[neteler]

I like the idea of flagging (labeling in GH speech) older, long-standing issues and PRs that should be merged after some further work but are stalled due to lack of bandwidth.

The word "Future" might be better than "Backlog" which is rather a specific term.

So: my support for a label called "Future".

[petrasovaa]

Hm, why not backlog? I guess I wouldn't immediately understand what label "future" means.

[echoix]

For issues, backlog seems more obvious that it isn't something that we are currently working on. For PRs, Future works better since the work is done, but not scheduled yet. Or waiting for an undefined release. But we usually aren't waiting for an undefined release, we go straight to the current or the next one, which we already have our milestones.

[echoix]

Overall, it's really to help out to know if a certain release has everything planned completed.

And as always, it's just a kind of labelling, it there is interest in an issue, it will simply be prioritized. We just need to untangle 3+ year old issues instead of dragging them at each milestone.

[wenzeslaus]

I'm for having "Future" milestone. I have seen another project using that and it made sense to me there.

[marisn]

We just need to untangle 3+ year old issues instead of dragging them at each milestone.

As long as "untangle" doesn't mean closing old but still valid issues.

[wenzeslaus]

Thanks all for the discussion. I created milestone "Future" and started to use it for 8.4.0. Name and description can be changed at any point in the future.