<div dir="ltr">IIUC, the problem at hand is:<div><br></div><div>- Folks (presumably newbies) are posting issues that they think are bug reports.</div><div>- Many of those issues turn out to be not bugs, but misunderstandings of the API, etc.</div><div>- We also have a large backlog of issues, and don't want it to keep getting bigger!</div><div>- And there is a limited pool of people with limited time to review issues.</div><div><br></div><div>- One solution is to quickly close issues that aren't really bugs.</div><div><br></div><div>This has the upside of helping keeping the issues list more manageable.</div><div><br></div><div>It also has the downsides of:</div><div> - 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.</div><div> - 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.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>1) is a real bug that needs to be investigated</div><div><br></div><div>2) is not a bug at all, but is a misunderstanding, which is one of:</div><div>    a)  something that is already reasonably well documented</div><div>    b)  something that is poorly documented</div><div><br></div><div>3) Is unclear at this point.</div><div><br></div><div>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:</div><div><br></div><div>1) gets confirmed bug</div><div><br></div><div>2b) gets Documentation</div><div><br></div><div>3) gets  Needs confirmation</div><div><br></div><div>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"</div><div><br></div><div>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!</div><div><br></div><div>-CHB</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 2, 2018 at 10:10 AM, Eric Firing <span dir="ltr"><<a href="mailto:efiring@hawaii.edu" target="_blank">efiring@hawaii.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 2018/11/02 5:03 AM, Thomas Caswell wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
<br>
</blockquote>
<br></span>
Tom,<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<span class="HOEnZb"><font color="#888888"><br>
<br>
Eric</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
Matplotlib-devel mailing list<br>
<a href="mailto:Matplotlib-devel@python.org" target="_blank">Matplotlib-devel@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/matplotlib-devel" rel="noreferrer" target="_blank">https://mail.python.org/mailma<wbr>n/listinfo/matplotlib-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><br>Christopher Barker, Ph.D.<br>Oceanographer<br><br>Emergency Response Division<br>NOAA/NOS/OR&R            (206) 526-6959   voice<br>7600 Sand Point Way NE   (206) 526-6329   fax<br>Seattle, WA  98115       (206) 526-6317   main reception<br><br><a href="mailto:Chris.Barker@noaa.gov" target="_blank">Chris.Barker@noaa.gov</a></div>
</div>