Good to see your thinking exposed - thanks for that.

Trade-off curves

The trade-off curves will be much better with numbers, to really see where the important ranges are for us to manage. Without them, they’re a useful expression of opinion, but not that actionable for designing options. For example here, if there are clear answers to how many notifications per day become too many, we can design around that.

Personally, I think we’d see that a lot of the linear, up-to-the-right graphs are more likely to be bell curves. Specifically, actionable info and steward damage control would go up in cases of too few notifications or too little or unfindable information.

Decentralisation in our comms

Stepping back to the main concept, it would be useful for you to show which use cases you see depending on Comms, and how you distribute them in those two categories.

One thing I’ve noticed is that tools that require “admins” force centralisation. Tools that give agency to people without them needing permission don’t. (Vitalik explained this at a high level which is relevant to us here.) That’s a salient issue for me when thinking about what Comms tools and modes I need for Topic Tracks and Juntos – and tbh any type of education that’s peer-driven – since we want our tool choice to “slope down” towards more agency rather than depending on permission.

👍

One more note for now:

@saintsal said in Can we combine the junto scoring rubric and buddying up for reviews?:

which assumes the endorsing fellow will come

This is true, and we can always penalise endorsing fellows who don’t fulfill their role (in the sense of helping their buddy get up and running through Kernel on their own) by taking away their invite for the 3-6 months, or removing them from the #mempool-defence channel. This seems like a more powerful cultural lever to me than an arbitrary scoring process on the way in.

Interestingly, even if they don’t do much mentoring, there is still the chance that their buddy gets going under their own steam - a true Kernel fellow indeed and we get them without even requiring a lot more than a warm invite from the og fellow…

Or, it may be that their buddy doesn’t engage even with high quality mentorship, in which case a targeted intervention and chat with them will likely surface ways we can help buddies in general and continue to get better in that domain.

@saintsal with respect, I find your reasoning opaque and difficult to follow.

If we agree that chat is not a good way to build an ACL, then this applies to slack, matrix, or email in my mind. It makes no sense to say “let’s do email” when we know it causes ops overhead (even if reduced here), especially given that it requires so many additional implementation steps (manually syncing, a magic API etc., as opposed to just calling slack’s API once for a v1 implementation now).

Happy for us to have a go at a standalone “access provider” for kb9, but that’s not relevant to this thread currently.

Even happier to see the unconf app whenever you’re ready.

@angela we await your thoughts here 🙏

Thanks for starting this and all the ongoing work @aliyajypsy - it’s really awesome. @saintsal

A fee to apply may make it prohibitive for people to continuously re-apply, which I don’t think is great. Are we all talking about an enrollment fee (i.e. paid once accepted to the mempool track)? If so, it could be helpful, especially if refundable. I like that it would go into a “scholarship pool”. I don’t think it’ll give us infinite runway (one of the risks being we will need to take breaks occasionally) but $500 per fellow should help significantly.

Now, how do we implement this? Of course, my mind goes to FreeLearn. Though it doesn’t quite fit, for various reasons. It would be simpler to:

Write a mempool contract that can receive DAI (lock it in a Yearn vault for slightly more return + much more contractual complexity). Allow anyone who sends DAI to withdraw what they send at any point. Allow the Kernel multisig scholarship fund (we need to set up another multisig anyway, for better accounting, greater security etc) to sweep funds in the mempool at periodic intervas.

The third point is scary and not good design. However, if we communicate clearly once the mempool is closed that we will be sweeping funds in it to go towards fellow scholarships, and then do the sweep ~2 weeks later, just before we open apps again, that could be OK.

One advantage of this is that it also gives us a (partial) source of truth for an ACL. It is partial due to self-qualifying financial assistance. We could include another function for that, which just requires people to register.

However, (i) this still costs gas and (ii) if we use the mempool contract as an absolute SoT, then anyone can “register” or send 150 DAI and we would mistake them as being in the mempool track.

@saintsal ok.

How about Meaningfully integrate blockchains into my work and relationships?

A few thoughts from recent explorations:

Moving to a track-oriented architecture removes some depdendency on a more complex or centralised ACL SOT Matrix’s User Registration Tokens is an interesting pattern to consider since it keeps coupling very loose. Each service maintains a registration token table accessible over API, limiting account creation to those with valid tokens. We distribute tokens to our new users. The POAP Chaining system from Cuppa might be a useful direction since it’s far more decentralised/distributed (not for next block, but might help make some of our current ACL management overhead temporary) POAP Chains + OpenID w/ a website-hosted wallet (like Kernel Wallet!) gives us extensibility to do auth on all services that accept OpenID logins. I’m seriously considering picking up Cuppa again.

Four total to add! A culmination of collective efforts this morning. Added clarity to Carrie & Genevieve, a first draft today on Christian & Sam.

Carrie the “Creative Coder”
Inspired by Anthony, Holly, and horsefacts

faf971da-2fe9-4b29-92c6-66a201552e4c-image.png

Genevieve “The Worldbuilder”
Inspired by Sean Esparza, Cynthia Alexander, and David Phelps

17fd5c52-cf04-4ab6-9c8e-8976ed47bd1a-image.png

Christian “The Kernel Keeper”
Inspired by En Canada, Maxwell Kanter, Fang Chen, and Rich O’Grady

0362d4a5-f6ae-4681-867a-7badc1ae3ae4-image.png

Sam “The Serious Player & Servicer”
Inspired by Sister Tibebwa, Liv P, Dounia, & Joan
d5c8f588-b131-4518-a4f7-1f45ccfe7663-image.png

Keeping a list of questions here:

https://hackmd.io/b1fg2tJwQcehC0W1B0nIBA

Nothing new, just added what you’ve shared and reorged it a bit.

@saintsal ok, that’s fine.

Let’s hire GOT and get on with it. I agree that if we can cut Slack and only spend ~$1k/month on some hosted solution, it is a step in the right direction.

Will Jon accept crypto, or would we have to pay by more traditional means?

Would you like me to pursue this while you focus on other things, or do you still have an inside line to Jon?

Updating here https://hackmd.io/K3BScLKBQ8OBDovlesvjPg

Cool, good reflections. Considering how we learn and move forward, here’s where I am:

For WIP Wednesday:

Agree with the nudge towards “you’re actively working on this week”, and more builder-y (the stretch goal for all things Kernel also being & diverse). I’ll take 3 big steps back from WIP Wednesday (I will happily be a substitute host, never a primary). It is yours and Andy’s to run & apologies for getting too close to the fire yesterday - I see where you’re coming from. I’m going to get an experimental convos up on the Mettā Module & its impact on both products & DAO’s. Maybe I’ll bring my thinking back to WIP as in-progress work – I think it’ll help me find a pocket of good work, to play with formats, etc. When Paper Party, Research Clinics, Intention Circles get going, I think I’ll be better suited to be a primary in some cases.

If you and Andy want my thoughts Week One happy to share. Also will update my mental model for whom to invite and what to suggest they share.