Reduce number of open issues

[odersky]

Our open issues trend is steadily upwards, and if we do nothing we will soon hit 500 open issues. I think this is self defeating. With so many open issues it takes major work to even get an idea what needs to be done. Hence, less issues get fixed, hence, even more open issues.

We should take efforts to reverse that trend, and ideally reach zero open issues at some point. How to do this? Here are some ideas:

• Try to assign an open issue within reasonable time to someone (where reasonable = ~ 1-2 weeks)

• Everyone should scan issues periodically to not build up a personal backlog

• If you feel you cannot solve an issue, try to assign to someone else

• If there is no clear assignee for an issue, and someone thinks the issue is important and/or urgent, that person should bring it up at the next meeting. Maybe we can work out together a course of action.

• In all other cases I feel it is better to close the issue and add a label "stat:revisit". This signals that without a change in circumstances the issue will not be solved at the present time. A possible change in circumstances could be

  • New insight how to solve the issue
  • A new contributor willing to look into the issue
  • A new reason why the issue is urgent and important.

  If any of these changes happens, we should then re-open the issue.

For community/help wanted issues we should apply the same algorithm. We can leave them open for some time (e.g. one month), but if no help is forthcoming, we should close with "stat:revisit". The docs should be updated to encourage potential contributors to also scan such closed issues and re-open some if they feel they can solve them.

[allanrenucci]

We should also go through the oldest issues. I had a quick look though them and it turns out that many of them can be closed:

• Some are already fixed. We can simply add a regression test and close
• Some are not actionnable anymore (e.g. related to the old REPL or the old testing infrastructure)

[smarter]

I'm not sure if closing unresolved issues really helps, it might be discouraging to bug reporters to see their problems ignored. What I think we need to do is give higher priority to fixing bugs over adding new features. For example, we could dedicate a 6 weeks cycle to only (or mostly) fixing bugs, or we could try to have everyone one the team try to fix at least N issues for some N in every 6 weeks cycle.

[odersky]

@smarter Agreed we need to prioritize bug fixes and I do so periodically myself. But I don't believe it alone will fix the problem.

[odersky]

it might be discouraging to bug reporters to see their problems ignored.

That's why I believe the "in-between state" of stat:revisit will actually help. It signals

• we currently do not have the means to fix this
• if you have an idea how to fix it or have reasons why we should re-prioritize you can re-open, we don't mind.

A normal closed issue has a different siganlling:

• we believe this is already fixed/not an issue/not worth addressing
• this is (normally) a final judgment

[odersky]

Another distinction is between open issues with "on-hold" status and closed issues with "revisit" status. An issue should be kept open with "on hold" if its solution needs to wait for one or more other changes, which are on the roadmap. By contrast closed "revisit" issues wait for a change of circumstances which is might happen in the future, but no current plans exist for the change to happen within foreseeable time.

[odersky]

I believe stat:revisit worked well. We have now 35 closed issues with this label, and no one complained yet. To further reduce issues I believe it would be important to assign responsibilities for areas.

Here are the current top areas according to https://github.com/lampepfl/dotty/issues/labels, together with the number of issues or open PRs for each:

• typer 46 @odersky @smarter
• pickling + quoting 15 @nicolasstucki @biboudis @odersky
• infrastructure 14 @allanrenucci @OlivierBlanvillain
• reporting 12 @allanrenucci @liufengyun
• REPL 11 @allanrenucci @Duhemm
• doctool 11 @Duhemm @OlivierBlanvillain
• testing 10 @allanrenucci @liufengyun @OlivierBlanvillain
• annotations 9
• docs 9 @biboudis @odersky
• backend 8 @smarter @nicolasstucki
• IDE 8 @odersky @Duhemm @smarter
• pattern-matching 5 @liufengyun @odersky

I think pattern=matching is under-reported since some typer errors also fall into this category. I think it would be good to have a moderator for each area that takes responsibility for following up on issues in the area, together with one or two assistants that can help moving issues along and that can review. Outside contributors are very much welcomed in these roles.

I am happy to take the lead (moderator) for typer and to help in pickling + quoting, IDE, and pattern-matching. It would be great if we would find people for the other roles as well.

[abgruszecki]

Closing in the name of reducing the number of open issues :)