<div dir="ltr">Hi,<div><br></div><div>Thanks, Eric! </div><div><br></div><div>I can just follow up and say that part of the reason for this discuss is of course that with Paul on parental leave we haven't been quite as blessed with somebody around to clean things up and steer us, but long term it seems like a gigantic waste to ask somebody (e.g. Paul!) to just sit and bump the milestone for tons of issues that we created 6-24 months ago but never bothered working on :-)</div><div><br></div><div>1. A couple of us are going through issues (in particular those with 2022-related milestones) and try to pretty aggressively remove them unless it seems reasonable it's being worked on actively and likely to meet the milestone. Please feel free to set one of the new milestones (see below) instead if you are working on the issue, or can commit to do so, but don't set a milestone merely as a vote not to forget an issue or that you think it would be useful. If there are urgent technical reasons why something NEEDS to have e.g. 2022-beta2 as a milestone, and that we as a consequence should prioritize something else lower, please explain that in the comments!</div><div><br></div><div>2. I have just created a 2022-beta2 milestone, but don't just bump everything we haven't done yet to that one. We will release beta2 by the end of November. Since this will be the last beta before the release candidates, any new code we're dashing to get in during the beta cycle (i.e., the "exceptions") must be in by this deadline. After beta2, only proper fixes will go in. Realistically, we might have resources to complete maybe 40 issues (?) by beta2, so this means we need to prioritize HARD. Only add things to the beta2 milestone if we have people working actively on something and feel confident it will be done (read: merged, not merely patch submitted!) by end-of-November. We are realistically also pretty much 100% committed when it comes to developer resources, so unless issues already have people planning to work on them, it is highly unlikely we are going to have any resources to spend on them (because we also have a TON of code review to do), unless we get volunteers who say they have time to spare :-)</div><div><br></div><div>3. It is not long-term sustainable to keep opening 3-4x more issues than we close, so we cannot use "open issue" as a scratchpad for things that would be good to do at some point. As we've talked about before, we'll try to move to a system where issues are automatically marked stale after e.g. 60 days of inactivity, and closed after another 60 days of inactivity. But, until that happens we might manually close some issues due to inactivity.</div><div><br></div><div>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).</div><div><br></div><div>Make sure you add any issues you want to be decided within the next 10 days, so everyone else has a chance to comment and discuss before the meeting - but at the meeting we will assume everyone who has opinions about the milestone-marked issues have read up on them so we're ready to make the decisions, not just decide that we should talk more or consult this list :-). </div><div><br></div><div>All the best,</div><div><br></div><div>Erik</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 20, 2021 at 6:45 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">Hi Devs.<br>
<br>
In the call today, there was a lot of talk about how not to use Milestones. I'm not sure how much agreement there was on how to use them, though. Here are some notes on what I understand the outcome to have been, and where questions remain.<br>
<br>
1. One observation was that there are a lot of Milestones related to the upcoming 2022 release. Can someone comment on which Milestone (if any) developers should be pointing their issues, MRs, or reviewer energy at to tackle the remaining 2022-critical stuff?<br>
<br>
2. The previous strategy of automatically punting issues from one "infrastructure-stable" milestone to the next has been abandoned. I believe there is now a request that contributors should not select a Milestone that implies a point in the development cycle. Is the expectation now that due dates or release targets will be decided at the biweekly meetings or at the quarterly planning meetings?<br>
<br>
3. There exist several feature based Milestones (used in several cases in order to have the burn-down chart and project board for big collaborative subprojects). Presumably these are clearly distinct from the Milestones that equate to points in the development calendar, and can optionally use due dates for additional clarification.<br>
<br>
4. At the last quarterly meeting, a "winter planning" Milestone was created to hold "umbrella issues" and such that still require group discussion regarding disposition of available effort or scheduling in the project roadmap. Do we still want to collect issues this way, or are we using a shared Google Doc to the exclusion of this milestone?<br>
<br>
5. Is there any additional guidance on how we can track which issues have been allocated effort and which are awaiting discussion? There exist a series of "Status::" labels, but it is not clear who sets these or under what circumstances.<br>
<br>
6. If anyone is looking for a place to record the results of these discussions or to refer to the records of previous discussions, try <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> and <a href="https://gitlab.com/gromacs/gromacs/-/blob/master/docs/dev-manual/change-management.rst" rel="noreferrer" target="_blank">https://gitlab.com/gromacs/gromacs/-/blob/master/docs/dev-manual/change-management.rst</a><br>
<br>
Best,<br>
Eric<br>
-- <br>
Gromacs Developers mailing list<br>
<br>
* Please search the archive at <a href="http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List</a> before posting!<br>
<br>
* Can't post? Read <a href="http://www.gromacs.org/Support/Mailing_Lists" rel="noreferrer" target="_blank">http://www.gromacs.org/Support/Mailing_Lists</a><br>
<br>
* For (un)subscribe requests visit<br>
<a href="https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers" rel="noreferrer" target="_blank">https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers</a> or send a mail to <a href="mailto:gmx-developers-request@gromacs.org" target="_blank">gmx-developers-request@gromacs.org</a>.<br>
</blockquote></div><br clear="all"><div><br></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>