On Mon, Nov 28, 2022 at 11:57 PM Ullrich Hafner
> Basically, the reasoning for this change is not clear for me.
The reasoning is simply that the rate of creation of new governance
action items is far higher than their rate of completion; i.e., a lack
of bandwidth. Adding a second board member from CloudBees will
accelerate the rate of completion of governance action items for the
benefit of the broader Jenkins community.
> They have not [a] majority, but we have a stalemate which is a potential risk.
I cannot think of a situation in which we even came close to a
stalemate over the past year. True, different people had different
views about when to require Java 11, but that issue never even came to
a board vote, let alone a stalemate. This proposal is certainly not a
move to obtain veto privileges. On the contrary, I think increasing
active engagement on the board would result in less stagnation for
> Here it would help to elaborate, what these work items are?
Take a look at the minutes of the last dozen board meetings and note
how many action items remain present for months at a time without
completion, through no fault of the individuals involved. As a small
example, the issue of servlet container support was escalated to the
board over a month ago but did not see significant progress until
today. The lack of bandwidth, while understandable, has long-term
consequences for Jenkins users.
> So if there is too much work we should rethink if this work could be delegated to other roles in the Jenkins project.
There is no shortage of people who are willing to make suggestions and
to delegate work, but taking action items to completion in a timely
fashion is another matter. To paraphrase what I wrote in a different
thread earlier today: "Who is going to implement this?"
Early in my career, I was tasked with implementing a complex project
and could not decide between two competing implementation choices. I
asked a trusted mentor for advice, and he simply replied: "To the
implementer goes the decision." The point was that skin in the game
promotes sound decision-making. I think the same applies here and that
the Jenkins community would be best served by a board composed of
individuals who are completing action items rather than delegating (or
attempting to delegate) them. If those individuals come from outside
CloudBees, their contributions are highly appreciated. But if they
come from inside CloudBees, why not empower them for the benefit of
the broader Jenkins community?