[gmx-developers] GitLab "Milestones"

[Eric Irrgang]

Hi Erik. Thank you for the response. I'm still unclear, so I hope I'm able to rephrase my questions better below.

> On Oct 25, 2021, at 4:37 PM, Erik Lindahl <erik.lindahl at gmail.com> wrote:
> 
> I think the overall flow is fine...


Is there an expectation that we are tracking this flow with Status labels? It is unclear how or why some issues have Status labels and others do not, but it seems like a useful practice if we can clarify how it is supposed to take place.

>  but it will get difficult if we only ever close issues after extensive discussions and reaching complete consensus in the team - just imagine if that was necessary to open them!  So, my preference would be...

Yes. But what is the new mechanism by which we will do a better job of managing the issue life cycle, moving forward? Do some or all of us have a responsibility to apply labels independently? As a group (during biweekly telcos or at quarterly planning meetings)? Do we expect to only close issues that time out to inactivity, or are we actively trying to find a way to close issues in a more considered way?


>> Recent issues have been closed with comments about assignees and timelines....
> "Recent" is relative; I think I stopped at residues that were at least ~1 year old...

I meant "recently-closed issues" (in reference to your heroic purge). I'm sorry the wording was ambiguous.

My question was two-fold.

1. Since the issues were closed without labeling them "Status::inactive", it is harder to apply a search filter that distinguishes between conversations on fixed bugs, rejected ideas, or productive conversations that merely stalled out.
* Do we plan to use (increase the use of) Status labels in the future?
* Is there any objection to adding the Status::inactive label to issues that were closed in the recent purge to make it easier to find old discussions, should they become relevant again?

2. I don't think anyone would disagree with the comments that you pasted in many issues that it would be useful to have a better indication of timelines and people involved. But, if a lack of such information justifies closing the issue,
* what is the proposal for establishing this information, and
* how should allocated effort and approved timeline be reflected in the issue?


>  we do have to make tough calls as a project, and every single feature/task that might be nice to have might not be a good priority for the rest of the project to spend time on.

Absolutely. But it is still not clear to me how and by whom these calls are made, and how/where the decisions are recorded.

I would think that some combination of the biweekly telco and the quarterly planning meeting would provide a sufficient venue to accept or reject issues, estimate timelines, and gather participants. The quarterly planning meeting would seem like an appropriate venue to accept, refine, or reject large or early-phase proposals.

In recent quarterly meetings, documentation was requested as "umbrella issues". Unofficially, Milestones describing features or functional levels have been used effectively for several efforts. I think we should strongly consider topical Milestones to focus discussion for larger projects/proposals at planning meetings, where we can collectively set a due date for Milestones that are chosen for targeting in a given development period.


> decide to be liberal about opening issues 


Yes, it is already alarmingly hard to solicit feedback (even bug reports!) from GROMACS users (and coders, sysadmins, etc). I think we want to encourage rather than discourage opening issues. Unfortunately, we don't seem to have an effective strategy for dealing with the information we are able to gather.


Best,
M. Eric Irrgang