S1 Budget Proposal: Onboarding

[luan]

[Final] S1 Budget Proposal: Onboarding

Author(s): @luan (lu.an#9388)

Link to archived version.

You can find previous discussion about this topic in the #onboarding discord channel within the Community Guild. And for a high-level overview of Developer DAO’s onboarding efforts, please see the original Onboarding Proposal that I put together back in January 2022.

Summary

This is the Onboarding Team’s budget application for Season 1. It outlines the high-level goals for the team, how we plan to get there, the team working to make this happen and the proposed budget we’re applying for.

Motivation

It’s important that as the Community Guild progresses through the seasons, we remain true to our ethos – as it undergirds the role we play in this community. For this reason, the proposal I’m making here is that we allow ourselves the flexibility to tailor our motivations to specific seasons; whilst maintaining some overarching structure that is predicated on our Guild’s ethos.

Mission, Values & Goals Alignment

The Community Guild exists in service to the Developer DAO community, helping to facilitate its core mission. We are primarily tasked with morale. And it is our duty to ensure that the Developer DAO community is safe, welcoming, diverse, and empowering. This plays out in a number of ways which includes (but is not limited to) member flow and UX, Onboarding, server architecture, category and channel management, Support, Scholarships and Fellowships, Moderation, Quests etc.

How members feel when they come into this community and navigate it, is in large part, down to us on the Community Guild. Whilst we are not in control of everything, the things which do fall under our purview; we must serve those things to the best of our abilities.

The above outline will largely remain consistent as we go through the seasons. But the things which we collectively decide to focus on, will be season-specific. As mentioned, we want to lean into the possibilities afforded to us when we’re flexible; whilst being able to rely on some form of structure as our guardrail.

Brand usage

The Developer DAO branding will be used on our https://guild.xyz landing page.

Scope of work

The overarching goal for Season 1 is to transition over to the new onboarding structure, and develop a regular cadence around that. Long term, the aim is for Onboarding to become its own distinct (and comprehensive) initiative within the DAO. As stipulated in the initial Onboarding Proposal I put together, the premise is rooted in member flow and UX - as onboarding is the most important initial stage in an organization, for a new member.

For the sake of clarity, it’s important to define ‘onboarded’ and ‘minimum viable contribution’ (MVC) for Season 1. What constitutes ‘onboarded’ is split into two stages:

1. Passing through the new Onboarding process
2. Making 1 minimal viable contribution

The Minimum Viable Contribution for Season 1 would essentially serve as a v1.0 of the future Guild onboarding.

As a quick reminder, the high-level thought process for Onboarding is to be:

DAO → Guild → Project/Initiative

We don’t yet have a structure in place for Guild Onboarding, at this early juncture. But the intention is to formulate a framework that Guilds can then build upon and apply, as they see fit. This helps us to foster some cohesiveness in Onboarding across D_D, without it being homogenous.

Minimum Viable Contributions will exist in future versions of Guild Onboarding (when it becomes more structured), but for right now: all that is required of a new member, is to complete a task that contributes to the Guild (or DAO) in some way. Low-lift, but impactful. One super early example of this that is currently being workshopped, is the Scribe’s Project within the Writers Guild.

Thus in light of the above, the scope of work for Season 1 will be divided into 3 phases. I’m encouraging us to be pedantic about focusing on only a few core goals for Season 1 - in addition to starting small and scaling up gradually.

Phase 1 - Migration

• Establishing a system that will operate under the new Onboarding structure
• Setting up roles, categories, and channels which facilitate this structure (luan)
• Transitioning over to the new Onboarding structure

Phase 2 - Fixed Onboarding Times

• Establish a fixed time(s) during the week, to hold an onboarding session
• Creating a discovery pathway for members who would like to contribute (i.e. host an onboarding session)
• Generating analytics processes to record data around how many members take at least 1 task, how many take 2 or more, and which pathways they use for discovery

Phase 3 - MVC (Minimal Viable Contribution)

• Cross-collaborating with key members in the DAO, to ascertain what would constitute a minimum viable contribution for their respective Guilds
• Creating a v1.0 list of MVC’s during Season 1
• Working with Guilds to establish a framework for Guild onboarding, heading into Season 2
• Generating analytics processes to record data on the no. of people who make an MVC vs the no. of people who do not

Financials

The requested budget is based on our regular-scheduled operations (onboarding calls + team syncs), as well as additional miscellaneous tasks which serve this effort. This includes (but is not limited to): any asynchronous work that gets done, curating and creating content for the onboarding channels, meetings taken with partners, research and development, and QA testing in a test server. We’ve also factored in Quests, which will be introduced under the new onboarding format.

The nature of some of the work that we’re doing, sometimes means that we are not working in strict 1hr time frames. It can be much longer, and it can also be shorter. Regardless, these efforts are impactful. And so I want to reframe how we quantify and ascribe value to that work.

Taking a cue from the legal profession — billable hours. Any work we do that is in service of the server architecture mission, is valuable; and thus should accrue remuneration in the form of $CODE.

Budget Calculation = 𝒙 no. hours per-week X 16-week Season X 15 $CODE/hr

Buffer (miscellaneous) = 9,960 $CODE

Total Requested Budget = 15,000 $CODE (3,750 $CODE per-month)

Contributor	Role	Hours (Weekly)	$CODE (S1)
Alex1237	CM (Onboarding), scribe	4hrs	960
wiseTy	CM (Onboarding)	3hrs	720
luan	Onboarding Lead	14hrs	3,360
Contributor_role	Ad-hoc contributor	1hr

Team

• @luan (lu.an#9388): Onboarding Lead

• @allWiseee (wiseTy#8689): Community Manager (Onboarding), session host

• @myz1237.eth (Alex1237#2487): Community Manager (Onboarding), session host, scribe

• @Contributor_Role: open position for anybody not listed above, to claim a task on DeWork

Success Metrics & KPIs

Migration

Onboarding currently takes place in the main DAO server, across 1 text channel and 1 voice channel. By mid-way through Season 1, the Onboarding Team are to have successfully migrated to the new system of onboarding-specific channels which are not visible to those who have access to the main DAO server (excl. Core Team and Moderators).

Guild Onboarding

As we have already met the majority of one of our Season 1 KPIs that was in our original budget proposal (i.e. establish fixed Onboarding times), I am introducing a new KPI for the team. By the end of Season 1, we want to have built a framework for Guild-based onboarding that can be adopted across the DAO.

DeWork

In order to open up the onboarding process for others to contribute to, there needs to be a structure in place to facilitate this. Therefore, we will rely on DeWork to administer tasks. Using a dedicated read-only channel within the Community Guild, members will be able to go in and see any live tasks (i.e. dates of availability). So the core KPIs are as follows:

• Select a fixed time each week for 1 onboarding session (1 session minimum)

• Establish a system under which this will function

• Decide which member of the Onboarding Team will be responsible for setting those tasks in DeWork at regular intervals (until the end of Season 1)

• Set up read-only channel, in order to pass in data from DeWork regarding live tasks

Next Steps

The immediate next steps are focusing on DeWork, and concluding QA tests around the onboarding-specific channels. Part of this work will happen in conjunction with the Server Architecture Team.

We do not expect there to be any drastic changes at this juncture, but there may potentially be amendments before the end of Season 1, should we adopt Orca Protocol across the DAO.

I do, however, want to emphasize the importance of this team and our efforts to the DAO. Onboarding sets the trajectory for any new member joining an organization; and the most valuable part about Developer DAO is its members. A community’s strength is in proportion to how empowered its members are. I believe that this proposal is critical to ensuring the retention of the existing team, and ultimately building out a much more improved Onboarding structure across the DAO in the future.

• Yes, I support this application
• No, I do not support this application

[luan]

Month #3 Rundown

Milestone Summary

Spent a considerable amount of time QA testing the incoming Onboarding structure. A lot of this process is interwoven with Server Architecture (as that is where SA largely originates from), so it has involved me creating the new Onboarding channels in accordance with my design, and then running through the flow and respective permissions that get assigned along the way. Due to limitations with the Guild bot however (but mainly because we are retroactively trying to build this out) — we’ve faced with a few blockers that would have negatively impacted integral parts of the new Onboarding process. As such, we’ve not been able to roll it out yet. The fact that no onboarding structure was in place when the server was created, is what has made this considerably more difficult than if we were building it from scratch.

Part 1 of this process has involved me using a bot to batch-assign a role called ‘main’ to all members who currently have the d_d role assigned. I will be testing out a workaround in the coming weeks.

I’ve also been tapping into different parts of the community to better understand what processes are in place at the Guild-level, to onboard new members. In addition to this, I’ve been having conversations that are helping to inform how we structure the member flow (access to information, how we communicate, how easy/difficult it is to obtain context and get involved etc).

Allocation Revisions (Optional)

N/A

[Narb]

@luan

we’ve faced with a few blockers that would have negatively impacted integral parts of the new Onboarding process. As such, we’ve not been able to roll it out yet.

Great stuff here @luan and team! just want to touch on the block quote above and if there’s anything we can do to help unblock you whether that be by purchasing a tool(s) and/or external services to help unblock you. Equivalently, do you think that maybe having more hands on deck would help?

[luan]

@Narb

if there’s anything we can do to help unblock you

hey!

so to elaborate:

The incoming Onboarding structure is predicated (in large part) on the Guild.xyz platform. We use Guild to auto-assign roles to people, based on them meeting a set of conditions (called requirements).

A key element in the incoming Onboarding structure is that it will offer new members a ‘guided’ approach into the server. This goes to the heart of one of our biggest complaints: the server is overwhelming.

And the way I devised this, was to effectively offer new members an isolated view of the server. i.e. they come into the server for the first time, and based on the roles that they have, they will only have access to the ‘Onboarding’ category of channels. This allows for a much more steady entrance into the DAO, and enables our team to interact with them in more meaningful ways (see screenshot below):

Currently, the Guild bot will assign the @d_d role to anybody who holds at least 1 Genesis NFT or at least 400 $CODE tokens. Since that is the role that grants people access to the main channels in the server, then I needed to figure out a way for new members (under the incoming Onboarding structure) to come into the server under that isolated ‘Onboarding’ view that you see in the above screenshot. And this needs to be done in a way that ensures they will not be able to access the main channels, unless they’ve manually exited the Onboarding flow (via an embed with role reactions that lets them manually assign a role to them self), or they’ve gone through the entirety of the onboarding sequence. See below:

Thus my initial idea was to create a @main role, which I would mass-assign it to everybody who currently has the @d_d role. What would then happen is I would need to manually migrate the existing @d_d permissions to the @main role and remove them from the @d_d role. This would relegate @d_d to being an aesthetic-only role. And then a @newbie role would be what gets auto-assigned to new members coming into the DAO.

This all worked fine in theory. I’d faced some initial difficulties, but I successfully managed to mass-assign the @main role to people under a specific role, as opposed to everybody in the server. But then I hit a blocker:

The @newbie role would also auto-assign to any existing member who has verified via Guild. Which in layman’s terms: means that members who are not in Onboarding, would have also been assigned this @newbie role and would end up seeing the onboarding channels. That is NOT what I want.

And because the new Onboarding structure is effectively being set up retroactively, this initially seemed like the only way to get around the conflicts, whilst not sacrificing the quality in the onboarding process that we’ve been building out (i.e. a guided approach).

And to reiterate: the onboarding channels (once launched) will only be visible to the new members of the community (who will have a designated role), the Onboarding Team, the Server Architecture Team, and the server admins.

Essentially, the @main role will allow us to split the view of the server without there being any conflict in views, or any friction on the side of existing members.

Guild.xyz currently do not have a feature that allows them to auto-assign a role, and exclude people who already have an existing role assigned to them. That would have been the perfect solution here, because I could then prevent all members who have the @d_d or @main role from being assigned the @newbie role. I’ve logged a feature request, but will need to wait.

So it’s back to the drawing board. I’m considering deleting the @main role and relying on the @d_d role as a differentiator from the @newbie role. but will need to think through this, some more.

__

We have a contributor allocation in our S1 budget, so I’m more than happy for people to help out. @Sunk8.eth has been getting involved and has earned some $CODE in the process (yet to be paid out). There’s no immediate requirement for any particular tools or external services.

[wolovim]

gm, steward duty

big fan of the idea of easing new members in. got some questions about roll-out.

@luan

they come into the server for the first time, and based on the roles that they have, they will only have access to the ‘Onboarding’ category of channels. This allows for a much more steady entrance into the DAO, and enables our team to interact with them in more meaningful ways (see screenshot below):

a couple questions that i’m particularly curious about:

1. who is responsible for what in this new world? my concern is that byfander town is illustrative of the challenges; few members can see those channels and those that do don’t have a clear directive afaik. no shade there, just would like to learn more about what an ideal user’s experience could look like in the onboarding channels and what it would take to make it work.
2. do we have any quest ideas in mind already? what might mvp look like?
3. as soon as we figure out the technical headaches about which roles to assign when, is there anything else holding us back from rolling out an mvp version?

[luan]

@wolovim

who is responsible for what in this new world? my concern is that byfander town is illustrative of the challenges; few members can see those channels and those that do don’t have a clear directive afaik. no shade there, just would like to learn more about what an ideal user’s experience could look like in the onboarding channels and what it would take to make it work.

Setting up byfander Town was predicated on a few things on my end:

• the assumption that a lot more would be happening in the DAO

• the assumption that the new Onboarding structure would be rolled out shortly after ‘Byfander Town’ was created

• intended to capture people’s interest prior to them flowing into the DAO, engage them and give them a reason to want to join

• serving as test case to see how to engage the wider community — since there’s a broader group of people who take an interest in Developer DAO. part of the rationale behind what I shared in ‘The State of Developer DAO’ thread, is rooted in some of these observations

ultimately, serving a community requires people. people who can engage. I’ve been pressed for time in trying to engage byfander, but also unsure on what to communicate outside of responding to some enquiries. it’s still something I’m assessing and taking queues from other servers and spaces to see what I like and what I think they do well.

A few ideas I’ve had, that I’m considering experimenting with in the latter part of this season

• I may potentially open up those channels to the wider community (D_D members), and allow people to meander into the space in much the same way that they do with the #General channel.

So byfander will still only see those channels, but D_D members will be able to see those channels as well.

• Restructuring the overview channel

• Adding an announcement channel (this idea came from some thoughts I’ve had around events, such as ETH India). Having an announcement channel will allow for polls to gauge sentiment on different things, too

Byfander Town was a mid-season decision that will take time to iterate on vs the proposed Onboarding structure that has a more defined structure and predates S1 by a handful of months. Arguably the biggest lesson is around the time commitment needed to steward and serve such spaces.

@wolovim

do we have any quest ideas in mind already? what might mvp look like?

So the initial Onboarding period will be 24-48hrs. This allows for a much quicker feedback loop than 7 days, or even the 4 weeks I proposed in my initial Onboarding proposal back in late-January.

See also: earlier comments for additional context.

I ran a test on 101.xyz and it’ll suffice as a platform to use for one of the quests. An ‘Intro to Developer DAO’ quest is great and will come with an L2 NFT at the end. Minting this will make a person eligible for a new role to be auto-assigned, and that’ll open up the next quest channel (since channels will be permission-based). That sequential, guided format is impactful and key to creating that good ‘flow’ for new members.

Undecided on what the 1 other quest will be, but my brain is simultaneously chaotic and sequential, and will select the most efficient path on any given day. And right now, it’s opted for doing this sequentially: i.e. getting over the Onboarding blockers before deciding on that final quest.

I’m able to conjure up things in a relatively short amount of time, so that final quest is a fairly low-lift endeavour. at least compared to the other tasks.

@wolovim

as soon as we figure out the technical headaches about which roles to assign when, is there anything else holding us back from rolling out an mvp version?

Nope, that’s really the big bump in the road for us

[wolovim]

thanks for all the context

@luan

So byfander will still only see those channels, but D_D members will be able to see those channels as well.

this feels pretty reasonable? original concern was exposing members to scammers/spammers via private DMs, but i think the new Guild.xyz flow is (hopefully) enough to stem the majority of attempts.

@luan

An ‘Intro to Developer DAO’ quest

however this manifests, . i’m sure we could crowdsource some fun ideas too for the second quest, maybe by surfacing at a Coordination Sync call, for example. spitball: collect a DevNTell, workshop, or guild sync poap? some kind of basic participation opportunity made available to members in this role.

@luan

Nope, that’s really the big bump in the road for us

great; if helpful, happy to sink a little time into this next week to see if we can find resolution. excited to see the other ideas unlocked