Probably me. :)

RT has always been my preferred issue tracker, and the one I linked to in META.yml. However, some people were reporting issues on GitHub anyway, which meant I often didn't see those issues. So I closed the GitHub issue trackers for each project not so much because I hate GitHub's issue tracker, but more because having two for each project was bad, and out of the two, I would rather use RT.

RT being shut down is annoying yeah. I'm currently investigating three routes:

1. Switch to GitHub issues. GitHub issues is mostly pretty decent if you look at it on a per-project point of view. However, if you're managing a lot of projects, it's less good. You can't move an issue from one project to another, for example; you'd need to close it on one project and open a new one on the other project. RT lets you create a custom dashboard where you can see new issues on all your projects at one glance. This is somewhat possible on Github, but it's a lot less flexible. Maybe I can figure something out with the API though.

2. Host my own copy of an open source issue tracker. A lot of them suck though. I've set up Roundup for clients a couple of times though, and it's pretty darn nice. Customizing it involves writing Python though. Ewww. Overall, it's still a good option, even if I'd need to shower afterwards.

3. Write my own issue tracker. Very tempted to go down this route. It would let me manage issues exactly how I wanted to manage them. I started fleshing out an SQL schema. It seems a lot of work though.

I think I'll probably end up using GitHub in the end; MetaCPAN has pretty decent integration with it, showing the number of open issues like it does with RT. And given the amount of work I'd need to put into setting up and maintaining my own hosted issue tracker, I could put that work into writing custom dashboards for the Github issue tracker using the API.

And actually switching distros over to use the new tracker is pretty easy. Perl exists. It can be scripted.