@ALuhning Love the thoughts! Some ping-backs for you –
Success – you make good points about quantity vs quality/activity/uniqueness. I think good metrics do need to be a bit blunt to be useful but you always sacrifice something in the attempt.
I actually see Guild metrics as a progression where, at each step, we learn more about both the guilds and how to measure them.
For example, in the earliest days the metrics that interest me are indeed blunt:
- How many guilds are there?
- How many on-chain accounts are linked with each guild?
I don’t think this is a mistake because you have to start somewhere and bluntness is ok to begin with as long as you don’t get overconfident in the numbers. Crawl → walk → run.
Then, presumably (as you indicate), people will take advantage of this (if incentives are provided) and/or we’ll notice abnormalities in the data which help us better classify different guilds and/or we’ll notice that it’s too broad to accurately reflect behavior of “good” communities. Then the second round of metrics will probably need to classify guilds differently, perhaps subdividing into categories like {mass community (size matters), service guilds (quality matters)}.
Those categorizations also have to come back to first principles of “what actually makes this guild successful?” since they should really be grouped based on that – eg. a service guild may ultimately be like a consultancy and thus use something roughly like “billable hours” whereas a marketing guild might be “bounties earned” (from a third party, presumably, to avoid self-dealing). A developer guild could manage towards number of active developers (which we already measure but don’t correlate with guild memberships) or they could manage towards $NEAR earned via hackathon prize referral incentives. A BD guild could manage towards maximizing their referral fees for refer-and-earn for grants.
And we can also look more at what engagement actually means. I’d argue that, at the early/high-level stage, the halo provided by an “active, engaged account” should extend to any guild that account has chosen to associate itself with. For example, a developer actively creating an app and winning hackathon prizes should give “success juice” to the Dev Guild that they’re associated with via how that guild’s metrics are tracked, and that an account like that is worth much more than an account that is idle or just auto-retweeting things. Over time, we’ll be able to quantify that better.
Regardless of the way we sub-divide categories or classify engagement, my major point is that we should start by collecting the blunt metrics first and then interrogate the data to make better decisions about the specific metrics over time. It may mean that it over-glorifies Guilds that have low membership requirements to start with. As long as we know that, we can keep evolving the approach to be more specific. But, as experience tells me, trying to over-engineer such things up front leads to constipation and lack of shipping and lack of learning.
Global Onboarding vs Guild Onboarding
I’ll differentiate global onboarding from guild-specific onboarding because they’re two pretty different sides of the same problem. Global onboarding means everyone who touches the NEAR ecosystem (eg visiting near.org, using a NEAR-based app, watching a video on YT, retweeting a thing… whatever) ideally finds their way as quickly and easily as possible to joining a Guild since Guilds are a fantastic retention and engagement mechanism to keep people engaged with the project and its facets.
The goals of global onboarding are thus supply-driven – take the firehose of traffic touching NEAR and sort them as quickly/easily as possible into the best Guild for them. In reality, this likely means optimizing for them to choose between the ~3 most popular Guilds by default but giving them the option to find more specialized guilds later in the process too. Think of this as the “If you get 7 followers on Twitter then they consider you properly onboarded” loop… if you just join a guild and post a thing, we’ll assume you’re in good shape and, even if you later would join 1-2 other more specialized Guilds, at least you’re not going to go wandering off into the woods and go check out some other ecosystem instead.
Then the other end of that funnel is the demand side, or Guild Onboarding, where the Guilds need to be ready to receive new members and help guide them home (at least those Guilds which actually want to receive unvetted new members). This process will be different for each Guild, but it does need to pass through some checkpoints either way so we can all acknowledge when someone has actually “joined” that Guild (ie an on-chain linkage).
It’s sort of like Club Rush or Fraternity Rush from school days – lots of people trying to rapidly sort themselves into the communities that are right for them.
The success of onboarding to me shows up in the success of members being more engaged (yay for on-chain activity!) and referring members, which ultimately means more people in the Guild. So, while we should always track metrics around onboarding in both directions, Global and Guild-specific, I still think its success materially feeds into the previously-mentioned metrics.
DAOs / on-chain tools
Yep, the goal here is to dogfood everything community. You can see in other ecosystems (esp Ethereum) that communities are iterating their tooling extremely quickly because they’re actually trying to build communities and those communities need tools. So the more we try to use this stuff, the more of a favor we’re providing to every builder who will need them later by helping to create better tools along the way.
Other stuff
every Catalyst community (DAO) is also an account and has a decentralized identifier (DID) making it unique. Every person joining a community gets their near account linked to a DID as well making it possible to create and store account specific data (all of this is done through Ceramic Network integration). Thus, for our communities, we know when someone joins or is affiliated because a proposal is passed that signals that.
yassssss… and doing something similar in spirit to this (though ideally even simpler in practice) is what I hope to see from the Guilds program, so every human who’s touched NEAR is a member of at least one Guild, which is verifiable on-chain.
I also hope that every hackathon that a developer wins or grant recipient a BD person refers or investment deal an investment Guild member refers will provide some referral incentive back to their guild automatically so all guilds are aligned with their members to drive actions which drive us all forward. The mechanics of this are still in need of production but the vision has been there from the beginning – Guilds are a program where anyone touching the NEAR ecosystem should find a community and those communities should be directly incentivized to support their members doing things that help our ecosystem.