On Sun, Jan 22, 2017 at 10:41:03AM -0500, Martin Owens wrote:
On Sat, 2017-01-21 at 21:04 -0800, Bryce Harrington wrote:
*I* think we did a great job. We had an intense number of severe problems that would likely have been far bigger impacts than this one, which we were able to resolve. Right now today, untold numbers of people are using the many new features packed into this release.
You're right of course. And your eloquent post about user involvement was very much on the money (you said what I wanted to say but much better)
Given the piles of bug reports we have, if it wasn't this particular bug it would have been one of the others. Or a *still* missing feature. Or performance under some circumstance, or UX that's utterly broken for some special use case.
In this case we may have mis-weighed the issue. considering how often Inkscape is used to add text to a project (rather foolishly perhaps considering svg's text support) but I'm not sure.
Thinking back through the history of the project, this reminds me of a recurring pattern we'd noticed. We introduce a feature that enables some use case that hadn't registered with us previously, but there is some problem limiting it and we get complaints about how broken that is. Then, the next release, we put more attention into that item and resolve the issues, but now some other new use case has been enabled as a result and it's got its own set of bugs.
For example, when we first introduced save as PDF, we figured it'd be a nice new output format for folks. But we had no idea how much pent up demand there was for it, and were rather taken aback at the level of complaints about missing features, bugs, and so on. With a few simple additions we'd opened the door for use cases we hadn't imagined, and found ourselves being roasted because our solution was so limited.
Maybe we've taken too much power out of the hands of the bug managers (and maybe we could do with more bug people?) so they feel empowered to say "No, this must be fixed before release".
Jeez, no this goes entirely the wrong direction for a solution. What this leads to is fatal gridlock in the release process. We would never be able to actually release.
I will spare you the full detailed rant on this (unless you want it), who wants to read a wall of text, right? Suffice it to say we have GOT to make the release process *easier* not harder, and to do that we need to work harder at minimizing the number of blocker bugs we deal with.
"Release early, release often." A few bugs will get through, maybe bad ones, but just keep releasing. The more releases we do and the less time we permit between them, the better the process will go. Less time between releases means fewer features per release, which means fewer new bugs added. More releases means more opportunities for end users to test and give feedback. More releases mean more PR opportunities, more chances to pull in more community members.
If you wish to indulge me in a bit of ranting I can give you a more elaborated answer with historical anecdotes and so on, but the short summary would be something like "blocker bug lists are harmful". IOW, the old adage "Perfect is the enemy of good" applies.
Bryce