What are the requirements to receive the member badge? We would probably want to make sure that they are not too arbitrary and actually encourage productive participation.
The requirements are very reasonable. I believe all our Core, Sokol members as long as known candidates already earned this badge.
Where exactly did this (this list for trust levels badges - is this from the forum software) come from?
Honestly, I don’t like this due to personal experiences. My fellow professors, those doing online classes, have very similar participation ideas. What happens is one of two routes:
- The quality of posts / interactions drops (eg: need to post 100 words a week - you get 100 words about how great everyone is…)
- It get outsourced
About #2 - there are literally companies that will log on and ‘participate’ for you. I’ve got students that show me these services - and I’m impressed. I don’t think this will happen here - but I’m always sensitive to the behavior(s) that I’m incentivizing.
I think badges as a gamification tool have limited usefulness - unless they are highly targeted and dialed in. I really think that participation needs to be seen through a critical eye (I love control charting personally) but I don’t really think there’s a good way to objectively measure this stuff.
@henryvishnevsky, I agree that these requirements seem reasonable.
@Marat, I envision a three step process with the following requirements:
- Submit introduction in Validator Intro section.
- Actively participate on the forums (achieve trust level 2/member badge, thanks for suggestion Henry!).
- Make a contribution to the project such as participate in Github activity, actively assist with test scenarios and DApp testing, contribute DApp ideas, propose governance solutions, assist community in Telegram and on forums, etc.
- Notary License.
- Be accepted to Sokol via governance process by Sokol Validators.
- Meet Sokol Requirements.
- Successfully ran Sokol node (low downtime, timely updates, etc.).
- Active participation in both onchain (voting) and offchain (biweekly calls) governance procedures.
- Be accepted to Core via governance process by Core Validators.
Basically very similar to what you proposed, just categorized a bit differently.
Hi Jeff, to see your badges you can click on the “hamburger” icon next to your picture in the top right corner and select badges.
As for the quote above, we all read the forum and can determine if the candidate just typed some random characters to earn the badge. I envisioned this objective metric of level of involvement to be on the list with other on-boarding requirements like notary license, sharing identity, participating in the calls and telegram channels etc. After the person met all of the above we will still discuss the candidacy and ultimately vote. I believe majority of us will be able to detect if the person really participated or just outsourced the work.
Just to be clear, these are not random strings - rather they have a combination of bots and human actors that post convincingly.
I just don’t want the noise from telegram to find itself here into the forums. I might be more inclined for posting == participation if there were between anti-spam tools ( removal of likes or a ‘cost’ associated. )
I was focused on just the “Testnet” for this post; however, I see that the discussion has come to include Core. So…
I’m concerned about the potential for Validators to get ‘friends’ on board, such that an oligopoly emerges. I’m of the opinion that all current Core Validators are required to sponsor one (1) new Core validator into the network by the end of year.
Before folks say…“didn’t you just say you’re worried about oligopolies…”
The Core network is 12 members. That’s rather small, if we all add one member - then we feel as if we had an equal voice in growing the network. We’ve also 2x the network size. Additionally, I believe that we must be completely responsible for this new member - ensuring that we understand the technical nuts and bolts; not having to rely on others/support staff (you really get to understand something when you have to explain it.) Sure - we can still vote on the new member per a list of requirements - but we all have to on board and vouch for one person.
I think at N=24, then the size would allow for on boarding completely new people.
I believe this is off topic. Lets create a separate topic and discuss it there.
Henry - agreed (you got my like) - Will you spin that discussion up?
Also - 1) what about my ideas RE: anti spam tools. I really don’t want the noise from telegram here.
- I think we need to also start talking about - ok, we’ve talked about this … now what?
I wanted to create a ballot the other day - only we have three possibilities (all having to do with key management). This might mean that we need to ask about getting the option to create more general purpose votes.
If someone were to make a proposal that would change either the Sokol or the Core onboarding procedures, should it be accompanied by a plan to accommodate everyone in the middle of the onboarding process that would be affected by these changes? It could be a grandfather clause for stricter procedures or an expedited process if requirements are loosened. What does everyone think?
I think I’d like to see a vote - any vote actually. We haven’t had this ‘type’ of vote yet…
We’ve had basically just a bunch of key management votes. Perhaps we need to see how a ‘vote’ like this ought to look like. We discussed this earlier in the year, we can brainstorm ideas as to how such a ballot might look like here.
POA Validators can only vote on-chain.
I’m not completely understanding your statement Henry.
Right now, a complex ballot does not exist. I suspect that such a ballot is hard to design for. Perhaps we can develop an informational sheet - one that clearly states a title (so that it can be ID’ed in the active ballots) and also containerizes important information. Information such as, where to locate discussions, a Pro/Con and Rebuttals (I’m thinking that this would be potentially from multiple people - as long as each statements’ author is ID’ed - even though in my mockup I’ve got myself and Sally Fields.)
If folks could look at the example and comment, I’ll generate V.0.2 later today… and we can comment/refine that to make v.0.3… etc…
I’m envisioning that this document would evolve during the deliberation period and then an individual would create the ballot. With a vote taking place on the POA Network proper.
At present, we sort of talk about stuff (here and there) and then someone creates a ballot (usually in the wee hours of Friday) that is somewhat lacking in high quality information. I don’t think this is business friendly in all honestly. We need to logically order and be able to find info/thinking so that an informed vote can take place. Maybe we can continue to or talk about design afresh?
What I meant is that we can certainly discuss things but we cannot vote and make changes to our constitution off-chain. I believe this is the idea behind the blockchain with on-chain governance.
Great. But what do you think about what I’m saying though - the need for designing a more complex ballot to allow us to put to rest this post in the future? ( By the way - I agree with you, and this was never in question). I’d like for us to move towards building something of value.
I feel compelled to state: we don’t have a constitution - we don’t even really have bylaws, playbooks, ISO9000, whatever you wish to call it.
Personally, I’m thinking that we need to move in this direction though. But that would be off topic (unless focused solely to on boarding to Sokol). Perhaps you could spin up that post.
If it was never in question, why the requirements for Sokol validator were changed without voting?
I would like to know that as well.
A Sokol validator never had to jump through any hoops / requirements.
However, what’s done is done. I think that we need to move forward in the interest of the group, so I’m willing to discuss this. Make no bones about it though, I’m of the opinion that a testnet is completely open - that’s a silicon valley lens, I know, and if the rest of the current group wants to limit validator membership… I suppose I’ll support reasonable limitations.
Again - limiting a testnet invites for a brittle system. But that’s just my two bits.
I disagree. The change was made without holding a vote and we cannot determine what is in the interest of the group without holding a vote on-chain. The change can be easily tracked on GitHub.
Just to be clear - we both agree that creating requirements for becoming a sokol validator broke the spirit and intent of the system? Furthermore:
Looking at the forum postings and wiki - it was seen that a mistake was made (and then corrected rather quickly - just wasn’t carried over to github’s wiki). Then people ran with it, telling others that this was ‘canon’.
My chief concerns are: 1) lack of critical thinking / reading completely of a forum post and 2) no one individual can nor should be allowed to make rules for others.
#1 is still on the table for me.
#2 not so much. I understand we are figuring things out, mistakes can happen. And even for the best of us, we must recognize that we haven’t the tools (yet) to come to consensus for ‘real’ topics. We have discussed rule for on boarding on Sokol (Only) - and I would like for us to now vote something in - so that we can move on.
However, we don’t even have a ballot designed / built / etc to do this function. We have three ballot types - all around key management basically.
So we need to design and get built such a tool. I’m suggesting that we table our concerns about what happened, and build these tools. Believe me, I’m really upset that we are adding limitations to Sokol Validator membership - but we need to move on. But I do appreciate how you’re feeling.
Posted Sokol requirements were seen as a mistake by whom? The GitHub wiki is the only place we clearly stated and published the requirements for Sokol and Core validators. The page remained unchanged for a long time until 12 validators were selected by MOC. We were given the project with the constitution and a set of rules and requirements we should strictly follow. All the changes we want to make to the constitution or the rules from this time on should be decided by on-chain vote. I believe this is very crucial to the project success.
Link to constitution please. We don’t have one (if you have a link - I’ll change my position)
As for the github wiki - this should not be used for the following reason: there is an issue to permissions resulting in a problem with people wishing to do a PR.
But more to the point - we do need to come up with tools to arrive at and solidify ‘rules’. But that is outside the scope of this post. If you could create that post and link here - that would be swell