Hi,
I'm on the verge to start my mega triage task of the currently
outstanding 0.7 bugs. The goal is to gauge the scope of the tenets and
architecture rework we listed, see if we didn't miss anything big and
identify orphan tasks (stuff for which we've no record and no owner). I
talked about doing this during the Apps meeting yesterday
(http://wiki.osafoundation.org/bin/view/Journal/AppsMeeting20051213).
I've been spending some time on it today and I feel ready to dive in.
Just so there's no surprise (and you don't panic under the deluge of
Bugzilla mails...), here's how I'll do it.
For each bug:
- Evaluate if it fits in one of the 0.7 tenets: though those tenets are
not yet gelled, Sheila and Mimi sent an email on the Design list
(appended to this email) and no one objected so, I'm taking it as a good
enough yardstick. Also Sheila updated today the ZeroPointSevenPlanning
page to reflect those tenets
(http://wiki.osafoundation.org/bin/view/Projects/ZeroPointSevenPlanning)
- Add something in the Status Whiteboard field to reflect which tenet
the bug is mapping to. I'm using this field because it's easily
searchable and erasable (hence the name "whiteboard"). I'll use the
following "tags":
[Scheduling]
[Dashboard]
[Dogfood]
[Platform]
[Release]
[PDA Sync]
[Architecture]
The last 2 "tenets" *are not* in Sheila's doc. [PDA Sync] will be used
to tag those records related to, well, PDA and other mobile sync ideas.
[Architecture] will be used to map those bugs that do not support a
tenet directly but are listed as architecture work we have in the
architecture task page
(http://wiki.osafoundation.org/bin/view/Projects/ZeroPointSevenArchitecture)
- For the bugs that do not fit a tenet, I'll set the Target Milestone
field to "Future"
- For the bugs I'll mark [Architecture], I'll add a reference to the bug
back to the Wiki page (note: I have *no intention* to maintain this
bidirectional reference forever and no one should feel pressured to do
it in the future... this is just done now so that we can scope and SWAG
blocks of tasks more easily in this first pass...)
- I'll set the prio to P2 if the bug is a clear "must" (relatively to
the tenet...), P3 if it's a good fit (will do but debatable if it's a
must), P4 for "if time allows" bugs and P5 if it's a fit but I think
it's superfluous (let's reserve P1 for the moment for bugs that needs
immediate attention...)
I'll go through bugs "per dev" and I'll send an individual email when I
start working on your bugs (I may ask you for info while doing this
review). Also, I plan to do that only for Apps devs.
Let me know if there's something you don't like with the here above
process (like: "don't dare touching my prio!!"...)
Well, I've something like 250 bugs to go through so I better get busy... :)
Cheers,
- Philippe
Sheila Mooney wrote:
All,
Thanks to everyone that has been contributing to the discussions on
the design list over the past week, I know there have been quite a few
mails to keep up with. Based on the discussions on the list and within
the design team, we have revised the list of tenets and wanted to send
out an updated proposal. At a high-level, not that much has changed,
really. The tenets in the initial list were very broad and our plan
was to frame them more clearly and in terms of specific end-user goals.
The modified proposal....
** Plausible Scheduling*
- some lightweight free-busy and invitation solution to support
experimental scheduling workflows (Mimi just sent out a more detailed
email on this)
- this accomplishes a couple of goals - some work on email and
incremental progress on furthering our calendar
** Some tenet around plausible dashboard and/or task management*
- we don't have enough clarity for a specific tenet proposal right now
- this tenets has 2 parts - the basic table work and fixing a bunch
of the current stamping and table bugs (included improved markup bar).
- the second piece (dashboard/tasks features) will be nailed down
in the next 2-3 weeks
** Support people outside OSAF "beta testing" the release* - support
the current "dogfooders" and address some issues to make what's in 0.6
work better
- release packaging
- schema evolution
- bug fixing - calendar, non-calendar, sharing
- performance
- Cosmo bug fixing, stability and scalability
** Dev Platform*
- similarly to the dashboard tenet we haven't nailed this down
specifically
- we have some ideas around api cleanup but need to frame this better
A couple of additional notes....
There seems to be quite a bit of agreement in favor of moving towards
short releases and the planning team has discussed various scenarios
that would accomplish this. Overall, we felt it would not be
productive to split this along tenet lines (ie: "support people
outside osaf" first then the rest of the work) since the reality of
resourcing and dev dependencies may mean we have pieces of all the
tenets completed for let's say release A. Our plan is to start most of
the work (roughly) at the same time and look for ways to stage this
into 2 releases that are coherent. We will be thinking about this in
more detail as the specs are written and we work with developers to
define specific tasks. For this reason, it's tough at this point to
articulate a specific "vision" for each of these releases. Once we
start digging into the details, we feel this will start to emerge.
We have also heard from many individuals the PDA sync is pretty high
on their list of priorities. Lisa has sent out an email to discuss a
strategy in more detail which is why I have omitted this from any of
the 0.7 goals listed here.
Comments/feedback welcome.
Sheila
------------------------------------------------------------------------
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
