...
- 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 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]
- maintenance team in 2.7 timeframe may be too hopeful
- in provisional criteria there was this notion of stealthing, are . 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. not everything may be easily packaged in this way. a question of distribution mechanism.
- There has been an unhelpful confusion over status of contrib projects
- if it's in a release as an option, there is a similar level of confusion. Stealthed provisional tools feels like a workaround solution, and not something that should be embedded by default, and we . We should test if we can get rid of it. should 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 goodof projects is the right emphasis
- 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?
- getting a credible timeline may be what they're trying to get into incubation for in the first place
- useful to set some sort of deadline on incubation period. concerned about corpses of incubated projects that can't exitnever go anywhere, need somehow to keep that from going on indefinitely
- one strategy: just a clear statement of how it will be get out of incubation, helps the question of timeline
- can help, but then people can be pulled off the project, 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 we want it to be a sign of community 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, Nate and Nate helping Eli ready to help edit results of discussion.
- got a good starting point. even if only see preliminary thinking, something for the community to start begin to reckon against it.
- 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
- stephen: happy to stick with this time.
- monthly? every other week?
- happy to see . 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.