A program manager adds value in a lot of big ways. If you’ve read Program Management for Open Source Projects, you’ve read about the myriad ways a program manager helps communities work together. But sometimes the contributions are a little smaller.
Lurking is one of a program manager’s most important jobs. Because the role involves sharing information across teams, you have to spend a lot of time passively absorbing what’s being said. Of course, you don’t want to be the exclusive source for information. But you are uniquely positioned to be an information conduit.
Let me give you an example. During the Fedora Linux 38 cycle, a package maintainer proposed one of his packages as a freeze exception. When making the proposal, he just said “a new version is available.” This isn’t particularly descriptive. Since the point of a freeze is to give testers a stable platform to test against, the default decision is to reject exceptions. Availability of a new version isn’t enough reason on its own.
But! I passively follow a lot of Fedora mailing lists. And one of those lists had a discussion about this package update fixing boot issues on some Arm devices. Because I had seen this, I was able to add the context for why this particular freeze exception should be granted. It quickly got enough votes to get pulled into the compose.
Now, it’s possible that voters would have granted the exception without the additional information. Or maybe they’d have rejected it, the maintainer would have provided more information, and then the voters would have accepted it on the second go-round. Or maybe someone would else have picked up the context from the mailing list and provided it.
The point isn’t “only Ben Cotton could have saved us!” The point is that because I spend a lot of time watching teams communicate, I can give context to other teams. This wasn’t a make-or-break moment for the release. It was a way to reduce the friction for individual contributors and make the process run a little smoother.