O> Onboarding coop and RAM members [#15 cont.] #253
Comments
BelovedAquila
added
Development
|
@lapin7 I'm copy-pasting my comment from issue #219 to here:
Next steps: A few other ideas I have:
@patrick727 mentioning you here, because I guess it might be relevant to you related to #219 also. |
|
@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. 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 :) |
|
@pmoorman connect it with [email protected]. I will make you an admin on that group. |
|
Oke, yeah sounds good. |
|
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. |
|
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. @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? |
Ojimadu
removed
the
Development
|
@Tonyprisca13 There's a description in https://github.com/rchain/Members/blob/master/CONTRIBUTING.md You're already halfway there :) |
|
@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.. |
|
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. |
|
@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 |
|
@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 |
|
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. |
|
@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 . |
|
@David405 simple issue is a welcome idea. |
|
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 |
|
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. |
|
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. |
|
Great idea @Tonyprisca13. You mean nursery chat channel? |
|
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. |
|
No, I mean a chat channel for new members.@Viraculous |
|
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:
I would be looking mostly for feedback on the following:
Maybe a look by 1 or 2 developers to estimate the scope would really help, too. |
|
@pmoorman, there's a lot of good stuff in thee, but the document doesn't seem to distinguish between the RChain coop and this 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. |
|
@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?
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: |
|
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. |
|
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
changed the title
|
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 |
|
@pmoorman writes in a Feb 3 comment:
@dckc responded:
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:
|
|
@dckc can you elaborate on the task of "add advice on finding a mentor"? What exactly do you mean with that? |
|
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? |
|
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. |
|
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." 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? |
|
@dckc wrote:
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. |
dckc
added
the
zz-Greeter
|
Here's my journey so far: #420 |
Continuation of #15 Onboarding coop members
goal: Describe process of onboarding coop members towards becoming active members (contributors / RAMs)
budget: $1000
time: 2 weeks
The text was updated successfully, but these errors were encountered: