Improving on-boarding at ISC

[claredillon]

This discussion thread is a place to store discussions, ideas and challenges around on-boarding at the ISC. When describing a thought/idea - it would be great if folks can describe a little of the context, the potential impact of any change, and if possible, even explore what the cost (time / effort / money) might be to implement it...

[claredillon]

First up - I believe it would be great to start with a little context of who participated in the community.

From previous discussions we have the following list of types of roles that may be visiting the website:

• IS practitioners
• ISPO folks (not necessarily practicing, but responsible for enabling/amplifying
• Org leaders who want to support InnerSource, or are looking for justification for investment
• Vendors (ultimately selling products/services to both above)
• Academics (interested in observing all of the above! ;))

You could also use a lens of OSS experience, or InnerSource experience.

I propose an on-boarding path might be different for each.

[claredillon]

It might be a really interesting community call or quick session to look at all of the above and write up some of their needs as they come to ISC, and their likely best experience of on-boarding.

[rrrutledge]

Thanks for writing these, Clare. I understand having a session to look at these, but what motivated the suggestion of a Community Call? Is the identification and discussion of these roles of interest to a general audience at the ISC?

[claredillon]

My suggestion of a community call for a couple of reasons: we've typically being doing a lot of "presentation style" - this would be more of a workshop style dedicated to getting info from the community (instead of Q&A on a presentation). Using the PR/comms channels for a community call seems more efficient than just putting out a call on Slack (doesn't hit that many people, and only the ones that are very engaged (see below - they may not be the right people) . So framing as a community call would get to more than the usual suspects in our WGs. And of course, this kind of workshop community call is like a bridge between passive viewing of presentation, and getting involved in a WG (which feels like a long term commitment - a turn-off for "drive-bys"). So it would also serve as an on-boarding experiment, kind of... a low commitment way to move from passive viewing to contributing something to ISC.

I think we need to ask people what they think about an on-boarding experience - really, the folks in our WG, or people who have been in ISC for a long time are not the right people to give advice on this - people closer to having done it, or new to the ISC are best placed to talk about what would work for them. So I would seed the conversation with maybe a rep from each of the groups above to talk about the challenge and then ask for input from the community call audience.

This is less about whether it is of interest to the general audience (broadcast goal) - it's about trying to do something with the general audience... which I think some of our community calls should focus on....

[claredillon]

I'll note here again - this is all based on my core assumption that on-boarding for ISC is different than on-boarding for OSS projects - as the ISC participants are not your typical OSS community folks - with different motivations, and cultural contexts... Explopring these would be a first step of on-boarding efforts.

[claredillon]

For example, some ISC participants have less of a "I'll read the docs and figure it out" mentality than OSS project participants. That's more of a dev-centric behavior... For example, there is some research that communities of practice for non-techical folks are often more successful with relationship-building activities (think of examples like office hours, or "meet the community" profile articles) than how-to docs... and of course we know we already have a discoverability problem with some of our documentation (just ask how many people have seen the InnerSource principles in the Learning Path)... so I'm thinking of how we can explore different ways of engaging newcomers...

[claredillon]

As we think of moving from consuming to contribution, it would be good to think about sand-boxing as a technique to allow those brand new to the community to trial things. For example, right now, setting up a working group typically feels like a permanent process, or something that requires a lot of formal docs etc. Should we have a really light weight recommended way to test an idea to see if there is interest, quantify that, scope outcomes etc.

Maybe an option to take over a community call to flesh out an idea etc... something like that. Rather than going from "I have an idea" to " here are all the things we need to do to set up a WG".

Setting up a WG is a little more effort for those running the group (to get consistent with the way we typically run them, the running of them, reporting on them etc.) - to the ISC staff (if help is required to set up repos, Slack channels, etc.). We cannot assume that those wishing to this are familiar with either how ISC works or how GitHub /our tooling works - and assuming people are happy to self-serve with the help of docs may not be the optimal way of getting more people to contribute. Hand-holding helps people who are not used to a given community and how it works - the fear of "doing something in the wrong way" can stop people doing anything at all.

[claredillon]

We've had great examplease of people mentoring or coaching new folks through some of these steps - but have we formalized that as the best way to do it? Or do we still assume "look at the docs" is the preferred way?

[rrrutledge]

Mentoring is probably the easiest way for the newcomer to learn and gain confidence, but it is harder to scale as a foundation.

[rrrutledge]

Even if mentoring is happening, it is good to have docs so that:

• mentoring is consistent.
• The mentee can go back afterward and look at what they were told.
• There is option to discover what to do even if not having encountered a mentor.

[rrrutledge]

We should have a way for anyone to set up a one-time call or discussion in the InnerSource Commons.

[claredillon]

Near -peer mentoring may scale better than expert-newbie programs... hence the suggestion above. We could experiment with a more scalable verion that could be considered as part of a on-boarding program. A version that relies on the idea that you don't become a mentor indefinitely - you pass on what you learned to one/two people (more if you like), but the ask/expectation of ongoing mentorship is much lower... One of the problems with maintainter/mentor burnout is that the lack of mentors and the ask is too much of a time commit if there are loads of folks to on-board.

Also on the "mentoring in consistent" - a good goal in some contexts (e.g. principles of engagement) - but the actual on-boarding advice might be particular to the type of persona being on-boarding... so not consistent in that way.

[claredillon]

Near-peer mentoring (where someone who has just gone through it, pays it back) might be a good suggestion here. Stops overloading for the folks who have been doing this for a long time. This could be a technique or practice we might think about peppering around as an expectation. If you get helped, help someone else with the same thing. Reward both sides.

[mishari]

Hi,

I've been looking into engaging Octalysis and their gamification framework in order to design game mechanics around open source communities to improve things such as onboarding.

The only catch is I need a funding source to engage them on a trial project. If anyone has a source, please let me know.

Best regards
Mishari