Please also see this related post:
1 Like
I apologize for being very late to this discussion. I confess that I have not successfully found a good way to follow topics that I care about on Fedora Discussion. I will try to better keep up with conversations like this. 
A ticket is formal. If there were a faster way to connect a prospective mentee or junior contributor with a senior contributor, I think this would help lower the barrier to entry.
I skimmed over this other topic shared earlier this week, which feels like a possible approach to lowering this barrier.
This is a great point. The best mitigation is to involve a diverse range of Fedora contributors who can represent various levels of the Fedora community. No mentee or mentor is the exact same; bringing in new contributors will also have its own uniqueness.
Could we also use the Fedora Mentoring Matrix chat (#mentoring:fedoraproject.org) to talk more too? I think our challenge is trying to funnel people into one specific place. If we can embrace the decentralized way that we work, it might become easier for people to get connected to engaging contributions more quickly.
Exactly like this! 
Could you share an example of what makes an onboarding session helpful or effective? Do you have general tips or guidance on how we could trial something like this in Fedora?
We need a better community map. The old Fedora Apps viewer was close to the spirit of this, but it is not as maintained as I wish it were.
https://apps.fedoraproject.org/
Now is a convenient time to think about how we can do it better. The migration to Forgejo is looming. But I think this is a great opportunity for us to be leaders in how to onboard new community contributors using our primary, self-hosted git forge.
This is a long-loved application in the community. Perhaps we can rebuild enthusiasm for community involvement with making it work very well for the next decade of Fedora. Although the UX for that web app has not evolved with the times, the enthusiasm in the community is maintained across generations of contributors. It is familiar and very much built in the spirit of “Friends” Foundation.
Oh no. 
This used to be a very similar site hosted by Mozilla. We took inspiration from the original Mozilla site for the one used today in Fedora. I guess this makes Fedora the de-facto upstream of this project now.
3 Likes
Unfortunately, such a system/way does not exist (nor has it ever existed)? Given the async nature of the community, we will always rely on some system that allows async communication. It could be a topic here on discourse, or a ticket on Pagure as we do now, or the mailing list or a chat channel, but it’ll need some shared location. The idea of the tickets is to give the newcomers ownership of their tickets. Yes, i guess it feels a bit formal, but I think anything that’s part of some process/pipeline will have some formality attached to it.
Sure. My only concern is that wherever we expect newcomers to go, we must have contributors who will help them. The idea of the Join SIG came from observations that there weren’t enough people in all our channels to help newcomers. So, we thought it better to come up with one consolidated location where newcomers come, and that we contributors can monitor. I’m happy to continue monitoring the join sig channels, but someone will have to commit to monitoring the others. if we can’t ensure this commitment/accountability, i’d rather not have multiple channels where newcomers don’t get the support they need.
Channels like -devel can feel a bit daunting to users, so another reason behind the join-sig channels was to create a separate “safe space” for newcomers where they could communicate with each other.
We do this in the welcome to Fedora tickets using the “interest” tags, for example:
https://pagure.io/fedora-join/WelcomeToFedora/issue/31
Ideally, what we’d like is for contributors who share these interests to come along and perhaps help newcomers, as Chris as suggested, but this hasn’t happened as far as I can see.
Sure, i don’t think where we do it matters so much. Pagure/GitLab/Forgejo/whatever are all OK. What’s important is that we have enough humans looking at it.
I’ve said this elsewhere—the issue, for me, isn’t the pipeline/tooling/whatever. It’s always been the lack of humans to help newcomers. So, if folks have ideas on how to get more existing contributors (a majority of who are volunteers and have very limited time) involved in whatever process/pipelines we set up, I’d put my limited resources behind those. Having contributor cohorts should hopefully get more newcomers speaking to each other.
4 Likes
Perhaps we can better distinguish between formal and informal mentoring? I learned a lot from @smeragoel and @riecatnor’s Mentorship Level Up workshop at Flock, which helped demonstrate how different mentoring approaches work for different kinds of people.
Does it have to be one place? Or is it better if we lean into other channels used by specific teams and SIGs, or those that have an onboarding process?
Fair. I think it is better to direct more experienced contributors to the Join SIG spaces. But I think it is hard for experienced and advanced contributors to help out. For example, I feel like the most I can do is open a ticket for a newcomer on Pagure, but I do not use Pagure regularly and I miss a lot of notifications there… I am better with GitLab and Matrix.
I agree that it is better to consolidate. But how can we get more experienced contributors to participate and show up? How can we widen the net of folks helping out on the mentoring side?
Is there documentation about this? I have seen the tags but I am little overwhelmed by the choices. If there is guidance on how they are designed to work, I could probably be more effective at triaging new tickets.
I think these two challenges are interlocked. Where we do it does matter, because we ask Fedora contributors to be spread out across various platforms. And we need to make sure that there are enough humans in the platforms where we are directing people to engage.
I think we have a big challenge with fragmentation… maybe we can use the momentum of changing the git forge to document the existing process into Forgejo, and shoulder-tap some other experienced contributors to help out with the revised process. We can use the momentum of the new git forge to do some recruitment while the excitement and buzz of the new forge is high.
Once this is in place, I would feel more comfortable with running contributor cohort. At least, speaking for myself as a potential mentor/coach.
2 Likes
In the long-run, we can’t use two ticketing systems - so it has to be Pagure or Forgejo. Therefore it will (future tense) be Forgejo. There is no problem updating the landing page at Pagure, it can simply be copy-pasted to Forgejo. And the ticketing system is already in place at Pagure so no their extra work dealing with that. We can at this time check in on newcomers and offer them help. Just pick up a ticket and contact them.
A question then: what is the format of the “new contributor” cohorts. I take it that it is a group format (cohort) for new contributors? What systems do we have in place for online group meetings or discussion? Discourse and Matrix. I spend a lot of time (at the moment) on Discourse and it does not seem to be a place to have more informal chats. The watercooler is not a busy space. Discourse is very focussed on problem/resolution and notifications. Matrix it is then.
Let’s just guide newcomers to Matrix to talk amongst themselves with good-folks from Join-SIG to be responsive and encouraging; to moderate and guide.
Routing people from Matrix to an interest area is the next step. Someone on Join-SIG will have to have a contact directory (which only comes with extended institutional knowledge) to to route the newcomers to their desired workspace. Some spaces are easy to access and have Matrix rooms or active mailing lists. Others are more difficult and gated areas.
One thing I can see that is not being done well is analysing and testing the skills of newcomers. Many volunteers want to help out (often to enhance their careers) but need don’t have a real idea of what they are engaging with. If you want to enter Kung-Fu temple, you don’t just wait at the gates. You look over the fence and start practicing.
Helping with this (demonstrating) skill-building and engagement should be a big part of a new contributor cohort. Others already have all the skills. Let them show them off.
To sum. We have the required processes and infrastructure to onboard in place already. Making people feel valued and connected in their early stages is key to retention.
PS, @jflory7 I read your Mastodon and I am in general onboard with your ideas about decentralization. I would like to discuss with you at a later time. Also I’ve been looking for the author of the Dylan Thomas poem you posted for years!
4 Likes
This is a great discussion, and I fully support the idea of organizing structured mentoring for new contributors. While aligning with Git forge integration and other ideal conditions would be beneficial, I believe we don’t have to wait for everything to be perfectly in place to take action.
From my own recent experience, I joined the Fedora (& Rocky Linux) Localization team and was able to grasp workflow quickly thanks to the help I received via the Matrix (& Mattermost) chat. The existing contributors were welcoming and provided the guidance I needed to understand the team dynamics, which allowed me to start contributing to Korean translations without much delay for Rocky Linux. This hands-on support made a huge difference, and I can see how a structured mentoring approach could provide similar benefits to many new contributors across different teams.
One challenge in mentoring is that mentees and mentors often have different levels of experience, expectations, and time zones, which can make coordination tricky. However, the key takeaway from my experience is that even small, consistent efforts to support new contributors can have an immediate impact. Rather than waiting for a perfect system, creating a welcoming environment and facilitating real-time or asynchronous interactions can go a long way.
I’d love to see this initiative move forward and would be happy to contribute in any way I can (my new timezone: UTC+9) !
2 Likes
Mentorship places a great strain and mostly unrealistic expectations on both parties. The other way of approaching training - and a way that I have found great, some might say overwhelming, success in - is in asking relevant parties for help in relevant issues. This way false or forced relationships are not forged. Questions are answered by the best person and friendships and collegiate may follow naturally.
I’m at +1030 so pretty close (in a global sense)
PS. I’ve just updated a dozen tickets Issues - fedora-join/WelcomeToFedora - Pagure.io and I can see that we need to action something pretty soon! I can probably do another dozen this weekend if someone wants to check up on my work!
2 Likes
You are absolutely right. Mentorship can create pressure for both mentees and mentors. Here are some ways to address this and create a more sustainable, low-pressure system.
-
While challenges like coordinating across different experience levels and time zones exist, my suggestion to focus on small, consistent efforts could indeed make a difference. By fostering asynchronous interactions, we can create an inclusive atmosphere that benefits newcomers. Your willingness to explore opportunities for mutual support, especially considering your time zone (UTC+10:30), is greatly appreciated and will be valuable as we move this initiative forward
-
Shift from “Mentorship” to “Guided Onboarding”
Instead of framing it as traditional mentorship (which implies a significant time commitment), consider a “guided onboarding” approach where newcomers can get help at their own pace.
- Use a Buddy or Peer Support Model
Rather than a strict mentor-mentee structure, create a peer support system where contributors help each other in small, informal ways. Rotating “buddies” for short periods can reduce the burden on any single mentor.
- Build a Self-Service Knowledge Base
I’m a big fan of self-serve starters. A well-documented set of onboarding materials, FAQs, and recorded sessions can help newcomers find answers without always needing a mentor. Mentors can then focus on higher-level guidance rather than answering the same questions repeatedly.
- Promote Asynchronous Communication
Encourage new contributors to ask questions in public forums (like Fedora Discussion or chat channels) instead of relying on direct one-on-one mentorship. This way, multiple people can help, reducing pressure on any single mentor.
- Recognize and Reward Mentors
Acknowledging mentors’ efforts through badges, shoutouts, or other forms of appreciation can make the role feel more rewarding rather than just an obligation.
4 Likes
It all looks very good. Thanks for doing that. Ideally if we have a few folks happy to do this, we should do this perhaps once a month (instead of once in 8 months :))
1 Like
Hank, thanks for unpacking the ideas about moving on from mentorship. That is a really great rundown.
To not dismiss mentorship entirely, it would be suited to a time-limited event such as ‘Summer of Code’. We could call that ‘Buddy System’ thought.
Speaking of ‘Buddy System’ @ancarrol has some good ideas written up on Pagure. The council closed the ticket and asked them to talk with Join SIG about it. I think we should engage with their ideas. Fedora-Council/tickets ticket #524: Onboarding and Retention
Over the weekend, I reviewed all the ‘Welcome to Fedora’ tickets for the last 8 months. Over that time their have been 49 signups. Issues - fedora-join/WelcomeToFedora - Pagure.io
Extrapolating to the year, that makes around 4 signups per month. From the approx 35 people I contacted, I have recieved 3 responses so far (plus 1 that was already onboard).
I have calculated that we currently have an 4% to 8% retention rate with the current system.
I predict that ‘Monthly Contributor Cohorts’ will have a monthly cohort of 1 to 2 people. Thus rendering the motivation for a group activity moot for the time being.
What do we do then? There are 41 members of Fedora Accounts but I only see around 8 active people in this and associated channels.
What we do is 1) Stick to our current workflow for now. 2) Discuss more outreach or changes to our current workflow.
Is there a group meeting that happens or a key decision making body for Join?
To clarify, monthly new contributor cohorts are not going to work, simply because of the numbers we have at this time. We need to do something else.
2 Likes
I took inspiration from this discussion to start a commops-team discussion to rally a cohort of contributors for the F42 release cycle. I am not sure how it is going to go yet… it is an experiment. 
But I felt like, the worst thing that could happen is that it doesn’t work.
1 Like
I find the mashup of contributor conversations with Ask Fedora to be a huge barrier for me using Fedora Discussion more effectively. 
I’m working on it, but it is hard for me.
A challenge here is that it is important to have separate communication options for synchronous comms and asynchronous comms. For synchronous, this is like Matrix or a video call: real-time, quick feedback, sequential. For asynchronous, this is like Discourse or a mailing list: over time, long feedback loops, non-sequential. Having both as an option is an effective way of making it easier for a diverse group of people to contribute to your open source project. It is why Matrix works better for me than Fedora Discussion, and also why I am better at keeping up on Matrix.
What ideas do you have for doing this better in Fedora?
Apt summary! 
Do you think that organizing the community into world regions makes this easier or harder? Would working with a mentor or mentee in your native language or from your region make coordination easier?
I like this idea a lot! I read it after I posted the link in my previous reply, but the CommOps onboarding thread is basically meant to be like this: guided onboarding.
Based on your experience as a Fedora community contributor, what do you think a buddy program might look like for Fedora? How would it function? Does it take authority from an existing team or group in Fedora?
I wonder how our Fedora Docs site could better suit the needs of a knowledgebase instead of a curated, “book-like” structure.
This is something that came up at the recent Fedora Council 2025 Hackfest. I believe @sumantrom and @jonatoni could share more about this.
1 Like
I am talking only about the ‘Welcome to Fedora’ process of the Join SIG on pagure. The people that find their own way with no help are being ‘managed’ exceptionally well as evidenced by the fact that Fedora works exceptionally well.
As I see it, the Welcome to Fedora process targets people that either 1) Don’t really know what they are getting into, and 2) People that need their hand held for a short time to get acquainted and feel like they have permission to proceed.
Part of the reason for the low retention rate (as evidenced by the “I am Fedora” tags awarded on Pagure) is that we are willing to accept people in to the process based on a single request.
Asking more questions and having an introduction prior to acceptance should help increase the retention rate by lowering the number of tickets created.
As Ankur has said, the required human resources to properly manage the JoinSIG have not been in place. I’m more that willing to help out here for a few months, but I can’t promise more than that as I have a lot upcoming.
So, suggestions: 1) Change the workflow to first require an introduction via the JoinSIG mailing list before opening their ticket. 2) Have people ask more questions of recruits on Matrix. Have ‘tour-guides’ that can show people around without signing them up. 3) Continue with the excellent efforts you have started with the F42 CommOps Cohort - it already has traction after one day. 4) Make it easier to find current contributors (trim the groups 
)
PS, You write and are engaged very well on Discourse. The long-feedback loops suit the kind of work you do. You take things on board and develop programs very responsively. Matrix feels quicker but I think you deal with the workflow better in an asynchronous manner (if I may humbly say so), excepting such stuff like testing Forgejo where synchronous is required.
1 Like
It would be harder to organize the community into regions. When people organize a regular event, a timezone that suits most regions would be appreciated. The de-facto language for communication should remain English.
We could define whether the program is for onboarding, skill development, or long-term mentorship. The next is a matching system, which is a bit tricky;
Manual Matching: Organizers pair mentors and newcomers based on interests, skills, and time zones.
Self-Matching: New contributors choose mentors from a list.
Automated Matching: Use forms and scripts to pair based on skills, interests, duration, and availability.
I learned that self-service guides for each working group / SIGs vary. Some would find it easy to start contributing without hanging around in the Matrix room. I’m not suggesting restructuring contributor guides.
1 Like
I agree with Hank that we should have one global region and one default language. We simply do not have the human resources to do anything else.
1 Like