[SciPy-Dev] Issues backlog

[Ralf Gommers]

On Mon, Aug 5, 2019 at 11:28 AM Matt Haberland <haberland at ucla.edu> wrote:

> >  I'd much rather go through them and close by hand than have some bot do
> it.
>
> Instead of automatically closing, how about a person or bot proposing an
> "issue of the day"?
>

This has the same issue imho, it's just more noise. We've tried this in the
past (IIRC with docstrings) and it doesn't really work.


> I did a survey of some old issues in preparation for the CZI proposal, and
> I got the sense that some of them just needed to find the right set of
> eyes.
>

Indeed. Or better: just any pair of eyes with some experience of SciPy
usage/development.

I'd be quite unhappy with more random pings or unfriendly bots. However, if
we want to make a dent in this, I'm happy to volunteer to triage 50 or 100
issues over the next few weeks. If some more people do that, the "outdated
issues" issue can be solved without too much trouble.

Also note, there's a second way to do this: consolidating issues. It's a
little more work, but can be quite effective. For example, search for
"mannwhitneyu" in the issue tracker. It shows 9 open issues for that one
function. I bet (almost) all of them are still valid bug reports. If
someone would spend 30 minutes or so to write a summary, we could bring
that down from 9 open issues to 1.

Cheers,
Ralf



Showing the same issue to many of us at the same time could help with that.
>
>
> On Mon, Aug 5, 2019 at 10:41 AM Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
>
>>
>>
>> On Sun, Aug 4, 2019 at 1:56 PM Stefan van der Walt <stefanv at berkeley.edu>
>> wrote:
>>
>>> On Sat, Aug 3, 2019, at 22:22, Dieter Werthmüller wrote:
>>> > I think this is a very good idea, and it should be applied to issues
>>> and
>>> > PRs. However, instead of age as a criteria I would use inactivity
>>> (e.g.,
>>> > if there is an old issue from 2013 that has activity discussions every
>>> > year then it should not be closed).
>>>
>>> Agreed, the last modified age may be a better measure.  That way we
>>> don't need to recreate issues we want to keep open, we can simply leave a
>>> comment / add a label / edit the description.
>>>
>>> But this method for closing issues can also be infuriating to users: how
>>> many times have you come across a project where an issue was described in
>>> detail with debugging info, only to be closed by a bot due to inactivity?
>>> Perhaps that can be addressed by setting the inactivity-time-to-closure to
>>> a high enough duration, perhaps 3 years.
>>>
>>
>> I agree with the infuriating part: each time I've had an experience like
>> that with another project (e.g. pip), it has been extremely annoying. To
>> the extent I decided to never contribute again. Issues closed that were
>> valid, PRs closed that didn't get reviewed, etc. It is a good way to tell
>> contributors that their contributions aren't valued, and/or lose useful
>> information.
>>
>> In general, valid bug reports should simply not be closed imho. The
>> exception is probably new feature requests. About 300 of the 1200 open
>> issues have the "enhancement" label. Looking through the older enhancements
>> shows that many can be closed. However even there, there's useful content
>> in some. I'd much rather go through them and close by hand than have some
>> bot do it. This has multiple advantages:
>> - doesn't anger contributors
>> - keeps the useful ones
>> - is probably _less_ work (at 3 minutes per issue one could triage the
>> 200 issues that haven't been touched in the last 2 years in a single day),
>> choosing and maintaining a bot is easily going to take someone that much
>> time.
>>
>>
>>
>>> If this method is enacted, I suggest an email to the list once a month
>>> with issues that were automatically closed.  That may at least provide an
>>> opportunity for those interested to go back and "save" any important ones
>>> they care about.
>>>
>>
>> This is actually even more work. It asks all maintainers and mailing list
>> contributors to triage with such an email, so many people will be doing
>> duplicate work.
>>
>> Cheers,
>> Ralf
>>
>> _______________________________________________
>> SciPy-Dev mailing list
>> SciPy-Dev at python.org
>> https://mail.python.org/mailman/listinfo/scipy-dev
>>
>
>
> --
> Matt Haberland
> Assistant Adjunct Professor in the Program in Computing
> Department of Mathematics
> 6617A Math Sciences Building, UCLA
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at python.org
> https://mail.python.org/mailman/listinfo/scipy-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20190805/02accf61/attachment.html>