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

Mon Nov 12 16:14:51 EST 2018

Following up a bit, we now have a "Community Support" label (
https://github.com/matplotlib/matplotlib/labels/Community%20support ).
Please use it for cases that are not clearly a bug and not clearly a "how
do I ...." question.

Tom

On Tue, Nov 6, 2018 at 10:22 AM Ryan May <rmay31 at gmail.com> wrote:

> 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
>
> _______________________________________________
> Matplotlib-devel mailing list
> Matplotlib-devel at python.org
> https://mail.python.org/mailman/listinfo/matplotlib-devel
>

-- 
Thomas Caswell
tcaswell at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20181113/e7f385b8/attachment.html>