...
- Noah Botimer
- Max Whitney
- John Lewis
- Michael Feldstein
- Stephen Marquard
- Eli Cochran
- Michael Korcuska
- Nate Angell
- David Goodrum
- John Norman
Minutes
| Warning |
|---|
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. 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.What are good prospects for projects ready to work with us, and targeting
Prospects for 2.x
...
projects:
- 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
- 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.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]
...
- in provisional criteria there was this notion of stealthing. Are we dropping that distinction?
- it's 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. 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 dispense with it when feasible.
Basic Criteria 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
- 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
...
- 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
...
- in some form
Next Steps
- Clay will clarify release proposal.
- 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.
- Clay will work up a draft of a simple incubation documentation form, with input from other PC members and by proactively engaging with the leads of candidate projects.
- 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.