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

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

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

tcaswell
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
[hidden email]

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

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

Paul Hobson-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 <[hidden email]> 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
[hidden email]
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

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

Jody Klymak
In reply to this post by tcaswell

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
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

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

tcaswell
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 <[hidden email]> 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
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel


--
Thomas Caswell
[hidden email]

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

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

Eric Firing
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
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

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

matplotlib - devel mailing list
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 <[hidden email]>
To: [hidden email]
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
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel



_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

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

Benjamin Root
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 <[hidden email]> 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 <[hidden email]>
To: [hidden email]
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
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel


_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

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

Eric Firing
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
> <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>>
>     *To:* [hidden email] <mailto:[hidden email]>
>     *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
>     [hidden email] <mailto:[hidden email]>
>     https://mail.python.org/mailman/listinfo/matplotlib-devel
>
>
>     _______________________________________________
>     Matplotlib-devel mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://mail.python.org/mailman/listinfo/matplotlib-devel
>

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

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

matplotlib - devel mailing list
In reply to this post by Eric Firing
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 <[hidden email]> 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
[hidden email]
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

[hidden email]

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

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

matplotlib - devel mailing list
In reply to this post by Eric Firing
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 <[hidden email]>
To: Benjamin Root <[hidden email]>; OceanWolf <[hidden email]>
Cc: matplotlib development list <[hidden email]>
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
> <[hidden email] <mailto:[hidden email]>> 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 <[hidden email] <mailto:[hidden email]>>
>    *To:* [hidden email] <mailto:[hidden email]>
>    *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
>    [hidden email] <mailto:[hidden email]>
>    https://mail.python.org/mailman/listinfo/matplotlib-devel
>
>
>    _______________________________________________
>    Matplotlib-devel mailing list
>    [hidden email] <mailto:[hidden email]>



_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

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

Ryan May-3
In reply to this post by Benjamin Root
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
To: [hidden email]
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
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel


_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel


--
Ryan May


_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
Reply | Threaded
Open this post in threaded view
|

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

tcaswell
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
To: [hidden email]
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
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel


_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel
_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel


--
Ryan May

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel


--
Thomas Caswell
[hidden email]

_______________________________________________
Matplotlib-devel mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/matplotlib-devel