Greetings infra folks (and any others)!
At the recent 2023 flock in Cork, James Richardson and I held a workshop on onboading, mentoring and documentation in the Fedora Infrastructure and Release engineering teams. We had a very lively discussion for the first part of the workshop and then mush less so for the second part after Lunch. (Many people had to leave as it was the last day and other excellent discussions were going on too).
So, this is going to be a long post, but we wanted to recap what we discussed there, present the current plans for documentation changes, and then ask some questions that we didn’t get to or didn’t finish talking about.
First I started in with some background and a drawing (all be it small to read for the people in the room). Fedora Infrastructure and Releng have always been teams that depended on community involvement. While there’s some folks paid by Red Hat to work on these things, they act more as a flywheel ( The flywheel theory of community engagement - Duck Alignment Academy ) to keep things moving along and onboard new folks.
A expanded version of what I had drawn:
marketing / outreach onboarding - apprentice program - drive by fixers - experienced folks progression and learning sysadmin groups sysadmin main offboarding
Basically a flow or set of flows for people to follow when they wished to contribute, either by joining as an apprentice and learning from there, or also handling cases of drive by fixes or people who are already knowledgeable who want to contribute.
Some of the items discussed:
what CPE is (the community platform engineering team in Red Hat where
many of the people working in this space are). There was discussion about
changing the weekly CPE reports to be infra and releng one with a CPE section
in it. We need to document the relationship and what it is.
Mentoring. How can we match people to mentors? Some kind of greeter/person
to direct new people. Can 1x1 mentors even work? What if there’s no mentors
available or in the same timezones?
Badges. Doing series of badges so people know what to do/learn.
This is going to take the new badges re-write being available.
Different types of newcomers: Totally new to linux, just want to fix something,
know a lot, want to learn another area.
Talk about permissions. We have always operated from the idea that
you shouldnt request permissions, you should be granted them if you need
to do something, but this wasn’t explained in docs at all. Also, there’s a
lot of subjective ‘are you ready for this permission’ that perhaps should
be more concrete and in documentation.
Some discussion of offboarding. Perhaps tie some things to Fedora release cycles
so people are removed when they become inactive. Also, having a mentor might help
to see when someone wants to step back.
So, based on all this, we came up with the following outline for docs
(subject to change):
getting help for users
- How to report issues / how our team works day to day
- How to contact us
- pointer to “one off contributions”
- who we are and what we do
- release engineering
- what is CPE? How does it relate?
- stakeholders and customers
- fedora council
- overview of the rest of the docs
- default to open
- polite, friendly, welcoming
- teach others who want to learn
- ask in the most public space you are comfortable with
- How our permissions model works
trust and permissions gained over time as needed
when you might be given more permissions
- sysadmin-* groups
Usually specific apps and areas.
how and why people are added
what kind of perms do they have
- Red Hat only resources
explain hardware budgeting, etc
One off contributions
- what sort of account(s) do you need?
- explain how to submit PR’s/MR’s
- explain how to figure out where
Joining the team
- intro tasks
- make an account
- (other non philosophy getting started things)
- get a mentor assigned
- pool of tasks to learn from / qualifications list
- attend a meeting
- run a meeting
- shadow an oncall person
- be the oncall person
- submit a PR/MR
- solve a ticket
- get X karma answering questions in matrix
- login to batcave01
- run an ansible playbook
- enroll a 2fa on your account
- … brainstorm and setup a bunch more…
- be promoted to a sysadmin group
- bunch of questions about this one
- intro tasks / setup
- setup development env
- how to find issues to work on
- … bunch of other tasks …
- bunch of questions about this one
Leaving the team
- When someone announces leaving
- Some kinds of cleanup processes for inactive members?
- Tied to fedora release cycles?
We need to fill in a good deal more things, but hopefully this docs setup makes sense?
There’s a bunch of outstanding questions we would love to get feedback on:
Need to brainstorm a bunch more things for the qualification list.
I think it would be great to have just a ton of these to get new people
interested doing the ones they find interacting and learning more.
We also need a way to check off things (badges might be great,
but perhaps we need a tracking ticket or something?)
should we fold developers into operations/apprentice?
Or should they have a completely different path?
What does onboarding/progression look like on the development side?
How can we tell what to do with experienced people?
Make them follow the apprentice track or part of it?
What kinds of cleanup/inactive process do we want? after every cycle?
We need to list all the places to clean up and how to do it.
How can we match mentors/mentees if we try and do 1x1… and
if we don’t have enough mentors what do we do?
or not enough in some timezone?
Can group mentoring still work?
So, if you made it to the end, thanks! Here’s a cat ( ) I hope we can work up a nicer onboarding workflow and get more people interested and involved. Feedback in particular from people who would like to use these docs would be very welcome.
Note that tomorrow I am off and then the weekend and then monday is a holiday,
so I may not reply too much here until next week, but I will definitely read
all the feedback.