<div dir="ltr">Hi Nyall,<br><br>thanks for raising this point!<br><br>I 100% agree with you proposals, but I have some additional topics that could IMO help a lot to increase the efficiency of bugfixing process, I'm talking about increasing the S/N ratio. <br>Sorry for the long email, but I think we really need to do something because the task of finding a bug ready to be processed is becoming more and more painful, time consuming and frustrating.<br><br>Recently I took part to several bugfixing sprints (but I do this kind of activity also as a volunteer) and this is roughly the process that I have to do several times a week (sometimes more than daily):<br><br>1. go through the bug queue (filtered to identify bugs open)<br>2. click on a ticket link to read the details<br>3. 95% of the times read some garbage information with some stack-trace<br>4. 95% of the times ask for some more information and for data/sample project<br>5. sometimes I just discover that another developer has already answered and he's probably taking care of the bug or willing to do that<br><br>6. Another part of my bugfixing time goes with reading email bug notifications (ok this is faster, when the email notification work) but still takes time and most of the times it is wasted time because all what has changed is (for example) a typo in the title or a discussion about if it's a regression or not.<br><br>So, here are my proposals to increase the S/N ratio:<br><br>a. immediately close (well, after a few days) the tickets that do not have enough information (example: <a href="https://issues.qgis.org/issues/20069">https://issues.qgis.org/issues/20069</a> <a href="https://issues.qgis.org/issues/19922">https://issues.qgis.org/issues/19922</a>), a simple criteria for these automatic tickets it to look at the stacktrace and see if is there any Qgs prefixed name there, if not: close because nobody of us will waste time on that ticket, so better spare our attention<br><br>b . immediately ask for some more information when it makes sense (and most of the times it does), I think that the triagers should have a way to call the attention of a developer if they have doubts on this point. Note that a sample project/data and/or a screencast almost always helps and greatly speeds up the fixing process.<br><br>c. developers should be good citizens and assign bugs to themselves when working on a bug: it's a stupid waste of time when you open a ticket, read it all and the discover that there is a pending PR that addresses it ... ok this just happened one or twice, but unassigned bugs are the rule, not an exception, that means that you need to open every issue if you want to know if it's really unassigned (meaning: nobody is publicly working on it). This is also respectful for other devs time.<br><br>d. we should have a clear and documented definition of what criteria are behind the bug priority (and status), is it a logic AND of crash and regression flag? (apparently not). What I'm trying to say here is that I've seen tickets without ANY useful information in them that are high priority, at this time the priority flag does not help at all in finding a bug ready to be processed.<br><br>That said, sorry if that sounds like a rant, I really appreciate all the hard work behind the bug queue management and I wish to thank to all people involved in bug triaging and fixing, we are a team, we can work together and that's what matters!<br><br><br>On Fri, Oct 12, 2018 at 1:56 AM Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>> wrote:<br>><br>> Hey PSC,<br>><br>> I've been thinking more about this topic lately, and I'd like to<br>> re-ignite discussion about whether we should be automatically closing<br>> bug reports after a certain cut off time period.<br>><br>> In the past I've been against this (simply because I think there's<br>> always value in older unresolved tickets), but I've recently changed<br>> my mind and would like to see us adopt an auto-close after ## days of<br>> inactivity for open bug tickets.<br>><br>> Here's my thoughts:<br>><br>> - We've had great success by implementing a 21 day cut off for<br>> auto-closing stale pull requests. After 14 days of inactivity a<br>> warning is automatically added to the PR, and if no further activity<br>> occurs after 7 days the request is closed. This has really pushed back<br>> the effort to original submitters to keep momentum up on THEIR<br>> requests. It's up to them to fix issues, request updated reviews, etc.<br>> This considerably eases the burden on the core development team and<br>> helps share the workload around.<br>><br>> - Because of this, I think the same approach would be valuable for bug<br>> tickets. It pushes the effort back to the original submitter to ensure<br>> that their ticket has sufficient detail to be reproducible, meaning<br>> that the overworked bug triaging team don't always have to be the ones<br>> pushing them for information.<br>><br>> - It helps send the correct message that QGIS is an open source<br>> software project, not a charity service, and not a 24x7 software<br>> service hotline. If they want their bug fixed it's up to them to find<br>> ways to make this easy for us.<br>><br>> - We are drowning in poor value tickets, with limited information, no<br>> test data, etc. Unfortunately, despite TIRELESS efforts by our<br>> fantastic bug triagers it's still very hard to identify good bug<br>> tickets to target. This has gotten more difficult with the addition of<br>> the automated crash reports, and the increase in reporters who are<br>> just pasting the crash report with absolutely no useful other<br>> information.<br>><br>> - People can always reopen tickets if they are auto-closed and they<br>> are still an issue. In this case auto-closing is a good thing, because<br>> it prompts THEM to test latest versions and do the work checking that<br>> the ticket is still valid.<br>><br>> - If a ticket is auto-closed multiple times, it will help convey the<br>> message to the reporter that their bug is low priority for the<br>> project. We could then make the auto-close message hint to the<br>> reporter that they may need to directly engage a QGIS developer or<br>> support contract if they want a speedy resolution to their issue.<br>><br>> - We see roughly 5-6 new tickets opened daily, and maybe a ticket<br>> closed every second day (very rough figures!). The current growth rate<br>> of tickets is making the situation more and more difficult.<br>><br>> Thoughts?<br>><br>> Nyall<br>><br>><br>><br>><br>><br>> - This should only apply to bug tickets, not feature requests. Feature<br>> requests are a different beast and should have different rules.<br>> _______________________________________________<br>> Qgis-psc mailing list<br>> <a href="mailto:Qgis-psc@lists.osgeo.org">Qgis-psc@lists.osgeo.org</a><br>> <a href="https://lists.osgeo.org/mailman/listinfo/qgis-psc">https://lists.osgeo.org/mailman/listinfo/qgis-psc</a><br><br><br><br>-- <br>Alessandro Pasotti<br>w3:  <a href="http://www.itopen.it">www.itopen.it</a></div>