From ndbecker2 at gmail.com Thu Nov 1 08:25:46 2018 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 01 Nov 2018 08:25:46 -0400 Subject: [Matplotlib-devel] matplotlib 3.0.1 drops title if data has NaN ! Message-ID: Really, it's true. I don't yet have a simple example, but just spent the last 1/2 hour debugging. I have a figure with multiple semilogy plots. When I do ax.set_title(title), no title appears (it will appear if I add y=0.95). I tried various constrained_layout and many other things. But finally, I found that some of the data had NaN. Using pandas dropna, to clean the data presented to semilogy, NOW the title appears. From elch.rz at ruetz-online.de Thu Nov 1 08:46:44 2018 From: elch.rz at ruetz-online.de (Elan Ernest) Date: Thu, 1 Nov 2018 13:46:44 +0100 Subject: [Matplotlib-devel] matplotlib 3.0.1 drops title if data has NaN ! In-Reply-To: References: Message-ID: <2f609f16-8a97-44c7-15e3-d0f0f9292d06@ruetz-online.de> Would it be possible to open an issue (https://github.com/matplotlib/matplotlib/issues) about this, including a self-contained example (ideally using numpy only, not pandas)? Am 01.11.2018 um 13:25 schrieb Neal Becker: > Really, it's true. > I don't yet have a simple example, but just spent the last 1/2 hour > debugging. > > I have a figure with multiple semilogy plots. When I do > ax.set_title(title), no title appears (it will appear if I add y=0.95). > > I tried various constrained_layout and many other things. But finally, I > found that some of the data had NaN. Using pandas dropna, to clean the data > presented to semilogy, NOW the title appears. > > > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > > From ndbecker2 at gmail.com Thu Nov 1 10:07:22 2018 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 01 Nov 2018 10:07:22 -0400 Subject: [Matplotlib-devel] matplotlib 3.0.1 drops title if data has NaN! References: <2f609f16-8a97-44c7-15e3-d0f0f9292d06@ruetz-online.de> Message-ID: Elan Ernest wrote: > Would it be possible to open an issue > (https://github.com/matplotlib/matplotlib/issues) about this, including > a self-contained example (ideally using numpy only, not pandas)? > > > Am 01.11.2018 um 13:25 schrieb Neal Becker: >> Really, it's true. >> I don't yet have a simple example, but just spent the last 1/2 hour >> debugging. >> >> I have a figure with multiple semilogy plots. When I do >> ax.set_title(title), no title appears (it will appear if I add y=0.95). >> >> I tried various constrained_layout and many other things. But finally, I >> found that some of the data had NaN. Using pandas dropna, to clean the >> data presented to semilogy, NOW the title appears. https://github.com/matplotlib/matplotlib/issues/12701 Perhaps the issue is due to cairo backend? From tcaswell at gmail.com Thu Nov 1 11:24:35 2018 From: tcaswell at gmail.com (Thomas Caswell) Date: Thu, 1 Nov 2018 11:24:35 -0400 Subject: [Matplotlib-devel] please be slower to close bug reports from first-time reporters Message-ID: 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: From pmhobson at gmail.com Thu Nov 1 12:36:36 2018 From: pmhobson at gmail.com (Paul Hobson) Date: Thu, 1 Nov 2018 09:36:36 -0700 Subject: [Matplotlib-devel] please be slower to close bug reports from first-time reporters In-Reply-To: References: Message-ID: 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 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 > https://mail.python.org/mailman/listinfo/matplotlib-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jklymak at uvic.ca Thu Nov 1 12:46:41 2018 From: jklymak at uvic.ca (Jody Klymak) Date: Thu, 1 Nov 2018 09:46:41 -0700 Subject: [Matplotlib-devel] please be slower to close bug reports from first-time reporters In-Reply-To: References: Message-ID: <8CE6B430-3622-45A5-BB39-7D3AE5E3A103@uvic.ca> 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 From tcaswell at gmail.com Fri Nov 2 11:03:24 2018 From: tcaswell at gmail.com (Thomas Caswell) Date: Fri, 2 Nov 2018 11:03:24 -0400 Subject: [Matplotlib-devel] please be slower to close bug reports from first-time reporters In-Reply-To: <8CE6B430-3622-45A5-BB39-7D3AE5E3A103@uvic.ca> References: <8CE6B430-3622-45A5-BB39-7D3AE5E3A103@uvic.ca> Message-ID: 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 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 > https://mail.python.org/mailman/listinfo/matplotlib-devel > -- Thomas Caswell tcaswell at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From efiring at hawaii.edu Fri Nov 2 13:10:01 2018 From: efiring at hawaii.edu (Eric Firing) Date: Fri, 2 Nov 2018 07:10:01 -1000 Subject: [Matplotlib-devel] please be slower to close bug reports from first-time reporters In-Reply-To: References: <8CE6B430-3622-45A5-BB39-7D3AE5E3A103@uvic.ca> Message-ID: 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 From juichenieder-nabb at yahoo.co.uk Fri Nov 2 13:41:09 2018 From: juichenieder-nabb at yahoo.co.uk (OceanWolf) Date: Fri, 2 Nov 2018 17:41:09 +0000 (UTC) Subject: [Matplotlib-devel] please be slower to close bug reports from first-time reporters In-Reply-To: References: <8CE6B430-3622-45A5-BB39-7D3AE5E3A103@uvic.ca> Message-ID: <1783902327.1610871.1541180469139@mail.yahoo.com> 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 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: From ben.v.root at gmail.com Fri Nov 2 13:58:21 2018 From: ben.v.root at gmail.com (Benjamin Root) Date: Fri, 2 Nov 2018 13:58:21 -0400 Subject: [Matplotlib-devel] please be slower to close bug reports from first-time reporters In-Reply-To: <1783902327.1610871.1541180469139@mail.yahoo.com> References: <8CE6B430-3622-45A5-BB39-7D3AE5E3A103@uvic.ca> <1783902327.1610871.1541180469139@mail.yahoo.com> Message-ID: 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 > *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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From efiring at hawaii.edu Fri Nov 2 14:34:28 2018 From: efiring at hawaii.edu (Eric Firing) Date: Fri, 2 Nov 2018 08:34:28 -1000 Subject: [Matplotlib-devel] please be slower to close bug reports from first-time reporters In-Reply-To: References: <8CE6B430-3622-45A5-BB39-7D3AE5E3A103@uvic.ca> <1783902327.1610871.1541180469139@mail.yahoo.com> Message-ID: <1bac606d-89dd-6591-c0ef-0a69b1af9e2f@hawaii.edu> 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 > > 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 > > *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 > From chris.barker at noaa.gov Fri Nov 2 15:33:00 2018 From: chris.barker at noaa.gov (Chris Barker) Date: Fri, 2 Nov 2018 12:33:00 -0700 Subject: [Matplotlib-devel] please be slower to close bug reports from first-time reporters In-Reply-To: References: <8CE6B430-3622-45A5-BB39-7D3AE5E3A103@uvic.ca> Message-ID: 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 wrote: > On 2018/11/02 5:03 AM, Thomas Caswell wrote: > >> The backlog problem is also real, however I am not sure that just closing >> old issues / PRs and rapidly closing new issues will actually make it >> better. It will make the number smaller, but the underlying issues (either >> the bugs or documentation deficiencies) will still be there. >> >> > Tom, > > It is a matter of triage. I think you are missing a critical point: > closing issues *can* make the situation better by reducing the time that is > lost on scanning them, or diving into them, when that time would be better > spent actually fixing something. Furthermore, the list of open issues can > simply be overwhelming, discouraging work by existing developers, and > probably also discouraging potential developers from joining us. > > It is not a tragedy if a genuine issue is closed. If it is reporting a > major problem, it will crop up again, and eventually get the necessary > attention. > > There will *always* be bugs and documentation deficiencies; the question > is how to maximize available developer time and attention, and how to make > the best use of it. > > Eric > > _______________________________________________ > Matplotlib-devel mailing list > Matplotlib-devel at python.org > https://mail.python.org/mailman/listinfo/matplotlib-devel > -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker at noaa.gov -------------- next part -------------- An HTML attachment was scrubbed... URL: From juichenieder-nabb at yahoo.co.uk Fri Nov 2 15:44:52 2018 From: juichenieder-nabb at yahoo.co.uk (OceanWolf) Date: Fri, 2 Nov 2018 19:44:52 +0000 (UTC) Subject: [Matplotlib-devel] please be slower to close bug reports from first-time reporters In-Reply-To: <1bac606d-89dd-6591-c0ef-0a69b1af9e2f@hawaii.edu> References: <8CE6B430-3622-45A5-BB39-7D3AE5E3A103@uvic.ca> <1783902327.1610871.1541180469139@mail.yahoo.com> <1bac606d-89dd-6591-c0ef-0a69b1af9e2f@hawaii.edu> Message-ID: <1885863921.32000204.1541187892411@mail.yahoo.com> 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 To: Benjamin Root ; OceanWolf Cc: matplotlib development list 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 > > 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 > >? ? *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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jklymak at uvic.ca Mon Nov 5 13:18:47 2018 From: jklymak at uvic.ca (Jody Klymak) Date: Mon, 5 Nov 2018 10:18:47 -0800 Subject: [Matplotlib-devel] Weekly call... Message-ID: <7F5B9324-A4CB-41F9-BAC0-0DD32EE91B6A@uvic.ca> Weekly call co-ordinates are: https://paper.dropbox.com/doc/Matplotlib-meeting-agenda--ARFMy4X1WGeiihXLsFRBdvD6Ag-aAmENlkgepgsMeDZtlsYu with the start of an agenda. 15:00 EST (20:00 GMT). Devs should feel free to add to the agenda? Thanks, Jody From rmay31 at gmail.com Mon Nov 5 18:22:32 2018 From: rmay31 at gmail.com (Ryan May) Date: Mon, 5 Nov 2018 16:22:32 -0700 Subject: [Matplotlib-devel] please be slower to close bug reports from first-time reporters In-Reply-To: References: <8CE6B430-3622-45A5-BB39-7D3AE5E3A103@uvic.ca> <1783902327.1610871.1541180469139@mail.yahoo.com> Message-ID: 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 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 >> *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: From tcaswell at gmail.com Fri Nov 9 20:48:28 2018 From: tcaswell at gmail.com (Thomas Caswell) Date: Fri, 9 Nov 2018 20:48:28 -0500 Subject: [Matplotlib-devel] REL: v3.0.2 Message-ID: Folks, Just tagged 3.0.2, will make wider anouncement when wheels / conda-forge is up. This is the second bug-fix release for the v3.0 series. - Un-breaks basemap which was broken by partially restoring private APIs for cartopy. - Fixes bug in warning code when used in an embedded context. - Fixes crash when using Tk and closing the first open window before showing it - Many documentation improvements. - Restore a corner case on ColorBar tick usage. - Change the default behavior of `matplotlib.use` to silently allow more 'safe' switching after auto-discovery, but before starting an event loop. - Improvements to bounding box calculations. - Provide the correct length for RcParams instances. --- Given that this is only a 2 weeks after 3.0.1 there are a surprising number of changes! Thanks to everyone who worked on this release and for bearing with my slowness in getting this tagged. Tom -- Thomas Caswell tcaswell at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From tcaswell at gmail.com Mon Nov 12 16:14:51 2018 From: tcaswell at gmail.com (Thomas Caswell) Date: Tue, 13 Nov 2018 08:14:51 +1100 Subject: [Matplotlib-devel] please be slower to close bug reports from first-time reporters In-Reply-To: References: <8CE6B430-3622-45A5-BB39-7D3AE5E3A103@uvic.ca> <1783902327.1610871.1541180469139@mail.yahoo.com> Message-ID: 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 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 > 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 >>> *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: