Possible RP Release Processes

Governance
1

This topic has come up a few times lately, and I find interesting, so I jumped to drafting something that I felt might work fairly well. Note that I’ve had no input into this, feel free to comment, use it as inspiration, work from it directly, disregard it, etc.

Possible RP Release Processes

General goals are:

  • Transparency - Everyone should know what is happening in a given release, and why.
  • Autonomy - Release teams must be free to make informed selections of what to work on, and include in a given release.
  • Expansibility - Processes must scale to additional options and release teams.

To achieve this, we adopt several independent processes.

Process #1 - Technical Design Generation

This is a continuous process, with no date cut-offs or consideration of the release schedule.

  1. Both the team and the DAO produce bounties rewarding technical designs of functionality for the Rocket Pool protocol.
  2. Both the team and the DAO produce RPIPs containing technical designs of functionality that Rocket Pool protocol should have.
  3. Technical Design RPIPs are given both a priority score and a cost score.
    • Priority Score - Technical Design RPIP ratification outputs a score rather than a binary.
      • Poll options are: Strong yes, yes, abstain, no, strong no.
      • Priority Score is yes - no, with some weighting for strong yes+no.
      • Where a binary is required, positive priority scores are considered ratified.
    • Cost Score - Release teams assign a cost score post-ratification of a Technical Design RPIP.
      • Release cost units tbc, possibly dev-hours, possibly some abstraction.
      • Costs are recorded for each release team if more than one.
  4. Ratified Technical Design RPIPs are listed in a living informational RPIP alongside their priority and cost scores.

PROCESS OUTPUT
A continuously updated Living RPIP including a list of possible inclusions for upcoming releases with

  • Full technical specifications in the form of design RPIPs.
  • A priority score generated by the pDAO.
  • A cost generated by each release team.

Process #2 - Release Content

This is a repeating process that takes place prior to implementation work beginning for a given release.

  • Releases can be scheduled well in advance or can be ad-hoc.
  • Releases made by other release teams trigger another instance of this process that can happen in parallel.

Releases should be planned and communicated to have a certain amount of capacity for inclusions, based on the technical resources available to the release team.

  1. The release team examines the list of ratified Technical Design RPIPs and makes selections for the release.
    • Items must be present in the list of ratified Technical Designs to be eligible for inclusion.
    • Inclusions must be determined by the Release team on the basis of priority score, cost, judged benefit and interest.
  2. The release team produces a draft Informational RPIP containing
    • A list of items proposed for inclusion in a given release.
    • A justification for each item included.
    • A list of any further input or decision-making that needs to take place prior to release, and how this will take place.
    • A list of any conditions that may trigger changes to inclusions.
  3. Draft RPIP is discussed with the DAO, any edits are made by the Release team as they feel are appropriate.
  4. Informational Release RPIP is finalized without a vote.

PROCESS OUTPUT
A Final Informational RPIP summarizing plans for a given release with:

  • A description of what is being included in a given release.
  • A justification for each item included.
  • A list of any further input or decision-making that needs to take place prior to release.
  • A list of any conditions that will trigger changes to inclusions.

Process #3 Release Ratification

This is a process that takes place once for each release at the point where the technical work and audits have reached a stage where no significant changes to release content are expected.

  1. The release team drafts an RPIP containing the following information:
    • The technical design RPIPs that have been implemented in the release.
    • Any other minor changes/bug-fixes that have been included in the release.
    • A brief report on the work done, the costs, and any issues that arose.
    • Links to newly deployed contracts.
    • Links to audits.
    • Post-release plan for updates to documentation, any metrics to watch, etc.
  2. RPIP is discussed by the community, and any feedback on the post-release plan is implemented.
  3. Information in the RPIP is finalized: Links, Changes, etc.
  4. RPIP is voted on by the pDAO - This should be a formality at this point, all significant changes were already ratified individually.
  5. On-chain upgrade is voted on by the oDAO if the pDAO vote is successful.
  6. Change is live.

PROCESS OUTPUT
A set of agreed-upon changes has been implemented in the Rocket Pool protocol.

1 Like
2

Hole-poking:

Hmm… I worry that needing a full technical spec before anything can be considered for inclusion in a release is a significant slowdown. I think I’d be cool with a process like this where Process 1 is only a rough goal, not a full spec and then ful speccing (and vote) happens alongside inclusion in release?

Not everything fits into “release” terribly well. Rpip-30 is a good example. There’s a smartnode change, a couple setting changes, and a SC change all in there. Is this 4 releases?

Release ratification is a good concept. I think it should happen way before on-chain stuff — we’re talking feature freeze, which is several months prior. On-chain execution should be partly based on that, but also on confirming that the implementation is an accurate and secure implementation.

1 Like
3

This is pretty similar to what i came up with. It was actually our intention to have a “Release” RPIP.

Development Process
Development Process3326×1524 67.6 KB

The process is pretty generic so doesn’t rely on any one release team. The one thing it doesn’t really show is that many of the processes are iterative. But there are opportunities to improve the diagram.

Release scoping is always hard. You have to get into the weeds a little to understand the size and complexity. We try to keep features in their own branch so that they can be merged separately into a release branch but that is not always possible when the features interact. So the release RPIP should be a work in progress until final.

The release RPIP imo should be pretty simple. As you said, in your post, it should be the release team who determines what should go into a specific release. justifications are already in the feature RPIPs so no need to repeat in the release RPIP.

Agreed that release ratification is necessary.

In terms of feature/technical designs, i would argue for an abstract cost unit - probably just a t-shirt sizing. In terms of priority, there are points that the community can guide priority. Scoring may help but it is often clear through the process what the priorities are from discussion. Doesn’t hurt to enumerate it but it is quite arbitrary. i agree with @Valdorff that they should not need to be final to be considered for inclusion but for the release to be ratified they should.

Regarding process in general - I am a fan of adding as you go and keeping it to a minimum, so that every element has a cohesive purpose. Everything in this post makes sense from that perspective.

3 Likes
4

This is a cool and important topic I’d like to contribute to, acknowledging a lot of the actions that have to take place will be beyond my control. With that said I think fundamentally there will need to be a lot of coordination and scoping that will need to be done to achieve a handover and I can help with that. For some context, here’s how I’m currently approaching the task at hand:

1. Operational Consistency vs. Decentralized Structure

Decentralization, while aspirational, often encounters the ‘tragedy of the commons’ when it comes to maintaining operational consistency. The key to navigating this is through clear delineation of roles and responsibilities, as well as ensuring redundancy. Placing a primary focus on maintaining a standard of operations is necessary, but should not impede the community from progressively decentralizing.

2. Addressing the Redundancy Challenge

Creating redundancy within Rocket Pool, especially for operational tasks, is a significant first step toward achieving decentralization. While initially resource-intensive, it’s necessary for a robust decentralized environment in the long term. Transferring powers and authorities can be a bit sweaty, but if multiple entities can perform necessary tasks we greatly increase the resiliency of Rocket Pool and makes it easier to “cut the cord.”

3. Ensuring Non-Criticality of Individuals or Teams

Ideally in a DAO, no one person or team should be mission-critical. I struggle to think of examples where this is achieved in practice, but that doesn’t mean it’s not a good goal for us to aim for. I think the coordination cost of having multiple teams that can work on something is made up for by the resiliency. It’s really hard to fight centralization if only some parties have the means and know-how to accomplish a task.

4. Knowledge Sharing and Documentation

The paths outlined by LongForWisdom and Langers point towards the need for extensive knowledge sharing and thorough documentation. This ensures that every team member is equipped with the necessary information to contribute effectively, thereby decentralizing knowledge and expertise. Docs are boring to make but essential for an open organization.

5. Iterative and Inclusive Decision-Making

Finally, I agree with the points raised about the necessity of an iterative and inclusive decision-making process. There is no one way to decentralize, and each tech stack is going to have different needs, just like each community is going to have its own definitions of what constitutes adequate decentralization. Helping push this charge forward is about empowering community members rather than directing them. Seeing these conversations was pretty personally motivating and I suspect others are willing to throw in a few hours if they feel like the collective is serious about the goal.

5

I wanted to leave a little time for other perspectives in here, but it’s been a week, so I’ll address the responses from @Valdorff and @langers

Yes, it might be. I do think that regardless of what process we adopt, we are going to see a reduction in response time. In an ideal world, throughput can be improved because there are more extensible structures in place, even though the end-to-end of an instance of the process takes longer.

We may also have a different idea of what full technical specs are in this context. I would consider the contents of RPIP-28 and RPIP-30 as sufficient to meet this, as an example. It just needs a clear unambiguous specification of what changes in logic should occur. Reference implementations I would consider optional.

Yes, agreed. I’d not considered the non-smart contract changes (bad assumptions on my part.) That said, I don’t think they are terribly incompatible with the processes above? You have releases 2-4 times per year, those releases can contain smart contract changes, settings changes, smartnode changes, etc.

Urgent changes can bypass this process, and planned changes can be defined and setup to come into affect between releases if necessary for the phasing in of changes.

Non-urgent minor changes could also be implemented between releases. Or you could have a schedule of minor off-chain releases interleaved with the major on-chain releases.

Will address this at the end of the post.

@langers, in general we seem to be thinking along the same lines? Dividing the processes into three seems to be a common thread. That said, some comments:

This is definitely one of the main drawbacks to this atomic approach. Depending on the changes, it isn’t always possible to keep them nice and siloed from the rest. I think the main way to avoid this is to only start serious work on feature implementation (as opposed to specification) after the release contents have been decided and communicated to the DAO.

Will cover this last, as I believe its a major point, and both you and Val disagree with me.

Disagree strongly here that justifications are present in the feature RPIPs and so don’t need to be repeated in the release RPIP. This is a misunderstanding of what justifications are for in these contexts.

Feature RPIPs justify the need for a given feature in isolation, why its good, why its needed etc. “Why should we do this?”

Release RPIPs justify why this feature is needed now in this release and why its needed more urgently than all the other possible features. “Why should we prioritize this over the other options?”

More specifically, the justification-for-inclusion gives the release team the chance to disagree with the priorities expressed by the community in a way which better preserves trust and transparency. It also gives the pDAO a chance to ask questions, and to point out potential flaws in the reasoning the release team is using to justify contents. The end goal being that issues are caught before the release team spends too much time on anything that isn’t going to work.

Yes, I think you’re right and that is preferable. Though I would recommend that you go a little more concrete than t-shirt sizing. IE: A ‘large’ release from this team can accommodate approximately X moderately sized features, Y small ones, etc.

Disagree with this strongly as well. I see this come up fairly frequently (from both company and DAO), and its understandable, but it is going to become a problem at some point if you all keep doing it. It is dangerous to make assumptions about DAO priorities solely from DAO discussions.

The reason we have votes is so that DAO opinion can be measured in a quantifiable way. It is much more arbitrary to observe a subset of participants in discussion and assume that it is the majority opinion. It usually is, but the times where it isn’t will really screw you over.

Discussions and forum polls are a starting point, and a useful gate to prevent work taking place on proposals that are clearly not favoured, however, these are not always an accurate signal. The people actively engaged with the DAO are only a a subset of total voters and so your signal is biased to what the most active participants want.

There is a debate to be had over whether only the active participants votes should count, but this is not the model you are currently using to make decisions. You should try to get the most accurate signal of pDAO priority you can, and this can only come from pDAO voting in some form. Priority scoring of possible release content is a lightweight way of doing this.

On the subject of release ratification

So for clarity my position is that release content RPIPs should not require direct ratification by the pDAO. They may have indictive votes organized by the release team if desired, but this should not be made a requirement. Obviously protocol upgrades (once they get to that point) should require a pDAO vote. Here’s why, but it’ll be a little long-winded.

This comes back to the authority part of power and authorities. Who has the authority to do what in this process?

Propose Items - RPIPs are permissionless, anyone can propose one. So the authority is wide.
Approve Items - RPIPs are ratified by the pDAO, so the pDAO holds the authority here.
Propose Contents - In theory any release team could propose an upcoming release including a certain set of items. So the authority here is again wide.
Approve Content - The complicated one, see below.
Propose on-chain changes - In theory anyone can propose on-chain changes to the protocol. So wide authority.
Ratify on-chain changes - pDAO holds authority (I think? though power is with oDAO currently.)

The authority to approve release content

This is complex because there are two competing priorities here:

Release Team Self-Determination
A release team has the ability to work on (or not) any part of the protocol that they want. The DAO doesn’t have to adopt the work, but anyone can do it. It’s an open system. This point becomes arguable if the release team is fully funded by the DAO, but as a general rule, I believe this is always beneficial. You get better output from people that want to be doing the work they are doing.

Much of the time, a release team should be doing what the pDAO wants, because ultimately the DAO controls what changes are ratified in the protocol. No one wants to do pointless work that will never be adopted. However, DAO’s are not capable of the same level of efficient coordination and long-term planning that a more centralized entity or individual is capable of. For this reason, it’s really important that a given release team be able to ignore the DAO if they believe its for the best.

DAO control of the protocol

The flipside and counterbalance to this self-determination is the power of the DAO to control which changes are adopted by the protocol. Work spent by release teams that is not accepted by the pDAO at point of completion is wasted, or at least delayed as it is restructured.

So ultimately:

  • The release team has a solid understanding of what the DAO wants and why, due to priority scoring and justifications attached to specification RPIPs.
  • The release team can ‘gamble’ on doing something other than what the pDAO most wants at a given time, however, this is a risk, and so is only worth doing if there is commensurate benefit.
  • The DAO understands why the release team has made a gamble (if they’ve done so), because the justification is a part of the (informational) release RPIP.
  • The DAO can express disagreement and censure of this decision quantifiably by refusing to adopt the proposed changes at the point of adoption.

Why is this better than just voting on the contents early?

  1. It gives more time to consider the results of any gamble. At the point the work is done, the need that was initially unclear may now be evident.
  2. Ratification of the release RPIP ties the release team to those contents in a way that requires another vote to modify (at least for non-trivial changes). No ratification gives the release team the freedom to modify contents (with clear justifications) during the implementation period if they believe its for the best.
  3. It provides more opportunity for trust to develop between the DAO and its release teams. Opportunities exist in this structure for both sides to take chances and live up to expectations in a way that is not possible if one side dictates to the other.
  4. It prevents harmful misunderstandings of the DAO-team relationship. Say under a release-contents-require-ratification system a release is late, but the team also have produced something unrelated. Did the team do something wrong? They have failed to deliver something ratified by the DAO, and instead delivered something unrelated using the same resources. If the team is seen as working for the DAO, this will be seen as wrong, and will invite criticism. If the team is seen as a partner to the DAO there is much less justification for criticism.
6

Minor follow up after chatting with @Valdorff . We came up with a middle-ground for release-content ratification that we both like.

Essentially, release teams would present an informational RPIP containing the release contents before implementation work began on the release. This RPIP would not be voted on by default, however, there would be a process for the pDAO to vote against a given set of contents via a challenge RPIP within a set period, before implementation work begins in earnest.

This is similar to how pDAO override of GMC decisions is handled (which was the inspiration.)

This has several nice properties:

  • It prevents a vote unless there is opposition to a certain set of release contents (saves everyone time and effort)
  • It saves time early if the pDAO is likely to vote against the release after implementation.
  • It provides more information to the release team in the event of a successful challenge. (The challenge RPIP would contain reasoning and specific issues rather than a general ‘no’ signal being applied to the contents as a bundle.)
  • It retains opportunities for trust to develop between the DAO and release teams.
  • The release team is not tied to release contents the way they would be if they were explicitly ratified.
1 Like