MGRC Diversity

zecretary · September 23, 2020, 8:48am

Thank you for your reply. My views on this remain as stated above.

It’s expected that technical people will reach for technical answers first or lean on their relative importance. I’ll spare everyone all the plant root analogies but you know where that’s leading…

I hope there are better voting methodologies, but that’s reaching for the technical salve to a people ailment. I wish everyone the best of luck constructing a truly fair & bias-preventing voting mechanism. If you do, it will be the first in all of humanity.

I just hope going down the “better voting” rabbit hole of technical comfort zone does not distract from the larger amount of DEI work to be done, which will have far more impact in achieving the stated mission of the project, than a singular internal voting procedure.

At a certain point, if you want a billion users, it needs to start actually being about them & not the internal that has been the focus thus far. The more this group centers themselves in the discussions & solutions, the further the project moves from serving its stated mission.

zecretary · September 23, 2020, 8:55am

Thank you for taking this to heart & for the quote help

KeepECC · September 23, 2020, 7:03pm

Voting based on merit, simple and effective. Good post.

jmsjsph · September 24, 2020, 8:02am

I don’t think that is true! Could be intent… bad for some, good for others Helios - Helios v3 Verification Specs
Helios - Helios v4

I am still wondering this, too

jmsjsph · September 24, 2020, 1:03pm

That one seemingly-innocuous change helped filter the most well-connected to the top with each additional vote, whether or not they were in each voter’s top 5.

Perhaps it was the plan all along…

I will let community decide what to do with this information. According to Zcash Protocol Hangout Major Grants Review Committee Q&A 2020-08-18, you just need to say the magic words!

tromer · September 24, 2020, 2:06pm

My 2 cents:

I strongly agree with the wish for MGRC diversity, along many axes, including: demographic (geography, gender, cultural, socioeconomic), different stakeholder’s perspective, and different expertise. We clearly did not do well enough on some of these.

I agree that, especially when the candidate pool is biased, approval voting can preserve or amplify this bias even against everyone’s wishes, as @holmesworcester crisply illustrated.

Moreover, echoing @mistfpga’s sentiments: in approval voting I would not vote against a highly qualified candidate just because he happens to be “yet another Western white male”. Approval voting encourages us to put candidates’ personal merit, and our abhorrence of personal discrimination on the basis of factors beyond the candidate’s control, first and foremost. This can indeed amplify the bias in the resulting group representation.

As for @zecretary’s “the thing speaks for itself” view: this is nuanced. Surely we have path-dependence here, where the community’s “established” demographies are over-represented in the MGRC. However, attributing this to machinations by “groups in power who directly benefit from maintaining the status quo” ignores the following simpler explanation for the observed outcome:

We had many candidates who could bring diversity (as e.g. @aristarchus pointed out), but the fact of the matter is that most/all of them are very new. So new that their MGRC candidacy announcement was their first post in this forum, and typically their first significant involvement in the Zcash ecosystem. Personally, I found it difficult to vote for someone who has an impressive CV, without also having a solid assessment of their character and conduct. Some made superb appearances on the community calls and in forum posts over the last few weeks/months, but I simply haven’t observed them acting and interacting long enough to entrust them with the Dev Fund’s many millions of dollars — yet. I heard similar sentiments from others.

The good news is that this part of path-dependence is easily solved: time will heal it. As these candidates remain active and constructive within the Zcash community (which I see some of them already doing), they will build up community’s confidence in them, and “check this box” too, making them very strong candidates for the next round.

(To be abundantly frank, there are also candidates that looked good on paper, but their reaction to not being elected made me happy that I didn’t place premature trust.)

Last but most actionable: I think @zooko made an excellent point that staggering the MGRC replacement would be simple and effective way to achieve more nuanced community control over the MGRC’s composition, and is desirable for other reasons anyway (namely, preservation of knowledge and working dynamics). We should let the inaugural MGRC find its footing first, but I tentatively support a future ZIP amendment that staggers the MGRC membership.

str4d · September 24, 2020, 2:12pm

The blog post that specified approval voting was published before Josh made that comment (blog post was April 15th, comment was May 14th), and approval voting was mentioned in several other ZF blog posts (August 21st, September 2nd). I interpret that as Josh mis-remembering the process in his comment.

holmesworcester · September 24, 2020, 2:16pm

I agree that this is worth trying, as a way to address diversity, but I think there will be objections to it if some members are serving a lot longer without a chance to be voted out than folks expected due to this change.

I know @zooko you think this is a benefit, but I’m not sure. I think in order to get an engaged and informed ZCAP it’s better to err on the side of giving them a lot of power to change the committee if they wish to.

What are some good proposals for staggering that wouldn’t significantly increase the time people are spending on the committee without having to be re-elected? Could the ZCAP vote once a quarter?

jmsjsph · September 24, 2020, 2:28pm

Unless I’m mistaken, the blog post says PICK 5 (not ALL approved of). (Am I to assume approval means Pick N despite calls for five? No, I don’t think so - otherwise helios wouldn’t have option for aforementioned pick 5 approval vote)

If so, without public discussion that acknowledged the change from pick 5 to most pop, then we must acknowledge video which suggests discussions were made “backroom”.

The “fire alarm” Nate, Miers discussed is for this very purpose, to preserve the institutions that promise, in this case, decentralization/diversification of funding decisions (assuming that is what was called for). We all admit that was not really achieved.

It is fascinating that the conversation keeps moving back towards entrenching incumbents with term limits.

If the mechanism and process was mismanaged - We should be talking about 1. Fixing it, 2. Preventing it. So, expand the ZCAP, first and foremost, to prevent this, especially before voting to entrench incumbents after a potentially faulty vote

str4d · September 24, 2020, 2:47pm

“Select (approve) any number of candidates from the list” is the definition of approval voting, yes.
“Select 1 candidate from the list” is plurality voting.
“Select at most 5 from the list” is somewhere in between, but with 18 candidates it is definitely closer to plurality voting than approval voting.

I can see how the text in the first blog post could be read as either “approval voting to find 5 members from the candidates” or “approval-ish voting for at most 5 candidates”. I read it as the former, but you’d have to ask ZF what was intended.

jmsjsph · September 24, 2020, 2:52pm

Besides, this helios reference code considers the voting type to be “Approval” and enables its max factor to be set to any number including 5.

That should settle it: election didn’t go according to plan.

No intent needs to be prescribed, unless we fail to fix it (and, worse, rub it in!)

mistfpga · September 24, 2020, 3:48pm

You are completely right, I answered my own question in the post. It seems not only timezone confuse me but also month of the year… sorry mate.

sarahjamielewis · September 24, 2020, 4:49pm

On the wider point:

There is already a wealth of academic consideration to the topic of approval voting with multi-winner elections, proposing a variety scoring strategies that take into account diversity metrics and the overall approval rating of the combined committee (e.g. see https://sci-hub.se/https://link.springer.com/chapter/10.1007/978-3-642-02839-7_6 for a summary survey of different approaches). I’d strongly caution against constructing an ad-hoc solution.

Every voting system has trade-offs, and moving from Simple Approval scoring to something more complex needs an actual formal analysis of the tradeoffs as they apply to the MGRC and the CAP - otherwise we risk introducing more bias (and strategic voting) into the process instead of less. (e.g. voting twice with or without a cut-off introduces a variety of strategic options for voters, some of them might increase the diversity of the committee, many of them will act against it).

On specific remedies:

I would put forward version of Net Approval scoring (coupled with the option of adding more seats to the MGRC, such that we add candidates if they would increase the overall approval of the committee) or maybe even Monroe Approval Voting (if there really is a community-wide assumption that candidates are represented by pools of voters e.g. ZF, ECC, Miners etc. then we can use MAV to ensure the committee is fairly represented). I don’t expect the discussion of what those pools should actually be to be a short or necessarily a fruitful one.

There is enough diversity of opinion in this forum that there will be strong, valid critique to practically any scoring scheme other than Simple Approval, but it is an analysis worth doing - and worth doing properly.

On CAP expansion:

Should the CAP be expanded? Absolutely, if only for the goal of decentralizing the ecosystem further. But larger voting pools are not correlated with more diverse elects (do I really need to provide citations for this?) - Diverse committees are a function of the candidate pool and the voting mechanism above all else.

On the candidate pool in this specific election:

I’ll echo @tromer and say that the current results well explained by the fact that many of the candidates were not part of the community prior to announcing their candidacy. That was certainly a consideration I made. Even with that consideration, the most-approved top 10 were diverse by almost every metric - which says something about the priorities of the community at-large.

There was also clearly a bias against pseudonymous accounts who had the disadvantage of running on a platform where they couldn’t publicly corroborate some or all of their relevant experience (that one is a much harder one to resolve going forward).

On 5/N v.s. n/N:

Regardless of the original intention of the blog posts v.s. tweets. v.s. what actually happened on Helios I’m of the opinion that n/N resulted it a more diverse approval ranking than 5/N would have.

@jmsjsph, you are going to need to provide some actual math that 5/N vs. n/N would provide a “better” outcome.

Going back to this specific election, no one candidate got more than 70% approval, and there was quite a significant difference between Shawn (69%) and Chris (56%) - zooming out further, approval ratings drop pretty quickly.

Based on the observed results it seems self-evident that 5/N voting would have likely resulted in at least 4/5 top candidates winning (I’d expect ECCs DC to have done slightly better under that model, and some turbulence among the top 5 so there is some room there).

While it is certainly a valid instantiation of approval voting to restrict the number of candidates a person can vote for, the exact number does have ramifications and they are not always going to be aligned with your stated goals - and thus they need analysis.

Specific quibbles:

@jmsjsph, I’m not sure why you’ve listed my industry as Fintech -and more so from that what you think it is that I actually do- but regardless I don’t think that’s a accurate categorization. The short code for Canada is CA, not CN (that would be China).

On to funding sources - if you are going to start stretching to second and third degree relationships (e.g. Hudson → EC → Least Authority → ECC) then I’ve got some really bad news for you about social graphs.

jmsjsph · September 24, 2020, 5:52pm

With only 5 votes, maximum, each vote becomes more valuable to each voter. They are more likely to assign them carefully.

Obviously each vote is less valuable when there are 19 vs 5, all else equal.

With as many picks as one wants, voter may be less likely to discern between candidates and succumb to preconceived biases (Zooko said campaign extended for months, some people wished to vote after spending hours reading, voters may have felt rushed, etc)

The real question is,

Why didn’t we follow the intended voting mechanism? This is a failure of governance. Are we going to turn a blind eye to this for the sake of political expediency?

Human-error, bias. I’ll fix it for transparency and accountability!

Very sharp distinction between well-connected/pre-funded candidates and newcomers that deserve a fairer shot.

With immediate and relentless push to extend term limits despite self-inflicted governance failure, I would not be surprised if this is all theater to ensure a well-timed red carpet is rolled out for a hidden product roadmap (Numerai Treasury Management? Balancer zUSD?)

(Which is fine, I guess. Disheartening for decentralization. If no one else wants to ring the alarm, I won’t! Some talked about impeaching committee members during candidate calls! Bring that same energy!)

Shawn · September 24, 2020, 8:17pm

3 posts were merged into a new topic: Voting Mechanisms

jmsjsph · September 24, 2020, 8:20pm

… out of the pool of candidates.

The pool of candidates = N.

The prescription is quite clear. We deviated from what was prescribed and without any reasoning or public discussion as to why.

Whether its incompetence or foul play, we should not be willing to change the voting mechanism without due process.

We should not accept the results of an experiment if it was not conducted appropriately, and we should not use those results as the initial conditions from which to extend and entrench decision-making for years.

So, the voting mechanism was clearly changed yet we are to assume it was done so accidentally? Why did it change?

If there is a reason for the change, reference it.
If there isn’t, we failed the protocol.

AFAIK, the change happened behind-the-scenes. Ring the alarm.

@moderator, please keep my replies in MGRC Diversity thread as I am concerned the voting mechanism was co-opted to favor insiders

Shawn · September 25, 2020, 3:37pm

5 posts were merged into an existing topic: Discussion about approval voting with unrestricted votes

Shawn · September 25, 2020, 3:36pm

I agree the Diversity thread has been overtaken by the voting mechanism/methods. I will move these to the more recent thread so this one can get back to “Diversity”

@jmsjsph please feel free to continue the conversation in the other thread.

All, please post discussion about this elections “Voting Mechanics” in this thread:

To keep this thread on topic.

sgp · September 25, 2020, 11:22pm

This is obviously a complex topic. I think there are several things at play here:

There is one set of voters
All candidates were being selected at once
Little diversity overall in open source projects, cryptocurrencies, etc.
Systemic biases in voting

That’s like asking for a full popular vote in the US for all representatives. Instead of some representatives being more similar to the district they live in, you would instead have representatives that are more “average” across the board.

Some ways to encourage diversity may be the following:

Try to divide the MGRC into voting groups. Say miners are considered important enough to select one board member, ZEC holders another board member, etc. This is super difficult to do in practice. In most public elections, we do this roughly by population, though of course humans mess with gerrymandering. No matter how this is done, it’s sadly bound to be political. Asking, say, the Zcash Foundation to “gerrymander” the voting blocks could be problematic, even if they have the best intentions.
Vote board positions in stages. It makes sense that the initial board needed to be elected at once. However, it’s easier to get a good picture of what the diversity of the board will look like if we vote for one person at a time. If voters see all of the other members are similar, they can prioritize voting for more diverse candidates. Voters selecting many options at once don’t really have a good understanding of what the actual diversity will look like before it’s too late. While in theory it would be possible for the voters to all select candidates a certain way, it’s easier to notice shortcomings in practice when voting for fewer candidates at a time.

I think the simplest thing to do is to vote for fewer candidates at the same time, though that alone doesn’t address the entire issue. Drastic other changes may be a good idea but they should be considered carefully.

john-light · September 28, 2020, 12:41am

Chiming in with my 2 zats as a voter, in case the feedback is useful for future iterations: I like the voting method used (approval voting) and am happy with the vote result. I myself made it a point to tailor my own voting selections to the best cross-section of “skills/experience/diversity” and picked all candidates that I felt were at the top of those criteria. When it came to the diversity category, I simply made sure not to weight my ballot too heavily toward any one gender/nationality/ethnicity/professional background.

Although the final vote result doesn’t reflect my ballot perfectly, many of the winners were those I voted for, and overall I’m happy with the results. I think this MGRC will be a great group to bootstrap and lead us through the first term.

To the question of how we can get more diverse outcomes in the future, that’s a tough question to answer. I think it depends not only on the voting method used but how voters themselves are voting. Are they voting with diversity in mind? Simply choosing all of the candidates they feel are most qualified without regard for diversity? Some other way? Although we can control the voting method we cannot control how voters decide to vote.

One idea I have that might not necessarily help with diversity directly (depending on how you’re defining diversity) but moreso with representation more broadly would be to have “chairs” dedicated to specific community segments on the MGRC. There could be chairs to represent different segments of the community we deem important: a “mining chair”, a “protocol dev” chair, an “app dev” chair, a “HODLer chair”, a “daily spender” chair, a “global south” chair, etc, and candidates would choose which chair to run for. Then voters could evaluate which candidates are most qualified for each chair. While this wouldn’t necessarily guarantee that we don’t end up with a mostly-white-male MGRC it would at least force voters to think about candidates categorically rather than all as one big group to select from, and would also increase the likelihood that the winners are each bringing a unique perspective to the table. (Coincidentally, I think the results of this vote kind of turned out like this anyways, which is one reason I’m happy with the results!)