Let's close all PRs and Issues from before Jan 1, 2023?

[ekalosak]

We're behind on reviewing PRs. To me, the only way to realistically start digging out of this backlog is to clear all the stuff that we've already dropped the ball on.

I'd love to get community and maintainer input before going on this opinionated crusade. Please weigh in.

And of course exceptions apply for those PRs and Issues that track critical bugs, etc.

[lawrennd]

Thanks for raising this Eric, I think this is a great initiative. I'm supportive.

[ekalosak]

I'll just continue sweeping out ~10 or 20 at a time from the back of the issues and if folks want to re-open that's great if not they stay closed and we get that number down to the most relevant 25 or so issues.

[MartinBubel]

I would agree. It also seems like most non-feature PRs are either adressing testing, maptlotlib, numpy, or setup.py (and sometimes combinations of them). Thus, it might be easier to consolidate on the main changes required and addressing them in dedicated PRs. This would also make it much easier to do updates without causing too much conflicts or blockings.

[MartinBubel]

How about opening issues and the respective PRs for the following:

1. pyproject.toml and setup.py clean, incl. metadata links and pep-compliance
2. cython and generated c code (after deciding on what direction to go here)
3. update numpy and matplotlib, including any changes of types that no longer exist
4. testing: move from nose to pytest here

And maybe we could list them under a dedicated milestone as the number of required issues might grow?

Please add if I have forgotten on anything or any idea is rather bad.

I also recommend on assigning a dedicated label to the issues where we close PRs because they are too old. That way, we could easily track those that were valid but simply to old and give the contributors and update once we fixed the required maintenance so they might even make a new PR?

[Dapid]

I think this is a terrible idea.

I have contributed detailed bug reports to other projects, only for them to be eventually auto-closed. The problem persists, and now I am annoyed. When someone proposed something similar on, IIRC, Scipy, other people shared similar experiences.

Some, like #609 are probably not applicable any more, and #622 is a request for help that never got answered, and the person is most likely not interested anymore. I think those are fine to close; but not just because of age. On the other hand, #984 is a valid issue, and it would be better marked as "triaged" or "contributions welcome", even "good first issue".

[MartinBubel]

Hi @Dapid thank you for commenting on this. You are absolutely right with your opinion on this. Are you willing to help us, e.g. by assigning labels as proposed?

Currently it seems like I am the only developer left to keep GPy alive. However, I am not a member of Sheffield ML Group. I committed to delivering a patch to GPy that improves compatibility with modern python but as off now, I won't do any further than that.

So far, I was fine with closing old issues and PRs because that would give a clear signal to users: "switch to another gaussian process package as this one most likely has no feature and will become a problematic dependency of your project".

[Dapid]

I could put some effort, yes.

Since GPy is not compatible with the latest Numpy, I have looked for alternatives, but they seem even more abandoned, except for Sklearn, but it only has a subset of the features.

[lawrennd]

It would be great if you can help out @Dapid!

[Dapid]

How?

Do you want me to post them here in a list? I could also label them myself if you give me access.

Another thing. A substantial part of the issues are requests for help. I suggest moving those to the new GitHub discussions to help with the volume.