Welcome!
I am also a new infra contributor. I'm still learning my way around the
project.
I will say - it is currently not easy to onboard here. Everyone knows
this, and there has been a lot of talk about how to fix it. But I think
the most important thing a new contributor can do is to think about what
onboarding experience you had *hoped* to see and what difficulties
you've encountered, and then at minimum write those down and share them.
It's very difficult for people who have been in a place for a long
time to "see what isn't there", e.g. which docs are needed or which old
projects were confusing red herrings that need to be cleaned up. (See
this classic article: https://danluu.com/wat/)
I'm currently doing a mix of 1) updating docs as I figure things out,
and 2) taking TODO notes of things I'd like to improve later once I
understand everything a little better. Docs contributions are always a
great place to start.
For basic project orientation:
- Get plugged into all the text comms channels, including the Community
Blog.
- I suggest turning on email notifications for repos and Discussion tags
that you are interested in, to get a feel for what's happening there.
Use your email client's automatic folder filing capabilities liberally
to stay sane.
- Even though I prefer text, I highly recommend checking out the 2024
Flock playlist on YouTube as well as the podcast. Both of these have
given me a lot of the project context that isn't really documented
anywhere else.
As for skills and tools:
- First, you should ask yourself -- what kind of work do you want to do?
Broadly speaking, do you want to run linux servers or write apps?
Because there is a line here (albeit a very blurry line) between
Infrastructure and Apps, and a lot of the code stuff is on the Apps side
of that line. So you might want to look in that direction too.
- For apps, you already know Python and Javascript. That's great, as
most of the code I've seen so far is using one of those.
- You'll need intermediate-level git skills no matter what you do, such
as such as sync'ing a fork by hand, rebasing, and signing off on
commits. Probably stuff you haven't had to do in smaller teams or on
Github.
- For infra you will need to know Ansible, and our ansible repo is
rather large and somewhat complex. So even if you know Ansible you may
need to spend some time staring at this to get your head around it.
- Some services have started to move to the OpenShift flavor of
Kubernetes. And whether you're ultimately more App or Infra, you'll
need to know the basics. If you've never worked with Kubernetes before,
I suggest to start with vanilla flavors such as minikube before checking
out openshift.
Regarding your questions about workflow and team coordination:
1.
A lot of the "IT" style work that this team does is what's called
"unplanned work". Meaning, something broke, or somebody is requesting a
change to permissions. Most of this work is not very collaborative by
nature -- a single person who knows how to solve the issue is going to
just go solve it. So there isn't a Kanban board or anything for that
stuff. Tickets are generally handled as Issues in various repositories,
and generic infrastructure tickets are filed in our infrastructure repo:
https://pagure.io/fedora-infrastructure/issues
You may find it useful to Watch that repo to get email alerts on tickets
as they come up. You could also look at some recently-closed tickets
and associated PRs to get a feel for the flow and how problems were solved.
2.
Not all of the work is unplanned work (thankfully!). In my opinion, we
actually have a lot of room for improvement in making that work visible
in a way where others can contribute (or even know what initiatives are
in progress / on deck / goals for the year / nice to have / etc.) It
seems that there have been various efforts in the past to achieve this,
but I get the sense that those efforts didn't have a lot of return on
investment in terms of added contributor help, so things naturally
returned to the lowest energy state.
To get involved with these larger projects, keep an ear out for things
that are happening (hint: look in recent public status updates), look
for something that sounds interesting, and then reach out and ask people
directly (in public spaces, not DM) where you can pitch in. Most large
initiatives here seem to be handled by one or two people, so there isn't
a "team" to go talk to.
Worst case: let the team know in the weekly meeting exactly how
available you plan to be over the next week (10 hours? 20?), and ask
for work. Nobody can resist letting all that free time go to waste when
it's on the table like that :)
Welcome again to being the newest newbie! You won't have that title for
long :) Feel free to reach me anywhere you find me.
Michael Winters
* *Familiarize myself with the workflow of Infrastructure.* I have no
idea where I could help, it feels a bit daunting. I have been
reading the tickets, the map of critical services, about each app,
and I'm yet to read the sysadmin and developer guide. So I believe
familiarizing myself with the workflow would make contributing easier.
* What things can I do to know how the team works? Besides reading the
docs and attending the meetings
* What advice would you give? You could answer this in a professional
or personal way. I see it as a way to get to know you better and
share wisdom
--
_______________________________________________
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/infrastructure@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
