<div dir="ltr">Hi all,<div><br></div><div>I&#39;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:</div><div><br></div><div>1. As great as an issue tracking system is, it&#39;s not a replacement for doing the work. In hindsight, I think we&#39;ve used both GitLab and Redmine in a way that effectively built up an &quot;issue dept&quot; (cf. technical debt). It&#39;s trivial to just create follow-up issues, &quot;consider ...&quot; 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&#39;t have any developer assigned. </div><div><br></div><div>2. Basically, we can&#39;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&#39;ll bring up for planning at our next meeting, and whether it is something we NEED to do (rather than could do).</div><div><br></div><div>3. Don&#39;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&#39;t helping much :-)</div><div><br></div><div>4. Guidelines and documentation improvements are great, but in most cases it&#39;s likely more efficient if we start with a code change implementing it (or at least don&#39;t open an issue until 2-3 of us are deciding to work actively on it). Personally I&#39;m also a bit skeptical of adding issues asking for &quot;policies&quot;, 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).</div><div><br></div><div>The good news is that we are now left with only ~360 open issues. I&#39;m well aware I closed some issues that weren&#39;t &quot;done&quot;, but for some areas (gmxapi, GPU/CUDA, &quot;consider&quot;, etc.) there were &gt;100 open issues - which I can&#39;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?</div><div><br></div><div><br></div><div>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.</div><div><br></div><div>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&#39;s happening in all our teams!</div><div><br></div><div>All the best,</div><div><br></div><div>Erik</div><div><br></div><div><br></div><div><br></div><div><br>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Erik Lindahl &lt;<a href="mailto:erik.lindahl@dbb.su.se" target="_blank">erik.lindahl@dbb.su.se</a>&gt;</div><div>Professor of Biophysics, Dept. Biochemistry &amp; Biophysics, Stockholm University</div><div>Science for Life Laboratory, Box 1031, 17121 Solna, Sweden</div><div><br></div><div>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.<br></div></div></div></div></div></div></div></div></div></div></div>