Committee Selection Process

Governance
1

Hi all,

I wanted to put forth a suggested committee selection process and get some feedback on it before I suggest it as an addition to RPIP-10.
I’d also like a similar process to be used for pDAO guardian committee when we get to that, even though RPIP-10 doesn’t directly cover that.
First the text, then a list of things I’d like feedback on:

Management Committee Selection

Normal procedure

  • Nominations
    • A nomination thread for the MC SHALL be posted on the forum for at least 5 days.
      • Any member of the community MAY nominate any member (including themselves).
      • Any nominated member MAY ask to be removed from consideration.
      • A final list of nominees (except those that asked to be removed) SHALL be created and posted as a comment in this thread.
      • If this results in insufficient nominees to fill the spots, the Management Committee Selection process fails and must be restarted from the beginning.
  • Nominee information sharing
    • Within 3 days of the final list being posted, each nominee SHALL provide the following:
      • An alignment statement explaining why they are motivated to act according to the MC charter.
      • A conflict statement explaining any other entanglements that could be perceived as motivation to act against the MC charter or the protocol. This includes entanglements with other crypto, other LSD providers, etc.
      • An identity statement explaining as much or as little of who they are as they wish to share. This MAY provide verification to the degree the nominee desires.
      • A contribution statement explaining their contributions to RP.
      • If this is not provided, the nominee shall be removed from consideration. If this results in insufficient nominees to fill the spots, the Management Committee Selection process fails and must be restarted from the beginning.
    • The nominee MAY also provide any additional information they deem helpful.
    • An organizer SHALL provide some basic hard metrics for all candidates; this SHOULD include:
      • Account ages of RP-related accounts.
      • Activity metrics for RP-related accounts (this MAY include items like: number of posts, how often their posts are liked, number of git commits, etc).
  • Membership selection (suggested method)
    • The information from “Nominee info sharing” SHALL be compiled and made available on a forum post.
    • Once that post is available, a Snapshot “Approval voting” vote SHALL be created with 2 options per nominee: “Support @nominee_name” and “Veto @nominee_name”
    • The vote text MUST include the following text:
      • You may vote for any number of options. At the end of the vote, support for each nominee is calculated as support_power - 2*veto_power and the top scorers will be selected. Please see vote `Management Committee Selection/Normal Procedure/Membership selection” in RPIP-10 (https://github.com/rocket-pool/RPIPs/blob/main/RPIPs/RPIP-10.md) for full details of this process.
    • At the conclusion of voting, total_support SHALL be calculated for each nominee as total_support = support_power - 2*veto_power. If total_support is less than or equal to zero, the nominee SHALL be removed from consideration; if this results in insufficient nominees to fill the spots, the Management Committee Selection process fails and must be restarted from the beginning.
    • The selected membership SHALL be the nominees with the highest N total_supports, where N is the desired number of selections. In the event of a tie in total_support, the pDAO treasurer SHALL randomly select which of those nominees are selected.
Membership selection (alternative A)
  • Membership selection (alternative A)
    • The information from “Nominee info sharing” SHALL be compiled and made available on a forum post.
    • Once that post is available, one Snapshot vote SHALL be made for each nominee
      • The vote text MUST explain that it’s part of a set of nominee votes, explain how total support is calculated, and point to this RPIP for a full explanation of the process.
      • Voters SHOULD vote “For” on any candidate they would be comfortable with on the MC
      • Voters SHOULD vote “Against” on any candidate they would be uncomfortable with on the MC
    • At the conclusion of voting, total support SHALL be calculated for each nominee as For power - 2*Against power. If total support is less than or equal to zero, the nominee SHALL be removed from consideration; if this results in insufficient nominees to fill the spots, the Management Committee Selection process fails and must be restarted from the beginning.
    • The selected membership SHALL be the nominees with the highest N total supports, where N is the desired number of selections. In the event of a tie, the pDAO treasurer SHALL randomly select which of those nominees are selected.
Membership selection (alternative B)
  • Membership selection (alternative B)
    • The information from “Nominee info sharing” SHALL be compiled and made available on a forum post.
    • Once that post is available, a Snapshot “Weighted” vote SHALL be made.
    • Voters MAY split their vote however they wish; it is RECOMMENDED that they evenly split their weight among their top N candidates, where N is the desired number of members on the committee.
    • If quorum is not met, the Management Committee Selection process fails and MUST be restarted from the beginning.
    • The selected membership SHALL be the nominees with the highest N vote weights, where N is the desired number of selections. In the event of a tie, the pDAO treasurer SHALL randomly select which of those nominees are selected.

Expedited procedure

  • If there is a pressing reason to select MC membership rapidly, the normal process can be bypassed:
    • The desire to bypass SHALL be confirmed with a poll on the forum.
      • The post SHALL state the pressing reason to bypass and use the expedited procedure.
      • The post SHALL point to this RPIP to explain the normal process and expedited process.
      • The poll SHALL be up for at least 48 hours.
      • The poll MUST achieve at least 2/3 agreement in order to use the expedited process.
    • The MC membership MAY be selected by any method desired.
    • The MC membership MUST be confirmed by a Snapshot vote.
    • The MC membership SHALL be voted on again (with the normal procedure) within 4 months.
      • Note that the new vote MAY be sooner than 4 months, and that is likely preferable. For example, the normal procedure MAY be started immediately after the expedited process concludes.

Areas I’d particularly like feedback on

  • Timelines. The normal process takes a minimum of 15 days and the expedited process takes a minimum of 9 days. Do we even need the expedited process?
  • Membership selection vote preference
    • See https://docs.snapshot.org/proposals/voting-types for vote types that exist in snapshot.Note that RPIP-4’s current form only supports Single choice voting (and Basic voting, since that’s a type of Single choice vote). The suggested method and Alternative B both require different voting types.
    • The suggested method attempts to present simple choices on each nominee in a single vote.
    • Alternative A makes each vote as simple as possible, at the cost of clutter (maybe we’d expect ~15 votes for a committee selection). It’s not clear how quorum would be defined – would we ask folks to actively abstain? Is it required on all separate votes, or any one vote?
    • Alternative B is the most compact, but I worry it’s too flexible and thus lends itself to gaming. The “recommended method” makes it somewhat similar to the Suggested Method, but folks would have the ability to split differently if they choose. This method also loses the “more weight to vetos” concept.
  • Do you prefer more numerical/measurable minimums? Eg, like suggested in Identity and Governance - #15 by Wander. (obviously my preference is for providing information to voters who can then value factors as they wish, which is laid out in this proposal)
4 Likes
2

Great work on this, I already shared some feedback that I’ll repeat here for the purposes of discussion:

I would prefer the only hard requirements for nominees (SHALL include) being:
Alignment statement/Why they would fit the role & Conflict of interest statement.
Which if not provided, they are removed from consideration.

With other information being optional, (MAY include):
Past Contributions to Rocketpool.
As much or as little of their background or who they are as they wish to share.

Though admittedly having more optional info makes the various nominee data more difficult to organise & compare.

Being wary of creating any default expectation of revealing ones identity I would favour avoiding terms like ‘identity statement’ or ‘verification’ as much as is possible.
Obviously I’m against any fixed or minimum requirements in this area.

The Metrics on nominee activity while useful, should be provided as is - without comment and with no subjective overall scoring.

For Membership Selection both the suggested method or Alternative B are fine, I don’t think the amount of votes required in Alternate A is workable.

The advantage of the suggested method is simplicity in voting and the veto power allowing you to strongly disagree with the inclusion of a particular candidate.
The advantage of Alternative B is that it allows you to more strongly support specific candidates over ones you are indifferent to.

I’m leaning towards Alternative B primarily because I’ve seen it in practical use and it seems to work quite well, there is certainly more potential for gaming involved but I don’t necessarily see that a disqualifying factor.
For reference, Alt B style is used by the Lyra protocol for their committee votes, example: Snapshot

2 Likes
3

Great suggestion, thank you for posting! As written, I believe it is a straight improvement to RPIP-10, even if I would prefer to go further for security purposes.

In general, I agree with @Uisce’s assessment of Alternative B for membership selection, but I’ll add my own commentary. For one, It’s easiest for voters to understand. I also think that the veto vote in the original suggestion, while a great idea in theory, is practically limited since I’d expect people to just vote for the ones they like and not care enough to veto anyone in most cases. Or in the opposite, if the political climate were to become terribly corrupted (e.g. USA right now), people would end up just vetoing the ones they dislike the most and not voting in favor of anyone.

@Valdorff One thing that isn’t specified in any of these Membership Selection options, though, is an answer to this question: “What happens when some amount of candidates are approved, but not enough to form a full committee?” Do we consider that a tie? I don’t think that works because it would be bad if 3 members are voted in, the rest are vetoed, yet some of those vetoed candidates are still randomly selected into the MC anyway.

Re: expedited procedure, I don’t believe it’s necessary since the pDAO guardian can already effectively “freeze” a MC’s access to funds. I propose that if this happens, the pDAO guardian publishes a statement on its reasoning and a new election may be triggered.

Re: @Uisce’s feelings on reporting requirements:

Being wary of creating any default expectation of revealing ones identity I would favour avoiding terms like ‘identity statement’ or ‘verification’ as much as is possible.

My view is that more information on candidates means more informed voters, and that it’s up to individuals to assess their own feelings on each candidate application. This is not incompatible with your suggestion to include optional information, but it’s reasonable to include any information omitted in the candidate’s application. E.g.:

Candidate 1: Alice

Alignment statement:
I am aligned with RP because I’m a NO, and I will vote in favor of NOs at the expense of rETH holders if necessary.
Conflict statement:
I own some LDO because I want to diversify my holdings, but I am not, nor am I associated with a Lido validator, and I don’t participate in Lido governance in any way.
Past contributions to Rocket Pool:
Declined to provide
Identity statement:
Declined to provide

1 Like
4

It says “If this results in insufficient nominees to fill the spots, the Management Committee Selection process fails and must be restarted from the beginning.”

Possible options would be to get different nominees, change the target committee size, or convince folks more nominees make sense before recreating a similar vote.

I personally like this too, but I understand @Uisce’s point that this does create an “expectation” by having a required category.

5

It says “If this results in insufficient nominees to fill the spots, the Management Committee Selection process fails and must be restarted from the beginning.”

Good point, thanks for pointing it out. I must have missed that!

I personally like this too, but I understand @Uisce’s point that this does create an “expectation” by having a required category.

I disagree that it creates expectations. If we’re going with the idea that it’s a voter’s personal responsibility in determining what trade-offs matter, we should show as much information as possible, including any areas where there is nothing provided.

6

Hi folks,

I put up a PR for this: Add management committee selection section by Valdorff · Pull Request #23 · rocket-pool/RPIPs · GitHub

I removed the expedited section and used Alternative B for the membership selection component. The rest of the text is as in the original post.

Re identity text: I went with my own initial variant since the community response was (A) not large and (B) mixed.

  • Support moving this to vote
  • Not ready for vote (and please reply about why)

0 voters

1 Like
7

EDIT: this is not applicable to this RPIP in particular, see below

@Valdorff you submitted this as a PR on RPIP-10 but Finalized RPIPs aren’t supposed to be changed this way.

I believe the correct way to do this is to write an entirely new RPIP, including all the required sections like “Motivation”, etc.

For the “Implementation” section, I suggest you write something like “RPIP-10 SHALL be amended to add the following text on line X.” If this is voted in, we could edit in the new text to RPIP-10 at that point with a note that this section was added via RPIP-X.

After this I would be comfortable bringing it to a vote if there’s enough positive sentiment.

8

RPIP-10 is marked as Living rather than Final and has text describing update procedure.

1 Like
9

Thank you for the correction. I forgot that RPIP-10 had its own change language. Will update my post above.

10

Very minor but, in the Nominee information sharing section it says:

If this is not provided, the nominee shall be removed from consideration.

It is not clear if it refers to the last piece of information, the contribution statement, or all the pieces of information in the section. Supposing it is the later, I would say “If these are not provided”.

1 Like
11

Good thought, going with “If any of the above four statements is not provided,”

12

This is somewhat beyond “selection”, so food for thought for the next iteration, but RPIP-10 states:

  • The pDAO MAY vote to change the membership of the MC at any time.
  • There SHOULD be a pDAO review of MC membership within 6 months of the MC’s creation.

Without a term of office/sunsetting, the default for these committees will be lifetime membership. Which is generally ok. What I’m concerned about is the conflict that will arise should there be discontent about the direction of the MC. Essentially, the only way to change the membership is for prominent community members to campaign to remove specific prominent community members, which risks creating huge rifts in a small community. My feeling is that, in the absence of a specific term, an affirmative “vote of confidence” should be performed yearly or so by default; if it fails (either by quorum or by “no” votes) then a fresh committee selection would happen.

Agree with nixing the expedited section. Thanks for the excellent work!

13

Minor addition:

This process SHALL be followed when committees are newly formed, as well as when all or part of a
committee’s membership is to be replaced (eg, due to term limits or a vote).

That’s just going below the header and before the bullets. The key item I wanted to make sure I touched was that we can do partial membership changes. That would actually be my preference in most cases since slow and stable tend to be go together.

@epineph
Note that individual MC’s can have extra stuff like sunsetting in their charters. I’m conceptually cool with affirming votes, though I’ll note my limited prior exposure to them was simply a yearly rubber stamp. My preference here would be to leave it as is for now and see how it goes - we can add such layers as we see fit in the future.

14

Am I missing something, or does this create an incentive to simply use all your voting power as veto, since it’s counted double?

Edit: I believe we’ve created a Nash equilibrium where committees can’t be formed. A rational agent will spend all their voting power in the most effective way possible, which is vetoing. Final support levels will all subsequently be negative and the process will restart.

15

I don’t think the veto idea made it to the RPIP in the end

16

that looks to be correct, danke