CCEP Purpose and Guidelines

CCEP	1
Title	CCEP Purpose and Guidelines
Version	1
Author	Christian Haudum
Date	2019-02-21
Status	Implemented

What is a CCEP?

CrateDB Cloud Enhancement Proposals (CCEPs) describe standards for the CrateDB Cloud platform, such as implementation standards, service interfaces, architectural changes and others.

CCEPs are conceptually equivalent to RFCs (Request for Comments) or PEPs (Python Enhancement Proposals).

Purpose

The purpose of CCEPs is to find agreement and document standards for the implementation and maintenance of CrateDB Cloud.

Proposals should be created in order to get consensus on bigger changes to the CrateDB Cloud development and architecture, such as API changes, deployment policies, client implementations, service interfaces, and so on.

Workflow

Enhancement Proposals are managed within the crate/cloud Github repository. Drafts and changes of states are made using the regular Git workflow by opening pull requests against the master branch.

Everyone within the engineering team is entitled to write CCEPs. Domain leads are responsible for administering them. They also have the final decision changing states of the proposals, such as accepting or rejecting drafts, and communicating these changes to the teams.

Status

The lifecycle of a CCEP is the following:

        +-------> Rejected
        |            ^
        |            |
        |            |
        |            |
        +            +
+---> Draft +---> Accepted +---> Implemented
        +            +                +
        |            |                |
        |            |                |
        |            |                |
        |            v                |
        +-------> Obsoleted <---------+

Draft

Initially a CCEP is proposed by opening a PR against the master branch of the crate/cloud repository. It has the state Draft.

Accepted

The proposal was accepted by the domain leads. It means that the change is going to be implemented. How, and when this is done is not defined, but could be part of the proposal.

Rejected

The proposal was rejected by the domain leads. There should be a reasoning for the decision when the state of a CCEP is changed to Rejected.

Obsolete

The proposal has become obsolete. This can happen at any time between writing the draft and implementation in case it was accepted. A CCEP can become obsolete, because e.g. the problem it tries to solve does not exist any more.

Implemented

The accepted proposal changes the status to Implemented as soon it has been fully implemented.

Template

Enhancement Proposals should follow this structure:

========
Headline
========

+-------------+------------------------------------------------+
| CCEP        |                                                |
+-------------+------------------------------------------------+
| Title       |                                                |
+-------------+------------------------------------------------+
| Version     |                                                |
+-------------+------------------------------------------------+
| Author      |                                                |
+-------------+------------------------------------------------+
| Date        | yyyy-mm-dd                                     |
+-------------+------------------------------------------------+
| Status      |                                                |
+-------------+------------------------------------------------+

Introduction
============

Provide background information.

Proposal
========

Describe your proposed change or enhancement.

Impact
======

Describe impact on other proposals.

Additionally, link the document in the “Drafts” section of the toc tree of the index.rst file.