Pardon the epithet in this post’s title. I’ve been hearing this question for a long time, since before I sat on the Board, and ignoring it isn’t making it go away. So I give up already! I’ve now been on the Board long enough to be able to make a reasonable stab at explaining who, what, where, when, and why.
While you can (and should) find some useful content on the Project Board pages that says what this group is (“clear leadership”), that doesn’t show what this group actually does. Another useful task is to go through the published meeting minutes. *yawn* Maybe in a later post I’ll go over some of those decisions, good and bad.
So far it’s clear to me the Board serves a rubber-stamping, figurehead function. It’s useful for everyone inside and outside of a project to have someone or some group to point at and say, “Ultimately, yeah, they’re in charge.” No matter how you handle the rotation to get your leader roles filled, one of their key values is to take the arrows and the mud. Thankfully, in Fedoraland, we have a Project Leader who is also given a body of deciders and advisers. That means said Project Leader can spread the accountability to those of merit. Ultimately the Board is a meritocracy with a thin veneer of democracy. Yes, we elect a portion of the Board members, but no one who is running for a position has a ghost of a chance if they do not merit the role. The rest of the seats Red Hat fills, because Red Hat is (currently) the biggest organized contributor to the Fedora Project and presents its leaders-of-merit by appointment.
What does all this accountability mean? What does it give you, the average contributor and user?
Without accountable project leadership, who do you have to go to when something must be fixed and you cannot get anyone’s attention to make it happen? When the leaders of the sub-projects and SIGs cannot or will not address your situation? (Answer: email the Project Leader and/or fedora-advisory-board aka f-a-b)
There are individual leaders in the sub-projects/SIGs who work close to their subject matter. Similar to the Fedora Project Leader and the Board, each sub-project/SIG has a committee or otherwise organized group that works closely with the project leader, sharing the decision making and the responsibility. Such leaders fulfill an important nonsense filtering role as well. But what do they do when they have a situation they cannot resolve yet they know it must be taken care of? Who do they turn to? (Answer: email the Fedora Project Leader and/or f-a-b, or private correspondence to fedora-board-list aka f-b-l)
For example, long before being appointed by Red Hat to the Project Board, I’ve been leading Fedora Documentation; it’s a role I gained through merit and a thin veneer of democracy, and I’m close to the action, making decisions and doing day-to-day work. I can think of many dozens of situations where we made a decision in Fedora Docs and didn’t kick it upstairs to the Project Board. Serious project decisions that, if mishandled, could have been problematic. At the same time, I can think of a few situations where I escalated an issue to the Board, or was involved as a resource for an issue raised by another contributor. On two occasions that I recall, I joined a Board teleconference to address topics that I was asking the Board to handle. Things that I, as a project leader and representative of Fedora Documentation, had thrown up my hands and said, “I can’t get around this one and make it happen, I need to hand this one off to someone with more authority.”
Herein lies the irony. The Board appears useless precisely because, for the most part, it is useless. The Fedora Project runs itself. In my experience, greater than 70% of the machinery of flipping over another release every six months just works. The 30% is where we are constantly churning to find a better, better, better way to do things. Again, greater than 70% of that 30% portion is churning itself along just fine. Somewhere in that remaining less than 9% is where the Board is mucking about. One thing the Board does is add fuel to parts in that last percentage, and some of it will grow to become a lesser or greater churn for the next six months, twelve months, two years, and so on.
The other part I want to address is the representative element. If you listen to open source project leaders, you learn they are very aware of their constituency. They don’t remain project leaders by being aloof (with notable exceptions.) People join the Project Board with an agenda, one that is born of their experiences working alongside all of you, contributing and using Fedora. For example, I’ve been quite delighted to find that Jef Spaleta has a lot of very good ideas about the care and feeding of humans volunteering their time. His open discussion of these and similar ideas predates his election to the Board, and that community vote gave him clear field to run with his ideas. We chose Jef, and in doing so, we the Fedora community helped set the agenda of the current Project Board.
In its history, the Board has overseen epic activities, such as the merger of Core into Extras, and not-so-epic, jury-is-still-out activities, such as the challenges around media formats and Codeina/CodecBuddy. In those situations, the vast, vast majority of the work was done by other roles (although in many cases, the Board members were also the active doers via their other Fedora roles.) The operational and technical decisions were handled within the sub-projects/SIGs. But these project activities, big and small, required that one group be at the top of the accountability pyramid, using the sharp tip with the many tons of rock behind it to punch holes through barriers and get the job done.
Figuratively, of course. Figureheads always act figuratively.