<div dir="ltr"><blockquote style="margin:0 0 0 40px;border:none;padding:0px">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. If developers end up creating parallel sets of milestones just for their own features, I suspect they will increasingly experience that they don't get much feedback or code review unless they participate quite actively in also providing e.g. code review for the overall project milestones.<br><br><br></blockquote>I personally think that more targeted feature milestones make sense. However, I would be on board with having project milestones if we had some sort of project planning. The current situation is that at the "planning" meetings, each dev just talks about what they want to do. No effort is put into, e.g, prioritizing a backlog, so calling what happens planning is a bit of a stretch. This is not to say that the planning meetings have no utility, just that we don't really use them for planning, as all the plans seem to be formulated outside of the meetings. Without some joint effort/mechanism to decide on and allocate work, there is just not much utility in having project milestones, since there are no shared project goals, only goals of individual developers. As such I don't really see what can be the benefit of overall project milestones (which would be time-based, I assume?) and think that feature milestones at least have the value that they let individual teams do some planning.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 15, 2021 at 4:46 PM Erik Lindahl <<a href="mailto:erik.lindahl@gmail.com">erik.lindahl@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi Eric,<br><div><br></div><div>First, be aware that we are pretty much 100% maxed out trying to get everything done for the final beta in two weeks. Any work on other efforts in parallel to that is presently going to have VERY low priority from the Stockholm team, so do not expect getting code review or any significant attention for issues not related to the release milestones in the near future (partly because everyone is busy focusing on the release milestones, and partly because we don't want any major destabilization of master branch 10 days before branching off the release on Oct 31), and similarly people are unlikely to engage in an meta-discussion about non-release-related issues right now.</div><div><br></div><div>Having said that, I will contribute one mail:</div><div><br></div><div>Unfortunately I think we've seen very clearly in the past that we all vote with our actions of not updating issues - 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 :-). 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.</div><div><br></div><div>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. If developers end up creating parallel sets of milestones just for their own features, I suspect they will increasingly experience that they don't get much feedback or code review unless they participate quite actively in also providing e.g. code review for the overall project milestones.<br></div><div><br></div><div><div>However, at the end of the day I still (strongly) prefer that we can be flexible with developers with slightly different preferences of handling issues, and I think we can try that here too - but that comes with a hard contract of managing the issues such that we don't fall back into opening many more than we close, or having issues that are just touched to avoid having them go stale, but no actual update. </div><div><br></div><div>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 :-)</div><div><br></div><div><br></div><div>Cheers,</div><div><br></div><div>Erik</div></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 15, 2021 at 2:51 PM Eric Irrgang <<a href="mailto:ericirrgang@gmail.com" target="_blank">ericirrgang@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi All.<br>
<br>
I wanted to take a discussion from <a href="https://gitlab.com/gromacs/gromacs/-/issues/3179#note_733291785" rel="noreferrer" target="_blank">https://gitlab.com/gromacs/gromacs/-/issues/3179#note_733291785</a> to the mailing list to avoid cluttering the issue comments, and because the scope is broader than that.<br>
<br>
First, I want to apologize for not writing to the list sooner to explain some updates to some tracked issues.<br>
<br>
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: <a href="https://gitlab.com/gromacs/gromacs/-/milestones/127" rel="noreferrer" target="_blank">https://gitlab.com/gromacs/gromacs/-/milestones/127</a><br>
<br>
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.<br>
<br>
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.<br>
<br>
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.)<br>
<br>
In addition to saving you some time, delegating issue updates would also allow for some reduction of noise in the issue comments.<br>
<br>
<br>
# kanban board<br>
<br>
I think the progress tracking of the milestone board is very informative regarding the described tasks. <a href="https://gitlab.com/gromacs/gromacs/-/milestones/127" rel="noreferrer" target="_blank">https://gitlab.com/gromacs/gromacs/-/milestones/127</a><br>
<br>
For better or for worse, the columns are assigned according to whether an issue has an assignee and whether it is open or closed.<br>
<br>
<br>
# issue assignees<br>
<br>
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.<br>
<br>
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.)<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
# Follow-up<br>
<br>
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).<br>
<br>
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.<br>
<br>
<br>
# Alternatives<br>
<br>
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 <a href="http://gitlab.com/gromacs/gmxapi" rel="noreferrer" target="_blank">gitlab.com/gromacs/gmxapi</a>. 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.<br>
<br>
<br>
# Summary<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
Best,<br>
M. Eric Irrgang<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"><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>
-- <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>.</blockquote></div>