2009-08-19 Product Council Meeting

  • 5 p.m. GMT
  • 1 p.m. EDT
  • 10 a.m. PDT

Phone number: 1 (812)856-7060
Internet: 156.56.240.9
Room code: 348#
Password: 72524#

Agenda

  1. Incubation Documentation
  2. Release planning developments
  3. Sakai 3

Incubation Documentation
How Sakai Development Works

Attendees

  • Noah Botimer
  • David Goodrum
  • Eli Cochran
  • John Lewis
  • Michael Korcuska
  • Michael Feldstein
  • Stephen Marquard

Minutes

  • Scope of #5 - what it means to exit incubation, make it small enough to be achievable. Aim to keep bar to get into incubation low: what do you know and not know at this point?
  • Start with BasicLTI and Chuck?
  • Shouldn't wait on Sakai3 stuff
  • A place to collect this documentation?
  • Presentation for community important, so Clay will work something up in Confluence
  • Release proposal developments: moving away from lightweight 2.7 in favor of semi-autonomous tool releases.
  • Does this allow us to explore different packaging or distribution models? Like a Linux distro? Current mechanism very unwieldy.
  • Modular packaging a good goal for Sakai 3. problem for Sakai 2 because people have already figured out how to get things done for themselves, and aren't inclined to spend more effort working through alternatives, even if better.
  • This raises a formal question of what the PC is looking at: what's in the release, what's designated as part of the product.
  • Important to get Sakai 3 projects into process very soon. Their current de facto status problematic. Need to keep momentum at conference about getting people involved in it.
  • The product development process would also help people keep track of development as it unfolds.
  • Migration work? Would that be a distinct project? Unclear.
  • Projects may be joined during incubation, so we don't need to decide this rigidly at the point of entry.
  • Intention that these projects work together closely, but want to keep focus on teams and what they're doing.
  • Eli, Nate and Max to help with docs. Eli going to think hard about accessibility criteria: there are different ways of approaching this.
  • Level of prescription for different stages? Level of specificity?
  • More inclined to support prescriptive standard for 3 than 2, but we need to think about how hard it will be to meet them. Retrofitting can be harder.
  • Even if our standard is relaxed, it will be good in the beginning to see more detail or examples. We don't all share in the same expertise, and the extra detail can be educational.
  • Encourage the presentation of all this to be standards bubbling up from the community and its expertise.

Next Steps

  • Clay, Eli, and hopefully others will continue to flesh out communication of development process, collect potential criteria, and draft documents for future stages.
  • Clay will make some adjustments to the incubation documentation as suggested, and then go out proactively to get interested projects to supply them.
    • Ripe 2.x projects will be approached, but so will all the Sakai 3 projects, K2 on up.
    • Incubation documentation criteria will be further refined in dialogue with the project teams.