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
