[gmx-developers] Some heavy GitLab issue reorganisation / cleanup - more work to do

[Erik Lindahl]

Hi all,

I've spent the weekend doing some major GitLab issue cleanup. First, I
apologize if I happened to close something you were working very actively
on (just reopen it in that case) - my time was limited since there were
over 1000 issues to go through - but this also exposes the great issue that
I think we need to learn from, so here we go with a couple of thoughts and
requests:

1. As great as an issue tracking system is, it's not a replacement for
doing the work. In hindsight, I think we've used both GitLab and Redmine in
a way that effectively built up an "issue dept" (cf. technical debt). It's
trivial to just create follow-up issues, "consider ..." issues, issues that
we should use some new language feature, issues that more testing would be
good, etc. That only takes 10 seconds - but actually completing the issue
(which will take hours or days) is left as an exercise to somebody else -
which is also the reason a ton of them don't have any developer assigned.

2. Basically, we can't keep opening more issues than we close. To justify
opening a separate issue (rather than adding something as a comment in an
existing one), we should think twice and e.g. consider if we expect to do
this work ourselves e.g. the next ~3 months (=we put ourselves as the
assignee), that it is something we'll bring up for planning at our next
meeting, and whether it is something we NEED to do (rather than could do).

3. Don't add issues for routine things such as considering to use new
language features, that we could consider using new language features, or
e.g. TODO-style issues describing there are too many TODO things listed in
the code - we already know that, and adding more TODOs reminding us about
the TODOs isn't helping much :-)

4. Guidelines and documentation improvements are great, but in most cases
it's likely more efficient if we start with a code change implementing it
(or at least don't open an issue until 2-3 of us are deciding to work
actively on it). Personally I'm also a bit skeptical of adding issues
asking for "policies", since we already have a bit too many hard rules - we
need to learn to play things a bit by ear instead (and many of these issues
tend to stay around forever with random comments, but little concrete code).

The good news is that we are now left with only ~360 open issues. I'm well
aware I closed some issues that weren't "done", but for some areas (gmxapi,
GPU/CUDA, "consider", etc.) there were >100 open issues - which I can't
imagine any of you actually kept track of.  Since many of them only had 2-3
lines of description (but no activity), I think those will fit better as
item lists in higher-level issues to make it easier for all of us to keep
track of. So, with that apology it would be great if those of you working
on these larger areas could have a chance to organize the remaining issues
a bit too - do we need all the remaining ones? Are there too many
non-orthogonal umbrella issues? could some of them just be tasks in
existing issues?


Finally, for the remainder of the 2022 release cycle, I have marked a bunch
of things for 2022.beta2 - there are currently *113* open issues there,
many of which are bugs or general things we should have looked into a long
time ago. Just remember that we need to look at these too in addition to
the work on our own larger changes - this is the reason I tentatively said
we only have this week + next for _new_ MRs, but if we do a good job with
the open issues we can expand this window.

My hope is that we could be down to 200-250 open issues by the time we make
a release - and then gradually aim to get down to ~150 continuously open
issues (in addition to bugs and specific things) - If we manage to do that
I think it would be much easier for all of us to follow what's happening in
all our teams!

All the best,

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/20211024/b89d861e/attachment.html>