<< High-profile SeaMonkey Usage | The roads I take... | Integration eines Magento-2-Webshops mit FreeFinance und selbstgebautem Warenmanagement >>
Openness and Community Improve Release Quality
Those two factors enable a state of constantly being reminded that you can't be sloppy on release criteria. You just can't downgrade an issue from a release blocker without a really good reason. You have to account for this change to the community before the actual release while in traditional software development, the user community will complain about problems solely after the release.
And that's the really big difference.
We have learned this process pretty well over the years in the Mozilla project, and managed to deliver constantly high quality releases because of that - and we even remember when Netscape ignored our community voices and released their 6.0 "final" from code that we wouldn't have dared to call a Mozilla final release.
In my comment on that other blog post, I ended with 3 guidelines I derive from what I think we have learned in the Mozilla project when it comes down to releases, and I'd like to repeat them here:
- Make your processes open, have the community actively participate, and quality will profit.
- Believe testers in the community. Sure, they are talking about their pet feature/bug, so take feedback with a grain of salt. But at least re-think if what you’re doing is really what you should do when the community disagrees. There’s some possibility that they are actually right.
- Never ship on a fixed schedule and never rush a release. Only, ever, ship when it’s ready to be shipped, never before that point. It’s better to tell users you need to ship a month or two later to meet your high internal quality standards and have some press about people eagerly waiting on your release than to ship right on time and have even more press about how your product sucks.
Entry written by KaiRo and posted on September 8th, 2007 04:14 | Tags: Mozilla, release | no comments | TrackBack
No comments found.