[Qgis-psc] Bug tracking (no, not *that* one... a different question)

[Alessandro Pasotti]

Hi Nyall,

thanks for raising this point!

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.
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.

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):

1. go through the bug queue (filtered to identify bugs open)
2. click on a ticket link to read the details
3. 95% of the times read some garbage information with some stack-trace
4. 95% of the times ask for some more information and for data/sample
project
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

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.

So, here are my proposals to increase the S/N ratio:

a.  immediately close (well, after a few days) the tickets that do not have
enough information (example: https://issues.qgis.org/issues/20069
https://issues.qgis.org/issues/19922), 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

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.

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.

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.

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!


On Fri, Oct 12, 2018 at 1:56 AM Nyall Dawson <nyall.dawson at gmail.com> wrote:
>
> Hey PSC,
>
> I've been thinking more about this topic lately, and I'd like to
> re-ignite discussion about whether we should be automatically closing
> bug reports after a certain cut off time period.
>
> In the past I've been against this (simply because I think there's
> always value in older unresolved tickets), but I've recently changed
> my mind and would like to see us adopt an auto-close after ## days of
> inactivity for open bug tickets.
>
> Here's my thoughts:
>
> - We've had great success by implementing a 21 day cut off for
> auto-closing stale pull requests. After 14 days of inactivity a
> warning is automatically added to the PR, and if no further activity
> occurs after 7 days the request is closed. This has really pushed back
> the effort to original submitters to keep momentum up on THEIR
> requests. It's up to them to fix issues, request updated reviews, etc.
> This considerably eases the burden on the core development team and
> helps share the workload around.
>
> - Because of this, I think the same approach would be valuable for bug
> tickets. It pushes the effort back to the original submitter to ensure
> that their ticket has sufficient detail to be reproducible, meaning
> that the overworked bug triaging team don't always have to be the ones
> pushing them for information.
>
> - It helps send the correct message that QGIS is an open source
> software project, not a charity service, and not a 24x7 software
> service hotline. If they want their bug fixed it's up to them to find
> ways to make this easy for us.
>
> - We are drowning in poor value tickets, with limited information, no
> test data, etc. Unfortunately, despite TIRELESS efforts by our
> fantastic bug triagers it's still very hard to identify good bug
> tickets to target. This has gotten more difficult with the addition of
> the automated crash reports, and the increase in reporters who are
> just pasting the crash report with absolutely no useful other
> information.
>
> - People can always reopen tickets if they are auto-closed and they
> are still an issue. In this case auto-closing is a good thing, because
> it prompts THEM to test latest versions and do the work checking that
> the ticket is still valid.
>
> - If a ticket is auto-closed multiple times, it will help convey the
> message to the reporter that their bug is low priority for the
> project. We could then make the auto-close message hint to the
> reporter that they may need to directly engage a QGIS developer or
> support contract if they want a speedy resolution to their issue.
>
> - We see roughly 5-6 new tickets opened daily, and maybe a ticket
> closed every second day (very rough figures!). The current growth rate
> of tickets is making the situation more and more difficult.
>
> Thoughts?
>
> Nyall
>
>
>
>
>
> - This should only apply to bug tickets, not feature requests. Feature
> requests are a different beast and should have different rules.
> _______________________________________________
> Qgis-psc mailing list
> Qgis-psc at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc



-- 
Alessandro Pasotti
w3:   www.itopen.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-psc/attachments/20181012/55ea3f31/attachment.html>