...

This page describes a proposed the Cassandra Enhancement Proposal (CEP) process, for proposing a putting forward major change changes to Cassandra for discussion and decision-making.

...

Purpose

Cassandra Enhancement Proposals are intended as a better landing space for New Features, as opposed to JIRA.

The purpose of a CEP confluence page is to help promote as much possible open collaboration during the initial brainstorming and navigation phase of a new feature. The benefit this brings to the author/initiator of the idea, increasing the likelihood of the idea getting implemented and committed, is intended to be enough incentive to write the CEP instead of the JIRA ticket.

CEPs should be used for significant user-facing or cross-cutting changes, not small incremental improvements.  At the technical level, CEPs are intended to increase the likelihood that compatibility requirements are safely met. At a user level, CEPs are to help ensure all variants of Cassandra installations and usages are considered.

CEPs are also not intended to be a return to waterfall development, and an acceptance of an CEP provides no guarantee to the work eventually being accepted. It is all too often that work-invalidating insights hit late, invalidating an idea, despite after a working group having formed, agreed, and a significant work has been done. This is always a risk of part of agile development, but a CEP up front with engagement from a bunch of parties should help surface those design implications sooner.

provide a process for the proposal, discussion and endorsement of new feature development in Cassandra.  CEPs confer advantages to patch authors by building legitimacy for changes within the community, and obtaining early consent for the direction of development.  It is up to feature authors to determine if a CEP should be pursued for any piece of work, balancing the costs of a more burdensome process against the benefits of early community input and endorsement.  As CEPs become more common, it is anticipated that project members will become less permissive to large changes that haven't attempted to seek consent beforehand, feeling freer to request major changes that they feel are suitable.

It is highly recommended to pursue a CEP for significant user-facing or changes that cut across multiple subsystems.  Community feedback is able to provide information on:

• Unexpected edge cases that may confound work or otherwise complicate it 
• Major users and their expectations of existing or future behaviour
• Project attitudes towards specific categories of feature
• Project expectations around how a feature should be structured and delivered

The CEP process aims to be lightweight and flexible.  One may be initiated The process of starting a CEP is intended to be light-weight and flexible. For example, a CEP can be started with nothing more than a title to begin with, and where it goes from there is left up to the , expanding as a working group that materialises and ideas crystallise. See Scott Andreas' 2019 NGCC presentation for a community perspective, and how this ties into the release lifecycle and evolution of the project. The information and guidelines that follow are only intended as food-for-thought to get started.

What

...

a CEP

...

A CEP should contain the following sections: 

...

Scope,

...

Goals (and non-goals),

...

Approach,

...

Timeline,

...

Mailing list / Slack channels,

is not

CEPs are not intended to presage a return to waterfall development, and an acceptance of an CEP provides no absolute guarantee that any final product will be accepted. Work-invalidating insights can hit late in development, invalidating an idea, despite significant work being done.  The CEP merely mitigates this risk, and helps build legitimacy for a change so that technical difficulties may be discovered early, and non-technical objections handled before work begins

...

.

Who should initiate

...

a CEP?

Anyone can initiate a CEP but you shouldn't do it unless you have an the intention and know-how of getting the work done to implement itcapability to complete the proposed change.

A CEP needs to attract a Shepherd that is , a PMC member who is committed to shepherding the proposed change throughout the entire guiding the proposal through the process. Although the a shepherd can may delegate or work with other committers in the development process, the shepherd is , they are ultimately responsible for the success or failure of the a CEP. Responsibilities of the shepherd  Responsibilities include, but are not limited to:

• Be an advocate Advocating for the proposed changeproposal
• Ensure Ensuring the working group achieves consensus among key stakeholders
• Ensure Ensuring the working group seeks feedback from relevant stakeholders and users, and iterates on the design & implementation (see below for additional CEP documentation)
• Ensuring project standards of development and quality are met
• Ensuring changes match 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 themBe committed to review code changes, ensuring project standards

What should be included in a CEP?

A CEP wiki page should aim to:

• Promote collaboration during the discovery phase of a new feature
• Serve as a permanent document describing the feature that evolves along with its development

A CEP should contain the following sections: 

• Scope,

• Goals (and non-goals),

• Description of Approach,

• Timeline,

• Mailing list / Slack channels,

• Related JIRA tickets.

The Process

Here is the process for making a CEP:

...