[NEW] Valkey Improvements/Enhancements/Features Proposal

[rlunar]

As we try to refine the RFC process, we need to find a mechanism that we can adhere to continue improving Valkey's Core, Modules, Clients and Tooling.

Proposed Solution

Follow a similar approach as Kafka, when announcing a release Introducing Apache Kafka® 4.0 the project has a concept Kafka Improvement Proposals (KIP) allowing to provide developers with preview features like KIP-932: Queues for Kafka

Following section borrowed from Kafka, we can always adjust the language and terminology to be Valkey friendly.

---

Valkey Improvements Proposal

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

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

What are the "public interfaces" of the project?

All of the following are public interfaces that people build around:

• The network protocol and api behavior
• AOF/RDB format
• Error/Authentication log format

What should be included in a VIP?

A VIP should contain the following sections:

• Motivation: describe the problem to be solved
• Proposed Change: describe 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.

Who should initiate the VIP?

Anyone can initiate a VIP but you shouldn't do it unless you have an intention of getting the work done to implement it (otherwise it is silly).

Process

Here is the process for making a VIP:

1. Click Create VIP. Take the next available VIP number and give your proposal a descriptive heading. e.g. "VIP 3247 Valkey Sink: Tiered Storage".
2. Update the next available VIP number below.
3. Fill in the sections as described above.
4. Also add an entry to the table VIPs under discussion.
5. Start a [DISCUSS] thread on the Valkey Contributors Slack channel. Please ensure that the subject of the thread is of the format *[DISCUSS] VIP-{your VIP number} {your VIP heading} *and the body contains a link to your new VIP. 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. When you feel you have a finalized proposal
6. 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 majority. The vote should remain open for at least 72 hours.
7. Please update the VIP wiki page, and the index below, to reflect the current stage of the VIP after a vote. This acts as the permanent record indicating the result of the VIP (e.g., Accepted or Rejected). Also report the result of the VIP vote to the voting thread on the mailing list so the conclusion is clear.

Approvals

These are the types of approvals that can be sought. Different actions require different types of approvals.

Approval Type	Definition
Lazy Consensus	Lazy consensus requires 3 binding +1 votes and no binding vetoes.
Lazy Majority	A lazy majority vote requires 3 binding +1 votes and more binding +1 votes than -1 votes.
Lazy Approval	An action with lazy approval is implicitly allowed unless a -1 vote is received, at which time, depending on the type of action, either lazy majority or lazy consensus approval must be obtained.
2/3 Majority	Some actions require a 2/3 majority of active committers or TSC members to pass. Such actions typically affect the foundation of the project (e.g. adopting a new codebase to replace an existing product). The higher threshold is designed to ensure such changes are strongly supported. To pass this vote requires at least 2/3 of binding vote holders to vote +1.

[rlunar]

Moved to issue #3289