Organising monthly new contributor cohorts

At the recent meeting in London there were a group of Fedora and Red Hat folks and we were talking about how we could improve our onboarding and retention of new community folks.

At the moment, people come in whenever and we direct them to the “welcome to Fedora” process:

https://pagure.io/fedora-join/Welcome-to-Fedora

While this does work, well better than the processes (or lack of) we had before, people coming in one by one still means that when they begin, they’re sort of by themselves—in the sense that there isn’t a small group of newcomers that can go through the whole process together.

So one idea was that we run monthly cohorts. For example, every first week of the month can be the Fedora Join Us week or something like that. This will be the week where we encourage people to start. That’ll be a cohort of people that join up together. We’ll open the tickets for them and help them work together as they navigate the welcome to Fedora process. We can then do things like weekly meetings where we meet the cohort together and help them through but being in a cohort also means they can have their own communications and so on.

Then, for the next few weeks, until the next “join up” week comes, we’ll collect the next set of people that want to join us and then bring them in together.

What do people think of this?

2 Likes

CC: @hhlp @alciregi @jflory7 (and everyone else!)

It seems like a great strategy to me, however, it seems to me that there is a little more left on the way forward, that is, the breadcrumbs, when we get to fedora as expected, but a step by step could be useful. Something that directs users to segmentation, that is, criteria such as whether it is a developer, languages, experiences, and very especially about internationalization, a clear example is that Latinos who generally speak Spanish could be guided by seniors with language mastery. I have been searching for my place in Fedora for several months, and although my small and insignificant contributions have been very well received, I think I could give more if I had more clarity on where I can be useful.

1 Like

It seems a very good proposal to me, almost ideal, the only little concern that I would have is that the effort needed by current members of the community sounds way bigger than the current process, so I don’t know how well the proposed process can be maintained in the long term.

2 Likes

This process creates much formality and has a high entry barrier. This can be already deterring. Just to read through this stuff makes me fear to maybe have overlooked something, and it takes time. Tickets and comparable stuff also create pressures to contribute - people think twice before doing that. They do not know what is to come once they open the ticket (or comparable activities), but at the same time, they would need to actively retreat after. People don’t like to do that (=entry barrier, deterrence).

Also, many (if not most) SIGs / WGs are tailored to their upstream - this is the nature of Fedora. Thus, there is no central organization/approach when it comes to understand why they do, what they do, how they do and thus if they fit me. I do not think that any central point of “how to” can fit all Fedora groups given their differently-organized upstream. It creates just work and entry barriers - and maybe even misinterpretations.

When people come through development, they are likely to end up in the devel mailing list. It has a quite simple rule: introduce yourself! Tell who you are, what you can, what you want to do and what your motivations are. Quite helpful to help you to find yourself in the devel list (and related people/groups) I think.

Why not do the same for non-developers?

We officially made discourse to our central point of interaction: If people are new, let them add a topic where they elaborate the same things as when they introduce themselves to the devel mailing list: if WG/SIG seek contributors, they shall check the “newcomers” category (which we then need to create) and see if there is someone they might make aware of themselves. They can identify and explain best.

Also, this way we motivate SIGs/WGs to review discourse more actively. If they don’t seek contribution, it is their own decision. And having more people reviewing discourse makes also more people to outreach to other Fedora elements (even if just by becoming aware of them).

We might find people who weekly check the newcomer category and maybe make people aware if they should maybe rather go to the devel mailing list, or make suggestions and at least say hello (effectively this would be the JOIN SIG, but also the contributors/volunteers of the quarterly intro topics; I can help here).

I tend to assume that this approach would replace the quarterly introduction topics, and create an introduction topic for each user. I know, more topics, but easy to sort if we had a category for it: and we never had so many newcomers that the amount of topics would be problematic. It’s just a few here and there.

Saying informally “hello” at a place, where people with related affinities are, seems to be what people intuitively appreciate: why stopping this in intro topics after the initial “hello & welcome”? At “Hello & welcome” (no entry barrier - but be careful what you ask them to tell in order to keep it that way!) is where the “flow” can begin intuitively, and where we can foster it to intuitively continue/develop (and where SIGs/WGs can make aware of themselves easily and without much efforts).

A permanently pinned topic for newcomers might be an additional incentive/facilitator.

Just an alternative perspective :sunglasses:

1 Like

Group onboarding is feasible and time efficient for mentors/helpers. We could group new joiners into categories/interests, for example.

  • Package maintenance
  • Design, UX/UI
  • A specific SIG

We need volunteers from relevant working groups as mentors/guides.

My time for contribution can be redistributed, so it doesn’t overstretch my time commitment.

On another note, with my employer at work, group onboarding is actually tried and tested method for new recruits and volunteers. I run onboarding session with distributed team of volunteers (subject matter experts). My colleagues believe initial time investment will pay off in the long term and help increase job satisfaction of interns and new joiners. After COVID, onboarding support is even more effective in bringing team together than pre-COVID.

Well, that’s a passing thought before my holiday. I’ll engage once again after I come back in end April.

2 Likes

this would be really good to help and get all the tools and how to use etc since i feel it is hard to start and find everything on multiple wikis and then sign in on multiple platforms matrix, irc, discussion etc jump in and out and what actually need to do and how is like I’m so lost and confused that i don’t know is it worth of my time to search and read and try and ask what and where.

i try to learn and contribute and take more steps to move forward slowly when i learn more

so making this would help alot on new comers and new contributers how to jump all the hoops and learn how to and where to and what to use not just spend days on wikis trying to figure stuff out

1 Like