[Matplotlib-devel] please be slower to close bug reports from first-time reporters

[Chris Barker]

IIUC, the problem at hand is:

- Folks (presumably newbies) are posting issues that they think are bug
reports.
- Many of those issues turn out to be not bugs, but misunderstandings of
the API, etc.
- We also have a large backlog of issues, and don't want it to keep getting
bigger!
- And there is a limited pool of people with limited time to review issues.

- One solution is to quickly close issues that aren't really bugs.

This has the upside of helping keeping the issues list more manageable.

It also has the downsides of:
 - seeming unwelcoming of help from the community -- we want new folks that
have taken the time to contribute to continue to do so -- maybe the next
one will be a real bug.
 - missing an opportunity to enhance the docs -- if someone misunderstand
MPL's behavior, there may well be a "bug" or missing feature in the docs.

In order to be efficient, no one should ever have to read and evaluate an
issue that someone else already has. So if one dev reads an issue and
determines that it is not a bug, then we don't want anyone else to have to
read that issue if they are looking for bugs to fix. So we need a way to
get this efficiency without simply closing those issues.

I'm thinking that we need a triage process. When there is a new issue
posted, the first person that reads it can determine that it:

1) is a real bug that needs to be investigated

2) is not a bug at all, but is a misunderstanding, which is one of:
    a)  something that is already reasonably well documented
    b)  something that is poorly documented

3) Is unclear at this point.

Can't we use tagging  to categorize these? I just looked at the tags
available -- wow! that's a long list. But surely there is one for every one
of the above:

1) gets confirmed bug

2b) gets Documentation

3) gets  Needs confirmation

As for 2a -- that should get a nice note in the comments before getting
closed. If the initial reviewer doesn't have the time to write that note,
maybe a tag for "community support" or "needs nice reply"

Anyway, the goal here should be no duplication of work -- the great thing
about closing an issue is that no one else is going to waste time reading
it again. But if we can accomplish that goal while still welcoming newbies
-- then great!

-CHB




On Fri, Nov 2, 2018 at 10:10 AM, Eric Firing <efiring at hawaii.edu> wrote:

> On 2018/11/02 5:03 AM, Thomas Caswell wrote:
>
>> The backlog problem is also real, however I am not sure that just closing
>> old issues / PRs and rapidly closing new issues will actually make it
>> better.  It will make the number smaller, but the underlying issues (either
>> the bugs or documentation deficiencies) will still be there.
>>
>>
> Tom,
>
> It is a matter of triage.  I think you are missing a critical point:
> closing issues *can* make the situation better by reducing the time that is
> lost on scanning them, or diving into them, when that time would be better
> spent actually fixing something.  Furthermore, the list of open issues can
> simply be overwhelming, discouraging work by existing developers, and
> probably also discouraging potential developers from joining us.
>
> It is not a tragedy if a genuine issue is closed.  If it is reporting a
> major problem, it will crop up again, and eventually get the necessary
> attention.
>
> There will *always* be bugs and documentation deficiencies; the question
> is how to maximize available developer time and attention, and how to make
> the best use of it.
>
> Eric
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20181102/03c2ce0a/attachment.html>