Re: [Cosmo-dev] Next steps for Cosmo

Hi Ted,

I'm definitely in favor of the picture you paint below, and agree with 
the general proposals.

I'm not going to weigh in on most of the release process details (I 
trust all y'all to work out how the branching is handled, for example).

I do have thoughts from two perspectives:
- strategic goals for OSAF
- tactical details on how we make product decisions from here

*Strategic*

The goal for Preview was to establish a baseline working application 
that was complete enough to demonstrate the vision and be useful to real 
users. We've hit that goal on the server side with 0.7 -- we have our 
baseline now. (Yay Cosmo team!)

The next goal is to build a user base and a working community. From a 
product perspective this means:
- support existing users
- fix bugs that prevent adoption
- add features that increase adoption (paying attention to investment 
required)

It is important to keep the high level goal in mind as we make product 
and bug decisions (i.e. argue over product and bug decisions).

Shorter cycles are critical to supporting the strategic goals.
- be able to fix bugs/emergencies that block usage (support existing users)
- be able to react to user feedback and and/or opportunities to get 
users (don't spend months going down a sub-optimal path)
- build a sense of momentum on the project

I know I'm likely preaching to the choir here, but perhaps it is good to 
remind ourselves why it is important when it does come at some cost in 
the short run (all those tests that have to written, for one).

*Tactical*

Putting on the PM hat, my biggest concerns are:
- How do we work product goals/milestones/tenets into the new process?
- How do we triage from release to release efficiently, without spending 
all of our time in IRC bug councils arguing bug by bug without having 
the bigger context in mind?

Ted, you've mentioned separating out tenets from releases. Example 
tenets that we've been talking about (some connected to a particular 
release and some not, some committed to and some not):
- Safari support
- Apple iCal/Calendar Server support (Leopard)
- CalDAV scheduling support

This seems like a useful technique for keeping the big picture in mind 
and focusing decision making. Be flexible about when a set of 
functionality lands, while still being feature/goal driven in how we're 
solving problems.

Mimi and I have also been talking about ways of framing short term bug 
priorities (not exactly the same as tenets?):
- fix problems where display does not match data (integrity)
- fix barriers to casual collaborator workflow
- fix bugs that are actively confusing

When Mimi gets back, she is going to go through *all* of the existing 
bugs/tasks logged in bugzilla for Cosmo and do a categorization. This 
will help PPD have a perspective on the existing bugs, and help us come 
up with some framing principles on how we might prioritize bugs.

(uh, strategy detour...)

One of my next projects for Cosmo (ahem, Chandler Server) is to frame a 
roadmap (or a set of possible roadmaps). And when I say "my project" I 
really mean "our project", as the whole team has a role in this, and I 
will look to others to drive big pieces of it. There is some tension 
between balancing being open to what happens in response to Preview and 
having a direction. That said, I think we can navigate a path where we 
have some bigger inspiring goals that guide us (Data Hub, small 
organization can install/run own server, compelling standalone vision 
for ui, etc.) *and* we are able to make tactical week to week 
adjustments in response to what we learn from users. I know, preaching 
to the choir again, I know some of you have been clamoring for a more 
coherent roadmap for some time.

(back to tactical...)

So from the PM point of view:
- PPD is going to propose a way of framing how we might prioritize 
0.7.future bugs, after Mimi has a chance to go through the bugs.

- PPD has some next actions in framing a discussion around 
roadmap/tenets for short term/long term. My next action is still to 
figure out next actions though (still mired in Preview details).

- Thoughts about short term and/or long term tenets are welcome, keeping 
in mind that the ultimate goal is user adoption. Design list is likely 
the best place -- not sure if the more technical goals should be 
discussed on this list instead.

- The mechanics of *how* we have the conversation of what bugs land when 
are important (to me, to ppd) -- I will likely have more specific 
thoughts/concerns/ideas once we've done the bug sorting exercise and as 
other details fall into place.

Cheers,
Katie

Ted Leung wrote:
> Hi folks,
> 
> I thought I would try to tie together Jared's note on "quick releases" 
> and Brian's note on "Cosmo 0.8", and try to give a sketch at how we 
> things might change in the Cosmo world.  My intent in doing this is not 
> to set down a definitive notion of what we will do, but to try and give 
> a flavor of what I think a desirable outcome looks like, and then get 
> people's reactions.  In particular, are there things that are missing, 
> are the obstacles preventing us from getting to a scenario  like this, 
> and so forth.   If you have questions,  concerns, or ideas *please* 
> speak up.
> 
> With that said, here goes:
> 
> 1. We are currently testing Cosmo 0.7 RC4.   Unless we find some 
> catastrophic bugs, this is going to become Cosmo 0.7.0.    Between now 
> and the Cosmo 0.7 launch, most people should be working on beefing up 
> our test coverage for Cosmo.   This is particularly important for the 
> web UI.    Also, there will be a series of IRC QA sessions between now 
> and than.   If you are a Cosmo developer you should be participating in 
> these sessions.
> 
> 2. After we launch Cosmo 0.7, we plan to do (at least) 4 Cosmo 0.7.x bug 
> fix releases, once a week.   When I originally proposed this, my 
> expectation was that the release happens every week and whatever stuff 
> is actually done within a particular release frame is what will go into 
> that release.   If it isn't done, it doesn't go into the release.    We 
> have not yet worked out all the details for how this process is going to 
> work, but here is a proposal:
> 
> - PPD comes up with an overall priority for all bugs currently targeted 
> for Cosmo 0.7.1 (How they do this is up to them).   We preserve these 
> priorities, and then put all bugs marked 0.7.1 into a new milestone 
> 0.7.Future.
> 
> - Prior to the start of each release "frame", we (TBD - but likely a 
> version of the bug council) figure out which bugs from 0.7.Future, as 
> well as critical bugs reported by end users.  In order to do this 
> effectively, we will need to work with individual developers to make 
> sure that bugs can be fixed in the time allotted to a release.   It's 
> possible that a bug that gets prioritized will take more than a week to 
> fix.  If this happens, the developer will start working on the bug, but 
> the fix will have to wait for the next release for inclusion.  An 
> example of a something like this is the Safari support that we punted.  
> It's unlikely that we can fix all the Safari bugs in a single week, but 
> we can start fixing them until they all get done.   Whatever release the 
> last bug is in will be the release that supports Safari
> 
> - developers make the necessary fixes
> 
> - at a well known date (we don't know what this needs to be yet), QA 
> begins qualifying the release - bugs which are not fixed by this date 
> are dropped into the next release - partially committed fixes will need 
> to be backed out.
> 
> - while QA is validating, the "bug council" picks the next set of bugs 
> and the process repeats.   Once validation is complete, we issue the 
> release and update the hub.   There is going to be an element of 
> re-planning at each release, because we'll need to adjust to what 
> happened (or didn't) in the previous release frame.
> 
> This proposal is a large change from our existing practice, and I think 
> it's safe to say that we will have some hiccups and learning as we go in 
> order to make this happen.
> 
> 3. We have a branch for Cosmo 0.8 that Brian is working in.  Right now, 
> the only goal for Cosmo 0.8 is to be compatible with Leopard (this 
> mostly means iCal 3).   We've been kind of loose about exactly what this 
> means.   Mikeal observed that Leopard iCal does scheduling and we dont' 
> support scheduling and currently our plan is not to do scheduling, 
> although I think we might be revisiting that discussion.  Let's assume 
> for the sake of simplicity that 0.8 does not include scheduling (if we 
> do scheduling it ends up in a later release due to size).
> 
> If you assume that Cosmo 0.7.0 launches next week, and then add four 
> weeks for the bug fix releases, then that puts us just about at the end 
> of September.   Leopard is supposed to launch in October, but we don't 
> know exactly when.  This probably means that we should plan to be done 
> with Cosmo 0.8 in time for an early October launch of Leopard.   You'll 
> notice that this leaves very little time for anyone except Brian to work 
> on features for Cosmo 0.8, so at this point I think it is very unlikely 
> that we will do any other features for Cosmo 0.8.   We haven't had a 
> real discussion of this with PPD yet, but the laws of physics seem 
> pretty clear to me here.
> 
> 4. After Cosmo 0.8, I would like to see us get on a regular release 
> cycle that lasts somewhere between 2-4 weeks.   The 4 1 week releases 
> for 0.7.x as a special event due to the need to stabilize Cosmo during 
> its debut to a large audience, but I also think that a 1 week pace is 
> probably a little too frenetic. It is very important that we be able to 
> turn releases of Cosmo quickly in order to address user feedback, and to 
> continuously improve the Chandler Hub service.   There are several areas 
> which need to change in order to be able to do this:
> 
> - We need to plan in smaller, less interdependent units, and plan for 
> regular releases to happen.   We will be revamping our planning process 
> to make sure that this happens -- this is a Chandler project wide goal, 
> not just a Cosmo goal.   The days of 3-6-9 month release cycles needs to 
> be over.
> 
> - We need to improve our automated test coverage.   The responsibility 
> for that lies both with developers and with QA.
> 
> I know that this is a long message and there are a lot of changes being 
> proposed.  At the same time, we've been saying for months that we'd like 
> to shorten our release cycles after preview, and that time is just about 
> upon us.   Please speak up with your questions, concerns, and ideas.
> 
> Thanks,
> 
> Ted
> _______________________________________________
> cosmo-dev mailing list
> [email protected]
> http://lists.osafoundation.org/mailman/listinfo/cosmo-dev

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design