Calendar:Status Meetings:2006-07-26 MeetingLog

Beware mispellings! I apologize in advance if I paraphrased you incorrectly.

trademarks:
lilmatt has been working with Frank Hecker to get the trademark stuff filed for sunbird. Once the paper work is filed, the
lawyers can make the trademarks and copyrights etc. Once done we can put the R and TM next to our logo
It's another reason why the generic branding happened. It's in progress

preferences:
(lilmatt) - not enough people weighed in on NG post. His thought is to resuse the same pref stuff from Sb
Instead of it separate windows just tabs under single window in tbird. 
Use inc files that we include and preprocess, but then the question is where do we put the stuff
in the tree? Reusing the files and the includes makes sense then where do we want to stick the stuff?
To follow the idea of lightning in lightning sbird in sbird and shared in base. So, need a better
decision to figure out where this stuff needs to go. Put ideas in the posting on the NG and we can 
make a decision next week.
Dan -- general idea is very reasonable. Pref UI tested in tbird and ffox, and that model works. Wonders if overlays are the way to go?
lilmtt - thought about doing testing using overlays
jminta - set up the skeletons that you need and overlay into a generalized hbox
lilmatt - the main point is to reuse code, so if overlays are the way to go, then that sounds good.
dmose: not a pressing drive to get into 0.3. THe hard piece is which preferences to expose since no
one is convinced we have the right pref in sbird now.
lilmatt: Reason for nominating it as a blocker for 0.3 is because it seemed to block several other bugs
in lightning. Thought this would unblock several bugs
jminta: there are several bugs about alarm preferences, and until we merge them, we can use ltn as a playground
to expiriment preferences and find a good design
lilmatt: The question becomes how to do this, overlays sound good, just sounds like we need to decide when and where to 
put them into the tree
lilmatt: Trying to not put in four new panes in tbird's pref window.

lilmatt: continue the preference discussion in the NG
lilmatt will post a summary of this into the NG

driving the bus:
lilmatt: we're getting close to the end of the release wanted to bring this up and ensure that everythign
that needs to be done has someone doing it. And no one is duplicating effort by accident because they ddn't know
jminta: Trying to push things forward. From the roadmap stuff in the NG there is awesome work there
and thoughts about where 0.3 should go and what should be in it.  Do we want mvl to drive it?
mvl: my ideas in the NG post were not very different from the existing ideas on 0.3  Basically to make a good upgrade from 0.2
lilmatt: is the blocking list as complete as we expect it to be? I've been trying to work on blockers,
but I didn't know if we were going to be more formal about when we're going to look at the bugs and submit them as blockers 
or what not
jminta: Blocking list is not set in stone, don't rely on it as it was. You can always add/subtract stuff from/to it.
jminta: ffox: blocking triage once a week, status is daily
lilmatt; what should our timeline be for that?
dmose: we benefit by doing more of ffox style driving but we don't want to be too heavy on the process either
identify who is going to drive the 0.3 rlease (nominates jminta and/or mvl)
jmitna happy to do it. Add permanent item to agenda for 0.3 status. So we have to spend time on it everyweek
mvl - jminta you shoudl do it and I will help with doing reviews and stuff. 
jminta - i'll group the bugs so we get some ideas on status and to have progress on different categories of bugs
ssa: it'd be great if those lists could go underneath the listing grouping that mvl had in the NG 
Seems next step would be to improve the list a little more and become more granular in terms of features and issues and bugs.
dmose: we can track it on the wiki or using the metabugs
jmitna; i don't like metabugs - painful b/c you get into weird dependencies. Rather keep track onthe wiki.
ssa: I agree
lilmatt: Beltzner's point about updating wiki, we should be able to do something on the wiki.
ssa then you can say how much work needs to be done, understand the status at a glance
mvl nothing in that NG has really been decided yet, that's all my ideas. 
lilmatt: can we come to consensus today? What's going on the 0.3 roadmap doc, and then get it up somewhere.
And get the 1.0 idea up there.  Make an official 0.3 roadmap.
dmose: We need to have the 0.3 page and then have the roadmap discussion in a bit
dmose: we agree that jminta will be the driver for 0.3 but there may be transition when he goes to lawschool
lilmatt: mvl may want to track the progress and be the "backup" driver for the release
mvl: not too much
dmose: cross the bridge when we get there

tasks in view!
dmose; lots of discussion for that. It got reviewed and landed w/out ui review b/c of miscommunication. 
Semantics of tasks in view are poorly defined.
Suggest: Leave code in the tree, but just switch the default of the preference. Because then people can 
turn it on if they want, and leave it off if not. 
ssa I think that's a good idea. But we still need to address the entire problem.May need more context to 
communicate that decision than a menu item can expose
dmose; a lot of design work needs to happen on that. And I think that we need to look at other tasks stuff.
If people can start using other task models and see how that works, and how it doesn't. There is a lot
of thinking to be done before 1.0.  We can't leave it this way for 1.0 but for 0.3 I think it's OK 
jminta: my opinion is that, there is no one who has failed to understand the general semantics, but they 
have nominated this bug as a blocker.
dmose: it's a ui compromise and it makes sense since we are only 0.3
ssa: problem is that things never tend to get removed though. Think that we need to really do a good design and 
not allow this design to simply fall in and never be removed. If we can agree to redesign it, then I'm ok with it.
Implementing a half-solution or an uncertain solution then it would be better to remove it and think about it more.
dmose: I thnk that is absolutely on our MUST HAVE for 1.0. I'm in for removing this instantiation of it if that's what 
we're going to do. I think it's something for the UI owners to talk abotu offline and come back with something
lilmatt: If we're just replicating something that existinged in 0.2 beacuse ppl used it, then lest's just use it and plan to
deisng something better, and if we aant to pull this out, then we can allow them to do that with an extension piece.
jminta: Question of whether or not tasks appear in their own view, doesn't solve the semantic issue. I have no problem
declaring that this is an expiriment and remove it if we decide to go otherwise
lilmatt: I'm saying that if people have an issue with us removing it then they can make an extension.
dmose: mvl and I will have a discussion about this offline, but whatever we say will only pertain to 0.3 and will not be 
the last word on 1.0 tasks

ROADMAP:
dmose: mvl made good points theer and jminta made soem followup. I will pull out all the TODO's from the discussions in 
toronoto pertaining to the raodmap
Hopefully we can pick up on where we left off from the toronto mtgs. 
lilmatt: where did we leave off?
dmose: feature to bug mapping, but I need to go through the ntoes and pull out that stuff so that we can remember where we are.
lilmatt: need to decide who is going to make the final 0.3 Roadmap document.
jminta: If you're fixing regression/dataloss etc bugs you're on the right track. This release may remain an organic release. 
We don't want to micromanage the release.
Worries that if we spend too much time nailing it down then we're losing time we could be fixing issues
lilmatt: just from a PR standpoint, we do need something that is final.
dmose: is there something you think is missing in mvl's post? 
lilmatt: what's missing is getting rid of the other roadmap docs and saying that this is blessed, and stamp of approval
jminta: what does that stamp of approval mean? How fixed is that document? How do we go about changing that? Can it be changed?
dmose: We don't want to do lots of process stuff up front, but i think jminta will be able to make those changes.
jminta: still don't want this to be a dictatorial process, want it to be a community process.
dmose: Seed a new roadmap with mvl's stuff, note that it is evolving and then put all the other roadmaps into a 
historical bucket somewhere.
lilmatt: can I do that? That's my point. If I can own that, then do it very quickly then that will solve it for me.
dmose: I'm signed up to do the next step on the 1.0 document. And figure out how we drive from here to there.
lilmatt: we just need to get something up there, and continue to maintain this as  a community process.
ssa: the most interesting part is how detailed the roadmap should be. It needs to be fairly granular.
dmose: there might be two documents - one is high level roadmap, and there's this thing with more drilled-dwn stuff.
jminta: any of those higher level tasks are better to let someone who has expertise in that area define that area. Letting
someone take the alaram bit and define their ownideas and bugs that belong under there. You need to let people who have
expertise and vested interest in those areas then put the bugs there.
ssa agree
lilmatt: when I'm making this document. I'll make blank pages for the drill-down items. 
jminta: I'll send you a template for that from ffox.
dmose: we'll do well to follow ffox since their process works pretty well.
ssa agree it doesn't need to be bug id's, but needs to be more than just the high-level items. I think
once we have the priorites in place, then we can just easily list the other items and keywords to tell the visitor
what we are actually doing in the area and will also keep the developers on track in that area.
dmose; i agree, and you'll find that is the way that ffox is doing this.
http://wiki.mozilla.org/Firefox2/Requirements
jminta: this is what we want for a release (dmse, lilmatt agree)
dmose: We want something a little higher level for 1.0.
dmose I'll come up with something for 1.0 after I sift through the toronto notes.

attendees: jminta, mvl, ssa, ctalbert, lilmatt, dmose