Weekly Meeting Agenda for June 27, 2006
In attendance:
Notetaker: Ray
Agenda
- Review draft personas
- Schedule stake-holders meeting for persona prioritization
- Status of solicited CM feedback from the community.
- Reorg of CM space
Notes
Marc: Did people look at personas?
Daisy: Yes.
Ray: No.
Josh: In progress.
Marc: Talked to many support people. Not all covered by the two personas, but very close. Closest at Berkeley is Charmaine; no real match at Stanford. Close match at Desire2Learn shop: someone really into cranking out the sites 9-to-5, dealing with smaller problems as they come up.
Josh: Developers have to describe high-level problems & solutions. Is it necessary for whole team to review the tools you use to get to your design?
Daphne: Intregal enough to process that it's helpful for whole team to buy into the persona descriptions. In working out solutions, we'll say things like "What would Sara want to do?"
Josh: Who says who's primary?
Daphne: We know these are all users of the system. Who should be designed for first? Lowest-common denominator may not be right answer, since that may not exist as a real user. The "customer" (in sense of funding) may not be the primary client, either. Then make it work for secondary persona as well.
Marc: Sometimes need two primary personas – but no more!
Daphne: Which makes two interfaces.
Marc: Samigo burned by trying to cover too many cases at once. These personas are draft, as of last week.
Who should have buy-in on picking persona, & on developing design to match it?
Who are the stakeholders?
Daphne: Would be hard to do virtually. Best in same room with a small core team.
Josh: Who has bought into the process?
Marc: Kristol Hancock did this with the tools team, so she should be included if possible. Ask Chuck for 1 or 2 people to represent their interests.
Daphne: Not getting feedback on site, either.
Josh: Peter Knoop?
Daphne: Kristol will be here for a class in a couple of weeks. Might be schedule conflicts with Peter.
Marc: Stanford has an excellent video conference room if needs be. But for me the primary are Stanford & Berkeley.
Josh: In that case, Karen Miles.
Marc: For us, Mikodo and either Jackie or Julie. (Marc and Daphne will pick people and send out invitations.)
Can't let disappointments about community derail this effort. Still need to follow up discussions with some people, like Aaron Z.
Daphne: Haven't done a good job of framing the project, especially on the tools side.
Marc & Duffy will decide who needs to be contacted.
Marc: July is make or break for the project. Can we keep enough involvement?
Daphne: We didn't explain well enough how much UI work was involved. The service/framework side is a bit clearer for people.
Marc: The tool scoping will be this month.
Daphne: Tools & code we're talking about are so intertwined that it feels like all or none.
Ray: May be able to get some flexibility based on target persona – focus on their needs rather than all needs covered by all existing code.
Josh: Do we need to say this is the only/main way to integrate Sakai?
Marc: We'll need to prove it works & is worthwhile in parallel. Once we're using it, it will demand greater focus & support.
Josh: Also tying in other applications will sweeten the pot – but increase the work & the risk.
Daphne: We can't afford to provide the entire development team for two years & then be the sole maintainers.
Marc: Any comments on the site redesign?
Daphne: Seems fine.
Marc: "Documentation" is the key place. Can we get API JavaDoc?
Josh: It would be nice to get that as part of nightly builds. I'll follow up on that.
Still working out mutability issue in interfaces.
Marc: Good that rSmart's involved.
Ray: Given a service interface, I like mutable objects with write-protection handled by the services. Also helps with federated objects: add in & override fields when incoming; let each provider handle its own authz on outgoing.
Josh: Simple, anyway.
Marc: Also want UCI, Portland State, ...