This repository stores proposals and designs for new features in Dapr (i.e not bug fixes or minor changes) with the intention of improving visibility, historical record-keeping and maintaining a consistent process.
As mentioned above, any significant change that needs design and a conversation around that design should go here. As a guideline, anything that would warrant a change in the Dapr SDKs would probably require a proposal. Some specific examples would include:
guides/)dapr/proposals for community review.Proposal file are named in the following format:
YYYYMMDD-FLAGS-description.md
Where YYYY is a 4-digit year, MM for 2-digit month and DD for 2-digit day of when the proposal was last updated (like 20240309, for example), and FLAGS is one (or possibly more) of:
So, for example, a proposal to create a new building block, such as the workflow building block, might be something like 20240102-BRS-workflow-building-block.md, whereas a change to the actor system, which does not require any changes to the SDKs themselves, would be something like 20240103-R-actor-reminder-system.md
To accept a proposal, the maintainers of the relevant repository must vote using comments on the respective PR. A proposal is accepted by a majority vote supporting the proposal. When this condition is true, a maintainer from the relevant repository may approve and merge the proposal PR. While everyone is encouraged to participate and drive feedback, only the maintainers of the relevant repository have binding votes. Maintainers of other repositories and community contributors can cast non-binding votes to show support. The majority vote needed is a simple majority (more than 50% of total votes).
Features in Dapr have a lifecycle (e.g Components) and, as such, should have a defined set of milestones / requirements for progression between the lifecycle phases. For example, can a user expect from a feature when it is Alpha quality? Once that is released, what is the plan to progress from Alpha to Beta, and the subsequent expectations? What is the expectation when this feature becomes Stable? It is important to identify what functionality or perfomance guarantees we are making to users of Dapr when adding something new.
For example, the lifecycle expectations of a "Foobar API" that is going to replace an existing API might look something like:
Alpha:
foobar-api is enabledBeta:
Stable:
This information can be included either in the template or in a README -- and is designed to provide a common language for proposals so that the expectations are clear.
(This is an incomplete list and should / will be expanded over time)
| Term | Meaning |
|---|---|
| Building block | Capabilities that solve common developmental challenges in building distributed applications |
| API | Application Programming Interface - functionality exposed to end-users that can be used to interact with Dapr's building blocks in the application they are building |
| Feature | New or enhanced functionality that is being added to Dapr |
The keywords “MUST”, “MUST NOT”, "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.