- Contribute authoring use cases (Authoring Summit - Use Cases)
- Begin to talk about summit agenda
The most important thing is to contribute use cases right now. Everyone should review, and either contribute or comment.
Mathieu's designs haven't had much comment yet, he'll look for overlap with other use cases.
We need a fuller discussion of technical issues, Jim will try to pull that together ahead of Dearborn.
Jim: 2 rooms available, Sakai bridges reserved all day Tuesday and Wednesday, Thursday afternoon. Earlier, we had in mind two simultaneous agendas: the user-facing capability and the back-end. Is that still the case?
Michael: Right way to refer to this is the desired outcome. 12 of them there now, if they are grouped broadly ...
Jim: The 12-point list is broader than what we need in Dearborn, and we need to focus as well.
Michael: A few categories:
- agreement on requirements with enough common interest;
- still a desire for a technical discussion on problems and technologies that can be brought to bear
- project planning
If we think about the first day focusing on requirements work, and the second day focusing on how we're going to work together to do it, does that sequence and division seem sensible?
Tuesday morning will have a general session: review where we are and what people have already.
Tuesday afternoon and Wednesday morning work on requirements (technical and other)
Wednesday afternoon and Thursday morning on project planning and how to divide the work up.
Requirements discussion may need more time.
Would be very helpful to have some interactive mockups once we decide what we're talking about.
Tuesday afternoon - split groups or full group? (when does the technical discussion want to split off?)
Don't want to split too soon, or the technical talk might lose touch.
Michael will put out a proposed agenda, circulated over email first.
Encourage everyone to mockup a vision for Tuesday morning, and if you want to present, let Michael know so he can organize it.
Jim: we end up having a lot of side conversations that don't go to everyone. The question of 2.x vs. 3.x, but we've been talking about something that will work in both places.
Michael: John and Clay had similar reactions, which I think are latching on to emphases that I didn't mean to make in the document, but I'm not sure. The worry is that the technology will be different in those two worlds, but I don't think that the requirements should be so different.
Noah: accommodating the notion of a site is where most of the difficulty may be.
Michael: I am thinking about groups rather than sites, but this is something to look at more closely.
Noah: My gut feel is that we can accommodate groups in 3.0 as sites in 2.x, and it may just mean a compatibility layer.
Michael: the question of priority and sequence should be for the project planning part.