Hi devs, We've been quite bad at following the release strategy we've defined so far: timeboxing. We've been constantly slipping our release dates during all the past releases (and not by 1 or 2 days, but by 2 weeks or more). Personally I find this not professional of us and for me it means that the date we give are just a joke now. I don't even see why we're giving dates since they can only be misleading to anyone who would act on them… At the current slippage rate, we should only give a month estimation to have a chance of being correct ;) There's only one reason we're really slipping IMO: we've forgotten that we're doing time boxing. Let me remind us what time boxing is and how it can be made to work: * It means releasing on a fixed date and releasing whatever is ready at that date. * The idea is also to do quick releases so that if a given feature is not in a release it'll be in the next one coming soon (we used to do 2 to 3 weeks releases at some points and recently we've been doing instead 3-5 weeks instead) * The reason for releasing often is because this pushes the bug fixes and new stuff to users ASAP and thus let them experiment with them and give us feedback (bugs, usability, etc) * The way to make timeboxing work is by having automated functional tests so that we can release safely knowing that our test suite will catch the problems if any. This means that whenever a commit is done, in the same commit there are tests proving that what is committed is working (and not several weeks later which would be anti-timeboxing). * it doesn't mean we cannot have a roadmap. What it means is that we should the maximum of what is in the roadmap in a given time slot. What's not done doesn't get released. This means that large features should be divided into small one that will fit. Developers need to think about what they're doing by constantly checking the release date and verifying what they can achieve for that date and make absolutely sure that what they have committed is working for that date (even if what they have committed is not finished). * Timeboxing is not about how many men/days you have available or whether people are on holidays or not. If you have less men/days you do less work. It doesn't change the release date. Basically you can only do timeboxing if you have good and automated quality control. The opposite of timeboxing is feature releases which lead to the following: * People committing not working stuff or without tests because they know they'll have time to fix it later on before the release (easy to think this since there's no release date, it's only when the features are done that it'll get released) * Release date become not important since they keep being pushed since what's important is to release planned features * Build failing all the time and developers not caring about it ("it can always be fixed later when we get close to the release date" - that's easy to say since there' no fixed release date) * Users seeing less frequent releases and giving less feedback to developers (thus helping less) * In general, quality dropping over time So we have several choices: 1) Forget timeboxing and do feature-based releases, i.e. we list features and we only release when they're done 2) Start doing real timeboxing again I've seen so many projects do 1) in the past with such bad results that for me there's no doubt that the only good strategy is 2). Especially for an open source project which has a strong community and we should be releasing stuff regularly and quickly to this community to get good feedback. Doing timeboxing is also a great way to improve the quality of our code. Timeboxing can only work fine if everyone agrees with it (we can revert stuff from a developer if it breaks things but it's a pain) and believe in the release date, so we'd need everyone's agreements. So WDYT, are we ok to resume doing timeboxing and go back on track? On my side I'm ok to do it and help enforce it. If we agree we should start now by releasing RC1 ASAP and give a new date for 3.4 final and release on that date. Thanks -Vincent