O> Onboarding coop and RAM members [#15 cont.]

[lapin7]

Continuation of #15 Onboarding coop members

goal: Describe process of onboarding coop members towards becoming active members (contributors / RAMs)

• @kitblake check in an editable version of proces flow or delete it
• create/change new proces flow
• update all content with regard to onboarding
• announce issue in Discord
• what else....

budget: $1000

time: 2 weeks

[pmoorman]

@lapin7 I'm copy-pasting my comment from issue #219 to here:

patrick727 what can we do to move this issue forward?

I saw that lapin7 created a new issue (issue #253) about better onboarding new coop members.

It would be great if we could integrate that into the marketing automation also.
For instance, the flow could look like the below (lapin7 , let me know what you think!):

1. We make it really easy on the website to sign up to "join the RChain cooperative" => person leaves email address

2. We receive them in the marketing automation tool, and schedule out an onboarding sequence, that tells people exactly what they need to do. That way it's not so confusing, because we can really spell out step-by-step what they need to do.

3. We could track on the member website whether people have completed certain actions (e.g. uploaded their passport, activated with Github, etc.), and then send them more information about the next step. That way, everyone get a personalised help.

4. Once they're onboard the Coop, we also automatically nudge them to complete the "who are you" form. I know that now for instance @dckc pushed me to fill that out, but really a marketing bot could just as well do that.

We could expand this as we go, to make it fully automated, and to make sure nobody gets lost in the complexity of onboarding. We could also for instance treat developers differently than marketing members (because they're probably looking for different sorts of information).

Two questions:

• Is this rough idea something worth pursuing? (maybe we should really discuss this in O> Onboarding coop and RAM members [#15 cont.] #253 I guess)
• patrick727 what's needed to make a decision on the platform, and move forward?

If we want to implement the above, I would suggest we use Drip rather than either MailChimp or ConvertKit. Drip will give us by far the best feature set to implement automations like this.

If we agree, I'll send patrick727 a private message so I can set it up, and we can discuss within issue #253 more about the exact details of the onboarding sequence.

Let me all know what you think!

Next steps:
How about I set up the marketing automation first (that's issue #219), and then create an outline of how an onboarding flow could look like? Then maybe @lapin7 could collaborate with me (or at the very least review that), and we can build it within the next 2 weeks.

A few other ideas I have:

• Would be best if we can segment people immediately based on role (devs, marketing, etc.) Maybe also experience level, or whatever.

• I'll work on re-recording @lapin7 's video about the budgetting/rewards spreadsheet. Maybe we should also create little videos about the other steps during onboarding so people know exactly what to do?

• Besides an onboarding for members, we really should also consider how we can better onboard 'everyone else'. A lot of people now discover RChain, go to the website, and leave semi-interested. We shouldn't let that happen, and nurture people properly. In my world you'd call that a sales funnel, but that should be a separate issue.

• Can we make/select a few issues that are "easy to get started" for new contributors? For instance, it would be great if there's an easy way for people that want to contribute towards marketing RChain, if they knew what to do to really make an impact. Otherwise we'll get a bunch of fanboys onboard, rather than real contributors.

@patrick727 mentioning you here, because I guess it might be relevant to you related to #219 also.

[pmoorman]

@kitblake just checked out your proces flow diagram.

I would suggest that we should really center all communications initially around someone's email address (rather than assume they have Slack, Github, Discord, or whatever else). The reason is that we cannot be sure that everyone will have a Slack account (for instance), but we can be pretty certain they have an email address.

So I would suggest all onboarding communications goes through email until we know they have any of the other accounts, too. That would mean for instance that we'll send them an email, and in that email invite them to sign up on the website, or to create a Slack/Discord account. But if they don't do that, we can still maintain the communications with them.
It wouldn't be a dealbreaker.

I could try to re-draw the diagram, but I hope the above explanation makes enough sense already.

TL;DR version: Make all onboarding communications email-first, because email is the most dependable delivery mechanism.

P.S. rest of the diagram is still very helpful. So thanks for making it :)

[lapin7]

@pmoorman connect it with [email protected]. I will make you an admin on that group.
We can forget about Slack. This channel is phased out.

[pmoorman]

Oke, yeah sounds good.
If you can make me admin there, that'd be great.

[Tonyprisca13]

There is a need to make the on boarding process easy to understand in other to create more interest as I am new to blockchains and cryptocurrency in general and I am completely lost as to how to get started and what issues to contribute on.
@lapin7 how do I become a collaborator? Here is my email: Tony prisca13 @ Gmail. com

[Ojimadu]

Work has to be expedited on https;//member.rchain.coop as this is where we can easily gather information about coop members. I dont think google forms would be effective in gathering information we need at this point as it is easy to lose track of the information supplied across all forms. We need want a situation where we can track information supplied so that can be used as part of the onboarding process.
For automation we need a database where we can get information that can be tailored to each individual based on the information they provide.

@pmoorman Do you have any plan on how to go about the email on boarding? Let's say I drop my email to join the coop as you suggested what message do I receive? How do you intend getting me to become active?

[kitblake]

@Tonyprisca13 There's a description in https://github.com/rchain/Members/blob/master/CONTRIBUTING.md You're already halfway there :)

[kitblake]

@lapin7 @dckc I deleted the Onboarding Workflow diagram. Glad it was useful @pmoorman but it's completely outmoded and at the time it was made it was conjecture; we never got much of it implemented. Flux happens..

Using the email address is attractive, especially because it' a unique id, but our current onboarding flows don't usually include email, until somebody requests to become an Activist.

A large proportion of new Discord users come in via Telegram. We don't know their email address on Telegram, and on Discord only Discord knows it.

Some Discorders decide to do the KYC and become paid Coop Members. The KYC happens in the flaky member.rchain.coop site but the email stays private. Only the admin that does the video verification knows the email address. Some people want their email address kept private so it's not revealed or used for communications.

It's only when a Member wants to contribute that they sign up on rchain.googlegroups and/or reveal a Github id. At that point they're fully on board, in the sense that the onboarding funnel successfully closed.

So while there are other, smaller incoming flow sources like the RChain newsletter, the onboarding mainly happens via chat channels.

I/we could make another process flow diagram for today's current state. But flux happens..

[Tonyprisca13]

how about having it advertised via goggle adverts, it wil create more awareness to the society this way we could get some persons willing to become a member.

[David405]

@pmoorman, I believe one of the major reasons that leave people "semi-interested" is the complexity of the rchain coop, by complexity I mean it takes a new member quite some time to understand how the coop really works. So if we hope to get bring in more persons then I suggest a whole lot of supporting documents and video tutorials should be done in clearly explaining all of the coops terminologies. I know some of these already exists but we can do much people.

The reason I am saying this is because I did a survey and discovered that 80% of the persons I surveyed where reluctant to respond to the coop because they really don't know what to do to become active on the coop.

I believe if this is addressed, a lot of progress will be made concerning onboarding

[David405]

@kitblake, I agree with your conclusion that a lot of on boarding takes place through our chat channels but let's not forget something, being onboard and being active are two different things.

Even when people get onboard, it takes a while for them to fully grasp the major concepts of the coop and this has to resolved

[David405]

Just like @pmoorman said, it isnt about getting just about any one but people who would contribute and for them to do so as newbies, there must be simple issues that they can work on and get rewarded to serve as a form of motivation.

[Tonyprisca13]

@David405 are right. rchain coop is too complex and need to simplified because alot doesn't understand how to become fully involved and this could cause lack of interest .

[Tonyprisca13]

@David405 simple issue is a welcome idea.

[David405]

Thanks @Tonyprisca, personally I would love to collaborate to make the coop simplified. We could make more docs that would simplify some processes for new members

[Viraculous]

I observed the same ambiguity in the community.@David405 and @Tonyprisca13 ref; #243 . Perhaps, this calls for an on boarded members preamble channel where contents, videos and document necessary for SMART participation of new members are simplified and explained where more complex. The channel could as well entertain questions from new members about the community. Some people join the coop and leave because the feel there is nothing there can actually do, while some other who remain, like @David405 said, becomes inactive. A channel for newly on boarded members can be useful in educating them on the basics of the community since synergy operates when people of common interest gathers and after which members can now move or given access to main channels for SMART participation.

[Tonyprisca13]

24 hour chat platform for newbies will be useful in tutoring them and having some of their challenges resolve by giving instant answers to their questions.

[Viraculous]

Great idea @Tonyprisca13. You mean nursery chat channel?

[makys]

I just joined the coop yesterday and it feels like a ton of reading to navigate the space. It would be nice to have projects where new member can pitch in from day one, so they feel part of the team and also feel that their input counts. This will create engagement and a sense of inclusiveness. The chat is a great idea, we could have mentor roles or a buddy program where one on one connection is formed and conversation history is tracked.

hey guys, I've got my hands up, looking for my first real engagement on this coop.

[Tonyprisca13]

No, I mean a chat channel for new members.@Viraculous

[pmoorman]

Hey all,

I've been working on this outline quite intensively for the last few days. I think onboarding is incredibly important for a well-functioning coop, and something we can do much better at (like HJ suggested by creating this issue).

Detailed description on how I suggest we approach the members onboarding:

https://docs.google.com/document/d/1TyJjtwdIjzPEzPD-X529pAv0h4VzurWs3zqcFfwDlTs/edit?usp=sharing

++++++++++

Please note, the document is a bit longer than I intended, but it'll read quite easily I suppose. The document is broken down into:

• A strategic overview of the onboarding situation
• A detailed suggestion on what's needed to make this successful.
• Detailed notes & thoughts that we might want to either discuss about or keep in mind while building
• Conclusions, and suggestions on how to proceed with this.

I would be looking mostly for feedback on the following:

• Does this satisfactory resolve the issue as @lapin7 initially articulated it?
• Do you guys agree with this suggested approach
• What can be done to simplify the process, so we'll execute it as fast as possible. Especially, I'm concerned about the (limited) development hours we'd need. Those hours are precious!

Maybe a look by 1 or 2 developers to estimate the scope would really help, too.

@Ojimadu @lapin7 @kitblake @dckc @makys

[pmoorman]

@n10n I've been told you run the members.rchain.coop website.
Could you have a look at the document in my comment above, please?

If you need more details to properly estimate (you probably do), then let me know. Or reach me on Discord @pmoorman

[dckc]

@pmoorman, there's a lot of good stuff in thee, but the document doesn't seem to distinguish between the RChain coop and this /rchain/Members/ repository, aka RAM.

For example, there's a whole constituency of investors, where the end-goal of onboarding to the coop is that they invest financially in the platform. After that, I expect they go about other business for weeks and months at a time. Perhaps they interact with the coop again when a milestone is due to see that things are on track. Or they participate in node testing now and again. But I wouldn't expect to see them in github at all.

[pmoorman]

@dckc yeah I agree with you that this document is primarily focused on getting people onboarded towards contributors. I might get my terminology mixed up (so correct me if I'm wrong), but I thought the original goal / issue was centered around essentially this, no?

Goal: Describe process of onboarding coop members and getting them active

So: this document => RAM onboarding (primarily)

++++++++++++++++++++

P.S. I totally agree with you that we should also work on engaging and activating investors and other interested people. This process should be more sales-oriented, and warrants a separate issue (and area of discussion) in my opinion. It would partially overlap on the top of the funnel, but the back-end would be quite different.

Again, I'm still pretty new around here, and I might have misunderstood what @lapin7 had in mind with this issue initially.

P.P.S. @makys pointed out that the document was comment-only, so here's a link to the edit-access version:
https://docs.google.com/document/d/1TyJjtwdIjzPEzPD-X529pAv0h4VzurWs3zqcFfwDlTs/edit?usp=sharing
Sorry for mixing that up!

[dckc]

The way to reduce the scope of an issue is to just edit the description; change it from "solve world hunger" to "make a sandwich for Bob", for example.

Currently, the scope includes not just describing the process but also changing it. Oh... I see that bullet is checked. I guess I'm just not up to speed.

The document has had extensive review, which is great. I just don't see what concrete steps it recommends we take. I could read more carefully, I suppose, but if somebody were to make a nice bullet list somewhere, that sure would be cool. Ah... now I see there is one in the conclusion. I would have been better served if that were up front in an executive summary, but no matter.

[pmoorman]

I appreciate you chipping in, @dckc. The scope reduction example made me smile ;)

I'll keep the idea of "executive summary" in mind for the future. Maybe whenever something like this gets posted, the Github comment could serve as a convenient executive summary...

[dckc]

At work, we add a ticket (issue) to our system each time we on-board a new staff member; we use it to track stuff like required training, granting accounts and such. Ideally, the title has both the name and their role: "On-board Bob for HERON software development" or "On-board Claire, an Honest Broker". The role helps justify the accounts and such that get created.

e.g. the Dec 26 interview @jimscarver did with krishna is really useful. Did we reward him for that?

Over time, I hope we have so many participants that this approach doesn't scale, but suppose we try it here? As patterns get established, larger scale should be feasible.

Perhaps I'll try issues for

• onboard @dckc, open source developer (to reflect the work @lapin7 and others did to get me up to speed)
• onboard @pmoorman , marketing wizard (halp with role, plz?)

[dckc]

@pmoorman writes in a Feb 3 comment:

I've doodled a little on a document to help new members better understand what we're all about.

@dckc responded:

Nifty writing. ... I think what you wrote is even more narrow than coop purpose and principles; it looks more like RAM purpose and principles. I'd like to see it merged/meshed with CONTRIBUTING and/or README.

Toward that end, I used it as the basis of Welcome To RAM. Compare with Welcome Visitors in the original WikiWikiWeb,

This is a revival of my suggestion in #88 to work toward a pattern language.

still TODO:

• add advice on finding a mentor
• cite Welcome to RAM from README
• refactor CONTRIBUTING w.r.t. (a) Welcome To RAM and (b) our list(s) of social media channels

[pmoorman]

@dckc can you elaborate on the task of "add advice on finding a mentor"?

What exactly do you mean with that?

[dckc]

We say "Be a self-starter :: ... nobody is going to tell you what to do. " but we're not quite that merciless, right? We do aim to do a little mentoring / orienting for folks that show a little initiative, right?

[dckc]

As I look back at this issue after doing some onboarding work (#295, #294) I wonder if we have attempted to generalize before gathering sufficient experience.

If you have spent hours onboarding people, is your experience written down and easy to find from this issue? If not, please spend a little time writing it down or organizing it from this perspective.

If you haven't spent hours onboarding others, please document your own experience coming on board in an issue like #293 or a blog item or whatever.

[lapin7]

We have also the system of "Statement of Work" and folks that apply for a job through [email protected]. The latter ones can become "Employee of the coop."
The folks that have an SoW do regular work and get a fixed reward per month. If they earn a reward for an issue, then this reward is listed on the invoice. When the total of rewards is more then the amount in the SoW, then they still get the fixed amount in the SoW.
The employees have also a fixed amount per month and are paid through a pay roll system. They can work also on issues, but they don't get a reward for that work.

So we can have the strange situation that people with an SoW can get paid less then people that get rewarded through the reward per issue system.

Apart from the financial side, there's also a coordination problem. Some people get guided by the "Seattle club", while the RAM's guide themselves more or less. Maybe it helps to create a more clear organization. But how? Who initiates that?

[pmoorman]

@dckc wrote:

If you haven't spent hours onboarding others, please document your own experience coming on board in an issue like #293 or a blog item or whatever.

I documented my onboarding journey here: #294 (comment)

That adds to our library of 'cases' to pull from.

I think having a few more people document their journey would be helpful, too.
@makys maybe, for instance? @Viraculous @David405

[dckc]

I worked a bit with @David405 in #295.

[makys]

@pmoorman documented my onboarding journey on #294

[theneverafter]

Here's my journey so far: #420