...
- 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 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.
- 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