After joining Fedora Project as a new contributor - what comes next?

Project Discussion
, ,
1

Hey everyone,
Sorry if I haven’t checked all the available resources or if this has been talked about before.

I’d like the join-sig group to also give their views on this.

Okay, people are joining - but what next?

There are two types of contributors I’ve noticed:

  • those who are new, like students, or transitioning to open source and want to earn a skill
  • those who are already experienced

My view here is on the first group - the new contributors who don’t have much experience yet. This is different from those who are already experienced; they know how to navigate, and I understand that they can catch up easily. I’ve seen that most of the people who have joined recently are in that second category - but let’s also talk about those who are in the first one.

I’ve been here for 8 months

Okay, I don’t mean I know much, but I’d like us to talk about this again, clear my thoughts, and also get your views on this.

From what I’ve seen, new contributors take time before they can start contributing. I don’t think it’s enough to just say “hang around until you find your way in.”

That’s fair - but in the past 8 months, I’ve seen and also talked to some of those new contributors. When I reached out to them recently, I couldn’t find them in the rooms anymore.

Which brings us to this:
Maybe maintainers of certain projects or teams (e.g. infra, devel) could tell us - do those new contributors end up contributing? How is it going? Maybe since the beginning of this year?

(Sorry if I haven’t researched or checked the survey to get the summary of how things have been.)

Current efforts I’ve seen

I’ve also seen a few other contributors - (Michael Winters(@mwinters) and Perpetrator - trying to beat this challenge, suggesting a few things to help:

(Thanks for that — posting here for visibility in case someone missed it in the rooms.)

But what comes after listing them? Sorry if I’m being too harsh or something, but let’s take an example:

You’d say, “check the first good issues (or beginner friendly)” - Issues · Fedora Websites · GitLab

Those issues were last opened in 2023 for that label.

I think it’s our responsibility as open source contributors to help others help us - by sparing time to create those issues. It’s us who are in those teams who can change that.

Again, I haven’t checked on other teams — maybe there’s more good first issues.

My suggestion

“Doubling the number of contributors” — are we really doing this the right way?
(I may be centered on my side, but I’m open to your views as well — and don’t be harsh on me, I’m only 8 months old :))

I suggest mentored bugs.

It’s the easiest and most flexible way. You see GSoC and Outreachy - they’re great, but those are paid. They attract new people, but they know it’s paid.

What if those who join willingly get the same kind of structured mentorship? They’re already here for good reasons - passion for open source, love for Fedora Linux, or wanting to learn a new skill.

Okay, I joined through Outreachy - I don’t know if I could have just joined Fedora earlier — but I fell in love with Fedora once I started as an applicant.

Let’s retain them. Mentored bugs would work!

Example from Mozilla

Mozilla has mentored bugs - it’s been smooth for new contributors to get involved and even stay. I’m one of them.

I wanted to explore browser internals, found mentored bugs, fixed a few (3), and went ahead to work on implementing a JS standard library feature. I got in touch with a contributor handling that area, and we’ve now been working together for almost a month on that feature — implementing the import bytes feature.

I’ll be honest - I don’t know much, but I’m doing it with the help of the community.

Yes, I’m helping - and maybe I’m slower than others - but that’s not the point. Let’s tie this to our “doubling” goal and our open source culture.

I learned this through my Mozilla experience. It was easier for me in Fedora since I had a project to do for the internship, but what about those who are just interested? Think about that.

Final thoughts

Can we do mentored bugs - have a mentor assigned to a certain bug?
Maybe comment the mentor’s name (username) in the bug, and anyone can follow up in the Matrix rooms?

Sorry if this post is too long, but I had to spit this out :slight_smile:
Also, don’t mind me - I love doing this when I have questions in my head.

6 Likes
2

oh, I forgot to tag our FPL - @jspaleta. I know you’re working on our goal - and we hope to hear from you as well soon on that and maybe if you have anything to add here, it’d be great.

1 Like
3

No, you are a lot faster. You are special.

Of the 20 Otreachy applicants, 3 approached me for mentorship, 2 of those asked maybe half a dozen questions and only you engaged with absolutely everything I had to offer.

The passion has to come from within. We can’t spoon-feed people.

Can we maintain a mentorship program where only 5% of people stick around?

5 Likes
4

@coredusk I’m glad you’re talking about this, I’ve had similar thoughts myself. Mentored bugs are a really good idea. I think the first step toward bringing in more contributors would be to build some sort of system that stays relevant for a long time, is easy to navigate, and simple to update as things evolve (could be software or an operational process). I’ve found the current setup a bit frustrating - maybe it’s just me - but there’s a lot of reading involved, and much of what you read might not be up to date.

Now, I know that if someone really wants to contribute, they’ll find their way, but as a community, we should make sure things aren’t heavy for newcomer. We could start by improving the existing infrastructure we already have, like What Can I Do for Fedora? That means improving the UI/UX, updating documentation, making things more accessible, etc. We should treat it like getfedora.org

Teams could also make sure there’s always something beginners can work on, tasks that help them understand how things operate and gradually build the skills to take on more. It’s also important to make sure these tasks are easy to find. Finally, as a community, we could host more social hour calls to talk to new contributors, play games, talk about their concerns and stuff like that.

4 Likes
5

I would read this discussion to get an understanding of why things are the way they are:

(There’s also a call for people to take the lead there.)

It’s great to come up with ideas to say “we should do X, and teams should do Y, and the community should to Z”—we encourage this. Where we seem to falter at is: “who is we?”, i.e., who is going to do this work?

At the moment, there’s no one path of what comes next. It’s left up to people to figure it out because here one size does not fit all. We had easyfix to funnel people into tasks, that didn’t work. We’ve had wcidff, that doesn’t work either apparently. There is also no one to maintain/improve either of these resources. If we want/expect existing community members to actively “mentor” newcomers, that hasn’t worked in the past either because we don’t seem to have enough community members with the extra resources to take this on.

So, I don’t have a concrete answer. The best I can come up with is: we give newcomers the resources and we make ourselves (the Join SIG for example) available to them to answer questions/queries and sign post them. This is where we’re at now with the Welcome to Fedora process.

So, in my view, we need discussions to come with concrete suggestions that are backed by volunteers who commit to taking the lead on those actions.

So: what are the concrete recommendations here, and who is going to take them on? What are “mentored bugs”. What resources do they need, both technical and human? Do we have these resources? If not, how can we obtain them? If we can’t, what is the best next thing that we can do?

4 Likes
6

Thanks MatH,

Yeah yeah. We’d need the numbers to grow as we progress - to easily onboard them quickly. The passion/energy within them would push them to take up those bugs - and since we would have mentors for those bugs it’d be easily fixed and they could move forward until they can handle things themselves later

7

I understand. It should just be simple.

What I would define as mentored bugs - it’s a bug that’s assigned(or just someone just volunteered) a mentor and that mentor is up to answer questions or help when someone is stuck with that specific bug. Of course if we have deadlines, and the mentee isn’t responding or haven’t been active for some time, the mentor can remove the assignee(mentee) from the bug and the mentor can solve the bug or make it open again for the next person interested.

The areas that doesn’t need technical expertise is doing fine and maybe they might not need to do this - but atleast give a word out to help if someone is willing to take up a task within a team.

I’ll do it myself as a pathway for a project that was done by the past outreachy intern - the release schedule planner - matrix room(https://matrix.to/#/#release-schedule-planner:fedora.im). I’d just need to file a bug, and if anyone would take up - I can redirect and show them resources - of course I’d advise the mentee to do research first (for example - how to use flask/bootstrap) that may be outside Fedora docs. We can chat in the room and share resources as long as someone(mentees) are active(?)

or even have something similar like this wiki page but for this specific project, and have resource there and all about the project. And be tagged in the room.

And lastly, can we have a badge for that? for example if you’ve mentored someone and they’ve pushed and got their PR(s) merged? @t0xic0der you’re doing something with badges!

Contributors around are good at answering questions, it won’t be hard to answer questions in a different platform(forge) just to help, it’s basically the same thing - it’s not teaching someone how to code.

1 Like
8

OK, how is this different from what easyfix was? It was a list of bugs that were considered good for others to work on, and each bug/issue had a point of contact for people to speak to.

Follow up: how is this different from what we have now where every issue/bug belongs to a team, and someone that wants to work on an issue needs to speak to the team to ask for clarifications—and then someone from the team steps in to help?

I think cookies are meant to be for this sort of thing. (In a matrix channel with zodbot, <fas>++). An explicit badge could be added too, sure—but it’d require someone to hand it out manually perhaps. (This is a second order problem, though)

9

Hehe, how about we revive it? and also I can now understand that it draws to personal level to speak up - that is for new contributors so that this would also be easy. Well, different people have different energies.

Is there a discussion about why the easy fix died? maybe I could draw some conclusions on it, and why we need to revive this again.

1 Like
10

Lots of discussions strewn all over the place, unfortunately. Search the forum for “easyfix”.

I’m sure t0xic0der was looking at re-doing easyfix, but decided not to. There’s a thread somewhere where he explains why too.

1 Like
11

I would be keen for someone to update WCIDFF.
The code is not difficult, however it may require working with the infra team to deploy the update.

2 Likes
12

Back to your core question “what comes next after after Joining Fedora?”

I would like to see a page in the Join docs, and a rewrite of the ‘welcome’ pack we send people who Join with the Join-SIG.

In that rewrite / additional info, we could provide the script that people need (the steps to take) to continue their journey.

Such steps would include how our current mentoring situation works - which is a group mentorship, based around SIGs, mailing lists and Matrix channels.

It could even include literal scripts such as “Hi, I joined Fedora with the Join SIG and they said I could come over and say hi. What projects are you working on at this time, and how can I get up to speed on that?”

If anyone wants to put together a draft, I’m happy to review it and to assist.

2 Likes
13

@theprogram I did it.,

Also:

Comment

Regards.,

2 Likes
14

Discussed in 2025-11-13 DEI Team meeting.

We had a very passionate, very engaging conversation about an adjacent topic about newcomer onboarding in today’s DEI Team meeting. The link to the topic is above. However, I want to copy-paste a specific part of the meeting summary that I think is relevant for this discussion:

There is a tricky balance we are walking here. One should walk in the shoes of the newcomer, but also the mentor/maintainer. Between all of the links to past discussions shared by @ankursinha and @hhlp, there is a lot of history to read about what we have tried before, what was successful, and what was not successful.

I have an optimistic view. While I think it is important to listen to the feedback and perspective of the many who have walked this path before, I think we should try and learn from our past mistakes and think about how we could try again.

I do feel strongly that in order for a newcomer onboarding and retention to be successful, we need to proactively engage and partner with some existing maintainers to help them out with this important but difficult work of bringing new people into the community. It is not enough to ask maintainers to simply “just do it” and start mentoring. First, not everyone has a clear picture of how to do that. (This is why we have a Fedora Mentor Summit event, to help teach people these skills!) Second, to do the mentoring and newcomer onboarding, it is actually a significant amount of new work. On one hand, yes, doing this work could maybe mean that more people come on-board and help out, there are also lots of examples of unsuccessful attempts at doing this on-boarding. And for the maintainers, then they have the sad feeling that they spent all this time helping someone new, but the person still goes away or doesn’t finish their big changes.

We can do better to bridge the gap. Any new effort to onboard newcomers to a project requires some proactive assistance to maintainers to help them do that. Fedora is an awesome community. We have people who are excellent engineers. We have people who are excellent communicators and people persons. Sometimes a person can be both, but actually, it is way more common that someone is one or the other. Fedora is not unique in this way even.

So, I think a more helpful and productive redirection for this conversation that accounts for the feedback given by the experienced folks, and also recognizes the new enthusiasm and energy from some newer folks, is figuring out how we can bridge the gap between the overloaded maintainers and the enthusiastic newcomers.

My big idea is choosing one or two projects as “newcomer-friendly” projects, where we can invite other Fedora contributors to help out with onboarding newcomers. Maybe not all of the helpers are expert coders, but they might know where to get help, who to ask for help, and which rope to pull for getting something done. This can help the overloaded maintainer in doing some of the community management work, while also getting the newcomer the validation and support that they need, when they need it.

Does any of this make sense? Is it resonating? I always dislike when I write long posts, because I know the average attention span of an adult is something like nine seconds or something ridiculous. Maybe my ideas are not clear enough, or maybe I need to ask an AI chatbot to make my ideas shorter and more concise.

But this is my raw feedback, without any AI alteration. If it doesn’t make sense to anyone, then maybe I will try to boil my thoughts down into something that is less long and rambling.

4 Likes
15

@theprogram @lochipi and I talked about this at stretch both during the DEI meeting where I was mentioned and also in the Fedora DEI chat. The “What next?” problem is indeed a tricky one and in addition to @ankursinha’s points (as he seems to have covered most of what I wanted to state) - I want to put some more points - to help draw a picture from both a project maintainer’s and an individual contributor’s perspective.

  • An act of contribution should be of the kind that provides mutual benefit. Just as much as project maintainers should not feel ashamed to use these as a means to meet deadlines, the individual contributors should come in with a self-serving intention. The intention might be to add a line to the resume for better employment, or to learn some difficult stack while contributing to a real world project. It is all valid - as long as both parties are able to derive something out of this.

  • As time goes on, this intention can evolve into something else. One of the reason why @ankursinha’s Welcome to Fedora Project workflow just works even after a decade or so (or prolly even more time) of its establishment is because while contributors come in with a certain purpose in their mind - they linger around long enough to make friends, meet mentors and heck, become mentors themselves. Hence, they outgrow their initial purpose so they start doing more than achieving that.

  • This purpose/intention part is like a mission/vision statement but on a personal level, you see. There have been times when I had also faced questions like “Oh well, the Fedora Websites and Apps Revamp Community Objective is done - What now?” but that purpose/intention in my mind helped me find things to work on and people to have fun with even after that was through. One of the best ways to “refuel” your purpose/intention is to talk with your fellow friends around Fedora Project.

  • I know just how frustrating it can be to hang around with literally nothing done to speak for it, but I also learned it the hard way, that it is even more difficult for the maintainers to be able to get back to folks right away with something to work on, when they have the entire Indian Cuisine on their plate. Looking at the issue tracker, starting with the documentation and doing some quality assurance while you hear back can ensure that you keep your wheels rolling, all while waiting for that reply.

  • I have brought this up doing the imakefedora.me conversation as well - it is not a technical stack problem but rather a people problem (which I learned after years of trying to revive the Fedora Easyfix project). A project maintainer is less inclined to make a self-contained and well documented issue ticket when that process takes longer than fixing the actual task itself - at the expense of an individual contributor’s potential experience because now they have to dive deeper to know more.

  • Let me use Fedora Badges’ example here to give you another perspective. This project is NOT prioritized right now by Red Hat CLE (@jbley can vouch for the same) and yet I try as much as I can spend some additional time on it. So already in the whatever little time, I ensure that I keep the ball rolling and provide mentorship to the likes of @sdglitched and others who come to its doors - but that’s already like 150% of the time (and I am certain, a bunch of ambitious devs are the same).

  • Given that Fedora Project has opened its doors to assistive AI-based tooling very recently with the Fedora Council ruling, I can suggest taking those for a spin to navigate a certain codebase or help understand the requirements from an issue ticket. I wished we had those back in our days and it would have made our lives so easy - I do think that Fedora Project allows folks to lower the barrier of entry with the use generative LLMs as long as the usage is under the permissive agreed-upon limits.

  • I can help with having mentored bugs in Fedora Badges. If you (or literally anyone reading this) want to contribute to the stack, learning Python and JavaScript while you are at it - please feel free to ping me in the Fedora Badges channel on Fedora Chat. There will be delays in responses as the Forgejo Initiative is the priority for me, but I will make it a point to get back to the messages as soon as possible. We can then use this contribution model to perhaps document standards for other projects.

5 Likes
16

@mwinters Talking about this:

Regards.,

17

A few things in https://whatcanidoforfedora.org still need updating. Overall is it is still fantastic, and if people can’t find their way around them they might need to learn to use a search engine.

We could remove the ‘modularity’ section.
Update the links from ‘ambassadors’.
I don’t know if ‘classroom’ is still active.
The link from ‘programming’ ‘c’ is not there (maybe link to matrix chat?) as there is no ‘c’ SIG.

1 Like
18

Atomic Desktop sigs would also be worth adding.

3 Likes
19

you can play with the new one:

Regards.,

2 Likes
20

Ok, Sweet.
You have an updated version in staging that you will push sometime soon?