Phone number: 1 (812)856-7060
Room code: 348#
Password: 72524#
Agenda
- Overall review of Clay's release proposal and the council's role therein
- Criteria/characteristics for projects moving from R&D to incubation (irrespective of 2.x or 3.x)
- Process for fleshing out criteria/characteristics for future stages
- For 2.8?
- For 3?
Useful Links
PC Role in 2.8
From the Release proposal:
4) The product council will:
- Work to quickly establish straightforward but preliminary guidelines for inclusion in 2.8, and refine them through iterations of documentation and discussion with both the development teams and the wider community
- Serve as a court of appeal where needed, where issues surface in conversation between the product manager, the release management team, and project teams
2009 Sakai Development Process
Incubation
From the Process proposal:
Incubation should prove that a project is both desirable and feasible. This stage is for projects that intend to end up in a Sakai release. The goal in the incubation stage is to prove the desirability to the community, formalize project requirements, assemble a cross-institutional development team that includes functional expertise, build a project & maintenance plan and reduce development risks.
Attendees
- Noah Botimer
- Max Whitney
- John Lewis
- Michael Feldstein
- Stephen Marquard
- Eli Cochran
- Michael Korcuska
- Nate Angell
- David Goodrum
- John Norman
Minutes
in process of being tidied up
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, 2.7 schedule may be in jeopardy if there are no schools willing to adopt it. Whether or not one deploys can be influenced by feature set, and so 2.7 may introduce risks here.
- 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.
- What are good prospects for projects ready to work with us, and targeting 2.x?
- Chuck with LTI, Kirk Alexander with Gradebook2, Assignments2 at IU, Nuno with SiteStats, perhaps others
- 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).
- 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
- 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.
- 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
- 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?
- it's 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. But not everything may be easily packaged in this way. It's mainly 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 get rid of it when feasible.
Basic Documentation for entering Incubation: (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
What Happens 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
- difference btw 2 and 3?
- for 2 a narrower set of issues to be canvassed, 3 broader and more complex
- would be sad to deal with them in isolation
- one of the characteristics we ask projects to demonstrate is how they integrate, how does it affect other tools
- let's separate out a couple pieces; separate out interdependencies from whether two tools need to come out in same release. need documentation on service level to demonstrate interoperation. separate hard documentation from hard acceptance criteria. need to document migration plan as well (eg from 2 or 3) and we can advise how significant that will be. keep it simple - need to say something about having a migration plan
- nagging desire to see us document requirements, and want to get drafts going for further stages, and see those take shape.
- Max, Nate and Eli ready to help edit results of discussion.
- got a good starting point. even if only see preliminary thinking, something for the community to begin to reckon against
- seems like this is a decent time, but must be inconvenient for Stephen and John. Stephen: ok if it's not too frequent, like once a month or something. easier to plan for regular mtg. conclusion: bi-weekly slot allocation that we wouldn't always use. If an agenda doesn't come together, Clay will coordinate it being called off.