...

• Be an advocate for the proposed change
• Ensure the working group achieves consensus among key stakeholders
• Ensure the working group seeks feedback from users and iterates on the design & implementation (see below for additional CEP documentation)
• Uphold the quality of the changes, including verifying whether the changes satisfy the goal of the CEP and are absent of critical bugs before releasing them
• Be committed to review code changes, ensuring project standards

What is considered a "major change" that needs a CEP?

Any of the following should be considered a major change:

• Any major new feature, subsystem, or piece of functionality
• Any change that impacts the public interfaces of the project (see below)

The Process

Here is the process for making a CEP:

1. To create your own CEP, click on 

   Create from template
   templateName 96600065 templateId 96600065 title CEP-NEXT: Insert Title Here buttonLabel Create CEP

   .
   If you don't have permission, please send an email with your Wiki ID to dev@cassandra.apache.org and request permission. Also add an entry to the table CEPs under discussion.
   Take the next available CEP number and give your proposal a descriptive heading. e.g. "CEP 1: Proposing an Apache Cassandra Management process".
   
   
2. Fill in the sections as described above.
   
   
3. Start a [DISCUSS] thread on the Apache mailing list. Please ensure that the subject of the thread is of the format [DISCUSS] CEP-{your CEP number} {your CEP heading} The discussion should happen on the mailing list not on the wiki since the wiki comment system doesn't work well for larger discussions. In the process of the discussion you may update the proposal. You should let people know the changes you are making.
   
   
4. As the CEP nears completion, consider adding any additional design documentation (see below) to the CEP, especially where it summaries working group discussions.
   
   
5. Once the proposal is finalized call a [VOTE] to have the proposal adopted. These proposals are more serious than code changes and more serious even than release votes. The criteria for acceptance is lazy consensus (3 binding +1 votes and no binding vetoes). The vote should remain open for 72 hours.
   
   
6. Please update the CEP wiki page, and the index below, to reflect the current stage of the CEP after a vote. This acts as the permanent record indicating the result of the CEP (e.g., Accepted or Rejected). Also report the result of the CEP vote to the voting thread on the mailing list so the conclusion is clear.

The following section provides insight into adding additional documentation to the CEP, after it has been opened and a working group has become active on it.

What is considered a "major change" that needs a CEP?

Any of the following should be considered a major change:

Example CEP Design Documentation

Suggestions for additional discussion and documentation, to help flesh out the implementation constraints, are…

• Motivation: The problem to be solved.
• Audience: The intended client audience. Examples include data scientists, data engineers, library devs, devops, etc. A single CEP can have multiple target personas. 
  
• Proposed Change: The new thing you want to do. This may be fairly extensive and have large subsections of its own. Or it may be a few sentences, depending on the scope of the change.
• New or Changed Public Interfaces: Impact to any of the "compatibility commitments" described above. We want to call these out in particular so everyone thinks about them.
• Migration Plan and Compatibility: If this feature requires additional support for a no-downtime upgrade describe how that will work.
• Rejected Alternatives: What are the other alternatives you considered and why are they worse? The goal of this section is to help people understand why this is the best solution now, and also to prevent churn in the future when old alternatives are reconsidered.
• Any major new feature, subsystem, or piece of functionality
• Any change that impacts the public interfaces of the project

Cassandra's Public Interfaces

...

This process also isn't meant to discourage incompatible changes — proposing an incompatible change is totally legitimate. Sometimes we will have made a mistake and the best path forward is a clean break that cleans things up and gives us a good foundation going forward. Rather this is intended to avoid accidentally introducing half thought-out interfaces and protocols that cause needless heartburn when changed. Likewise the definition of "compatible" is itself squishy: small details like which errors are thrown when are clearly part of the contract but may need to change in some circumstances, likewise performance isn't part of the public contract but dramatic changes may break use cases. So we just need to use good judgement about how big the impact of an incompatibility will be and how big the payoff is.

Additional CEP Design Documentation

Suggestions for additional discussion and documentation, to help flesh out the implementation constraints, are…

...

is

...

.

...

List of CEPs

Adopted CEPs

...