please be slower to close bug reports from first-time reporters

Development matplotlib-devel
1

Folks,

We have had a number of bug reports come in recently from first-time
reporters (you can tell if you mouse over their icon) that have been
quickly closed. On one hand, they have been technically correct, however
on the other we should try to be more welcoming to new contributors.

I propose that in "we think this is not a bug" cases instead of immediately
closing, we ask the OP if they are ok closing as not a bug and leave the
issue open for a few days (there has been discussion of using one of the
auto-close bots for stale issues / PRs which I am in general against, but I
think a "waiting for feedback" label + a bot that either removes the label
on the next comment or auto-closes after N days would be useful).

We should also consider changing some of those issues into documentation
issues. It can be useful to ask the OP "where would you have expected this
to be documented?".

Tom

···

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

2

I think this is a great approach, Tom.

Sorry I haven't been super active lately. But what little review I do, I'll
keep this in mind.
-Paul

···

On Thu, Nov 1, 2018 at 8:24 AM Thomas Caswell <tcaswell at gmail.com> wrote:

Folks,

We have had a number of bug reports come in recently from first-time
reporters (you can tell if you mouse over their icon) that have been
quickly closed. On one hand, they have been technically correct, however
on the other we should try to be more welcoming to new contributors.

I propose that in "we think this is not a bug" cases instead of
immediately closing, we ask the OP if they are ok closing as not a bug and
leave the issue open for a few days (there has been discussion of using one
of the auto-close bots for stale issues / PRs which I am in general
against, but I think a "waiting for feedback" label + a bot that either
removes the label on the next comment or auto-closes after N days would be
useful).

We should also consider changing some of those issues into documentation
issues. It can be useful to ask the OP "where would you have expected this
to be documented?".

Tom

--
Thomas Caswell
tcaswell at gmail.com
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20181101/30a00e4e/attachment.html&gt;

3

Hi Tom,
  
Sorry if I?ve been too aggressive about this. I?ve been trying to curate issues more aggressively, not to be unwelcoming, but simply to save the rest of the dev team time in parsing issues. I *try* to put a note in that we are happy to re-open the issue if more info is forthcoming. But, if its considered rude to close issues, I?ll stop doing it.

OTOH, I think *something* should be done, because we have *lots* of zombie issues and PRs around that no one is going back and doing anything about. I don?t see the point of that huge backlog, and it actually wastes time, because its not easy to go back and sort through what issues and PRs actually need attention. Github strongly encourages last-in-first-out processing, so anything more than a week old might as well be a year old.

Thanks, Jody

4

I should have been clearer, I did not mean to say anyone was being
intentionally unwelcoming, rude, or mean, however it is being perceived
that way. Text strips out a tremendous amount of context in our
communication, it is very easy for people (particularly if they are first
time contributors) who are already anxious about the whole process to read
the wrong subtext out of a conversation.

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

···

On Thu, Nov 1, 2018 at 12:47 PM Jody Klymak <jklymak at uvic.ca> wrote:

Hi Tom,

Sorry if I?ve been too aggressive about this. I?ve been trying to curate
issues more aggressively, not to be unwelcoming, but simply to save the
rest of the dev team time in parsing issues. I *try* to put a note in that
we are happy to re-open the issue if more info is forthcoming. But, if its
considered rude to close issues, I?ll stop doing it.

OTOH, I think *something* should be done, because we have *lots* of zombie
issues and PRs around that no one is going back and doing anything about.
I don?t see the point of that huge backlog, and it actually wastes time,
because its not easy to go back and sort through what issues and PRs
actually need attention. Github strongly encourages last-in-first-out
processing, so anything more than a week old might as well be a year old.

Thanks, Jody

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

--
Thomas Caswell
tcaswell at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20181102/6da5e20c/attachment.html&gt;

5

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

···

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.

6

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20181102/12d21c63/attachment.html&gt;

7

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
Matplotlib-devel Info Page

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20181102/c8d879c5/attachment-0001.html&gt;

8

Good points.

I have no objection to a moderate slowing down of closing new issues, to
give the submitter time to respond and to reduce the likelihood of
closing an issue based on a misunderstanding.

Nevertheless, the basic point remains: we need ways of focusing
attention and reducing the distraction, distress, and wasted time caused
by the excessively long list of open issues.

Eric

···

On 2018/11/02 7:58 AM, Benjamin Root 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 <mailto: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 <mailto:efiring at hawaii.edu>>
    *To:* matplotlib-devel at python.org <mailto: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 <mailto:Matplotlib-devel at python.org>
    Matplotlib-devel Info Page

    _______________________________________________
    Matplotlib-devel mailing list
    Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>
    Matplotlib-devel Info Page

9

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
Matplotlib-devel Info Page

--

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&gt;

10

But if we have good triage tags of how ever many levels of severity we choose, and thus filter issues/PRs based on those, doesn't that solve the described problem?? No more distraction, distress nor wasted time, right?? Just a short list of triaged issues when filtering based on severity.

···

From: Eric Firing <efiring at hawaii.edu>
To: Benjamin Root <ben.v.root at gmail.com>; OceanWolf <juichenieder-nabb at yahoo.co.uk>
Cc: matplotlib development list <matplotlib-devel at python.org>
Sent: Friday, 2 November 2018, 19:34
Subject: Re: [Matplotlib-devel] please be slower to close bug reports from first-time reporters
   
Good points.

I have no objection to a moderate slowing down of closing new issues, to
give the submitter time to respond and to reduce the likelihood of
closing an issue based on a misunderstanding.

Nevertheless, the basic point remains: we need ways of focusing
attention and reducing the distraction, distress, and wasted time caused
by the excessively long list of open issues.

Eric

On 2018/11/02 7:58 AM, Benjamin Root 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 <mailto: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 <mailto:efiring at hawaii.edu>>
? ? *To:* matplotlib-devel at python.org <mailto: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 <mailto:Matplotlib-devel at python.org>
? ? Matplotlib-devel Info Page

? ? _______________________________________________
? ? Matplotlib-devel mailing list
? ? Matplotlib-devel at python.org <mailto:Matplotlib-devel at python.org>
? ? Matplotlib-devel Info Page

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20181102/5d6b3ed8/attachment-0001.html&gt;

11

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
Matplotlib-devel Info Page

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

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

12

Following up a bit, we now have a "Community Support" label (
Issues · matplotlib/matplotlib · GitHub ).
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
Matplotlib-devel Info Page

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

--
Ryan May

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page

--
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&gt;