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

[Schulz, Roland]

Hi,

Some of the issues are really just questions whether this should happen or not (e.g. https://gitlab.com/gromacs/gromacs/-/issues/3888).
Instead of creating an issue, should we ask on this mailing-list? Or what is the recommended way to ask whether the community wants to see a specific MR?

Roland

> -----Original Message-----
> From: gromacs.org_gmx-developers-bounces at maillist.sys.kth.se
> <gromacs.org_gmx-developers-bounces at maillist.sys.kth.se> On Behalf Of
> Erik Lindahl
> Sent: Sunday, October 24, 2021 1:26 PM
> To: gmx-developers at gromacs.org
> Subject: [gmx-developers] Some heavy GitLab issue reorganisation / cleanup
> - more work to do
> 
> 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 <mailto: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.