Fedora Infrastructure has been a somewhat a complicated place for someone to start contributing to - often things are setup in a specific way and then there is the issue of access. There are a few open questions that may help improve the process.
Any input would be greatly appreciated.
Maybe we could also ask those question on the weekly Fedora Infra meeting.
I think this has been an issue for awhile now. Making the new-comer feel welcome, making the first contribution as easy as possible, well written docs for that person to read over to hopefully answer the basic questions, have all been a focus for awhile. Have we considered the “buddy” option before? If someone has joined the fi-apprentice program, is there a way we can then pair that person with an experienced engineer who would be in the same time zone and can walk the apprentice through their first ticket?
This is a good idea I think.
For anyone unaware we have weekly meetings on a Thursday at 16:00UTC. These are text meetings and all are welcome.
IRC: #fedora-meeting-3@libera.chat
Matrix: #meeting-3:fedoraproject.org
I think this is a possibility for some apprentices. It would depend on availability and scheduling. I would be happy to make myself available in a mentor capacity for someone willing to learn in the EU timezone.
As a mentee it is important to come with a goal in mind and an area of interest to look at. That makes it much easier to work with the correct person.
In the past we have avoided direct mentoring due to availability and fairness issues. We often have many more folks interested than we have mentors, so how do you decide who gets a mentor and who doesn’t? Or even if there’s capacity now, in a week say, a new person shows up and doesn’t have anyone left to mentor them. 
Because of that we have tried to have more a communal model, where anyone can ask anyone in the open about things and hopefully the answers are good for more than just the one person. 
One thing that might help us is to have a longer list of joining tasks that are more well defined. ie, introduce yourself, read this, and then… go do this tutorial, etc. So by the time someone is looking for tickets to work on we have a better idea of their interest areas and that they know something of our setup. That would require us to build that however, and some people might see that as a gatekeeping type thing.
Anyhow, I am all for trying things, I agree we need to/can definitely improve in this area. Thanks for starting this topic!
A 1:1 mentoring does look like an alluring choice in theory but it is less feasible/viable practically due to the timezone differences there may be between the mentor and mentee, and the count mapping of each cannot quite keep up with more influx of new contributors. What I’d suggest instead is to put our attention to making sure that our documentation/SoP is as refined as possible by maybe having someone new go through it and see if they reach the intended goal. This is what we planned for ourselves in the Websites and Apps Team and it has been going well so far.
Another means of improving contributions here include participation in formal mentorship activities like GSoC, Outreachy etc. There is an increased likeliness of retaining contributors beyond their official period of working in these cases and even they can help document stuff about Fedora Infrastructure. Surely the count will not be that huge but I would pick fewer consistent contributors over more fleeting contributors any day. This also helps ensure that the time/effort spent on mentoring a said newbie would probably be worth it - both for the mentor and the mentee (professionally) and for the team, as a whole.
Can think of plenty of ways to improve things, focus on documenting the tribal knowledge eg SOPs, high level architecture diagrams, modernisation of the metrics, monitoring stack.
Apprenticeships are the best way ultimately, making ourselves available to be shadowed.