lucaswilric

Others have suggested starting with the small things - email, text messages, etc. I agree; those are good places to practice.

I've gotten a certain amount of benefit from exposing my work to trusted test readers. Sometimes that's my manager, sometimes my team. Sometimes I deliberately look further afield for readers from my target audience (e.g. people who don't already know the thing I'm writing about).

I hope this helps. Best of luck!

I think there are better ways to solve the problem of maintainers burning out.

Encouraging code contributions is a good thing, it encourages people to suggest solutions to their problems. I think it fails to solve the burnout issue, though, because processing those PRs is also work for the maintainer.

Encouraging donations is also a good thing, because good work deserves reward, and sometimes cash is an appropriate way of helping a project.

The problem with both of these tactics is that they reduce the overall input of ideas - both good and bad - into the project. They make no distinction about the quality of the ideas or the validity of the issues.

I think a better solution is to address the burnout problem more directly, for example by helping the maintainer manage that huge list of issues. That's hard, because the maintainer is unlikely to trust just anybody with their project, if anybody even volunteers. But if a project you really care about is failing because of this, then maybe that's a way you could offer to help. The worst that's likely to happen is that the maintainer will say "no, thanks".

It's feasible, as long as you can tolerate a bug for a short time. The advantage is that once you notice a bug, there's less in the way of getting a fix out to production.

And let's face it: we're all tolerating bugs in production all the time.

As an aside, CD doesn't obviate QA or testing. It strongly favours automated testing over the manual flavour, especially during integration, but even then there's nothing stopping you from conducting manual tests on your branch before integration.