[gmx-developers] GitLab "Milestones"

Wed Oct 20 19:29:42 CEST 2021

Hi,

Thanks, Eric!

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

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!

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

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.

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

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

All the best,

Erik

On Wed, Oct 20, 2021 at 6:45 PM Eric Irrgang <ericirrgang at gmail.com> wrote:

> Hi Devs.
>
> 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.
>
> 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?
>
> 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?
>
> 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.
>
> 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?
>
> 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.
>
> 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
> https://gitlab.com/gromacs/gromacs/-/blob/master/docs/dev-manual/reportstyle.rst
> and
> https://gitlab.com/gromacs/gromacs/-/blob/master/docs/dev-manual/change-management.rst
>
> Best,
> Eric
> --
> 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/20211020/36f1f42e/attachment.html>