Paris Contrib-Provisional-Core Discussion

Owned by Former user (Deleted)
Last updated: Jun 18, 2008Version comment
3 min read

Contrib/Provisional/Core Tool Status Discussion

This page is intended to help facilitate the discussion around the usefulness of the Contrib/Provisional/Core tool status schema scheduled for the Paris Project Coordination Meeting. The two driving questions for this discussion are:

  1. What are the goals of these distinctions?
  2. Do they serve us well today?

Table of Contents:

Background

The Contrib/Provisional/Core "tool status" schema was adopted very early in the Sakai Project. Its intention is to help differentiate between tools that are trusted and ready for use in production (Core), tools that are likely to be ready for use in production but with which the community needs to gain more experience first (Provisional), and those that are not yet "fully-integrated" with Sakai and ranged from ideas in early stages of development to production ready tools (Contrib).

Another way to slice this is that Core and Provisional tools are included in Sakai releases and Contrib tools are not. Additionally, Core tools are enabled and Provisional tools are disabled by default in the release. Contrib tools are not included in a release and have to be obtained separately, either from Sakai's "Contrib" SVN repository or from an external source.

The trio of tool statuses also carries the implication of a pathway, Contrib tools could become Provisional tools could become Core tools as they undergo development over time, with the main boundary being between Contrib and Provisional status. To cross the latter boundary a project needs to meet the Provisional Tool Criteria. Once a Provisional tool, it is relative easy to become a Core tool, the tool simply needs to demonstrate it is reliable in a variety of production settings to gain the community's confidence in enabling the tool in a subsequent release. (An effort at further refining the definition of Core tools, and relabeling them instead as "Supported" tools, was put forth by Mark Norton as the Criteria for Supported Status.) For each release we called for nominations and discussed which tools were ready for promotion starting several months before the code freeze for that release.

As Sakai continues to grow, the not unexpected problem of what to do with tools that were no longer of interest to the community or which no longer have sufficient development effort behind them arose. These became known as "Deprecated" or "Retired" tools. We have limited experience in this area though, as we have only done this for Chat (deprecated for 2.4 and replaced with a new Chat tool), Message Center (deprecated for 2.4 and split into two separate tools: Messages and Forums), and Discussion (deprecated for 2.5), and we our still working out the best way to handle this need.

Discussion

To facilitate discussion of how to improve the usefulness of the existing tool statuses, or to suggest alternatives, please provide share thoughts and suggestions as comments on this page. Initiating this discussion prior to the meeting is intended to allow those who will not be present an opportunity to provide their input, as well as to advance the starting point for the face-to-face discussions in Paris.

Here are some questions and observations intended to stimulate this discussion:

  1. Do perceive the existing tool distinctions as meeting your needs?
  2. What are your goals for distinguishing between tools? What criteria might you suggest?
  3. Is determining whether a tool should be included in the release or not or enabled in the release or not, key considerations of yours in distinguishing between tools?
  4. Do we need a different or better way of identifying or labeling tools which the community feels are ready and reliable for production use (e.g., Melete), but for one reason or another cannot readily be included in a Sakai release? (Perhaps they have incompatible licensing, have their own release schedule that does not align well with Sakai's schedule, etc.)
  5. How can we better handle the deprecation or retirement of tools that are no longer appropriate for inclusion in a release? What makes a tool no longer appropriate: lack of resources to maintain it for a release, replacement by other tools with similar functionality, replacement by other tools with better functionality, etc.?
  6. Do we need a similar pathway for adding new services to and deprecating/retiring old services from the release? What criteria might such pathways be based on?

Please feel free to edit this page and add additional points to the end of the above list. (I've set Confluence to number them so that you can easily refer to individual points in your comments below.)