I wanted to get some more formal feedback (beyond what’s been provided in the #Grants thread on Discord) on this draft RPIP.
The content for the RPIP was mostly taken from conversations in the #Grants channel, as well as from this somewhat older forum post.
The aim was to get us something that met the criteria of earlier/on-going RPIPs while also allowing us to get a committee up and running sooner rather than later. Any input is most welcome!
First - thanks for getting this going!
Now on to some thoughts/opinions:
Looks great, initial thoughts:
If a custom amount is a better fit for a grant I think that should be the standard , downsides would be some ambiguity and possible contention between GMC members on deciding amounts.
If going with fixed categories there should be a larger variance in amounts/timelines,
500 RPL for instance is 9.2 ETH/ $12k USD at the time of writing.
This is quite a sizeable amount for the smallest category. Something like 20 RPL ($480) over 1 period (or even 10 RPL for future proofing) wouldn’t be unreasonable.
An early suggestion for a possible grant was Rocketpool swag to give out at an event, this would be a relatively low-cost example, $2-3k (100-130~ RPL) but would require up-front disbursement rather than over multiple periods.
On Retrospective awards, I agree that they should be ongoing rather than just for the first period.
For the purpose of rewarding beneficial work by users who:
Mixed opinions on requiring snapshot approval for individual grants, I’m pro explicit community approval but worry about voter fatigue.
Perhaps grants over a certain size should require individual snapshot approval and the GMC can have discretion on smaller amounts up to a combined maximum per period.
Timings specific to the first period probably don’t need to be explicitly detailed, the majority of people will be accepting of some fluidity during the initial setup.
To address question 8 with my own opinion, I think core team and oDAO are both excluded from “community member” as well as those who are regularly paid by the team since they are already strongly connected. For example, someone being paid regularly by the team might have the incentive to vote with the team. Any relationship with the team, especially financial should be disclosed so we are not confused or misled.
Thoughts on different topics (using Val’s original numbering):
1 and 2: This was something that came out of the original discussions here on the forum. Hopefully someone who was in favor of the specific levels will come forward and explain their logic. Since it was a piece of the original discussion that people seemed to agree on, I thought it important to include it. The alternative would maybe be having the grant applicants specify a proposed amount with justification?
3: Completely agree with both Val and Uisce on this one. Retrospective awards should be awardable at any time, including for projects that start after the inception of the GMC. I am sure there will be people who are too self-effacing to apply for a grant for their own work.
4: It didn’t get cut off – I forgot to delete it. I found what I thought was a more elegant solution to the first awards period, namely basing the cut-off dates on the first month after the creation of the rubric. Forgot to go back and delete that one bullet. If someone wants to DM me how to delete things in my own draft RPIP on Github then I’ll do that, along with adding a link to this forum post.
5: Agree with Val and Uisce that there is probably too much snapshot voting. I decided to err on the side of having the community vote on everything and then waiting to see if the community said it was too much while giving feedback. Voter fatigue is real. Open to possibilities – some have already been mentioned by Val and Uisce – for how to manage the balance between internal committee decisions and snapshot voting.
6: I should specify that. In any round in which member(s) are recusing themselves, the threshold for majority would be set by the number of members of the GMC who are eligible to vote.
7: Works for me!
8: I think that’s probably for you all to decide in discussions here and then we can clarify it in the RPIP. I would basically say someone being directly compensated by the team with something approaching a regular salary (though any other payments should be disclosed in conflict of interest statements). I don’t personally see oDAO as part of the team. I see why people feel that oDAO might be more suggestible than non-oDAO to team suggestions, but for the purposes of this particular committee, that’s just not a concern for me. I find it unlikely that oDAO members are going to choose to run for, and spend time being on, the Grants Management Committee without wanting to be an active part of the community.
2: I’m proposing that the GMC be the actual sizer. Sure, if the proposer wants to suggest something, they’re welcome to, but the actual size offered would be what the GMC decide. If this is smaller than desired, perhaps the original folks that wanted to do it no longer want to, ofc – and if it’s larger perhaps it gets more competitive.
4: will DM
6: That’s interesting in and of itself. If a lot of the MC members are active, then a vote might just be a couple people. Weird. I’ll need to think more on this.
Got your DMs on 4. Thanks! I’m getting caught up at work but will try to do the updates to the RPIP tomorrow afternoon.
For 2, I think that would be a real challenge. Most grant applications I am familiar with (admittedly that’s all academia, which is quite broken), involve the applicant proposing a budget. I think it would require a level of expertise that I wouldn’t expect GMC members to necessarily have to be able to accurately guess how much each grant would need without either (a) having a series of award sizes to decide between, which reduces the decision space or (b) having some sort of proposed budget from the applicant, even if it’s only a request.
On 6, I do think it’s imperative that a committee member not vote on their own grant (obviously). I think they probably should not be voting at all during that round, since strategic voting would be tempting. Having said that, the RPIP as written would not preclude them from voting in future rounds, even if their grant was on-going. I don’t know how many GMC members we expect to be putting in for grants, but I find it unlikely that someone is going to apply for a new grant every round or even every other round. Having said that, I could also live with just forcing committee members to recuse themselves from any vote that they will directly financially benefit from.
Doesn’t seem like there’s going to be much other conversation on this one. I really wish we had more people weigh in on whether we should have specific values for grants and, if not, whether we should require proposals to submit a budget or not. That seems to be the biggest point of contention among the (very few) posts we’ve had here so far.
If I had to pick something to put in the final RPIP, I would probably suggest going with no fixed amounts but a need for grant proposals to have a proposed budget. We could always add in the specific levels of grants after if the GMC finds it helpful.
I’m down with requiring a proposed budget. That said, I still think the GMC should set the actual budget, which may or may not match the proposed one.
Agreed. The GMC should not be constrained by the proposed budget in any grant proposal.
RPIP has been updated. Any last comments would be welcome.
@langers I’m not sure if the language on identifying who is a community member actually makes any sense. Specifically, is “Individuals that receive a salary from Rocket Pool, Ltd.” a reasonable way of identifying a dev team member?
Thank you for all the work you have done in creating this RPIP.
I strongly favor the Grants & Bounties Management Committee making decisions, executing those decisions, and reporting to the community how such decisions benefit Rocket Pool. Requiring a snapshot vote for each decision will introduce too much fatigue and overtime result in less informed decisions. It’ll likely slow worthy grant & bounty allocations considerably.
GMC appointment should be a set term (1 year or 15 rewards cycles?). End of term the same method of committee nomination should occur with incumbents able to be reappointed. This provides a forcing function for the community to come together and review GMC decisions. It gives committee members a set commitment time to alleviate burnout, churn, and ghosting. It also allows new invested community members the opportunity to provide different perspectives on the committee.
GMC members may not be able to serve a full term as life happens. Allowing a committee member to bow out and a stating a mechanism for their replacement will help make that transition easier. A simple special nomination with the same format can be used to serve out the vacating member’s term. Alternative is allowing pDAO to appoint interim committee member.
To clarify, the updated version of the RPIP has reduced use of snapshot voting (it’s primarily there for selection of the committee and for community objections to committee decisions).
Any reason we kept the whole selection bit here instead of just pointing to rpip-10? I think I’m reading everything as per rpip-10 with the additional requirements of:
I’d suggest starting it as a 5/8 multisig. Then if any one person leaves, the MC could still function while a new election is kicked off.
I don’t feel strongly about term limits.
If we do them, I strongly prefer some kinda staggering. Knowledge of how the MC works is valuable, so we shouldn’t swap everyone. At the same time, we shouldn’t feel the need to keep folks just to keep folks. This could be done by randomly selecting half the folks to do a 14-period term and the other half to do a 21-period term; subsequent terms are all 14.
The alternative is just having churn handle it, and taking an opportunity to say “hey, Billy has been here for 18 months - let’s revote on that” whenever we have other churn (since selection multiple people isn’t much harder than selecting one).
I’m against having specific values for grants. I don’t see the benefit of restricting grant negotiations to those few specific arbitrary values, in particular having those values set in RPL (which is a volatile asset) can lead to even more inflexibility.
I could agree with a concession of having a min % and max % of the budget that can be destined to a single project, but even then I don’t see how this is better than giving the GMC full freedom to select the best allocation.
As for whether we should require a budget, I think it should be encouraged but not required. Some projects have stricter budget requirements and this should be clearly stated in their proposals, other are more accommodating and could work within a range of both budget and estimated delivery time. In the latter case, the GMC and contributors should be engaged in negotiation to reach the best possible deal for both parts.
@calurduran great job kicking this off! The RPIP looks really good. Excited to see it rolled out.
Pretty much. Although we do pay community members regular “salary’s” for stuff. It might be enough to say individuals that are on the Rocket Pool Core Team but if you want to be exact “individuals that receive a salary from Rocket Pool Pty to work full-time on Rocket Pool”
I agree with the changes to the snapshot voting requirements to avoid voter fatigue. I also support giving the committee the freedom to choose the payout amounts on a case by case basis rather than having fixed values to choose from, but I also acknowledge this might need a little more structure in the future depending on the committee’s ability to keep some level of consistency with valuing contributions to the protocol.
Apologies, folks. It looks like the link to the RPIP in the original post didn’t update, which I thought it would. I think some folks are still looking at the old version. I tried to edit the original post but it doesn’t look like I can? Anyway, to be explicit, here is the link to the new version: RPIPs/RPIP-draft.md at main · dafuerstman/RPIPs · GitHub
@Valdorff - the new version had removed most of the selection stuff and just defers to RPIP-10. It doesn’t actually mention multisigs and funds, though it probably should in retrospect. I don’t like even numbers on committees that have to have a majority to function, though. Perhaps 4 of 7 multisig?
For the discussion re:budgets, I am strongly in favor of grant proposals having budgets attached. The people writing these things are the domain experts in what they are proposing to do. If they can’t come up with a reasonable budget to propose, I don’t know why we would expect the people on the Grants Committee (who will not be expected to be experts in all possible things RP grant related) to judge the appropriate dollar amount. They don’t have to automatically defer to the budget proposed in an application, but it’s a helpful signpost to them in deciding amounts. If we’re not going to go with set amount levels, then a proposed budget is crucial. It can always be amended by a future grant application if the budget seems to be undershooting the actual time/effort required to fulfill the grant.
The term limits thing is interesting. We didn’t put any on the IMC members, so I’m not sure why we would start by putting one on the GMC. We have a pretty flexible governance process so it would be quite easy to introduce them later if we needed to. On the other hand, I’m not opposed to it if there was a strong sentiment that it was needed from the start. I do think that it presupposes a level of interest in being on these time-consuming committees that is not going to exist in fact after a few months/years of operation. Having said that, we do definitely need a section on what to do if there is an opening (unless that already exists in the updated version of RPIP-10).
@langers - Thanks for the language feedback! Rocket Pool Core Team works for me.
## Selection and Governance
In addition to the "Management Committee Governance" and "Management Committee Selection" sections of RPIP-10, the GMC will abide by the following:
- The GMC SHALL contain a minimum of seven individuals.
- The GMC SHOULD be composed of a mix of core team and community members, and SHALL at any point in time have a majority of the membership be community members.
- Individuals that receive a salary from Rocket Pool Pty to work full-time on Rocket Pool or who are members of the oDAO SHALL NOT be considered community members for the purpose of this RPIP.
- During committee selection, ignore all remaining vote weight for non-community members if that group (non-community members) would become the majority with one more selected nominee.
- For the initial selection process, 7 members SHALL be selected.
My only concern with starting at 7 and 7 needed to operate is stalling out. That said, maybe I’m being silly. The multisig will still actually have 7, even if someone declares they’re leaving. So it could continue to operate while a vote happens.
New thought: we probably want to change the “community member” and “member of the community” uses to “anyone” or “community” in places where it’s not meant to specifically exclude team/oDAO (see Awards Process, Assessment of Awards, Rationale). Now that we put in a technical definition, so the “normal english” uses need to go.
I like the new verbiage for Selection and Governance and that makes sense to be consistent throughout.
I don’t know that the language specifies we need 7 to operate. If someone stepped down, the committee could still operate until a replacement was voted in - they’d just need a majority to approve anything, which would be harder to achieve with an even number of people. The addition of the multisig would make it more complicated, but this isn’t the most time-sensitive of funding. I’d be more concerned about that with the IMC.
As a note, I live pretty much right where Hurricane Ian is supposed to be in a few days, so if I disappear for a bit, that’s why. I assume someone (realistically Val) can copy the draft RPIP from my Github fork if we want to move forward with it without needing to wait for my return. I am 100% okay with doing so in the interests of keeping forward momentum if I disappear for a while. My primary interest is in getting some sort of grants committee up and running, and there’s already going to be a lot of lead time for nominations, elections, creating the rubric, soliciting applications, etc.