[gmx-developers] More on Milestones

[Eric Irrgang]

> On Nov 15, 2021, at 6:46 PM, Erik Lindahl <erik.lindahl at gmail.com> wrote:
> 
> Unfortunately I think we've seen very clearly in the past that we all vote with our actions of not updating issues

I think that until a few weeks ago there were mixed and foggy understandings of what sorts of curation issues were expected to have, and who was responsible for such curation.

For reference, the policy is now as follows. (If someone else has a different interpretation of the decisions that were made, I suggest we try to clarify in a new thread.)
* issues should have assignees if and only if someone is working on them
* issues should be given milestones only when a realistic timeline for delivery has been determined. (Since this requires committed reviewers, delivery targets can only realistically be determined collectively, such as at a biweekly or quarterly planning meeting)
* issues that seem inactive (no milestone, no assignee, or no activity) may be labeled "Status::Stale".
* issues that are "stale" for more than 3 months may be closed
* efforts will be made at upcoming biweekly meetings to reject or accept new issues (assigning milestones, if possible)
* the issue tracking system may be used for long-term planning (greater than 3 months) only if issues clearly indicate that they are being used this way, such as by association with a maintained milestone and responsible party / contact point

> - including several issues where updates were promised as recently as two weeks ago after the major clean-up. I am thus somewhat pessimistic that people are suddenly going to change behaviour and do that spontaneously, although I would like to be wrong :-)

I think it will take at least a few more weeks for people to recalibrate how they track their development efforts; and, possibly, a little more guidance or discussion at the biweekly meetings.

> . This far, not having anybody assigned has just meant that it became Paul's (or presently my) responsibility of checking the status instead, and that's a pattern we need to break.

It can be all of our responsibility.

Both in biweekly telcos and other meetings, groups of developers have begun trying to curate issues, but it was clear that there were a variety of opinions on how this should work. I think that such sessions can be more efficient as the guidelines continue to be clarified. There is certainly no reason to assume that any issue targeting one milestone should be automatically moved to another when the milestone expires.

With that in mind, I think that milestone-based triage (including null milestones) will be useful for simplifying issue lifetime moving forward. This notion seemed to meet with approval (cautious optimism, at least) at the quarterly meeting in November.

> While we can in theory have some feature milestones, overall I think we need to get better at focusing on joint overall milestones for the entire project (with one set for each quarter now) to make sure we make progress through the release cycle.

That would be nice, but it seemed like we concluded at the November meeting that we don't know how to make that happen. The upshot seemed to be that it was not generally possible to plan features and delivery timelines at the all-hands meeting, but only either with the guidance of a specific funding source or within smaller working groups.

> If developers end up creating parallel sets of milestones just for their own features

That is not what was described at the quarterly meeting. We talked about organizing groups of developers who could self-organize, document and manage the collaborative efforts they would participate in. Several efforts were outlined, but in need of follow-up discussions, for modular simulator, simulation input, MdModules framework, and library structure.

> So, I'm perfectly happy to try it e.g. until the end of the year, if we agree there will be fewer open/unassigned gmxapi-related issues after that than we have today, and that long-term-inactive reopened issues will have clear updates what the status is, who is working on them, and when they are going to be completed :-)

The proposed start data for MdModules / library infrastructure efforts for the 2023 release was March 1, I believe. I expect it could take until then to refine the milestone and issue descriptions, but I expect to have any potentially-long-term issues (that I care about) associated with project-level proposals (at least as provisional milestones) by the end of the year.

I think that March 1 is also a reasonable date to target for the goal of having no issues (or milestones) older than 3 months that don't have a clear disposition (and projected lifecycle).

Thanks for the discussion.

Best,
M. Eric Irrgang