It would benefit beta users if the Scrivener programmer (s) focus on finishing COMPILE before all the many little bugs, additions, and changes. Having Compile complete and fully functional makes using the “beta” more of a beta then the alpha we’ve all been testing/working with. More users would be willing to use if Compile is completed. The little bugs are never ending.
There are a lot of different schools of thought regarding proper software development time management and task prioritization.
What many of them have in common is that by allowing developers to have a mix of big and little bug fixes, you actually help their productivity. Developers are humans, and we all like/need a sense of accomplishment. It is soul-crushing to have to work on one big block of new code, or lots of in-depth debugging where you can spend days or weeks working out several tangled issues, and not be able to say, “Look, see, this works!” This literally drags your productivity curve down and drags out the development time. It also allows new bugs to pile up, which creates its own set of complications (how many of those are duplicates of each other, or in a related chunk of code?)
In other words, while it intuitively makes sense to say “work on all the biggest problems first and only” that actually gets you farther behind. The little stuff never makes it to be the biggest problem. It never gets done.
The solution is to reserve some time to allow developers to tackle and fix the smaller stuff. Sometimes it’s just quick annoyance. Sometimes the fix requires waiting for someone else (a graphic designer to produce an updated set of icons, etc.) so you’re not really losing much time kicking off that process and then going back to other work while waiting for your dependency to be resolved. Sometimes the dev opens up the code to fix a small bug and realizes that it’s a symptom of a much larger one that nobody had gotten bitten by yet, and taking the time to fix it now saves a whole lot of heartache down the road. And sometimes the small bug turns out to be an iceberg, and it’s a much bigger problem than thought, and now that is going to require a lot more time and energy to fix than realized and there is no clear path forward yet, so that needs to be moved up in priority/research.
Everything I’ve read about productivity management says that this approach is true for pretty much any task humans do, not just software development. Farmers have to take time to make those quick fixes on gear before they get neglected and cause critical equipment to be damaged/destroyed. Carpenters and other fabricators need to take a few minutes to work on this trim over here while they’re figuring out how to solve this big problem over there.
So even though it seems counter-intuitive, be heartened by that steady stream of “fixed in the next version” reports. That tells you that work is continuing under the surface and that the devs have a healthy grasp of the bugs, new code, and issues they have in front of them.