IIUC, the problem at hand is:
- Folks (presumably newbies) are posting issues that they think are bug
- 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
- 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!
On Fri, Nov 2, 2018 at 10:10 AM, Eric Firing <efiring at hawaii.edu> wrote:
On 2018/11/02 5:03 AM, Thomas Caswell wrote:
The backlog problem is also real, however I am not sure that just closing
old issues / PRs and rapidly closing new issues will actually make it
better. It will make the number smaller, but the underlying issues (either
the bugs or documentation deficiencies) will still be there.
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
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.
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Christopher Barker, Ph.D.
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...