<div dir="ltr"><div dir="ltr">Hi,<div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 25, 2021 at 2:10 PM Eric Irrgang <<a href="mailto:ericirrgang@gmail.com">ericirrgang@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br>
> On Oct 20, 2021, at 8:29 PM, Erik Lindahl <<a href="mailto:erik.lindahl@gmail.com" target="_blank">erik.lindahl@gmail.com</a>> wrote:<br>
> But, until that happens we might manually close some issues due to inactivity.<br>
<br>
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 <a href="https://manual.gromacs.org/current/dev-manual/reportstyle.html#general-issue-workflow" rel="noreferrer" target="_blank">https://manual.gromacs.org/current/dev-manual/reportstyle.html#general-issue-workflow</a>. 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"?<br></blockquote><div><br></div><div>Yes, very much so (there were things that had been open for 10 years....) - but also to open slightly more arrows to the "closed" state so we avoid re-building a debt of constantly increasing issues in various states. </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<a href="https://gitlab.com/gromacs/gromacs/-/blob/master/docs/dev-manual/reportstyle.rst" rel="noreferrer" target="_blank">https://gitlab.com/gromacs/gromacs/-/blob/master/docs/dev-manual/reportstyle.rst</a> 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?<br>
<br></blockquote><div><br></div><div>I think the overall flow is fine, we just need to remember that to maintain a roughly stationary distribution of things that is long-term sustainable, we need to get to a situation where we (averaged over time) close as many issues as we open. That is hard, because it's easy to open issues with incomplete information (that's often why we DO open them), 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 that (1) we are a bit more restrictive with opening new separate issues, and (2) we get a bit more aggressive closing ones that aren't moving. We can all keep an eye on the counters of "open issues" over time to see if we're heading in the wrong direction.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
> 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).<br>
<br>
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.<br></blockquote><div><br></div><div>No, not at all - discussion just means that we should discuss them! However, I created a separate _milestone_ for issues that we want to close at (or just after the meeting) - all those are policy issues where we just need to decide.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
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?<br></blockquote><div><br></div><div>"Recent" is relative; I think I stopped at residues that were at least ~1 year old that hadn't had any apparent progress (but I'm sure I made some mistakes). I don't think the main problem is issues that somebody is working on but not getting review (having a single person with clear responsibility is good, IMHO), but mainly issues where not much happened at all. </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
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.<br></blockquote><div> </div><div>In general I think it's a very good idea to ensure there are people interested in helping things through review before one does the work, but that is of course also dependent on building karma by reviewing code from them. Having said that, 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. </div><div><br></div><div><br></div><div>At the end of the day I think we come back to the challenge that it often only takes 30 seconds to open an issue, while it can easily take hours or days for the entire team to engage in a deep discussion about the issue. Given that, we can either decide to be liberal about opening issues and accept that some of them will have to be closed without much discussion due to lacking activity/interest, or we can expect to have much deeper discussions about issues - but with the consequence that perhaps only a small set of people will be allowed to open issues. The second setup sounds a bit strange to me though, so I would much prefer the first one, imperfect as it is.</div><div><br></div><div>Cheers,</div><div><br></div><div>Erik</div><div> <br></div></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Erik Lindahl <<a href="mailto:erik.lindahl@dbb.su.se" target="_blank">erik.lindahl@dbb.su.se</a>></div><div>Professor of Biophysics, Dept. Biochemistry & Biophysics, Stockholm University</div><div>Science for Life Laboratory, Box 1031, 17121 Solna, Sweden</div><div><br></div><div>Note: I frequently do email outside office hours because it is a convenient time for me to write, but please do not interpret that as an expectation for you to respond outside your work hours.<br></div></div></div></div></div></div></div></div></div></div>