[gmx-developers] GitLab "Milestones"

[Erik Lindahl]

Hi,

On Wed, Oct 27, 2021 at 8:10 PM Eric Irrgang <ericirrgang at gmail.com> wrote:

>
> Is there an expectation that we are tracking this flow with Status labels?
> It is unclear how or why some issues have Status labels and others do not,
> but it seems like a useful practice if we can clarify how it is supposed to
> take place.
>

I don't have any patent answer, I'm afraid. However, given that we are a
very diverse & distributed team (which comes with a TON of obvious
advantages too), my personal preference would be that we should strive for
sufficient documentation/text/status in each issues so that somebody who
has not been involved in it before will be able to more or less directly
understand what the status is, if anybody is working actively on it, if
there's interest (we should get better at using thumbs up/down I think!),
or if it's just gone stale because we don't have time.

I think we're skilled enough to aim for a lot of freedom (since issues are
also VERY different in nature), as long as we find a way to avoid going
back into exponentially growing complexity :-)

There is one thing I have a bit of bad conscience about, and that's the
umbrella vs. child issues. I know they are important, and in principle
hierarchical organization is good, it's just that I don't know how to
handle the complexity (in terms of sheer open-issue-count) when a bunch of
umbrella issues have several dozen children that we aren't working actively
on (yet). Maybe one solution could be to just list expected upcoming
children in a task-list in the umbrella issue, and hold off creating the
actual issues until we at least expect to work on them in the foreseeable
future.

>
> Yes. But what is the new mechanism by which we will do a better job of
> managing the issue life cycle, moving forward? Do some or all of us have a
> responsibility to apply labels independently? As a group (during biweekly
> telcos or at quarterly planning meetings)? Do we expect to only close
> issues that time out to inactivity, or are we actively trying to find a way
> to close issues in a more considered way?
>

I would suggest two things:

* First, I've played around with running gitlab-triage in the CI
(interfacing with the database), and I think I found a config that will
allow us to automatically label things as "stale" when they haven't had
updates e.g. in 2-3 months. My plan is to add a default text apologizing we
haven't been able to look into it, provide some trivial suggestions, but
then also saying that if this is an umbrella or child issue, it's an
indication it's time to provide an update of  status, timeplan and
assignee(s). Spontaneously, I'm even thinking of auto-closing stale issues
that still don't get an update in another 3 months unless somebody is
assigned (then we can warn the assignee first(. That might seem harsh, but
if we haven't bothered looking at it for a quarter, we don't bother to
provide an update when reminded, we don't bother to assign it to anybody,
and then let another quarter pass - then I would say that we effectively
already voted to close (or at least ignore) it, so the "closed" status is
really just reflecting reality.

* Second, I think the bi-weekly telcos are a great point to spend 10
minutes syncing on the status of issues and decide what has to be
accepted/rejected/closed, and make sure we don't have a ton of issues
without assignees. The hardest part is likely that we'll have to accept
that we can't really have more than ~30 (or whatever issues each assigned.
After that it's just a question of whether we are closing old or rejecting
new things - but keeping that in mind might help us to jointly prioritize.

>
> 1. Since the issues were closed without labeling them "Status::inactive",
> it is harder to apply a search filter that distinguishes between
> conversations on fixed bugs, rejected ideas, or productive conversations
> that merely stalled out.
> * Do we plan to use (increase the use of) Status labels in the future?
>

Labels (or detailed comments) are awesome, but prio #1 is that we make
decisions, so I don't want us to hold back on decision-making/actions
because we first carefully want to label each issue with the exact reason
:-)

* Is there any objection to adding the Status::inactive label to issues
> that were closed in the recent purge to make it easier to find old
> discussions, should they become relevant again?
>

On the contrary, that would be great!


> 2. I don't think anyone would disagree with the comments that you pasted
> in many issues that it would be useful to have a better indication of
> timelines and people involved. But, if a lack of such information justifies
> closing the issue,
> * what is the proposal for establishing this information, and
> * how should allocated effort and approved timeline be reflected in the
> issue?
>

See above; I don't think we want to have _one_ prescribed way it must be
done, but the key is that a reader should be able to understand (very
roughly!) what the status is by reading the issue rather than having to
check with everyone on the team.

However, one (strong) preference I have is that we make it the
responsibility of team members who want to keep an issue open to also
ensure that it has reasonably up-to-date information, rather than saying
it's the poor soul (often Paul the last 2-3 years...) actually trying to
clean up who also gets the unthankful job of reminding people.



> >  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.
>
> Absolutely. But it is still not clear to me how and by whom these calls
> are made, and how/where the decisions are recorded.
>
> I would think that some combination of the biweekly telco and the
> quarterly planning meeting would provide a sufficient venue to accept or
> reject issues, estimate timelines, and gather participants. The quarterly
> planning meeting would seem like an appropriate venue to accept, refine, or
> reject large or early-phase proposals.
>
In recent quarterly meetings, documentation was requested as "umbrella
> issues". Unofficially, Milestones describing features or functional levels
> have been used effectively for several efforts. I think we should strongly
> consider topical Milestones to focus discussion for larger
> projects/proposals at planning meetings, where we can collectively set a
> due date for Milestones that are chosen for targeting in a given
> development period.
>
>
agree on both counts.

Cheers,

E.

-- 
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/20211027/99a7a0dd/attachment.html>