On Fri, Apr 19, 2013 at 10:16:35AM +0000, Murali Reddy wrote: > > Pardon my ignorance of project management, but it appears to me we are > talking of managing a release after half way through the cycle. May be > this is orthogonal discussion, but how about taking approach of planning a > release early in the cycle (at least for future releases)? Having a time > window between each release where we actually plan for the next release. > Discussions include - direction of the project, what big features are to > be included, rough estimate of the effort, risks and timelines would help > in planning releases better? Perhaps we should use Collab conferences for > this purpose, where we can plan for the next release (apart from show > casing the features of previous release). Since Collab is also scheduled > to happen on a half-yearly timeline it makes this easier to execute > release management starting from there.
I think you're far from ignorant on the topic, and bring up some good points. IMO there are 2 models for projects to follow: 1 - feature-based releases 2 - time-based releases The feature-based approach is one where features are planned and executed with a target completion date, and is managed much like a traditional "project" that we are used to in corporate life. Tasks, ordering, dependencies, etc... The release isn't complete until the features are done, docs are complete, QA is signed off and the marketing stuff is ready to go out. Certainly there are target dates, but the priority is on the feature list of "must have" changes getting done. Everything in the planning and execution process focuses on those features as the overall goal of the team. Things will be pulled, and changes to the plan / schedule will be made, all in the service of getting as close to the planned feature set as possible. The time-based approach (currently the one that I thought we were trying to follow) is very different. It decouples feature development (and any associated planning around task ordering, testing, etc...) from the act of releasing code. In doing this, it *should* allow anyone to start the mechanics of releasing code at almost any point in time. For us, this includes a QA cycle, doc and translation work, marketing, etc... Those tasks take time to get done, and they represent the cost of the release itself. I'm an advocate of continuing to get better at time-based releases. To get better, I feel that we need to focus on improving the quality and completeness of what makes it into master. This means that a feature development effort will have more work to get done before it's allowed to merge into the (hopefully) stable and well regression tested master branch. It also means that some of the more traditional project management tasks are going to be happening as part of feature development, and not part of the release process. The time-based model, IMO, should work much better for a volunteer community like this. If someone goes on vacation or has $dayjob responsibilities that take their time away from ACS, that only impacts their feature(s), not the release itself. This is a generalization, because certainly there could be 2 features that rely on each other, and we rely on QA, docs, translators, marketing folks, as well as an RM to actually perform the release... but I think you should be able to follow the point there. As I've said on other topics, there's a natural inclination to want to apply solutions to planning / execution / whatnot that work well in a corporate environment to OSS projects. I have that inclination as well sometimes. However, we need to make specific decisions that get us in a position where community growth and changes in composition are unrelated to our release cadence and processes. A bit long winded, sorry, but I think the difference in philosophies are important to understand. Happy to debate any of this though. -chip
