[gmx-developers] GitLab "Milestones"

[Erik Lindahl]

Hi,

On Mon, Oct 25, 2021 at 2:10 PM Eric Irrgang <ericirrgang at gmail.com> wrote:

>
> > On Oct 20, 2021, at 8:29 PM, Erik Lindahl <erik.lindahl at gmail.com>
> wrote:
> > But, until that happens we might manually close some issues due to
> inactivity.
>
> 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
> https://manual.gromacs.org/current/dev-manual/reportstyle.html#general-issue-workflow.
> 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"?
>

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.


>
> https://gitlab.com/gromacs/gromacs/-/blob/master/docs/dev-manual/reportstyle.rst
> 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?
>
>
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.



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

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.


>
> 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?
>

"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.


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.
>

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.


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.

Cheers,

Erik

-- 
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/20211025/fea8218f/attachment.html>