Skip to content

Proposal to change release feature planning #81

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Proposal to change release feature planning #81

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
a8e043f
Initial feature planning change proposal
WhitWaldo Apr 14, 2025
58722d9
Shortened existing proposal to cover only feature release changes
WhitWaldo Apr 17, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
182 changes: 182 additions & 0 deletions 20250412-P-feature-planning.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,182 @@
# Improving the Dapr Feature Planning

* Author(s): Whit Waldo (@whitwaldo)
* State: Proposed
* Date: 4/12/2025

## Overview
This proposal aims to formalize a new approach to planning releases, enhancing feature eligibility criteria, and
bringing transparency, clarity and definitiveness to the current process.

### Current Process
After releasing a new Dapr version, maintainers and contributors meet weekly to discuss high-level goals for the
next release. We review what happened in the previous release interval, identify improvement opportunities (process,
tooling, new capabilities) and draft proposals reflecting these discussions over the following weeks.

These proposals are debated and iterated upon until consensus is reached. Developers and assigned tasks,
POCs are built, tests are added, documentation is produced, SDKs are updated, and features may be highlighted in a
community call before being released.

### Shortcomings
The current process has several shortcomings:
- **Pending Proposals:** Many proposals in dapr/proposals have been iterated on for months or years by numerous
contributors but remain inactive due to lack of advocacy. Despite broad community interest across a long period, these
proposals are often overlooked.
- **New Proposals:** In contrast, new proposals benefit from only a week of feedback from a limited number
of contributors. This rushed process often results in features that may not align with larger project goals or
provide lasting positive impact.
- **Artificial Urgency:** Setting tentative release dates upfront and selecting priorities before designing them creates
unnecessary urgency. This rush to consensus risks half-baked ideas being implemented and potentially impact
credibility around release timelines as issues that might have been caught during the design process are identified
and iterated on on-the-fly in a rush to get the feature completed.

The current release cycle structure is ineffective as it forces us to race potentially incomplete ideas out the door.

## Proposal
I would like to propose several changes to our release process starting immediately.

### Develop Proposals Between Releases
We launched v1.15 on February 26th. Each of the current goals of this release span proposals introduced largely around
and since then:

| Proposal | Introduced At | Proposed By |
| -- |---------------------------------------------------| -- |
|Actors: Bi-directional streaming | February 17 | Josh van Leeuwen |
| Actors: PubSub | February 26, alternative proposal raised March 25 | Josh van Leeuwen, alternative by Whit Waldo |
| Multi-App Workflows | March 24 | Josh van Leeuwen |
| Event Streaming | March 24 | Cassie Coyle |
| Workflow Re-runs | March 25, alternative proposal raised April 6 | Whit Waldo, alternative by Josh van Leeuwen |

Despite being raised no more than a couple of weeks ago, many of these proposals have already gained significant traction.
However, implementing well-designed flagship features based on a three-week ideation and design timeline is unrealistic
and isn't the process taken with larger software groups. It shouldn't be done here either. Furthermost, most of these
issues have minimal community presence outside of the most-active contributors themselves.

#### Proposed Changes
Now is the time for brainstorming big-picture ideas when contributors take breaks from coding or casual discussions
spark new inspiration.

Discord frequently features requests for smaller features that could collectively form larger improvements both in terms
of quality of life and feature additions. Even if these authors don't write original proposals themselves, we should document
these ideas (in a place the stalebot won't hide them) and solicit community feedback to gauge traction. Regular community
and meteor calls should highlight these new ideas with balanced commentary from hosts and direct viewers to relevant
issues so they can chime in themselves.
Comment on lines +59 to +63
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can all agree it's important that we encourage end-users to self-report issues as GitHub issues where they don't already exist as GitHub Issues. If those issues do already exist, it is important that we encourage users to add their feedback and votes of support to those issues.

Discord is a fine place to have conversations and explore issues, but it must result in an output into GitHub Issues/proposals to be super effective as a means for building evidence and datapoints for future considerations.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discord is a fine place to have conversations and explore issues, but it must result in an output into GitHub Issues/proposals to be super effective as a means for building evidence and datapoints for future considerations.

Agree


Designing large-scale features without time pressure soliciting feedback from less-invested contributors can help ensure
that new capabilities are well-thought-out and either fit into our larger vision or require further refinement.

### Release Prioritization
Currently, we ideate high-level goals on maintainer and design calls following a release and wait for proposals to be
submitted, and then largely just move forward with them.

#### Proposed Changes
I propose a substantial change to our process. Barring hotfixes for intermediate patch releases, only ideas backed by an
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this idea, just feeling that the "two months" period should have some level of justification for being that amount of time and not another

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While we aim for four releases a year, we've been hitting three releases a year, meaning each release is taking on average 4 months or so to complete. So I just picked 2 months as that's half of a 4-month release cycle and feels like a sufficiently long enough period for a "last-minute" idea to start baking and getting public feedback, project alignment, design iteration, etc.

existing proposal (at least two months old) should be considered for a new release.

We aim for four major releases a year, though we're more on track for three (one release every four months). By
requiring proposals to exist for at least two months, they will have been considered for at least half of the previous
release cycle, especially during the final stages of the release when unexpected issues tend to crop up while trying
to get the release completed.

This longer proposal period means release prioritization meetings can focus on highlighting eligible proposals and
providing a call-to-action for final comments and votes on the PRs. If there are too many accepted proposals,
prioritization can narrowed to those proposals where contributors wish to be assigned and developers can
immediately move forward with the implementation instead of only then thinking about the design.


### Proposal Acceptance
Currently, features are decided using the
[following approach](https://github.com/dapr/proposals/blob/main/README.md#proposal-acceptance):
> 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).

[This](https://github.com/orgs/dapr/teams/maintainers-dapr) is the list of people who currently have binding votes
on runtime features:

| Name | Organization |
| -- | -- |
| Josh van Leeuwen | Diagrid |
| Yaron Schneider | Diagrid |
| Cassie Coyle | Diagrid |
| Loong Dai | Intel |

Dapr is a core runtime surrounded by a collection of language-specific implementations of it. There's no real proposal
process for the language SDKs as that's left to the maintainers (who are most likely the most active contributors as
well), meaning that most of this proposal language is relevant only to the core runtime.

More to the point, there will almost _never_ be a circumstance where some proposal is made to one of the SDKs that
would ever propagate into the runtime because it wouldn't work without runtime support. All new features must be built
out in the runtime first, making the "relevant repository" language unnecessarily restrictive.

By allowing only binding votes by the few maintainers of the runtime, this minimizes impact of contributions of the
larger collection of [other maintainers](https://github.com/dapr/community/blob/master/MAINTAINERS.md) and their
relevant prioritization interests:

| Name | Organization
|---------------------| -- |
| Artur Souza | Amazon? |
| Bernd Verst | Microsoft |
| Cassie Coyle | Diagrid |
| Cecil Phillip | Stripe |
| Dana Arsovska | Ahold Delhaize |
| Deepanshu Agarwal | Microsoft |
| Elena Kolevska | Redis |
| Hannah Hunter | Microsoft |
| Hal Spang | Microsoft |
| Josh van Leeuwen | Diagrid |
| Long Dai | Intel |
| Marc Duiker | Diagrid |
| Mark Fussel | Diagrid |
| Maurucio Salatino | Diagrid |
| Mukundan Sundarajan | Microsoft |
| Nick Greenfield | Microsoft |
| Paul Yuknewicz | Microsoft |
| Phillip Hoff | Microsoft |
| Rob Landers | Automattic |
| Whit Waldo | Innovian |
| Yaron Schneider | Diagrid |

Members of the steering group committee have equally weighted vote regardless their personal or organizational use
of Dapr. Non-core maintainers can have an equal passion for Dapr's success and relevance, so they should have a
single binding bote on runtime features as well.

By requiring a better-than-half consensus across the broader group of maintainers, this will lessen the unbalanced
nature of the existing binding voting pool. Consider the most recent proposals again:

| Proposal | Introduced At | Proposed By |
| -- |---------------------------------------------------| -- |
|Actors: Bi-directional streaming | February 17 | Josh van Leeuwen |
| Actors: PubSub | February 26, alternative proposal raised March 25 | Josh van Leeuwen, alternative by Whit Waldo |
| Multi-App Workflows | March 24 | Josh van Leeuwen |
| Event Streaming | March 24 | Cassie Coyle |
| Workflow Re-runs | March 25, alternative proposal raised April 6 | Whit Waldo, alternative by Josh van Leeuwen |


Most features proposed for 1.16 are introduced by members with binding votes atn an organization comprising
more than half of the votes needed to approve anything. By diluting this voting pool to all maintainers listed above
(even if some may need to be pruned based on activity), new Dapr features must be designed to be acceptable and
relevant to a broader pool than just the core team.

While expanding the core runtime maintainers list itself might be another way to address this, it requires time,
expertise and a willingness from unknown other parties. Instead, we can change the process itself on a shorter timeline,
and I propose we do so.

## Conclusion
The proposed changes to the Dapr feature planning process aim to address the current shortcomings by fostering a more
inclusive, transparent, and well-considered approach. By extending the proposal development period, we ensure that
ideas are thoroughly vetted and refined, reducing the risk of rushed, incomplete implementations that may be effectively
rendered effectively dead on arrival. Additionally, broadening the voting pool to include all maintainers will
democratize decision-making, ensuring that features not only relevant to a few, but to a broader group of maintainers based
on their personal experiences and the diverse parts of the community they represent.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is certainly something that has been discussed in the STC as part of an objective to increase project diversity in 2025

I strongly agree that having more binding votes from a wider pool of dapr maintainers would in general benefit of the Open Source project.

I also think that this move would potentially attract more SDK maintainers, as they now would have a greater say in the core direction of the project, rather than just the SDKs, which is a great selling point.

Copy link
Member

@yaron2 yaron2 Apr 15, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This specifically would prove very detrimental to the project, and will go against how most (if not all) of CNCF projects assign binding votes, many of which go much more granular and only assign specific voting rights for sub-sections of the code in a given repository.

The reason for this is to allow subject matter experts to make decisions based on their deep, ongoing understanding of their area of ownership, after having worked and achieved a level of understanding that can allow one to weigh in on what often times are critical changes. Giving SDK maintainers the ability to vote on a codebase they are not necessarily familiar with, on a language they are not proficient in (A PHP maintainer voting on a Go codebase, for example) can result in decisions that would harm the project rather than help it. This goes the other way around, as well - If you open it up this way, you will get votes for SDK based decisions from developers who do not have the deep, ecosystem-wide understanding required to keep SDKs feeling natural and true to their language of choice.

Another fallout of allowing this would be creating bottlenecks in voting. When you have a much larger pool of votes, votes can hang sometimes indefinitely due to people being out, sick, on leave or just overwhelmed with other work. What then happens is people are pinged continuously to provide their vote, and often times a vote will be given in a rushed way to just "get this done" and simply to unblock others. I know this well because we've been there in the past, and that hasn't worked well. I've also been privy to other CNCF project maintainers chats talking about the same experiences and lessons learned.

So, I am very much in favor of soliciting feedback from more people in the community and taking that feedback into account to increase the diversity of opinions, but that should not come down to indiscriminate voting rights which will have the ability to throw the entire project out of balance.

Copy link

@olitomlinson olitomlinson Apr 15, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand your concerns, specifically about people who don't have Go experience being in a position of authority over the runtime. It's a fair point.

Putting Go skillset aside, how do non-maintainers of the runtime (like Whit, for example), take some equity in the runtime from a Product perspective? To me, It's becoming clearer that as the user base of Dapr grows, we need to add more product-led thinking into the roadmapping and prioritisation aspects of the project.

Although the runtime and SDKs are separate components with their own implementation details, they need to be thought of as one holistic experience, where one is not more important the other.

As it currently stands, for proven maintainers (like Whit), there should be away to achieve some equity in the OS product vision/direction of the runtime, like a maintainer would have.

Thinking of ideas...

Would it be entirely unreasonable to create a new non-maintainer role (more akin to a Technical Product Owner / Product Manager role) in the runtime which affords n equitable vote over product-related decisions rather than internal implementation details?

Maybe such a role is only attainable via a vote by the STC. e.g. "Once an SDK maintainer has been committed for 12 months (plus other criteria), they are eligible for applying for a Technical Product Owner role on the runtime" or something akin.

I propose that demonstrating that there is a pathway to allow proven people an opportunity to influence the project would be a testament to Daprs commitment to diversity of opinion.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As it currently stands, for proven maintainers (like Whit), there should be away to achieve some equity in the OS product vision/direction of the runtime, like a maintainer would have.

Strong disagree. In the CNCF, and even more so in Apache, projects are assigned maintainers (committers in Apache) on a per-project basis and maintainers are scoped with deciding the technical direction of the project, including everything you'd put in product-level decisions.

Would it be entirely unreasonable to create a new non-maintainer role (more akin to a Technical Product Owner / Product Manager role) in the runtime which affords n equitable vote over product-related decisions rather than internal implementation details?

There are no such roles that I'm aware in the CNCF or elsewhere, however if you can find an existing model somewhere that works, I think it'd be great because then we'd at least have the ability to audit something that works (or doesn't) and make an informed decision instead of coming up with a bespoke model that will make Dapr stand out from its peers. Also, there is the STC which allows every member, regardless of Go skills, to bring up any high level changes in the project which align more with product level thinking (recent examples: Dapr Agents, new APIs etc.). This is generally the established way for non-technical people to contribute to and vote on major decisions related to the project. This is less about technical implementation details of the runtime, which, as established, should be left to the maintainers of the given project as the subject matter experts.

Putting Go skillset aside, how do non-maintainers of the runtime (like Whit, for example), take some equity in the runtime from a Product perspective?

Projects in the CNCF do not have a separate product function or element. The established and widely used maintainer model is based solely on merit and equal opportunity, which allows absolutely anyone who invests the time and effort required to make informed decisions to become a stakeholder and decision maker in the project and be voted as a maintainer.


These changes will not only enhance the quality and coherence of new features while strengthening the collaborative
spirit of the Dapr project. By embracing a more structured and inclusive process, we can better align our development
efforts with the varied needs and aspirations of our contributors and users, ultimately driving the project forward
in a more balanced and sustainable manner.

Let's seize this opportunity to refine our approach and build a more robust, community-driven Dapr that continues
to innovate and excel.