I have found over the years that trying new software risks immediately running into a road block in real use. There will be some detail or complexity or bug on a semi-basic requirement that goes directly to an issue in github.
Dokku is not one of those, it does what it does well and aside from a couple of cli argument ordering quirks it's been great for my light usage. If I was using it more I'd probably want to configure entire architectures with declarative config files, I have no idea if it can do that though.
Whenever a new tool / library / plugin / whatever is evaluated by myself or my team, I spend some time on gathering some github issue / PR stats. I think this is now part of my "software engineering toolset" / best practices.
If there are too many open PRs, or unresolved tickets, OR there are too many _new_ ones, I would rather start searching for something else
Same. I do a lot of research and try to get a sense of the person/team behind it and their values, vision, dedication, if they accept outside contributions, etc.
A few years ago it became popular to document the project processes, but it all turned into generic code of conduct garbage and abstract governance pillars, as if they were writing a constitution. So looking at GitHub issues and commit history is still the best way. And very well invested time.
Dokku is not one of those, it does what it does well and aside from a couple of cli argument ordering quirks it's been great for my light usage. If I was using it more I'd probably want to configure entire architectures with declarative config files, I have no idea if it can do that though.