Design

But first, reasoning. This module to reimagine Kernel intros comes from asking three questions:

1. how do we better connect fellows who share similar (or maybe opposing) interests?
2. how do we give fellows more agency to connect with fellows?
3. do we need fellow profiles on Notion?

The last question I ask because, are we convinced that setting all that data to sit in a repository converts to activation energy to find the others? Or isn’t that likelier to be accomplished through dialogue and inquiry in the paper parties? The convos? The unconferences? The async communications in Slack?

Consider the cons of data management liability & access issues in Notion. Additionally, the organization of fellow profiles in the fellows book is monotonous, rows and columns of text, and having to control + F to search key words of interest. It is not an appealing, fun, or convenient way to search for and consume information. Long term, I think we all see ourselves moving away from Notion, to tools with more creative liberties, especially when Kernel Services makes a comeback .

And enter, intros! Intros hold bushels of energy. It is when fellows are bright eyed and bushy tailed, and willing to share their background and the why/how they made it to Kernel. It is a capacious activity full of opportunities for us, which if we seized, I think we’d nullify the three questions I posed at the beginning.

I propose that we carry on with Kernel intros as usual, maybe with an increased emphasis in initial messaging that all fellows should submit an intro to #kernel-intros! then, as they come trailing in, I, and if any other steward would like to help me, would create a map of the intros by fellow and their background, interests, and themes. i would cluster like by like - the map would be organized by themes, and transitions to adjacent themes would be straddled by the fellows who had both sets of themes in the intros. i imagine i’d create it in figjam, and it would be at the disposal of all fellows to use and find friends. we could also add to it and edit it as the block went on, if they added adventures, transmuted adventures, and so on. i could also use colors, hues of colors, to indicate themes too, to make it more visually digestivle. i have tried to make a small example below:

[i’m working on a rudimentary draft sketch. i thought i’d have it ready by now but having scrolled through many intro examples, it seems more challenging than i expected]

this idea reminds me of an old post @cryptowanderer shared last year shortly after I joined Kernel, about how he wished social networks were designed to connect you to people you’d want to meet in a similar way. if i remember correctly, there was no news feed or wall, and you would have a circle of your profile on a map that was clustered to other profiles, the proximity to others indicated similarities between profiles and was recommended to you. maybe that’s the origin of this idea here! thank you, Andy!

the world seems to be in a frenzy lately about ChatGPT. i haven’t used it, and don’t plan to - i’m quite the averse adopter when it comes to such new technologies, but i just realized it might be interesting to see how ChatGPT would condense long intros to their core topics & themes, because it would make the manual aspect simpler - less reading. but if i’m honest, similar to Kernel news, i like the homemade, handmade, scrapbook nature of these rituals. the time it takes holds beauty and is undoubtedly generative - i learn at length about the new mempers and who overlaps. If i were to use ChatGPT - i’d say to technologize intros is to adulterate intros; it might sully my ability to match and categorize the map into clusters well.

if anyone has a better idea to execute this, please drop your ideas in the comments @vivek @saintsal @cryptowanderer

Dependencies

1. The map won’t account for the people who don’t submit intros.
2. The map won’t account for the people who write short & vague intros.
3. Is it feasible for me to commit so much time to this ritual in weeks 1-2?
4. Will fellows appreciate this map visual more than a webpage where they can control + f?
5. I wonder if before they have access to #kernel-intros, we can hint to the fellows the type of format we encourage, but without prescribing an equation and still emphasizing their originality, creativity? Just so that it would make this ritual a little more convenient on the manual side?

Design

1. I particularly like Andy’s framing of pertinent Kernel information about programming and operations for a mempool/block as our collective intelligence and organizational intelligence (in the mempool with variable length blocks option - where this post was originally birthed and hence will now stand on its own too). There is no need for us to be gatekeepers or make it as complex as it has become.

2. The thought led me to imagine a home base that mempers/fellows knew they could flock to whenever they had operational or programming questions. I imagine a landing page that is built in the design of, well, a, KERNEL! A seed. Imagine concentric oblong shapes superimposed over a distributed node network. Now, As far as I understand, this type of webpage is probably not capable of being built in Notion? Anyway, indulge me, and you builders can tell me what might be possible. At the core of the Kernel could be:
   a. The calendar
   b. The syllabus
   c. Convo link & convo explanation

This would emphasize the foundation that the syllabus is meant to edify, in tandem with dialogic discussion - meeting and finding the others.

Aside: Do we need fellow profiles? Are we convinced that setting all that data to sit in a repository converts to activation energy to ‘find the others’? Or isn’t that likelier to be accomplished through dialogue and inquiry in the paper parties? The convos? The unconferences? The async communications in Slack. + consider the cons of liability of data management & access issues.

The second layer could be:
a. Topic track/unconference/guild info & signup
b. Notification stream opt-in

The third layer could be:
a. Peers and buddies info
b. Invite your friend to the mempool

Then, this seedling of helpful (& only necessary information) would be superimposed onto a distributed node interactive image where helpful but not essential informational articles would be linked, for example (each article accessible by clicking the node):
a. Enjoying Kernel
b. Slack Guide
c. In Real Life Dinner Guide
d. Juntos & The Convo App
e. How to Edit Your Convo Event
f. Kernel YouTube

As you hover your cursor over the distributed node interactive image and seedling, the clickable objects would embolden and enlarge to indicate its clickability. Here is a 5 year old’s, I mean my, rendering:

Perhaps this diagram is no bueno, but it has been a generative exercise for me to reimagine how Kernel might look thanks to the trigger of this Continuous Kernel shape, and the way we can transmute our communications and improve our discoverability of information. I think making our Block Explorer and landing page a more visual and playful one, compared to links ordered in columns and rows, might help with the discoverability and memory of information.

Communications Notes

One way is to make all events equal in convo, make that the only calendar, and then figure out UI affordances to get events onto people’s calendars easily without constant management from us.

1. I am curious about using one calendar for all events too - I agree it will increase simplicity. We cannot continue leaning on Google. In my research to find other calendar options, I’ve come across this Urbit posting, and this GitHub repo with code for a calendar. I wonder if it might help us in building a quasi-decentralized calendar? I defer to the builders @angela @saintsal @cryptowanderer

2. With this version of mempools and continuous Kernel, there is likely no need for the weekly syllabus emails. The email could then become a roundup of the conversations that mempers planned themselves, their questions, their readings, and convos. Since that shan’t be too lengthy, it could also include a roundup of offers, asks, opportunities, in hopes of surfacing and connecting them better. While yes this is manual, I think there’s beauty to the human touch aspect. I don’t think everything should be automated or left to the devices of the fellows. Thoughts here, @vivek ?

3. Communication channels: Slack, Notion, Zoom, Calendar, Convo, Email, Automated notification streams
   a. I want to note that huddle does not have a recording function, and that wouldn’t be kind or inclusive to fellows whose time zones inconvenience them from attending events.
   b. Maybe we can consider Jitsi for events that do not expect more than 30-40 people? As we move in the direction of using more decentralized and open-source tooling.
   c. Automated notification streams would be opt-in - provide announcements and messages from topic track/guild/unconference leaders, reminders for convos and events, and potentially for items like asks, opportunities, offers.
   d. Slack bot would auto-notify when a new channel is created, and report back when there is a surge of activity in a channel.

@saintsal said:

A few dimensions from our convo:

• opt-in vs required (or effectively required)
• noise level
• age group & which channels already have their attention
• which use cases require intermediatedl, centralised or official communication, and which are better suited to enabling direct p2p

@saintsal can you share your 4-week idea for a Kernel Block that is a puzzle piece to continuous Kernel? can you also share your idea for a simultaneous 3-month long build track that’s only available for fellows who have already completed a block (the other puzzle piece)? and share how the two would complement each; one feed into the other? Salim’s 4-week timeline has a handful of elements worth considering in our discussion for program redesign, whether we vote for a 4-week program or not.

since i don’t have much program design experience, i’m questioning my authority to share my opinion for comprehensive program designs in this process. my opinions are mostly based on ‘senses’ and ‘feelings’ that i have. sure, they’re based on real-life experiences which are valid, and i have helped to coordinate two kernel blocks before, as well as short experience in philanthropic programming. but i can’t say my opinions are grounded in research, or many samples of lived experience. at best, they’re grounded in observations i’ve made from being around kernel fellows for two complete blocks and the time between. i do have plenty of fellow anecdotes in my repertoire, but i’m not sure it equips me to participate as fully as the rest of you in the redesign. Vivek and Andy, you have the experience of running Kernel 6-7 times + prior work experience in senior roles. we know that Salim has worked in such educational environments designing programs for 10+ years.

i think right now is the point at which i’m beginning to learn - about web3, about peer learning environments, about program design, and i’m grateful to begin at all. i thank each of you. i thank you for giving me the chance to learn alongside you and from you, and trusting me to do this work. i just want to call out my weakness here, as maybe my time right now can go to another effort. and if you’re ever wrestling with specific facets, i’d love to hear and talk through it, and provide my opinion once ideas have reached fuller fleshed out forms.

lastly, i sense tension between the baby Vivek and Andy have built and Salim’s work experience and best practices. i’d would like to frame this tension as a strength. we have your three experiences building peer-learning environments together in one place. how lucky are we? it is an immense strength that bolsters our ability to improve the experience we create for fellows. i don’t want us to get lost in this strength or be frustrated by it. i’m hoping we can communicate clearer, better. whether that’s here, or in sync meetings.

@saintsal agreeing with the stipulation that we communicate to the public our best gu-estimated timeline for our internal reflection time (~1-2 months) along with when applications will likely be live and when KB8 will likely kickoff.

I imagine this communication as a Twitter post, an email to all those candidates whose interviews were deferred, and accepted candidates who deferred their participation.

@vivek said in Proposal: change the order of stage gates:

the longer we wait to open apps the more pressure or lethargy we will feel as stewards.

may i ask what is the rush here? i agree that we need to communicate a timeline publicly to those interested in applying/interviewing since we’re deviating from a normative schedule we have established in the public eye, or maybe more specifically, on crypto twitter.

why isn’t making a public acknowledgment, even if somewhat vague, suitable? as we pass time now constructively trying to redesign it intentionally and with evidence-based practices? a post such as ‘kernel is taking time to redesign a better program for you - we don’t expect the next applications to open for another 1-2 months with KB8 kickoff in Q1 2023.’

what do you think we might lose by taking longer to constructively figure out how we’d like to redesign kernel? i agree that it seems you like to have a deadline to keep us moving, but if it only creates pressure, it doesn’t feel healthy to me. it feels like we’re not carving the time for the meaningful deep work required to wean off SaaS applications and complete a transition to kernel services.

building on @saintsal’s point:

The question in front of us then is, how do we narrow down to a program length and start date without first agreeing on the content and structures in the program – and do that by a specific date?

if we could narrow down a program length and start date, the next step popping into my mind is an application ready to go live, which we also don’t have, and doesn’t feel accounted for.

furthermore, to think of receiving applications and managing prescreen review processes while ‘specific modules decided with input/output between them agreed’ feels too heavy of a workload simultaneously. i can only imagine it working if we divided responsibilities, and the rest of the team worked on ‘specific modules decided with input/output between them agreed’ while i solely focus on managing application intake and prescreen review processes with guides.

In reference to @saintsal’s,:

Propose only the parts of the program you are committing to design and run yourself. The main thrust of this form of communication is not to design a program that others will run, but rather to take responsibility for the part you will run and how it fits with other parts.

Proactively seek “deference” to other concepts. What aspects of what you’re exploring don’t fit well with others, and which do? If so, how? Look at other concepts to anticipate these issues, and ask specifically about them. (Ideally, keep a section in your proposal called Deference Questions updated to invite this kind of feedback.)

My suggestions function more as puzzle pieces rather anything upending our current design. I will share a leaner timeline, emphasizing a few elements I believe are paramount to have in a healthier block, rather than trying to offer a comprehensive blueprint from start to finish.

I am also realizing that my mind is stuck OR I really simply like the 8 week program that goes hand in hand with the syllabus modules that has been developed. I’m not saying it’s perfect or that I’d argue to keep it precisely the same, but whenever I go to the drawing board to think of new ideas, I have trouble deviating from the core skeleton that has come to underpin and guide a Kernel block. I’m not sure why that is. Maybe it’s lack of creative juices on one side, and on the other side, the sense that the current program works, although we know it can work a lot better – we just have to tinker with finer details such as size, setup of office hours, mentor engagement, guide outreach. Here are the elements:

1. Carving out more space and time for fellows to breathe.

• Time for pause and reflection. A break to feel less overwhelmed. Kernel is not the only activity in fellows’ lives. I’m quite flabbergasted by the fellows who engage deeply - how do they do it? I have a lot of respect for them. Excluding the financially privileged ones, when do they sleep? When do they work? I think there is responsibility on our side to plan more calmness than we currently have into the block. This could be a start to test it.
• I imagine more space and time in the form of two one week breaks, after each set of four weeks. These are also breaks for us - to pause and reassess. Ask where are we headed and should we about face? Or just turn a few degrees?
• In the break we will provide a wall or resource in which we ask fellows to share their experience so far, work on adventures/artifacts, and any other thoughts they have, feedback.
• I’m curious what could surface and emerge in these breaks. Being open to surprise. Who sticks around too, and continues playing, continues co-hosting convo events? What are discussions about?
• On the last day of the second break, we’d have the Kernel Celebration on a Friday, coming full circle with kickoff.

2. Limiting the block to absolutely no more than 200 fellows, maybe even 150.

• What does the block look like when we prioritize that every fellow meets with a guide and/or steward at least once and hopefully twice? With 440+ fellows it’s as if we set ourselves up for failure. I’ve spoken to at least five guides who have told me ~2-3 of their fellows never responded to their email after Sid’s introduction. I think that guides’ experience is more common than we know. How is it that people who RSVP never accept our Slack invite?
• how might engagement change? how might the flow of a week change?
• Can having fewer fellows make Slack a more welcoming space? Less noise?

3. Set the goal that all fellows create an artifact.

• Whether participating in build track or not, we can cultivate an understanding of the importance of artifacts - instantiations of learnings or reflections from a particular time. I think it holds capaciousness. While it could be an adventure, it may also be a poem, an interpretation of a syllabus module, a performance, a collaboration, a learning from a guild session, thought from a junto. We can frame it as a representation of any element of fellows’ time in kernel, an exploration of one’s self in their kernel journey.
• We unintentionally tend to limit the idea of the adventure to build track and building. In KB7 we became more expansive and inclusive, but that was as the block went on. What if in orientation we presented it differently, clearer?
• This would feed into our new style of expo in which we encourage all types of artifacts and reflections to be shared.
• Approaching the block while thinking of creating an artifact may change the nature of engagement and participation.
• I don’t want to confound labels though - artifact and adventure might be too many. What if we went back to the basics and adventure simply became project? Build track project? And artifact would be a term less defined, open to interpretation.
• Now I have an idea of artifacts for learn track, adventures for build track. Hmmmmm.