[gmx-developers] More on Milestones

[Eric Irrgang]

Hi All.

I wanted to take a discussion from https://gitlab.com/gromacs/gromacs/-/issues/3179#note_733291785 to the mailing list to avoid cluttering the issue comments, and because the scope is broader than that.

First, I want to apologize for not writing to the list sooner to explain some updates to some tracked issues.

Peter and I found some limitations in gmxapi that seem very important to solve before the gmxapi 0.3 release. Since there was already existing documentation about several of the issues, and because I wanted to provide a clear, open, and organized description of the issues and path to resolution, I created a "gmxapi 0.3" Milestone: https://gitlab.com/gromacs/gromacs/-/milestones/127

I am salvaging some stale issues. Some issue descriptions may not be updated right away, but I promise to clean up the "gmxapi 0.3" milestone and any issues I associate with it in a timely manner.

Again, I apologize for not communicating clearly and immediately. Erik Lindahl noticed the surprising re-opening of stale issues and we started to bump into each other trying to update them.

Erik: I think most developers would be happy to do the menial labor of applying whatever updates and status changes are deemed necessary, if directly contacted. (It seems like unnecessary overhead for such things to land on any single person's shoulders.)

In addition to saving you some time, delegating issue updates would also allow for some reduction of noise in the issue comments.


# kanban board

I think the progress tracking of the milestone board is very informative regarding the described tasks. https://gitlab.com/gromacs/gromacs/-/milestones/127

For better or for worse, the columns are assigned according to whether an issue has an assignee and whether it is open or closed.


# issue assignees

I am putting some issues under the Milestone while I review them, and may permanently close them (not just "Stale" label and closed due to inactivity). We had been saying that whether an issue has an assignee should map to whether it is actively being worked on. I don't want to indicate that I am working to resolve an issue when really the issue is being investigated for whether it will be addressed and on what timeline.

Neither Erik nor I know off-hand of a way to change the kanban column rules easily. As such, I think our efforts would be better spent finding ways to make the existing GitLab logic work for us. (I wasn't sure whether this sort of column editing was unavailable or whether it was just something I didn't have access to.)

In the absence of easy rules editing, I think it would be most effective to use the built-in rule based on assignee, and find another way to indicate to other devs that the issue is being actively managed.

Is it sufficient that the issue is associated with an actively maintained Milestone and marked with a "Stale" tag, which marks an issue for closure after a further 3 months? I think it is clear that I am taking responsibility for the "gmxapi 0.3" milestone and its associated issues. I hope we can agree that the utility of the Milestone interface is more valuable than the ability to filter on the attribute of whether an issue has an assignee.


# Follow-up

I will be making many updates to a lot of gmxapi-related issues over the coming weeks. In particular, all of the issues labeled for "winter discussion" will be either closed or moved to new feature-oriented milestones (per discussion on the mailing list and at the quarterly meeting).

It will take me a while to update all of the text in the issue descriptions. Some will be closed after some inspection. And I expect there will be some iterating with other developers to refine milestone descriptions or the specific milestones to which issues are grouped, before accepting or rejecting milestones to particular timelines. Per the meeting, it sounds like some of the planned efforts will not be possible to clarify until as late as March.


# Alternatives

I have previously been urged to do all gmxapi project management and issue tracking through the common GROMACS schemes. If a low-noise issue tracker is more valuable than complete and open gmxapi project management, I could move some or all of the gmxapi issue tracking to a separate system. I still have a lot of content in the old GitHub issue tracker (I was urged restraint on migrating those issues to the GROMACS tracker). It might improve both repository and issue maintenance to create gitlab.com/gromacs/gmxapi. However, I think this could reduce awareness of gmxapi efforts, and all of the activities described at the quarterly meeting were explicitly coupled to design and development in the core library, as well.


# Summary

I would like to reopen some of the issues that were closed in the recent purge. Those that have not yet been marked "Status::Stale" will be so-labeled to help identify them. Until their disposition is clear, I would like to mark such issues as unassigned.

I understand the concern about orphan issues. I support the policy of closing issues that remain stale and inactive for a few months, or that do not have a well-understood milestone (with a timeline) or an assignee for longer than a quarterly planning cycle.

I don't think the issues I will be updating need an assignee to avoid becoming a problem. Please give me a month or two to clean things up.


Best,
M. Eric Irrgang