We recently created a [thread] around medium term initiatives we could work on for Rocket Pool. One of the higher ranked items was the creation of a Operational Process Framework. This is that framework.
Summary
A Voted Operational Process (VOP for short) is a process that we need / want people to vote on, but one that is not strictly speaking an improvement to the Rocket Pool Protocol or DAOs. Instead it’s more of a maintenance or operational decision.
Think committee elections, oDAO membership management, grants appeals, etc.
VOPs are defined inside of RPIPs. So for example the GMC RPIP would now include a VOP definition.
A VOP definition is just a list of attributes that a certain process or decision has, formatted in a consistent way. For example, GMC elections are elected by the pDAO, happen ~once a year, take place on snapshot using weighted voting, etc.
A single GMC election would be an instance of the GMC election VOP. The outcomes of instances are recorded within RPIPs.
A summary of all VOPs in Rocket Pool is kept in a separate informational RPIP, known as the VOP overview.
Part of the proposal here is to adapt existing processes within Rocket Pool to use this framework. Some fit better than others, listed below. Note that the intention is for no logical changes to take place to the process requirements / voting group / etc, it would just no longer require use of the RPIP process.
Easy Fits
(planning to modify relevant RPIPs to fit this framework)
GMC membership selection
GMC admin selection
GMC admin removal
GMC dispute / appeal
IMC membership selection
oDAO member suggestion
oDAO member change
Less Obvious Fits
(may do these as well if people have strong feelings they should be in this framework)
Core Team Development Funding - Not in RPIP form yet, so would need to be made from scratch
pDAO charter changes - Fits framework. Ideological reasons to require RPIPS for changes
oDAO charter changes - Fits framework. Ideological reasons to require RPIPS for changes
pDAO Budget Split - Fits framework. Ideological reasons to require RPIPS for changes
Rocket Pool Inflation Allocation - Fits framework. Ideological reasons to require RPIPS for changes
GMC Internal Decisions - Can fit framework, may be unnecessary.
IMC Internal Decisions - Can fit framework, may be unnecessary.
Example
This is what a VOP definition looks like (again using GMC as an example)
VOP-GMC-MEMBERSELECT
This is a voted operational process (VOP) definition, see RPIP-34 for more information.
Name: Grants Management Committee Selection
Description: An election to fill the membership slots of the GMC.
Purpose: Ensure that the pDAO has the opportunity to periodically vote on GMC membership.
Responsible Party: GMC Administrator > GMC Members > RPIP Editors
Voting Group: pDAO
Vote Type: Weighted (Snapshot)
Trigger(s):
Periodic approximately yearly (between 10-14 months).
More than half of the GMC’s membership has not been elected via vote.
There are vacant seats on the GMC that cannot be filled without a vote.
Other Requirements: See RPIP-10 - Management Committee Selection for full requirements.
Would love some feedback here, it’s a bit of an meaty addition, but essentially would just provide rails for documenting reoccurring procedures and how people can participate in them.
I’ve made some formatting and content fixes to the RPIP34 draft. The changes can be seen in this [PR]. List below for convenience.
Things updated
Unified examples around the EMC (example management committee) for clarity.
Clarified elements fields some.
Moved templates to implementation section.
Moved backwards compatibility (= changes to existing processes) to specification section.
Added pDAO budget management to VOPs framework.
Explicitly supporting removing or modifying VOP definitions.
Major outstanding
Get community feedback.
Create a separate PR containing the required modifications to other RPIPs in order to integrate them into this framework.
I would like to again request community feedback on this RPIP. I’m aware that as a meta-type RPIP, this has less direct bearing on you as node operators, but the goal here is to reduce friction in the governance of the protocol and should (assuming I’ve done a good job) make your lives as NOs slightly easier.
Meta feedback is also appreciated, if any of the below is true:
You’re finding this too intimidating to engage with.
You feel the way I’m approaching the RPIP process is wrong / unusual.
Something else (that I can mitigate) is preventing you from engaging with this.
It would be useful to know, so I can adjust my approach to better fit expectations. Comments here or DMs on forum or discord are all fine ways to reach me.
I love this idea and the visual example really helped me understand it better, I would love more of that. I really just want to post to say that I really like this idea and I think that it would be so beneficial for newer members of the community. In the beginning it’ll probably be a hassle to set up VOPs for each RPIP but I think once that is done future use of the template would be so easy.
I have two questions/suggestions:
In an RPIP, is the VOP defined at the point of where the action is defined or are VOPs defined at the end of the document so that you can see everything defined at the same time?
In the RPIP it says, “existing ratified RPIPs containing processes that would fall under the VOP framework will be modified to use the VOP framework,” but I was wondering if it would be better to define the action in more detail and the VOP serves as a supplement. (Maybe I’m misunderstanding this part)
Really appreciate you taking the time to comment, @regexbuster!
Might be you meant this as a general comment, but in case not: Was there something specific in the VOPs framework you thought would benefit from additional visual aids?
Maybe something that shows the sort of lifecycle flow of a VOP definition? Ie:
VOP define is added / included in RPIP
VOP added to overview
Instances created as community makes decisions
VOP either modified or removed when no longer needed.
Not something I’d considered strongly yet. I suspect I will have an opinion on it after I have modified some of the existing RPIPs.
Thinking now, I would lean towards grouping them at the end? I think it would be a SHOULD rather than a MUST though. I would prefer to give the author flexibility to adjust ordering if they think it improves readability.
Maybe some misunderstanding? Hard to tell from your comment.
What I mean by modifying the existing RPIPs is:
Adding VOP defines for existing processes.
Making sure VOP define matches existing process requirements
Removing requirements from the RPIP text if it is now covered in the definition (I will lean conservative here, and only remove things if I am certain its fully explained by the VOP definition.)
The current set of processes in the existing RPIPs are somewhat inconsistent in their level of detail. There are some that just say something like: ‘X can be modified via vote’ with no further detail. Others have lots of additional rules.
The overall goal with converting the processes is to maintain the current functionality. This means its difficult to justify defining them in more detail. However, in the case where they are very underspecified, I will likely:
Default to pDAO as the voting group
Require promising community sentiment per RPIP4
Hopefully that clears up any confusion, and answers your questions. Feel free to follow up regardless.
More of a general comment. I think most if not all of the other RPIPs are purely text and sometimes that visual aspect is helpful to break down the concept.
I like this idea. I think it would be beneficial to have them all at the end since it would be easier to just look at all of them together instead of trying to pick through the RPIP to find the different VOPs that are defined. However, I don’t want to stifle clarity since it may sometimes be better for clarity’s sake to have them sprinkled through the RPIP.
This helps clear it up. I was concerned mostly about disturbing how the RPIP is structured now. I like how there is the ‘X can be modified via vote’ directly where it is relevant but. However, I think we should leave it similar to that and then have it link off to the VOP at the end of the page. (Or just have the VOP there if that’s what the author prefers)
So, its been a couple of weeks without any further comments.
I’ve spoken to a few people about this via discord. On balance, I’ve decided to put this RPIP on hold for the time being. My reasoning is as follows:
RPIPs are required to show positive community sentiment to move to a snapshot vote. I don’t believe this exists in a meaningful amount for this proposal, at this time.
A number of people expressed lukewarm sentiment around the changes, and a lack of expertise to judge further. These are valid comments and it further convinces me that this isn’t the right time for this proposal.
Ultimately, I don’t want to impose structure that isn’t obviously valuable to the DAO. If this was fixing a problem that the average community member cared about, there would be more engagement with it.
Some feedback has been along the lines of: “There are better places to improve things in the DAO right now”, and I agree with this sentiment.
To be clear, I’m happy to pick this up again (or for someone else pick it up, if I’m unavailable) if:
A clear need for it develops in the future.
Community sentiment leans more obviously positive.
I’ll still be around and working on other initiatives in the meantime.