RFC Process

This document describes the procedures for suggesting enhancements and changes to the CAS products and protocols.

1. An RFC describing the proposed change is posted to cas-dev. Any member of the CAS community may post an RFC, but must clearly label it as such.  A proposal may include a request for incubation.
2. Discussion on cas-dev by the community to evaluate the RFC.
3. The RFC, and appropriate comments, are added to a publicly available wiki space in preparation for the Community Conference Call.
4. The RFC is added to the agenda of the next Community Conference Call. The comment period closes no later than the second community call following the initial posting. At the discretion of the CAS Steering Committee an earlier close date may be established.
5. After the comment period closes, CAS Committers decide by consensus to endorse or reject the RFC.  Endorsed Incubating RFCs receive access to Jasig resources (eg: SVN).
6. If endorsed, the following types of proposals require approval of the CAS Steering Committee, by consensus:
   1. Proposals impacting the functional design
   2. Proposals impacting the project direction
   3. Proposals to make a client official

Approval or endorsement of an RFC does not imply anything about who will actually implement it.

See also the JASIG Incubation Process - R1. Where an appropriate proposal is presented to the Steering Committee, it will be proposed as an RFC, following the processes described above.