Roadmap and Releases
Michiel van Leeuwen
During the Toronto meeting, we talked a lot about the roadmap. One of
the documents we ended up with, was the features document:
http://wiki.mozilla.org/Calendar:Feature_Tracking
I took the liberty of taking that document, and assigning releases to
the items. That gave me the document you find in this post.
What do you think of it? Does it sound reasonable? Am I on crack?
(I posted the document here, and not on the wiki because there are
already way too much roadmap documents on the wiki, and adding yet
another will only lead to more confusion)
(Please don't focus on one small part, like the priority level of one
item. First, talk about the high level, then the low level details.
Also, a lot of the P-levels were already agreed on in Toronto. I didn't
change them. I just added them to items that didn't have a P-level)
Michiel
The plan is to speed up the process by not doing too many releases.
Releasing keeps the tree in a fronze state for way too long. The road to
1.0 shows the following milestones: 0.3, 0.5, 0.7, 0.9, 1.0
The theme behind some of the milestones is clear:
0.3: soon, upgrade for 0.2 users
0.9: mostly bugfixes
1.0: only bugfixes.
Most new features should be included in 0.7. (there might be still some
bugfixing to do, but the feature needs to be partly implemented and have
a plan for what it is, how to implement the rest etc)
For other milestones, I suggest using those themes:
0.5: Collaboration
0.7: UI improvements/experiments, Performance
Based on this, the feature list can be split into milestones this way:
Core (P1)
P1 0.5 Editing / viewing etc
P1 0.7 Keyboard navigation
P3 0.9 Other accesibitily features
Views (P1)
P1 0.3 Viewing of events
P2 0.5 Performance
P2 0.7 Display of tasks
P2 0.5 Investigate zoom scroll*
P1 0.3 Navigation
P1 0.7 Work-flow (user experience) (?what's this?)
P2 0.7 Agenda View
Item Creation/Modification (P1)
P2 0.5 Event vs. Task semantics (design)
P2 0.5 Autocompletion
P1 0.5 From external sources
Alarms (P1)
P2 0.7 SMS
P1 0.3 Visual
P2 0.5 Email
User Experience (P1)
P1 0.7 Polish
P2 0.7 Drag-drop
P2 0.7 Customizability
P2 0.7 Fun
P1 0.7 Menu layout
P3 0.7 Auto-scheduling
Get Data Out (P1)
P1 0.3 ICS
P2 0.5 Sync (with extenal files / other calendars)
P1 0.3 Printing
P2 0.3 Publish
Get Data In (P2)
P2 0.3 Public Holidays
P1 0.3 Subscribe
P3 0.5 Sync from device (getting data out is more important)
P1 0.5 From existing calendar application
Email Integration (P2)
P1 0.5 Tighter intergration of lightning in thunderbird
P2 0.7 Sending email from sunbird
P3 0.7 See the context (that's stored in emails) when in calendar
P3 0.7 See the context (that's in your calendar) when in email
Calendar Interoperation (P2)
P1 0.5 Able to invite other people (iMIP/iTIP)
P2 0.5 Sharing
P2 0.5 Freebusy
P3 0.7 Autodiscovery
P2 0.5 Address book intergration
Local Search (P2)
P1 0.7 tags/categories
P2 0.7 date range search
P1 0.7 text search
Sync (Device) (P2)
P2 0.5 Sync with devices
Web Service Integration (P3)
P2 0.7 Maps
P2 0.7 Weather
P1 0.5 Holidays
P1 0.7 Search
Backup (P3)
P3 0.5 Make backups of data
* Zoom scroll: Where the month view can start at any week, not just the
first week of the month. Compare multiweek view. Might also change the
dayview in a similar way.
A little summary, to see if everything is at least somewhat balanced:
Split per Priority and milestone
0.3 0.5 0.7 0.9 1.0 total
P1 6 6 7 0 0 19
P2 2 10 10 0 0 22
P3 0 2 4 1 0 7
total 8 18 21 1 0 48
This shows that there is not one release with much more work. 0.9 and
1.0 don't have much new feature work assigned to them, because there
will be a lot of bugfixing to do by that time.
Joseph Minta
> The theme behind some of the milestones is clear:
>
> 0.3: soon, upgrade for 0.2 users
> 0.9: mostly bugfixes
> 1.0: only bugfixes.
>
> Most new features should be included in 0.7. (there might be still some
> bugfixing to do, but the feature needs to be partly implemented and have
> a plan for what it is, how to implement the rest etc)
>
>
> For other milestones, I suggest using those themes:
> 0.5: Collaboration
> 0.7: UI improvements/experiments, Performance
>
it. However, I do have 2 concerns with this proposal, from a high-level
perspective.
1) I get scared with backloading "bugfixes." Joel on Software suggests
that doing this will actually extend the development timeline, largely
because it takes time for developers to get back into the mindset of
what they were doing when they originally wrote the code, 2 milestones
ago. I'd rather see an emphasis on bugfixing associated with the
landing of a particular area. We can push the less risky areas to later
releases and do the ones that are likely to have harder to find bugs
earlier.
2) Grouping the UI improvements sounds wrong to me. One of the things
that resonated most with me from Toronto was the iterative approach to
UI. With the proposed schedule, we really only have 1 release where we
can gain feedback on experiments. Globbing several experiments together
seems like it will make it difficult to get the more specific feedback I
think we're looking for.
Am I out in left field on these?
-Joey
Michiel van Leeuwen
> 1) I get scared with backloading "bugfixes."
I'm not suggesting to backload all bugfixes, but experience has showed
that bugs show up anyway. My suggestion is to reserve some time for it.
I'm not saying that we shouldn't do bugfixing in earlier releases, but
planning the last release with features, only to find out you have bg
bugs from previous releases might lead to problems.
And i think that we can reserve less time for those last two milestones.
Less features, less time.
But you are right: we shouldn't backload all bugs, and only work on new
stuff. So maybe we need to shuffle a bit.
> 2) Grouping the UI improvements sounds wrong to me. One of the things
> that resonated most with me from Toronto was the iterative approach to
> UI. With the proposed schedule, we really only have 1 release where we
> can gain feedback on experiments. Globbing several experiments together
> seems like it will make it difficult to get the more specific feedback I
> think we're looking for.
I think you have a point there. But again, i'm not saying that we
shouldn't do any UI changes in other releases. Just some experiments,
like the scroll-zoom. Those are somewhat lower priority.
But maybe we need to shuffle here too.
Michiel
lilmatt
Excellent work!
I'd like to see the items slated for 0.3 fleshed out with more detail.
Then they can be included with the items already nominated in Bugzilla
for 0.3.
The length of the list of items slated for 0.3 already concerns me.
Therefore, getting UI experiments in for 0.3 seems unlikely, but I
agree that we should try and get some landed in each milestone after
that, except 0.9 and 1.0.
-lilmatt
Michiel van Leeuwen
> The length of the list of items slated for 0.3 already concerns me.
These items are on the list for 0.3:
Views (P1)
P1 0.3 Viewing of events
P1 0.3 Navigation
Alarms (P1)
P1 0.3 Visual
Get Data Out (P1)
P1 0.3 ICS
P1 0.3 Printing
P2 0.3 Publish
Get Data In (P2)
P2 0.3 Public Holidays
P1 0.3 Subscribe
I put them there, because we already have most of that! Basic views
work, we have visual alarms, we can publish etc. Printing needs some
work, but have patches.
So I think the list is not that big.
But if you define alarms to be something that also works when sunbird
isn't running, we need a whole lot more work. So yes, for some items, we
need more details. (or split them)
Michiel