Summary of Meeting - Saturday, September 5, 2009
Ian MacLennan
Summary of Meeting – Saturday, September 5, 2009
The production working group leadership team held a meeting on Saturday, September 5, 2009. Below is a summary.
Present at Meeting: Sam Moffatt, Louis Landry, Chris Davenport, Ole Ottosen, Ron Severdia, Mark Dexter
Regrets: Ian MacLennan
Status of 1.6 Beta
1.6 is progressing, my current plan was to get to beta which was the original plan and then assess the situation from there
we're still far from final release, front end is missing a whole bunch of ui, acl is still being debated and a few other things are sitting around
at beta release the release team are scheduled to transfer control of the release to the jbs
so the jbs handle the stabilisation and repeat beta until we're stable
Its a little worrying when we can see the most wanted feature Access control list (ACL) is set to 10%, and are now in discussing again. Close to beta this would be a 95% when we were close
May have missed it, but do we have a clear list of targets that has to make it to beta for it to be ready, what do we need help for?
Maybe we could have a clear list of features, that are now proposed, and that we can say: These are coming for sure in 1.7 (multilingual, content renewed, etc.)
So, let me just throw out this hypothetical.... What if 1.6 fails on several fronts...quality, functionality, overal user satisfaction, etc.?
what do you mean by "fails"? That we release a bad product?
I think if we release a stable release that isn't functional, quality coding that works in a way that is at least intelligible to a user (even if it takes a day) we need to be shot
Yes.. by "bad product" it's obviously a broad generalization
But what if there are so many issues that the beta period is 6 months or more?
I think that the Development Coordinators should have a pow-wow and work out the spec for what 1.6 is. Sort out the decisions and make sure that the i's are dotted and the t's are crossed.
I think from there we can review that the things coming in (with all of your help if possible) are written to that spec and that things are up to snuff
Broader community involvement
We discussed the challenges of getting more people involved in development
I think the notion of "lets get others helping with code" is a great one, but I think there are some logistical realities that make that difficult in our current situation.
there are quality control concerns that go along with it
someone has to approve it and when we have not enough people to even commit more than once a week it's difficult to say to those people who DO know how the system works enough to make intelligent decisions. "hey ... review all these other people's work and give them constructive criticism on how they can improve it" when that's not what they have traditionally done because there is more to patch review than just (y) and (n) you have to guide people into making things better and help them get up to quality specs. And that takes tons of time. It's ABSOLUTELY where we have to get but i don't think its as simple as a switch we turn on is my point
even with those less complex tasks, someone has to define what needs to be done, then make sure that what was defined was done. and even in those situations it's usually the someone in "the know" that has to do that initial bit and we aren't used to that and we aren't used to that and even fewer who have a solid vision of the forward path.
Would it make sense for the experienced people to be writing specs and reviewing code? would that leverage their time better than coding?
I don't really know the answer to either of those, but there must be at least some of those people doing the specs and review.
I take it at this point we don't really have any specs?
We have a list of abstract ideas and conversations that took place in toowoomba 8 months ago.
the specs are slowly being formalised on the dev list for the finer details
But unless they're far enough along, people can't be expected to develop/write specs at the same time as things are being built, right?
people have ideas of how to do things in their head
sure, the issue there is that none of those ideas mesh, well ... not a majority
well people disagree with those ideas, i wouldn't say all of them break but there is always someone who has a different way
point being... being in someone's head doesn't communicate it to the masses and others can't join in and help
If our goal is to increase the number of contributing devs, then we need to make it a priority to do things to allows others to contribute
In my opinion, that's a priority but we can't make it a priority in the middle of trying to get a release out.
My observations from following the lists, there was a clear set of targets for Alpha and blockers that could postpone a release. Since the Alpha release I´ve had the impressions that community devs have been invited to come with input and improvements, but it feels like more and more ideas been added, and its not been totally clear what to expect the target for the release would be. Some may have expected their ideas to be included, and now see it not happening.
Big Picture Questions
OK... so how do we produce the best quality product in the shortest amount of time?
I guess one question is whether, all things considered, it's better to have our most knowledgable devs (a) coding or (b) writing specs and reviewing code or (c) some mix of the two?
I think we should discuss long-term issues at a later meeting. Things like how to shorten the time between releases, etc. Our main priority right now is to put together a plan for getting 1.6 out the door. I'd like to hear specific action points on that.