Suggestion / Discussion : Everest credibility system

[Web3Slimchance]

Regarding Everest: Voting power is based on how long the projects you own have been part of the registry. If you create an entry for someone else's project, and they claim that project, you loose the ability to leverage that credibility.

I think this credibility system has a few flaws. We want Everest contributors to contact developers to have them claim their projects. However, in doing so, they loose their voting power.

[itsjerryokolo]

I agree. I want developers to claim their projects but I don't really see developers actively managing or maintaining the quality of the registry. I would like it, if project owners or Everest contributors who initially created those projects, as long as those projects remain in the registry, still have the ability to challenge future projects. My concern with the current model is that developers would just claim and forget about the registry.

[Vseb]

Agree, the creator/ contributor on the project could keep voting power if the project is transferred. Even if this is calculated for the limited time he had the project under his responsibility. That to avoid accruing extensive voting power just because you created a project 5 years ago and did nothing about it for the most part of it.

[koen84]

I have pretty much the opposite opinion. Your voting rights are "borrowed" against a project you might have nothing to do with. As such i'm not even convinced non-representative project creators should have voting rights to begin with.

If anything, i'm much more concerned about someone submitting in a project's stead might stop caring that the project itself making sure everything stays up to date. Projects are also more than a lone dev.

IMHO web3 is about the commons, what's best collectively.

[Web3Slimchance]

I have pretty much the opposite opinion. Your voting rights are "borrowed" against a project you might have nothing to do with. As such i'm not even convinced non-representative project creators should have voting rights to begin with.

If anything, i'm much more concerned about someone submitting in a project's stead might stop caring that the project itself making sure everything stays up to date. Projects are also more than a lone dev.

IMHO web3 is about the commons, what's best collectively.

First of all - I absolutely agree with the your sentiment - web3 is about the open, the shared, the collective. However, I don't see these kind of registries being maintained by just devs. Instead I see a group of idealists (or opportunists, if we further develop economic incentives).

However, I would much rather have the voting power in the hand of non-biased idealists that are working on a ton of different projects. Imagine a system like wikipedia or an open source project, where the most experienced and idealistic indviduals had no actual say in decisions.

How about a system where you could vote on behalf of yourself as a contributor as well ?

[itsjerryokolo]

I have pretty much the opposite opinion. Your voting rights are "borrowed" against a project you might have nothing to do with. As such i'm not even convinced non-representative project creators should have voting rights to begin with.

If anything, i'm much more concerned about someone submitting in a project's stead might stop caring that the project itself making sure everything stays up to date. Projects are also more than a lone dev.

IMHO web3 is about the commons, what's best collectively.

I think there are merits on whatever side you lean on. I see how this could easily get political. On one side a person is contributing to the greater good of the community because there's a 'reward' at the end of it for their efforts. It doesn't necessarily have to be monetary reward. Reward could be the ability to still challenge future projects. On the other side, a personal could be contributing because they are being selfless. They want no reward for their efforts. Perhaps they find fulfillment in selflessness. IMO for this to work, there should be a bit of both.

[koen84]

To link my related but different concern #143 It's also part of my argumentation on the discussion here.

Other than that, i reckognise valid arguments being made (just not sure i'm convinced).

[yanivtal]

This is a really great discussion. The current solution of basing reputation solely based on length on the registry and having it reset upon transferring is fairly arbitrary though directionally correct. I think this idea of having reputation for skills is extremely powerful and important. In this case, the skill in question is: project curation.

Many reputation systems have been proposed with various levels of complexity. I agree that having created a good project listing in the past should count toward your reputation even if you transfer ownership. There are lots of actions that could count toward or subtract from a reputation. Mostly the bottleneck comes down to computational constraints so heuristics and simplifications may be valuable. I would love to see someone analyze this further and propose an alternate reputation scheme. We could pilot it on a different registry and see how the outcome compares.

[koen84]

If the ideal goal is for project team members to be in control of their spot on Everest, i'm still questioning if incentivising the lister is a useful path at least in the current form, seeing i noticed 2 projects being taken aback by a "pre-emptive" listing. Even more because 1; the rights it garners they might not be inclined to attempt getting the respective team on board and 2. transfer might not happen e.g. if the original lister doesn't catch the request for any whichever reason.

If it remains important to reward "evangelising" Everest to projects, maybe a reflink would be better ? Maybe it can even be some sort of "suggestion link" where there's a placeholder project submission and the link would allow the project team to take direct control without the OP needing to sing off on it ?

[itsjerryokolo]

I think having roles works for everybody, the same way we have roles in The Graph network. There could be for instance a Developer Rep and several rules on what they can and cannot do. It could be that the role of a Dev Rep is to only create, update their projects and challenge projects. -Everest Contributors could have the ability to challenge projects but only when they are initiated by a Dev Rep or multiple Dev Reps to prevent competitive takedowns by Projects. -Onboarders - Onboarders could have the ability to use reflinks as @koen84 stated above to onboard Dev Reps so they can list their project themselves. This will also be subject to approval from Project Approvers. -Project Approvers - They could be the ones who approve new projects created by Dev Rep and make sure that a true team member created it.

If Everest Contributors have the ability to add projects, there could be a tag on top the project that clearly states that this was created by an Everest Contributor. Projects like this can be elevated to Developer status if the contributor can prove to Project Approvers that the transfer of the project is being claimed by a true Dev Rep. Perhaps a time delay before Approval. If this is a problem, the Dev Rep can create a new listing and then the 'contributed project' will be replaced by Project Approvers.

These are just roles I could think of while I'm typing this. If there are more ways to make these roles efficient, that's great. How we go about adding incentives to these roles is open for discussion. Participants could have the option to opt out from incentives if they don't want it.

Roles + Role Rules + Incentives; that's how I think this is going to work. If these things are out of balance, then it's the wild west.

1. People will challenge legitimate projects for their own interest (This is already happening)
2. People won't care about spending their time on Everest because there's no incentive. I guess, some people will but then that's not truly inclusive.