Infra team - onboarding and work visibilty

Project Discussion
,
1

I’ve been onboarding to Fedora Infra for a little while, and I’ve made a lot of observations and notes about opportunities to improve the experience. The single biggest gap that I can see for new contributors is also a “non-incremental” change that I’d like to propose here, which will require coordination and buy-in from existing contributors. That is: making the work visible.

Unplanned work

I’m not talking about the “unplanned work” like break/fix stuff and community requests for permissions changes and other tweaks. There is some room for improvement here, but in general this type of work is not a good place for new users to start contributing because it requires a lot of knowledge and granted permissions, and it’s not easy to collaborate on. So I don’t think any changes here will dramatically benefit new users.

Planned work

However, the “planned work” is currently either mostly invisible or scattered across repo issues, Discussion threads, and various documents that are not really discoverable. For example, there is no single fedora-infrastructure Issue that covers the Forgejo migration - only a few “tweaks” requests. There is an issue for the Zabbix migration, but it was last updated 6 months ago. And there is nothing discussing Anubis, leftovers from RDU migration, etc etc, let alone anything which may be known and coming down the pipe, or our 6-24 month aspirations and desires.

If newbies can’t see what’s being worked on or what we’d like to work on, they can’t contribute to it. And newbies not getting traction is worse for us long-term than not attracting new contributors at all, because a single person’s success or failure has a way of growing beyond them.

Suggestions

I see some ancient Pagure boards out there that looked promising until I realized that there was stuff in the Backlog column that was completed >2 years ago.

Here’s a plan I’d like to suggest. Please poke holes vigorously.

  1. Clean up all existing boards so that there are no red herrings out there. Delete them entirely if possible.
  2. Establish a Kanban board outside of the fedora-infrastructure repo, to create separation of “unplanned work” from “planned work”. This provides the necessary clarity for all involved, and lets us tweak these processes separately.
  3. For any effort that is expected to take more than 2 weeks (negotiable!), we should have a task / issue out there which is:
    1. Assigned to a “steward”.
    2. Lists any contributors or “intends to contribute” members.
    3. Outlines basic plans and current status at a very high level. This could be 20 words and some links.
    4. Has some mechanism by which a newbie can express interest in contributing, along with a few words about their availability and what they could work on. This could just be a comment mechanism, or something more elaborate. But it must notify the steward, and the the steward is expected to respond to these. Note that the steward does not need to be closely linked to the work if the primary contributor is not interested or available in stewarding. The steward just takes responsibility for keeping one eye on the work and communicating and connecting the dots when newcomers express interest.
  4. At least once every 3 months we go through a round of updating the board. We ask stewards and primaries to do this independently, but we also dedicate a weekly meeting every quarter to ensuring that everything has updates and there is no lingering cruft. Anything which still needs an update at the end of the meeting becomes an assigned issue to get it updated. And to hold ourselves accountable, we have an eternal “canary” item, which encourages people to yell loudly if it goes without updates. If this gets too far out of date, at least then it’s visible to newcomers that this process is dead / unhealthy.
  5. This is probably the hardest part… we need to make an effort of predicting and/or requesting the future. Aka, a real backlog, which is separate from the day-to-day unplanned tickets. This doesn’t have to be very detailed, but we should have at least something out there for major anticipated or desired future work, and/or our “2025 goals” or similar. Something that A) tells people what they could get ready for, so they can be in position when the work actually comes, and/or B) tells people what major work is not happening (example: Anubis circa 2 months ago) just because nobody has yet dedicated the time to it.

Ideally, the “primary contributor” towards any major efforts would also be the steward. But I’ll hereby cautiously nominate myself as the steward for the foreseeable future on anything where the primary is not available or interested. I don’t want that to become the norm, but I also think it’s important to get this off the ground and make the project approachable for newcomers.

Next steps

  • I currently have zero permissions in Fedora, including to clean up obviously-ancient Pagure boards. I’m willing to do all of the legwork that I ever suggest (here or in any other thread), but I either need permissions or someone else with the right permissions needs to take this. Whether we move forward with anything else, we should definitely clean this up. It’s disheartening to see this cruft as a newcomer.
  • We need some consensus that this process seems A) at least plausible, and B) beneficial to retaining new contributors. We don’t have to agree that it’s going to work, just that it might work and might help. And I would suggest that new voices should weigh a little more heavily here than old-timers.
  • If we generally agree that this process might be feasible, we need to decide where it should be hosted. Forgejo does have a kanban system like Pagure, which is linked to issues. This seems like the right place to me, but I don’t really know the full status of Forgejo today.
  • We also need to incorporate this “grooming” meeting into our Fedocal.

Hit me

It’s always easy for the noob to come in and declare that we need to rewrite everything :slight_smile: . I have zero knowledge of the battle scars or constraints here. Tell me what I’m missing! Hit me with the clue bat! Let’s get this conversation moving, because everyone seems to acknowledge “the onboarding problem”, and I believe that this is a fairly high-impact / low effort option which would help significantly.

And just to re-iterate: I’m happy to do all the work to get this off the ground. I just need others to be willing to share what’s in their head.

1 Like
3

Fantastic! When I first Joined (not that long ago) I cleaned up the Join SIG pagure tickets.
Super glad to have you here. I’ll write a fuller response to your proposals tomorrow, but in general I like the way you are thinking.

4

You’ve (inadvertantly?) convinced me to Join the Join :slight_smile: . More on this elsewhere.

1 Like
5

I’ve been onboarding to Fedora Infra for a little while, and I’ve made a lot of observations and notes about opportunities to improve the experience. The single biggest gap that I can see for new contributors is also a “non-incremental” change that I’d like to propose here, which will require coordination and buy-in from existing contributors. That is: making the work visible.

Unplanned work

I’m not talking about the “unplanned work” like break/fix stuff and community requests for permissions changes and other tweaks. There is some room for improvement here, but fundamentally most of this work is 1) not easy or necessary to collaborate on, since a single contributor can respond and deliver, and 2) not a good place to start for new users. So for the most part, I’m not talking about any changes here.

Planned work

However, the “planned work” is currently either mostly invisible or scattered across repo issues, Discussion threads, and various documents that are not really discoverable. For example, there is no single fedora-infrastructure Issue that covers the Forgejo migration - only a few “tweaks” requests. There is an issue for the Zabbix migration, but it was last updated 6 months ago. And there is nothing discussing Anubis, leftovers from RDU migration, etc etc, let alone anything which may be known and coming down the pipe, or our 6-24 month aspirations and desires.

anubis: Issue #12463: [Spike] Investigate options for mitigating AI scrapers - fedora-infrastructure - Pagure.io but I
suppose I should have closed that and opened a new one.

RDU migration items:

Things coming down the pipe and beyond are somewhat difficult.
There are things we would like to do, sure, but also there’s things that
come from the fedora council/fesco to do, or where we just provide
logistics and such.

Don’t get me wrong, I would love to have a nice well planned roadmap,
but it’s not really easy in a community space.

The CLE team (Community Linux Engineering) which some of us are members
of is working on coming up with a unified backlog and doing sprints.
That may help some of this.

If newbies can’t see what’s being worked on or what we’d like to work on, they can’t contribute to it. And newbies not getting traction is worse for us long-term than not attracting new contributors at all, because a single person’s success or failure has a way of growing beyond them.

Indeed.

Suggestions

I see some ancient Pagure boards out there that looked promising until I realized that there was stuff in the Backlog column that was completed >2 years ago.

Here’s a plan I’d like to suggest. Please poke holes vigorously.

  1. Clean up all existing boards so that there are no red herrings out there. Delete them entirely if possible.

We are moving git forges very soon. The boards on pagure.io will not be
something used anymore (if they were). So, we should be able to delete
or archive those once we move.

  1. Establish a Kanban board outside of the fedora-infrastructure repo, to create separation of “unplanned work” from “planned work”. This provides the necessary clarity for all involved, and lets us tweak these processes separately.

We could do this as part of the forge move sure.

Note that in the past we did have this… larger planned work was
“initatives”.

  1. For any effort that is expected to take more than 2 weeks (negotiable!), we should have a task / issue out there which is:
    1. Assigned to a “steward”.
    2. Lists any contributors or “intends to contribute” members.
    3. Outlines basic plans and current status at a very high level. This could be 20 words and some links.
    4. Has some mechanism by which a newbie can express interest in contributing, along with a few words about their availability and what they could work on. This could just be a comment mechanism, or something more elaborate. But it must notify the steward, and the the steward is expected to respond to these. Note that the steward does not need to be closely linked to the work if the primary contributor is not interested or available in stewarding. The steward just takes responsibility for keeping one eye on the work and communicating and connecting the dots when newcomers express interest.

This is the sort of thing that would be in a ticket tracking the task
no?

There’s also a number of other issues here:

  • Does someone who wants to contibute have permissions needed to
    contribute to that thing? We typically add permissions to people as
    they need them, but after they have been around a while and proven
    themselves.
  • In my experence people tend to say “this looks interesting, I can work
    on any of it”, but turns out they don’t have the background to work on
    a lot of it. It puts the ‘steward’ in the position of trying to assign
    work to volenteers, which can work out, but also can not work out.
  1. At least once every 3 months we go through a round of updating the board. We ask stewards and primaries to do this independently, but we also dedicate a weekly meeting every quarter to ensuring that everything has updates and there is no lingering cruft. Anything which still needs an update at the end of the meeting becomes an assigned issue to get it updated. And to hold ourselves accountable, we have an eternal “canary” item, which encourages people to yell loudly if it goes without updates. If this gets too far out of date, at least then it’s visible to newcomers that this process is dead / unhealthy.

We do from time to time in the weekly meeting work on backlog and any
blocked tickets. We could review those I suppose…

  1. This is probably the hardest part… we need to make an effort of predicting and/or requesting the future. Aka, a real backlog, which is separate from the day-to-day unplanned tickets. This doesn’t have to be very detailed, but we should have at least something out there for major anticipated or desired future work, and/or our “2025 goals” or similar. Something that A) tells people what they could get ready for, so they can be in position when the work actually comes, and/or B) tells people what major work is not happening (example: Anubis circa 2 months ago) just because nobody has yet dedicated the time to it.

This is not so easy in a community facing setup. Sure, we can list the
things we would like to do, but then urgent things drop on us all the
time too as well as the day to day fires.

But sure, we can list things…

Ideally, the “primary contributor” towards any major efforts would also be the steward. But I’ll hereby cautiously nominate myself as the steward for the foreseeable future on anything where the primary is not available or interested. I don’t want that to become the norm, but I also think it’s important to get this off the ground and make the project approachable for newcomers.

Thats great, but not sure you should overwealm yourself and try and do
too many things at first.

Next steps

  • I currently have zero permissions in Fedora, including to clean up obviously-ancient Pagure boards. I’m willing to do all of the legwork that I ever suggest (here or in any other thread), but I either need permissions or someone else with the right permissions needs to take this. Whether we move forward with anything else, we should definitely clean this up. It’s disheartening to see this cruft as a newcomer.

Sure. You could generate the exact list of things you are looking at for
someone to process?

But also, I think there’s some bugs in pagure around deleting boards (I
would have to go back and try and recall what that was).

  • We need some consensus that this process seems A) at least plausible, and B) beneficial to retaining new contributors. We don’t have to agree that it’s going to work, just that it might work and might help. And I would suggest that new voices should weigh a little more heavily here than old-timers.

I think there’s a lot of great ideas here. Not sure what you mean by new
voices weigh more heavily there… that they decide what we work on?
Or that they decide as we work?

  • If we generally agree that this process might be feasible, we need to decide where it should be hosted. Forgejo does have a kanban system like Pagure, which is linked to issues. This seems like the right place to me, but I don’t really know the full status of Forgejo today.

Yeah, it’s… soon! I’d say in the next few weeks.

  • We also need to incorporate this “grooming” meeting into our Fedocal.

I’m not sure we need another meeting, perhaps this is something we could
do in a weekly meetings from time to time?

Hit me

It’s always easy for the noob to come in and declare that we need to rewrite everything :slight_smile: . I have zero knowledge of the battle scars or constraints here. Tell me what I’m missing! Hit me with the clue bat! Let’s get this conversation moving, because everyone seems to acknowledge “the onboarding problem”, and I believe that this is a fairly high-impact / low effort option which would help significantly.

And just to re-iterate: I’m happy to do all the work to get this off the ground. I just need others to be willing to share what’s in their head.

here’s mine… or at least what I had time for right now.

back to meetings.

6

Michael means that recently onboarded or newly joined contributors to Fedora should have a stronger voice in reviewing the onboarding or joining process.

1 Like
7

Oh, and I meant to mention… Scrum in Community

Our team (CLE, the community linux engineering) team is moving to a scrum thing. We are doing our standups in matrix in the open and as part of that there should hopefully be some better backlog/planning… but it’s all early days.

1 Like
8

Thanks Kevin :slight_smile: . I didn’t mean to pick on you in the above (and meant to say as much in Matrix before you had a chance to respond.) I’m just more familiar with your WIP than that of others because you’re more responsive to Matrix questions. You see what that gets ya? :wink: . Hopefully this didn’t sound like a “Kevin sucks” post!

Any reason we need to wait for the migration? At minimum I’d say let’s move all the tasks there to Done (if they are.)

Yeah, I’ve seen remnants. But I also assume that this is no longer done for reasons I’m blind to. I like what I’ve read on how CLE / CPE operates, but also no idea whether that too is ancient red herrings.

So, this gets to what I’m talking about.

1:
Yes, each repo has their own set of Issues, but there is no overview tying it all together to answer the question - what’s happening in Fedora and how can I help?

What I’m suggesting is basically exactly how we use fedora-infrastructure as a an issue-only repo, but specifically targeting “initiatives” that are actually in flight or on-deck. Stuff that will likely span multiple individual Issues / Repos / Git Forges / etc.

2:
The “initiative board” (let’s just call it that?) doesn’t track work at the day-to-day level. It just A) lists the initiatives and links over to where that work is happening, and B) provides a central place to track who is working on what initiatives.

p.s. I feel like there’s probably a lot of baggage around “initiatives” which I’m trying to avoid, because I’m trying to create a process which is extremely lightweight, and which gives noobs only an MVP overview of large WIP / on deck. (Emphasis on the “M”.)

Good call out. I feel like we need to address “pointing noobs to the work” first, but then that will quickly lead to this question. I think this would depend on the specific work, and the availability of people to e.g. review PRs. I think it’s “out of scope” / TBD for this level of convo though.

So … yes. You’ll have that. I think stewarding is going to be like 90% community management. (And maybe we could even get some help from others here? Join SIG? etc.) And that’s why I anticipate that many “primaries” will not want to be stewards.

However, I think it could be worth it, because IMO even though I’m skilled and motivated it’s still extremely difficult to onboard here. I would never have been able to do this without extended downtime from work. And I think “don’t have a job” is a bit much to ask of people who are skilled and motivated.

(In case you’re feeling beat up by this comment: I don’t think this situation is unique to Infra.)

One nitpick: In my head, the stewards do not “assign” work. They help newcomers find it, and optionally they assist with Fedora-specific or initiative-specific questions like, “What git forge do we use for this?” and “What’s the latest status on issue X?”. But critically, they are not technology mentors. Once the newbie has all the context-relevant info and status (maybe because it’s all in the kanban ticket!), then it’s up to them to actually contribute. The actual “project management and collaboration” work doesn’t change.

Yeah, from what I see a huge percentage of the work is this “unplanned work” of urgent things dropped on us. But I’d like to address whatever percentage is either A) not that, or B) huge enough to warrant extra hands.

I’m trying to be conscious of this. I’m ok for now though.

Will do, in fedora-infrastructure issues. And I’ll link here.

What I meant by this is: my proposal is intended to help newcomers. So, while some things seem obvious or “they didn’t RTFM” to those who have been here a while, we should also lean towards, “Maybe this isn’t obvious? Maybe there’s a better way?”

Definitely not accusing anyone here of the opposite! But in my employment I’ve tried hard to place extra emphasis on listening to newbies because it’s almost impossible to see through their eyes once you’re settled in.

See this article for where I drew most of my inspiration around this. Nobody is immune to normalization, and especially not myself.

The idea here is, “Don’t plan on remembering to do this. Let’s put it on the calendar, where everyone can see it and notice if it’s not happening.” In other words, let’s aim to avoid silent failure. And yes, this could just be something that happens at the existing weekly meeting once every 3 months. But let’s get it actually into our tools somewhere.

Thanks again and again nirik! Don’t forget to hydrate and stretch :slight_smile:

9

It might be helpful to contrast my proposal with alternate ways to solve the problem.

1: I could go gather all the initiatives that I’m personally aware of and put them into docs.

This seems to be how “Initiatives” were communicated in the past. I thought for a second I might do this, just so that all the knowledge I’ve gathered in my personal notes gets out to where it can benefit others.

On the one hand, immediate action would pave some road for those who join tomorrow.

However, this sets the precedent that making the work visible is my solo contribution, and if I don’t do it then nobody else needs to. (Not to mention the fact that I need to become omniscient to do that job well.)

In contrast, I’m hoping that if we can establish the process I’m suggesting, the work to keep the overview updated would be minimal (5-10 minutes per initiative every 3 months?), distributed, and just a part of “how we work”.

2: We could try to do a full-on scrum with epics, sprints, grooming, etc.

This “works” if you have lots of people dedicating a lot of time and things are moving fast. But that’s not the problem we face today, and I don’t think that getting to “90% solved” for onboarding requires us to expend that level of effort.

It would be sufficient to provide an accurate-but-simple snapshot a few times a year, because then newcomers don’t have to start with discovering the work, just getting the latest diff.

10

The reason why we dropped the initiatives inside Infrastructure (CPE Team (now CLE Team) was the one managing them) was that people thought this is a work done by CPE and not Fedora community. So we decided to move this big initiatives to Fedora leadership, but I’m not sure where those are tracked.

So moving them again to infrastructure side will make break the whole “What is Fedora Community working on?“ thing.

We can still highlight a bigger tickets that are not full blown initiative, but still need work from multiple folks to get them done.

We are starting on that in CLE Team (as Kevin mentioned a plenty of infra folks are part of) and we will see how that will go.

We also have a lot of other work going on in various trackers for services we maintain, which is hard to find and the amount of it is overwhelming.

But I agree that it would be great to have a one place to look at the big picture for Fedora infrastructure. Not only Fedora infra, but whole Fedora Community, as there is a lot going here. Even we don’t know everything that is going on and some of the things we find out about only on Flock or randomly staggering into them.

11

Hi Michael, thank you for giving an outside state of eyes on where things are. A lot of times, you get so used to fighting the alligators and snakes of current things that it is useful to be reminded we were trying to build a road through this swamp.

I saw you mentioned not having a background on why things are at, so I thought I would give some background.

  1. The Fedora Infrastructure is over 20 years old in some parts. It has several ‘customers’ it needs to serve 24x7x52weeks which are: corporate sponsor (Red Hat), community developers, and general users looking for certain services (downloads, updates, logging into shared resources like this tool, etc).
  2. There are over 100 systems and services which need to be up and running at any time to allow those customers to get what they need
  3. Many of these services tend to be ‘reused’ parts where X was meant to do Y when it came in, but has now transitioned to doing Z because it was close enough that we didn’t need to write a new tool.
  4. The 24x7x52 ‘staff’ of the organization are a couple of teams of Red Hat employees who are mostly half-time (doing other Red Hat things) and I think only a couple of ‘full-time’ people. The full time people are also needing to do multiple hats where they may be doing systems administration, release engineering, code development, and other tasks as assigned. I think I averaged a 60 hour week ‘keeping up with the firehose’ and I know Kevin was doing more as he was working volunteering weekends too.
  5. Most of the volunteers who help out do so on a ‘when I can’ state. This may be a full couple of days or once every couple of months.
  6. The fundamental rule of volunteers is that you really can’t tell them what to work on. They have a dozen other things they could be doing other than fixing something they don’t care about so those things no matter how far in the backlog get worked on versus that top thing.
  7. Because we have a lot of ‘customers’ closing out issues as ‘WONT DO’ etc usually ends up being a long exercise of frustration as you generally find that it will cause headaches for other parts. This has meant closing out old dead items tends to require waiting for the person asking to implement something themselves and then tieing that into the existing infrastructure
  8. If a volunteer, group, etc get something running in the infrastructure, you find it can take years of multiple “It’s still being used by us 4 people” revivications before it is turned off completely. [The service like the torrent server can be broken for weeks until someone notices but trying to turn it off then becomes a “its still needed” which has gone on for 10 years.]
  9. Another background item is that most of this was initially built by seasoned system administrators of the 1990’s and early 2000’s mindsets and tooling. When I started in 2009 as a system administrator, most of the things i needed to take care of like koji required me to set up an entire set of infrastructure at home in order to see how the parts put together. That ethos has sort of baked into a lot of things, but doesn’t work as well if you need many systems to just simulate the login system or the various internal ‘buses’.

I expect my 9 background items need more research versus ‘Old Man ranting at a cloud’, but I am hopeful they can help figure out if there are paths which could/should be explored.

3 Likes
12

Thank you for all of that!

I have so many questions that are currently unanswered, I’ve decided it’s impractical to actually ask them all – I’ve already exceeded the bandwidth of the available providers. (Which is not a knock against them! This is a simple matter of physics.) And I’ve decided that the most important thing to understand (and help other newcomers understand) is the topic of this thread.

But I’d like to get all the answers eventually and get them into the docs in some form, and I absolutely think there’s a place for “candid lore” like this near the top. (If this were a private team, I’d copy-paste your post right into ONBOARDING.md.) I don’t know how others here feel about that sort of candidness being “unprofessional” or disparaging and thus distasteful to publish, but I believe it’s foundational to aligning with the reality on the ground.

I’ll probably make a PR along these grounds after 43 is out the door and things are settled down, and we can negotiate the verbiage then. I’ve realized that even though we have paid people working here, it’s still like any other open-source project: it’s not really about my availability, it’s about the availability of others on the project (until / unless I become a “maintainer” or equivalent).

By the way, I’m frequently tempted here to “just get to work” and ship some bits to prod instead of being the noisy newcomer, but I can’t seem to ignore these onboarding gaps because I think they’re all addressable. And frankly, I wish I had been able to join years ago, but I didn’t have the cycles necessary to penetrate this opacity. So I’ll continue to do my best to reduce it while I have the time. All of which is to say: thanks again, and I’ll try to multiply any time spent with me on this.

13

Thanks Kevin :slight_smile: . I didn’t mean to pick on you in the above (and meant to say as much in Matrix before you had a chance to respond.) I’m just more familiar with your WIP than that of others because you’re more responsive to Matrix questions. You see what that gets ya? :wink: . Hopefully this didn’t sound like a “Kevin sucks” post!

No worries at all. I hope I’m not discouraging you any and wish I had
more time to chat over this stuff with you. :slight_smile:

Any reason we need to wait for the migration? At minimum I’d say let’s move all the tasks there to Done (if they are.)

Well, sure, but… I recall there were some bad bugs around board
handing in pagure in the past. I don’t recall if those were fixed or
not, so I want to look around a bit before we do this.

I remember cases where if you delete a board it makes it impossible to
update some tickets or something… but it could have been fixed. Just
being cautious.

Yeah, I’ve seen remnants. But I also assume that this is no longer done for reasons I’m blind to. I like what I’ve read on how CLE / CPE operates, but also no idea whether that too is ancient red herrings.

Yeah, the problem with those was that we would set them up, discuss them
and then decide who was working on what. Sounds great right? But the
problem is then the community was like: “great that you are working on
that, I don’t need to help you! Good luck”.

There was a plan to replace them with another system that was actually
out in the community a lot more, but I guess that never took off sadly.
;(

So, this gets to what I’m talking about.

1:
Yes, each repo has their own set of Issues, but there is no overview tying it all together to answer the question - what’s happening in Fedora and how can I help?

Yeah, thats hard to get…

What I’m suggesting is basically exactly how we use fedora-infrastructure as a an issue-only repo, but specifically targeting “initiatives” that are actually in flight or on-deck. Stuff that will likely span multiple individual Issues / Repos / Git Forges / etc.

Right. Often for these we do have a infra ticket, but it’s just a
tracker for all the work that could be happing elsewhere (in an app
upstream, etc)

2:
The “initiative board” (let’s just call it that?) doesn’t track work at the day-to-day level. It just A) lists the initiatives and links over to where that work is happening, and B) provides a central place to track who is working on what initiatives.

Sure, and we could do this in a seperate place, but then we need to
decide what goes there vs normal. Or… we could just use
labels/something to track them in the main repo. I guess it doesn’t
matter and depends on what forgejo can do.

p.s. I feel like there’s probably a lot of baggage around “initiatives” which I’m trying to avoid, because I’m trying to create a process which is extremely lightweight and gives noobs an MVP overview of large WIP / on deck.

Yeah.

Good call out. I feel like we need to address “pointing noobs to the work” first, but then that will quickly lead to this question. I think this would depend on the specific work, and the availability of people to e.g. review PRs. I think it’s “out of scope” / TBD for this level of convo though.

So … yes. You’ll have that. I think stewarding is going to be like 90% community management. (And maybe we could even get some help from others here? Join SIG? etc.) And that’s why I anticipate that many “primaries” will not want to be stewards.

However, I think it could be worth it, because IMO even though I’m skilled and motivated it’s still extremely difficult to onboard here. I would never have been able to do this without extended downtime from work. And I think “don’t have a job” is a bit much to ask of people who are skilled and motivated.

One nitpick: In my head, the stewards do not “assign” work. They help newcomers find it, and optionally assist with common Fedora beginner Q’s like, “What git forge do we use?”. Then it’s up to the contributor to actually contribute.

I’m open to the idea… I am not sure we have enough ‘stewards’ vs
primary people working on something. I guess it might depend on the
work/issue/item.

Yeah, from what I see a huge percentage of the work is this “unplanned work” of urgent things dropped on us. But I’d like to address whatever percentage is either A) not that, or B) huge enough to warrant extra hands.

Sure.

I’m trying to be conscious of this. I’m ok for now though.

Good!

Will do, in fedora-infrastructure issues. And I’ll link here.

Sure. I will see the issues (lots of us are cc’ed on all of those, but
can’t hurt to list them more places)

What I meant by this is: my proposal is intended to help newcomers. So, while some things seem obvious or “they didn’t RTFM” to those who have been here a while, we should also lean towards, “Maybe this isn’t obvious? Maybe there’s a better way?”

Absoluetely. We should always stive to help new folks as much as we can.

Definitely not accusing anyone here of the opposite! But in my employment I’ve tried hard to place extra emphasis on listening to newbies because it’s almost impossible to see through their eyes once you’re settled in.

See this article for where I drew most of my inspiration around this. Nobody is immune to normalization, and especially not myself.

The idea here is, “Don’t plan on remembering to do this. Let’s put it on the calendar, where everyone can see it and notice if it’s not happening.” In other words, let’s aim to avoid silent failure. And yes, this could just be something that happens at the existing weekly meeting once every 3 months. But let’s get it actually into our tools somewhere.

Sure, if the consensus is to do it, I’m all for it.

Thanks again and again nirik! Don’t forget to hydrate and stretch :slight_smile:

Indeed. :wink:

Thanks for the thoughts

1 Like
14

The relevant formula is bandwidth*time so as you understand the bandwidth, extend the time. Asking the questions is useful for all of us.

15

Thank you for all of that!

I have so many questions that are currently unanswered, I’ve decided it’s impractical to actually ask them all – I’ve already exceeded the bandwidth of the available providers. (Which is not a knock against them! This is a simple matter of physics.) And I’ve decided that the most important thing to understand (and help other newcomers understand) is the topic of this thread.

But I’d like to get all the answers eventually and get them into the docs in some form, and I absolutely think there’s a place for “candid lore” like this near the top. (If this were a private team, I’d copy-paste your post right into ONBOARDING.md.) I don’t know how others here feel about that sort of candidness being “unprofessional” or disparaging and thus distasteful to publish, but I believe it’s foundational to aligning with the reality on the ground.

Well, the fedora project in general and infrastructure/releng in
particular does have a long and rich history for sure.

I don’t disagree with anything smooge said, but I don’t think thats
really ready to consume in a onboarding doc…

I’ll probably make a PR along these grounds after 43 is out the door and things are settled down, and we can negotiate the verbiage then. I’ve realized that even though we have paid people working here, it’s still like any other open-source project: it’s not really about my availability, it’s about the availability of others on the project (until / unless I become a “maintainer” or equivalent).

Happy to look at any PR’s.

Sure, time is always in short supply in any open source project.
Some of us have more time than others due to working on this stuff for
$dayjob, but in that case we have to prioritize the fires/important
things.

But you never get out of a firefighting thing by not fixing onboarding
to get folks to help out, so thats definitely important too!

By the way, I’m frequently tempted here to “just get to work” and ship some bits to prod instead of being the noisy newcomer, but I can’t seem to ignore these onboarding gaps because I think they’re all addressable. And frankly, I wish I had been able to join years ago, but I didn’t have the cycles necessary to penetrate this opacity. So I’ll continue to do my best to reduce it while I have the time. All of which is to say: thanks again, and I’ll try to multiply any time spent with me on this.

Thank you for asking questions, starting debate, injecting energy into
things! It’s appreciated. I hope you don’t find things to slow or
frustrating, so do pace yourself, but I hope you can keep going. :slight_smile:

Visit Topic or reply to this email to respond.

To unsubscribe from these emails, click here.

The relevant formula is bandwidth*time so as you understand the bandwidth, extend the time. Asking the questions is useful for all of us.

yeah, I know this is true for me… when it gets really busy I mark
things to reply to, but it sometimes takes a while before I get cycles
to get back to it. :slight_smile:

(Like this thread)

16

:+1:

Me too! If I were independently wealthy, this would be entirely sustainable for me. But I’m not, so TBD how much time I can dedicate after I’m employed again.

That’s part of why I’m digging into so many things at once right now – so that I have a few items of varying sizes to pick from in my personal backlog once my time is metered. But also, I hear horror stories every day of how long it’s taking people to find jobs, so I might have far more time for Fedora than is otherwise desirable… I might as well put that time to maximal use. Certainly better than ruminating on the situation.

Just FYI, that’s 100% understood. I just want to make onboarding a little more self-service so that we don’t actually need people’s time to get through basic orientation. I shouldn’t need 100 hours of your time (or anyone else’s) to get started. And I feel like the meter is running … :wink: Thanks again for all you’ve given me.

17

:+1:

Me too! If I were independently wealthy, this would be entirely sustainable for me. But I’m not, so TBD how much time I can dedicate after I’m employed again.

Indeed. The open source world would be a very different and better place if we had
universal base income for everyone. alas.

That’s part of why I’m digging into so many things at once right now – so that I have a few items of varying sizes to pick from in my personal backlog once my time is metered. But also, I hear horror stories every day of how long it’s taking people to find jobs, so I might have far more time for Fedora than is otherwise desirable… I might as well put that time to maximal use. Certainly better than ruminating on the situation.

Sure, makes perfect sense.

Just FYI, that’s 100% understood. I just want to make onboarding a little more self-service so that we don’t actually need people’s time to get through basic orientation. I shouldn’t need 100 hours of your time (or anyone else’s) to get started. And I feel like the meter is running … :wink: Thanks again for all you’ve given me.

No problem…

1 Like