RPIP Modifying Operations of GMC

Hi folks. This has now been talked about in multiple forum threads, so I decided to write it up as an RPIP. This piece of it specifically modifies RPIP-15 about the size, frequency, and membership of the GMC. There were other things discusses (including specifying terms, election dates, and procedures for vacancies) that would be a modification of RPIP-10. I am working on those as well, but this is a bit more time-sensitive so I wanted to get a heat check on it before moving it to snapshot. The vacancy procedures outlined in this RPIP are temporary awaiting broader clarification in RPIP-10 of how we handle all vacancies.

  • Do you favor moving this RPIP to snapshot?
  • Yes
  • No
  • Other (specified in replies)

0 voters

Abstract

RPIP-15 created the Grants Management Committee (GMC). Several small issues have arisen with the committee as envisioned by RPIP-15, with this RPIP serving as a corrective. Specifically, this RPIP fixes the size of the committee at nine members, changes the frequency of grant rounds from every-other-month to quarterly, and removes the community majority requirement.

Motivation

The Grants Management Committee serves an important role in the functioning of the pDAO. It exists to incentivize and reward community activities that further the goals of the pDAO and the protocol. In the process of starting the committee and running the first round of awards, three issues have arisen. First, the committee could use a couple extra individuals to help manage its workload. Second, the frequency of award rounds (every-other-month) creates a significant workload for the committee and is more frequent than other grant-giving authorities in the crypto space. Third, the bestowment of an oDAO position on community members identified as Rocket Scientists has created complications with the RPIP-15 requirement that a majority of committee members be neither Rocket Pool core team members nor oDAO members.

Specification

Guiding Principles

  • The guiding principles of this RPIP remain the same as RPIP-15, with the added principle of furthering the efficient and reasonable functioning of the Grants Management Committee.

Operations

  • Committee Size
    • The existing text of RPIP-15 under ā€œSelection and Governanceā€ reads ā€œThe GMC SHALL contain a minimum of seven individuals.ā€ This instead shall read as follows: The GMC SHALL contain nine individuals, except in cases of vacancies.
    • The procedure for filling vacancies SHALL be as follows unless and until it is changed by a future RPIP or an amendment to RPIP-10: if a vacancy occurs within six months of the previous election, the next highest vote recipient from the previous election shall be offered the seat, with the GMC going down the list of nominees until the position is filled. If it has been more than six months since the most recent election, a new election shall be held to fill any vacancies.
    • Upon approval of this RPIP, immediate elections following the guidelines of RPIP-10 shall take place for the two new GMC seats.
  • Award Frequency
    • The existing text of RPIP-15 under ā€œAwards Processā€ SHALL instead read as follows:
      • The GMC SHALL publish an open call for grant, bounty, and retrospective award applications by the first of the month of the first month after the successful creation of the scoring rubric (see below), with deadlines for application falling on the 15th of that month. Subsequent calls for applications SHALL occur at the start of every quarter - January, April, July, and October, following the same 1st of the month/15th of the month deadline schema.
  • GMC Member Status
    • The following existing text of RPIP-15 SHALL no longer be in force: ā€œ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.ā€

Rationale

The three issues addressed by this RPIP were raised shortly after the creation of the RPIP and/or subsequent to its first election. Community input was gathered through forum posts here and here. On the first issue, of committee size, there was general consensus that a larger committee would be acceptable and would make it more easy to manage its workload. On the second issue, of grant award frequency, community member Epineph noted here that the grant calendar seemed aggressive and that the paid team from Optimism took significantly longer to do grant rounds. The experience of the GMC to date has reinforced that the every-other-month grant schedule is a big ask of a volunteer committee. On the third issue, of community status of GMC members, there has been significant conversation at the previous links. General community sentiment favors removing restrictions on the Team- or oDAO-affiliation of committee members and leaving to to the pDAO voters to decide who they would like to represent them.

4 Likes

This looks good to me.

Iā€™m a little uncertain about what is procedurally better:

  • An RPIP that has all the ā€œfinalā€ text and supersedes RPIP-15
    • Pro: one source of truth
    • Con: annoying to see differences (though git diff can help here a bit)
  • An RPIP that modifies RPIP-15
    • Pro: clear differences
    • Con: need to flip back n forth to get full picture

I tend to lean towards the former, but donā€™t feel terribly strongly.

1 Like

In favor of moving to snapshot. (Btw, the poll is slightly broken, the question itself is a poll answer. :see_no_evil:)

Out of curiosity, why not opt to immediately apply the procedure from the previous bullet point? The GMC membership vote started Oct 24th, so only about 3 months ago. So we could select the next candidates from Snapshot instead of holding a small new election. Link here: Snapshot

Mostly because we already know the results of the previous election and so the RPIP would effectively be appointing two specific individuals (or at least offering them the opportunity), which feels weird to me. And I say that as someone who would strongly favor both of those people being on the GMC. But I also donā€™t feel strongly about it and could happily go with deferring to the previous list.

I personally am interested in running for GMC. Iā€™m also interested if it brings any other new candidates. However, if the general consensus is that running another election would be inefficient, Iā€™d be in favor of using last electionā€™s results.

1 Like

Thanks for putting this together!

Can you elaborate on the rationale here? Specifically, are you confident that more people wonā€™t slow things down by making coordination, communication, and consensus more expensive?

1 Like

I canā€™t speak for everyone on the GMC, but there has not once been a time yet that Iā€™ve thought ā€œI wish there were fewer people involved in thisā€ and several where Iā€™ve thought more would be good. And the committee has not yet gotten to the grant management phase, which would be especially helped by having extra hands on deck.

1 Like

Thanks for sharing your point of view, makes total sense now!

That makes sense, in a way it would be retroactively applying the new rules because the previous outcome is already known. I donā€™t have a strong preference either. Giving new people a chance to throw in their application is another advantage of a new election round.

Since I donā€™t know if everyone reads the governance channel on Discord, I wanted to mention here that I found out this weekend about a big new project Iā€™ll be taking on as part of my side gig. It will necessitate my needing to step down from the GMC in a few months. While this came up after Iā€™d mooted and posted the proposed changes to RPIP-15, it makes me more inclined to suggest elections for the two new positions, as it would also involve electing a replacement for me. If we did all three of those by resorting to the next-highest-vote-recipient, that would risk having nearly a majority of the committee not having won the original election (weā€™d be up to 4 of 9).

2 Likes

Coming back to this, I strongly prefer a single final RPIP that supersedes RPIP-15.
We only have to deal with the change comparison once. In contrast, using ā€˜modifyingā€™ RPIPs quickly gets unmaintable in the future when we could have modifications upon modifications or several RPIPs that are modified by other RPIPs.

1 Like

Hi all. Hereā€™s a draft of the RPIP. As per the request of several folks, it is a single RPIP that supercedes RPIP-15, rather than a list of changes and amendments. Any feedback welcome, otherwise the poll seems to indicate we are okay with moving to snapshot.