Proposal to change release feature planning

[WhitWaldo]

Thank you for giving it a read and for your consideration!

[olitomlinson]

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.

[yaron2]

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

[olitomlinson]

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.

[yaron2]

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.

[olitomlinson]

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.

[yaron2]

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.

[yaron2]

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

[WhitWaldo]

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.

[WhitWaldo]

I have updated the proposal to limit it only to those aspects that have support and to remove the governance changes to a separate proposal for further discussion.