[gmx-developers] GitLab "Milestones"

[Eric Irrgang]

> On Oct 20, 2021, at 8:29 PM, Erik Lindahl <erik.lindahl at gmail.com> wrote:
> But, until that happens we might manually close some issues due to inactivity.

Some of us recently tried to update the guidelines and conventions for issue management, including documenting the labels that seemed to map to the scheme at https://manual.gromacs.org/current/dev-manual/reportstyle.html#general-issue-workflow. Does the current move to close the old issues imply an abandonment of that scheme or is it intended as a sort of "reset" to a "clean slate"?

https://gitlab.com/gromacs/gromacs/-/blob/master/docs/dev-manual/reportstyle.rst provides a little bit more guidance, but not a mechanism. Should we be developing a mechanism for managing issue disposition? Or should we remove the documentation and labels describing issue tracking practices that we do not employ?

> Finally, this relates a bit to the winter planning meeting we have coming up on November 10 :-). I think it's great to add metadata to issues, but let's separate the concept of things we will *decide and close* at the development meeting (then the issue should be marked for the meeting milestone), vs. noting that we would like to discuss it, but don't expect to close it (for this we have the label Discuss::2023 winter meeting).

Is the idea that issues with the `Discuss::2023` label will be either rejected or given a milestone at the meeting? My primary hope for the November meeting is to clarify the status of proposed efforts in the context of the project roadmap.

Recent issues have been closed with comments about assignees and timelines. Should we use the November meeting to discuss/assign/reject timelines? Should we assign issues to 3 people to clarify that issues have a quorum of support to make it through review?

It takes at least three developers (at least one contributor, and at least one core developer reviewer) to commit changes, and development efforts are still frequently killed when they are misaligned with other project priorities. It does not make sense to allocate effort to write (or even to review) MRs for a feature that is not wanted.

Best,
M. Eric Irrgang