2009-08-05 Product Council Meeting

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

Agenda

1. Overall review of Clay's release proposal and the council's role therein
2. Criteria/characteristics for projects moving from R&D to incubation (irrespective of 2.x or 3.x)
3. Process for fleshing out criteria/characteristics for future stages
   • For 2.8?
   • For 3?

Useful Links

Release Proposal 2009

2009 Sakai Development Process

Incubation Documentation

Attendees

• Noah Botimer
• Max Whitney
• John Lewis
• Michael Feldstein
• Stephen Marquard
• Eli Cochran
• Michael Korcuska
• Nate Angell
• David Goodrum
• John Norman

Minutes

Comments about release proposal:

• the possibility of being able to introduce new functionality to 2.7 should be explicitly stated
• Staffing of release team - anthony and pete identified, and then somebody unknown. some clarification of their responsibilities. explicitly calling for one or two more people.
• a 2.8 branch manager should be identified early
• pragmatism ... people willing to be branch manager depends on deployment schedules. Whether or not one deploys can be influenced by feature set, and so 2.7 may introduce risks here. 2.7 schedule may be in jeopardy if there are no schools willing to adopt it.
• brings up the old question of release philosophy: time-based v. feature-based, etc.
• uncomfortable with suggestion of PC's role in targeting particular releases, shouldn't set hard boundaries
• is there a pragmatic benefit to southern hemisphere sites? UCT in particular: would favor independent project releases instead. A forums release would be more useful than a full 2.7 as currently described.

Prospects for 2.x projects:

• Chuck with LTI, Kirk Alexander with Gradebook2, Assignments2 at IU, Nuno with SiteStats, perhaps others
• Whatever we start with, wouldn't want it to be something that might tend toward rejection
• It's not really rejection, it's more a process of identifying what more is needed, and helping people to get there. It's valuable to raise these questions in a solvable form. Spur to doing work in incubation
• LTI a good first prospect in some ways, but won't present a thorough workout of the process because it's fairly narrow. Still, may present some issues that would be good to work through (such as cross-institutional support).
• Would be good to review code in light of our ability to support it; eg LTI touches on portal - who's working on that, who can, and what would that mean for maintenance expectations?
• Would something like LTI allow us to fast-forward the development stages in a collapsed timeframe?
• Need to get projects to self-document, with standardized documentation to show that it's gone through the steps.
• Whether or not there's a maintenance team ... might influence these decisions [aside: Anthony's working on a proposal for this]

What Product Development Means for tool 'stealthing' convention:

• in provisional criteria there was this notion of stealthing. Are we dropping that distinction?
• Stealthing is a valuable option, but I would focus on the goals and see if they could be achieved otherwise - if it could be a contrib project and applied easily to a main distribution, then that might meet the same need in a better way. But then not everything may be easily packaged in this way: a question of distribution mechanism.
• Leaving things in contrib has led to an unhelpful confusion over status of contrib projects. And yet if a tool is in a release in an optional way there is a similar level of confusion.
• Stealthed provisional tools feels like a workaround solution, and not something that should be embedded by default. We should test if we can get rid of it. Should be clear that we hope and plan to dispense with it when feasible.

Criteria Documentation:

• (see Incubation Documentation). Would like to see clearer description of process: make it public enough that people can see what's happening, how to get involved and how you see the process to be managed. For example, it seems the Foundation already committing resources to Sakai 3, need to look meaningfully at K2, eg, ... documenting clearly about what's going on
• Would it be asking too much to ask people to list rough timeline?
• Arriving at a credible timeline may be what they're trying to get into incubation for in the first place: to recruit resource, flesh out a project plan
• We have a good starting point for incubation entry, but need also to get drafts going for further stages, and see those take shape. Even if it's only preliminary thinking, we need something for the community to begin to reckon against and comment on.
• Wouldn't want to have to say "Do these steps," then check them off, then come back with more steps and keep ratcheting things up ... want to lay things out clearly ahead of time
• Max, Nate and Eli ready to help edit results of discussion.

Projects that go dormant in Incubation?:

• Useful to set some sort of deadline on incubation period. Concerned about corpses of incubated projects that never go anywhere, need somehow to keep that from going on indefinitely
• One strategy: just a clear statement of how it will get out of incubation. Helps the question of timeline.
• That can help, but then people might be pulled off the project, etc. starts to create clutter that is confusing
• Clutter as such not a big worry. Helpful to see clutter that has good information in it. Worried more about zombie projects that have nothing going on.
• Right, the issue is misinformation; a project in incubation may be dead, whereas we want incubation to be a sign of community activity
• Apache has "the attic" as a way to shelve things that go dormant
• It may be part of the PC role to review and determine whether a project should continue in incubation
• This triggers a thought about apache. They have an interesting model of getting regular status reports. Clay might give an update, could be helpful to identify where projects are running into trouble. Could be very brief report, a paragraph or so
• needs to be more frequent than annually, and a lack of reports is a good indicator

How to handle projects that may bridge 2.x and 3.x:

• for 2 a narrower set of issues to be canvassed, 3 broader and more complex
• one of the characteristics we ask projects to demonstrate is how they integrate, how does it affect other tools
• need to document migration plan (eg from 2 or 3) and we can advise how significant that will be.
• Keep it simple: needn't try to establish hard criteria on the details, but we can say that there should be a migration plan in some form

Next Steps

1. Clay will clarify release proposal
2. Meetings will be bi-weekly for now, though they may be called off in a given week where there isn't a need. Next meeting will be Wednesday, August 18th.
3. Clay will work up a draft of a simple incubation documentation form, with input from other PC members
4. Clay will organize some pages in Confluence for working on drafts of criteria/characteristics for future stages as well. Nate, Eli and Max are particularly ready to help flesh these out.