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

Mon Nov 5 18:22:32 EST 2018

In my opinion, there's nothing wrong with closing issues quickly. If in a
developer's judgement (making sure to exercise care) and issue is resolved,
it should be closed, period. This communicates the status clearly to the
user and to other developers, so that people are not wasting their time. To
leave an issue open otherwise just means many people look at it again for
no good reason, and somebody has to come along later and close it anyway.

Having said that, I agree with the idea that the way we're closing these
out is often seeming quite curt and short. While I don't believe this is
done with any mean intent, more effort needs to be put into the responses
to create an environment that's welcoming to support inquiries, especially
for novice users. For example:

"Don't use the issue tracker for questions."

would be better as:

"Thanks for the question. This would really be better suited to ask on
Stack Overflow or our mailing lists [link] where more users who can help
will see your question.'

Also

"This is not a bug in matplotlib"

would sound better:

"Thanks for letting us know. I think this is really an issue with [blank],
would you mind reporting this problem to them [link provided]? Feel free to
re-open this issue if you think this is incorrect."

The problem is not a technical one, but a social one--communication is
hard. Hamstringing those going through the effort to look through and close
out issues isn't the answer, though.

Ryan

On Fri, Nov 2, 2018 at 11:59 AM Benjamin Root <ben.v.root at gmail.com> wrote:

> I think part of the issue is literally how quickly some of these issues
> are being closed, not so much that they are being closed. I have seen
> issues get closed within minutes of being opened up, and even as a
> long-time contributor, that has come across as jarring to me. I worry that
> it may convey a lack of consideration of the issue. Even if we know 100%
> that the issue should be closed, closing within just a few minutes might
> make submitters feel like their issue wasn't fully absorbed. If they spent
> 10 minutes or more writing up their issue, and it gets closed in 2 minutes,
> they might feel like there was a net negative amount of effort in the
> discussion. Maybe the problem is totally on their end and they are doing
> something wrong, but closing the issue so quickly may make them feel like
> they are left adrift.
>
> I especially worry about the issues that get closed and redirected to the
> mailing list or stackoverflow. In the past few months, I think I have only
> seen one issue get re-raised on the mailing list. I don't follow
> stackoverflow, so I don't know if those issues are getting discussed there
> or not. Does anybody have a sense for that?
>
> And finally, we need to remember that we may indeed be misreading some
> issues. I accidentally closed an issue too quickly last week, too, because
> I thought it was the same-old mplot3d can't render things right problem.
> Turns out it was much more nuanced, and while we couldn't really solve the
> problem anyway, I think I did pounce too quickly on that close button.
>
> Cheers!
> Ben Root
>
>
> On Fri, Nov 2, 2018 at 1:41 PM OceanWolf via Matplotlib-devel <
> matplotlib-devel at python.org> wrote:
>
>> But doesn't the issue of triage mean we distinguish between issues/PRs
>> based on severity e.g. ranging from critical to wishlist.  To me at least
>> open suggests that the issue still exists and closed means that it doesn't
>> exist as a issue for us, either because we don't see it as an issue, or
>> because it has been fixed, and thus says nothing about triage state.
>> In terms of workflow I see the difference as if something has been marked
>> closed and someone comes along with the same issue, it can give the
>> suggestion that we don't value the reopening the issue/PR, and thus it
>> indicates that we value it a waste of time for anyone to spend their time
>> on it, and for some issues that might exist as the case seeing something as
>> out of scope for MPL, but for others we should just assign a low triage
>> status to it so that if we get people super keen about a particular issue
>> then we let them know that we welcome their input on it :).
>>
>> ------------------------------
>> *From:* Eric Firing <efiring at hawaii.edu>
>> *To:* matplotlib-devel at python.org
>> *Sent:* Friday, 2 November 2018, 18:14
>> *Subject:* Re: [Matplotlib-devel] please be slower to close bug reports
>> from first-time reporters
>>
>> 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
>>
>>
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Matplotlib-devel at python.org
>> https://mail.python.org/mailman/listinfo/matplotlib-devel
>>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>

-- 
Ryan May
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20181105/113f60cc/attachment.html>