[gmx-developers] More on Milestones

Mon Nov 15 16:46:15 CET 2021

Hi Eric,

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.

Having said that, I will contribute one mail:

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.

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.

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.

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 :-)

Cheers,

Erik

On Mon, Nov 15, 2021 at 2:51 PM Eric Irrgang <ericirrgang at gmail.com> wrote:

> Hi All.
>
> I wanted to take a discussion from
> https://gitlab.com/gromacs/gromacs/-/issues/3179#note_733291785 to the
> mailing list to avoid cluttering the issue comments, and because the scope
> is broader than that.
>
> First, I want to apologize for not writing to the list sooner to explain
> some updates to some tracked issues.
>
> 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:
> https://gitlab.com/gromacs/gromacs/-/milestones/127
>
> 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.
>
> 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.
>
> 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.)
>
> In addition to saving you some time, delegating issue updates would also
> allow for some reduction of noise in the issue comments.
>
>
> # kanban board
>
> I think the progress tracking of the milestone board is very informative
> regarding the described tasks.
> https://gitlab.com/gromacs/gromacs/-/milestones/127
>
> For better or for worse, the columns are assigned according to whether an
> issue has an assignee and whether it is open or closed.
>
>
> # issue assignees
>
> 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.
>
> 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.)
>
> 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.
>
> 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.
>
>
> # Follow-up
>
> 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).
>
> 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.
>
>
> # Alternatives
>
> 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
> gitlab.com/gromacs/gmxapi. 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.
>
>
> # Summary
>
> 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.
>
> 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.
>
> 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.
>
>
> Best,
> M. Eric Irrgang
> --
> Gromacs Developers mailing list
>
> * Please search the archive at
> http://www.gromacs.org/Support/Mailing_Lists/GMX-developers_List before
> posting!
>
> * Can't post? Read http://www.gromacs.org/Support/Mailing_Lists
>
> * For (un)subscribe requests visit
> https://maillist.sys.kth.se/mailman/listinfo/gromacs.org_gmx-developers
> or send a mail to gmx-developers-request at gromacs.org.
>

-- 
Erik Lindahl <erik.lindahl at dbb.su.se>
Professor of Biophysics, Dept. Biochemistry & Biophysics, Stockholm
University
Science for Life Laboratory, Box 1031, 17121 Solna, Sweden

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://maillist.sys.kth.se/pipermail/gromacs.org_gmx-developers/attachments/20211115/b1cf69f2/attachment-0001.html>