PIP-8: Use Coordinape for Contributor & Voter Onboarding

Attributes

Summary

Currently there is only one class of stakeholder (Voter) in the DAO and it is pretty high-friction to enter. Becoming a Voter requires completing a series of quests to level up and verifying their identity on BrightID. The level of friction involved is undermining the engagement of contributors in our community. I am therefore proposing that we recognize a new class of stakeholder (Contributor), which would be easier to enter, and would be a stepping stone to becoming a Voter. This would be administered through Coordinape.

Motivation

The key motivation behind this proposal is to maximize the engagement of community contributors by minimizing friction.

Specification & Rationale

New Contributor Onboarding Path

The path to becoming an official Contributor will be Coordinape’s vouching system.

Any existing Contributors will be able to nominate new Contributors along with a reason. Then a 14 day period will begin in which other Contributors will be able to vouch for the nominee. If the nominee gets 3 vouches, they’ll be an official Contributor.

This should be pretty low friction compared to our other onboarding paths because it allows members of the Coordinape Gift Circle to use their own discretion, rather than being a set of rigid rules like the quest and BrightID verification system.

Adjusted Voter Onboarding Path

The highest source of friction in the Voter onboarding path is currently BrightID, due to it being a pretty arbitrary black box that gives no feedback on what needs to be done to achieve verification. Verification is determined by sponsorship from an app and connections with a minimum number of people depending on their score in the BrightID social graph, where the score is determined by how close they are to the center of the graph. However, BrightID is another community that we don’t have much overlap with, which makes it difficult for our community to verify each other.

The Coordinape Gift Circle is also a social graph in a sense, except it is a social graph with only Pocket Network community members. In addition, vouching for a nominee can include assessing whether said nominee is a unique person. Therefore it is my belief that Coordinape could replace BrightID in the Voter onboarding path.

If someone is vouched into official Contributor status, and they get qualified by completing the quests, then they’d be eligible to claim their vote. In this way, becoming a Contributor is a more direct stepping stone to becoming a Voter.

Dissenting Opinions

TBD

Viability

Coordinape is very easy to use and works out of the box. Currently the Contributor role will have to be manually assigned after successful nominations but the Coordinape devs are receptive to the idea of updating their bot to auto-assign a role when someone new enters the Coorodinape Gift Circle.

Implementation

If this proposal is approved:

  • I will add all existing Voters to the Coordinape Gift Circle, who will then be able to nominate new Contributors.
  • The Contributor role in Discord will be manually assigned by me when new people are inducted into the Coordinape Gift Circle
  • BrightID will be removed from the Voter onboarding path and replaced with the Coordinape Contributor role

Copyright

Copyright and related rights waived via CC0.

1 Like

I love this idea but I would passionately suggest the following.

Value our Values.

Instead of attempting to build a reputation/reward system based on the estimated value of an output, we should instead think of how to align the “way we work” and value that.

Risks of output based merit.

  • flashier stuff gets valued more
  • complex contributes limits the ability for others to fairly value
  • timing matters, if the SME’s are busy or if there are parallel workstreams that need someone’s limited attention, it is not valued the way one believes it should be.

All of these things lead to an inaccurate estimation of the value of our social network and run a high risk of a political climate that is more about campaigning to the invisible power structures then it is about collaborating for the common good.

Values in an organization are already established for the purpose of aligning around “the way we work”

My fundamental assumption for putting this forward is this.

“If the values are comprehensive and widely acceptable, then valuing them at the core of a rewards system will not only create the outputs we believe will result in a better ecosystem and product(s), but also the culture that will give it sustainability.”

I believe valuing the values will do the following.

  • Allow the majority of contributors to fairly determine the merit of a given work
  • Minimize the political/output driven evaluations and there risks.
  • Create and environment where values are always at the top of the conversation which in the long run will make the culture outputs more sustainable and autonomous.
    - does there need to be more documentation/explanations?
    - do some need to be made more clear, added or removed?

It keeps the most important aspect of a community “culture” the top of mind, because people’s rewards depend on it.

What would be needed.

Exercise with the values as they exist to see what aspects need to be reworked, removed, added, or additional education (examples, documentation, etc) to see.

Dissenting Opinions

The values as the are described now won’t work

Excellent, sounds like our new growing community should do an exercise to iterate on them in a way that makes them able to be demonstrated in a merit system.

Demonstration of the values does not account for domain expertise

This may be true, but a community rewards system does not need to solve for this.

We have other mechanisms that are better suited for that anyway, the DAO proposal system and VC funding are two examples. What a community rewards system should optimize for is decentralized autonomous organization, literally. You do this by focusing on “how we work” not “what we work on and how hard we believe it is to get done.”

You can see in the language of output driven rewards system that it will inherently create separations, and classism.

I would also add the values can be described in a way that is inclusive of difficulty or expertise required. For example some the concept/elaborations around a value like “relevancy” focuses contributions and their subsequent rewards throughout time.

Interpreting the demonstration of a value is more subjective then an output.

I believe this is a risk if the language, context, education and support that exists anyway, but the sbutle beauty of using the values in this way is that it is a forcing function to make them explicit enough to be widely accepted.

I would also argue that is possible to make there demonstration more objective, using “remove dependencies for others” as an example we can refine that language and context to result in a culture where every contribution is documented, curated into single sources of truth and embedded into our commons channels such that new people do not need to start from scratch and take others time.

Using ROSE bot as an example. you could say “rose bot took X amount of time to set up and required these skills therefore it is worth Y” which is very zero-sum gamey.

Or you could say “Rose bot enabled community members to rapidly onboard and educate new members on the most common questions, as a result saving the core team hours a week which they can spend on providing deeper compounding value to the community”

Which is more valuable? The skills it takes to set up a bot, or the empowerment of others because of it?

In conclusion

They’re called Values for a reason, Value them.

Pocket’s values currently.

1 Like

I conditionally support this proposal.

I read through the Coordinapes docs several times trying to find the answers to my question, but could not. I love the ease of use spelled out, I love the social graph aspect, and I love the vouching system, which I think can be a useful replacement for BrightID, driven by participation in our community versus participation in theirs.

Here are my questions:

  1. I don’t see any mention of the usage of the Coordinapes GIVE token, which is used for token distribution at the end of each Epoch. Does this proposal intend to be a precursor for usage of that system? If so, it raises a number of other questions regarding distribution models that may or may not be appropriate here.

  2. If the answer to item 1 is yes, can Coordinape be configured in such a way that it would distribute pokt via a network transaction versus an ETH based token via Metamask?

There are a number of points in here that merit discussion, and you touch (in spirit) on some of the things I outlined in my comment on PEP-16. Given that the scope of this proposal seems focused on the vouching and onboarding system, whereas PEP-16 focuses on the actual Contributor model, would you be willing to move (or copy) this comment there, so we can keep the concerns regarding distribution all in one place?

1 Like

I think this proposal works for where we are now and the issues we need to address with our current on-boarding.

Just like we are tweaking our DAO on-boarding now, we can grow and change as the needs arise.

Most important right now is to have a DAO that people can understand and there is a clear path. Right now we struggle in these areas. This much more approachable right now, but will no doubt require optimizing in the future.

1 Like