Wichert Akkerman wrote:

 - January 7th  : final bundles merged
 - January 21st : first beta release
 - March 11th   : first release candidate
 - April 23rd   : release

And here is a problem: I learned this week thatthere is a UI sprint
scheduled for February. I do not want to see any non-small changes in
the beta stage, UI or otherwise. So we can do two things:

1. only pick the small changes that result from that sprint and include
   those. Everything else will be an excellent start for Plone 3.5.

2. postponse 3.0 further. This means that we can't go beta until end of
   February, more likely early march. I don't expect to see any UI work
   fully finished before then.

Talking with limi he appears to be in favour of the second option: he
considers it critical that 3.0 has a very polished modern UI. Personally
I have a slight preference for the first option: we have landed an
awesome amount of changes and can still keep a healthy release schedule.

This mis-match had kind of gone by me...

I am thinking we need to be stricter about the alternating
infrastructure and UI releases in the future: currently we are still
doing both infrastructure and UI in a single release. The infrastructure
changes are landing close to the merging deadlines and the UI is not
being done until after the infrastructure has landed. This means the UI
is being done too late and jeopardizes the release schedule.

I think you have a good point. Often, it is easier to do UI once the code has been accepted "in principle" and merged into trunk, because UI tends to have more interdependencies, but also because UI deficiencies often are not discovered until people (esp. limi and co) have used the code a bit, and expecting people to try out all bundles regularly is not very feasible.

I think the UI/infrastructure dichotomy is a false one. No new feature should have a crappy UI. Plone stands out from the rest in large part because we don't let user-unfriendly and inconsistent UI pass (too often). I think a better way to think of it is "end-user focus" vs. "developer focus". 3.0 is very much end user focused; 3.5 should be much more about tools that integrators and developers need, as well as under-the-hood stuff like improving our indexing and searching infrastructure.

A lot of 3.0 needs a tight pulling together in the UI stage, and a lot of work (I know both the portlet and content rule management UI does, and I am fully expecting to dedicate the UI sprint to these two). From 2.1, we learned that a lot of this happened at the (first) UI sprint, and from the way the UI sprint was run. I don't think it's an acceptable option to say "we'll give you the functionality in 3.0, but you'll have to wait 9 months for 3.5 to get a UI that isn't lame".

That said, I don't think it's terrible to see strong UI improvements after the first beta. At the beta stage, we expect more testers, so we can get their feedback into the UI. I agree that looking at the dates, though, we may need another couple of weeks (I really don't think it's more than that) before we start talking RC.

For the future - I think we need to start planning our sprints and our release cycles together. The way it's shaping up, it looks as if the Amsterdam sprint (Feb 17-20) will be about fixing up a lot of the UI turds and loose ends from the bundle frenzy. Sorrento (Mar 27-Apr 3) will be about fixing bugs, tying up remaining lose ends and getting 3.0 into a releasable state. Take away the sprints and I don't think either will happen.

Organising sprints takes some effort and planning, as does getting the best people to them. But we know that the best work happens at sprints. I think it'd be wrong to let a (somewhat arbitrarily decided) schedule override the realities of what we can expect to achieve when we have many our best people in the same place for 5-7 days, and for the sake of our users and for making Plone better, we should work around that. (And next time, timetable sprints for specific purposes in the release schedule).

+1 to delay, by 2 about weeks, the first RC. I wouldn't mind that meaning we get 2 more weeks of beta, but then I'm not so hung up on the alpha v beta distinction. :)


Framework-Team mailing list

Reply via email to