Tool Status

Summary

Core/Provisional/Contrib Promotions and Guidelines/Criteria (Peter)
Start using "Supported" instead of "Core"?
Criteria for Supported Status document (Mark)
How to treat a major re-write of an existing Core tool, (e.g., Chat in 2.4)
Deprecating Projects
- deprecation procedure
- Core to Provisional or to Contrib? (e.g., Chat in 2.4, perhaps Discussion in 2.5)
What does "run in production" mean to everyone?
Should we encourage running in production by shipping with all Provisional tools enabled, but with a list of known issues to help folks decide what to turn off?
Tools versus Services; handle the same or differently
- What is a good alternate path and criteria for Services?
- Can we split project summary tables into tools and services? This would "hide" many of the rows that are confusing to end-users who only want to know about tools.

John L added

Should there be an item on the checklist for tools moving from provisional to core that includes permission handling consistent with other tools in Sakai? Some tools have a permission page, some don't, some were setting them in properties, etc.
Should there be a requirement that ongoing setup/config be via a UI or sakai.property as opposed to requiring sql to load db tables, after the initial install? E.g., term info.

Replace references to "Core" in the tool status levels (Core/Provisional/Contrib) with "Supported".