Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 15 Next »

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?

Release Proposal 2009

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.

Incubation Documentation

Attendees

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

Minutes

in process of being tidied up

  • the possibility of being able to introduce new functionality to 2.7 explicitly stated, 2.8 branch manager 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. deployment influenced by feature set. release philosophy? time-based, feature-based
  • uncomfortable with LTI tool, uncomfortable with suggestion of PC's role in targeting particular releases, shouldn't set hard boundaries
  • UCT? Other southern hemisphere sites? rather be on release branch rather than custom branch ... favor independent project releases as an institution
  • what does quickly mean? Any project prospects
  • Chuck with LTI, Kirk Alexander with gradebook, Assignments2 at IU, Nuno with SiteStats
  • LTI a good first prospect, but won't present a big workout, but may present some issues that would be good to work through (such as cross-institutional support).
  • Wouldn't want to start with something that tends toward rejection
  • More a process of how to recruit additional support to make it acceptable
  • LTI work still won't be as hard because of complexity
  • valuable to raise these questions in a solvable form. Spur to doing work in incubation
  • wouldn't discount prospect of reviewing code and seeing our ability to support it; eg LTI touches on portal, and what would that mean for maintenance expectations?
  • fast-forwarding the stages in a collapsed timeframe?
  • standardized documentation to show that it's gone through the steps of the stages. Get projects to self-document.
  • wouldn't want to have to say do steps, check them off, then go back with more steps ... want to lay things out
  • talking around maintenance team ... might influence these decisions
  • in 2.7 timeframe may be too hopeful
  • in provisional criteria 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, then that might meet the same need. not everything may be easily packaged in this way. a question of distribution mechanism. confusion over status of contrib projects
  • if it's in a release as an option, there is a similar level of confusion. feels like a workaround solution, and not something that should be embedded by default, and 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.
  • 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.
  • self-documentation good
  • like to see clearer description of process: public enough that people can see what's happening, how to get involved and how you see the process to be managed. Seems 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
  • useful to set some sort of deadline on incubation period. concerned about corpses of incubated projects that can't exit, need somehow to keep that from going on indefinitely
  • clear statement of how it will be out of incubation, helps the timeline
  • can help, but then people can be pulled off, etc. starts to create clutter that is confusing
  • potentially an issue, but may be an alternative to make it part of the PC role to review and determine whether a project should continue in incubation
  • triggers a thought about apache, they have an interesting model of getting regular status reports. might be handy. 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
  • some sort of EOL procedure for projects in incubation stage would be useful, yes
  • needs to be more frequent than annually, and a lack of reports is a good indicator
  • need another category than end-of-life. less fearful of clutter as such. helpful to see clutter that has good information in it. worried more about zombie projects that have nothing going on.
  • the issue is misinformation; a project in incubation may be dead, and not a sign of activity
  • apache has "the attic"
  • 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 and Nate helping to edit results of discussion.
  • got a good starting point. even if only see preliminary thinking, to start to reckon against it.
  • seems like this is a decent time, but must be inconvenient for Stephen and John. ok if it's not too frequent, like once a month or something. easier to plan for regular mtg
  • stephen: happy to stick with this time.
  • monthly? every other week?
  • happy to see bi-weekly slot allocation

Next Steps

  • No labels