[SciPy-Dev] Issues backlog (and PRs)

[Pauli Virtanen]

Hi,

la, 2019-08-03 kello 17:21 -0700, Joshua Wilson kirjoitti:
> The SciPy repo currently has 1,242 open issues. The oldest open issue
> is from April 25th, 2013. There is definitely some signal in those
> old
> issues, but, as the project has evolved quite a bit from then, also
> quite a bit of noise (e.g. feature requests that one person cared
> about many years ago).
> 
> We could spend a lot of time going through the old issues and closing
> the ones that are no longer relevant, but that's going to take a lot
> of time and I do not believe it is a high-leverage way to spend our
> limited developer time. Instead I propose that we simply close issues
> over a certain cutoff date. More concretely, we:
> 
> - Determine a cutoff date beyond which we will close issues
> - Announce a date when we will close the old issues
> - During that time, if anyone wants to preserve an old issue they can
> open a new, updated issue, or perhaps adjust the SciPy roadmap if
> something is particularly important.
> 
> Anyway, I am sure this will be controversial, so looking forward to
> hearing everyone's thoughts!

I'm not sure I like an auto-close bot myself --- a bug is a bug. The
"defect" labels I think have been somewhat conservatively correctly
assigned, and probably not so many of those are in reality invalidated.

There's of course a problem that some old issues are open because the
scope is big, and would need lots of work to address.

With the "enhancement" etc. labels the situation may be a bit
different, as some of those probably are specific to someone's needs at
a specific time.

A bot just tagging old issues with "stale" probably would be fine, as
it's simple to filter the old ones out ("-label:stale").

    ***

We have a somewhat similar issue with old PRs --- there's quite many
where the original submitter has been MIA for years.  For many of them,
I think there's usually some reason why they were not finished (i.e.
some roadblock has been encountered, the approach wasn't quite right,
polish is missing, etc.).

I'd like to suggest the following:

* Old and stale? Do you want to do it yourself?
-> Do it yourself (possibly from scratch).

* Old and stale? Is there something useful?
-> Add `needs-champion` label and close. Say it's been closed due to
lack of activity, but if someone wants to they can pick it up.

* Just old and stale?
-> As above, but don't add `needs-champion`.

Probably should not be blindly applied, e.g. to cases where the problem
is just that nobody got around to review at the time, and then it got
buried.


I'd also like to recommend reviewers to use the PR workflow features:

* Did you complete reviewing a PR (so it's waiting for changes)?
-> Tag with 'needs-work'. 

* Did you complete re-reviewing an updated PR (so it's waiting for
changes again)?
-> Remove 'needs-work' label, and then re-add 'needs-work' again. (A
line at the bottom will then appear saying you removed and re-added the
tag.)

Alternatively, use Github's review system --- but when you have
completed re-reviewing an updated PR, add a new "Changes requested"
review comment instead of only adding new comments to the discussion.
(Using the tags may be less hassle.)

This will help e.g. my custom status tracking script to keep up:
https://pav.iki.fi/scipy-needs-work/

Last time I looked, Github's web UI workflow tracking still couldn't
list PRs that are awaiting reviewer response, so I guess I'm sticking
with this script until the situation improves.

	Pauli