Alternatively, going all-in would involve careful planning on things to report, reporting constantly on the many small things, always chasing about the "quick things that can be done and reported on", like a quick plugin port, fast untested releases and stuff like that.
Those sound too much like the capitalistic "short-term profits above all else". 🤮
Some time with just focusing on fixes might be what is needed, but need to set the expectations right...
@falktx If you change your work to fit a mold of quick results for small tasks, you will create an expectation that may disappoint subscribers if you deviate from it in the future. On the other hand, if you are transparent that you are working on tasks that have not reached completion, I doubt subscribers would mind... unless you go 2.5 years without a release.
@falktx Having functioning code to release every few weeks takes lots of resources. That is feasible for a venture capital funded company like GitLab or a huge community like Rust, but expecting that from a single developer working mostly alone or even a small volunteer team is unrealistic.
@falktx I don't think regular progress reports require having tangible results in short intervals. You can say you've been working on this and that large project, they will take more time, here is what you have done so far, these are the obstacles you are working on overcoming, and there are not any usable results yet.