Thus the fixing of Curses::UI is a side project of a side project into which I cannot afford to invest much time.

I can completely understand that, and I certainly wouldn't want to "scare you away" by telling you how much test code I've had to write compared to application code for some commercial software ;-) And I also understand that if a fix is trivial, you don't necessarily want to write a full test case for that - but I guess you'll still want to briefly check that your fix worked? I'm just suggesting that it's better if it's possible to do so with code that is part of the Curses::UI package, even if it's just the examples/demo-widgets script. And sorry if I made it sound like POD documentation is necessary for every bugfix, what I was describing was more of a best practice - for trivial fixes a short commit message (referencing the RT bug if applicable) can certainly be enough. This is open source, if you want to fork Curses::UI you are free to do so and make contributions however you like - there are just some "best practices" (often subjective) that can improve cooperation. You could for example make a fork on GitHub of the latest Curses::UI release, something anyone could pull patches from if they want. Perhaps that could be a compromise between limited time and your willingness to contribute to an open source project :-)