On Mon, Nov 28, 2022 at 11:57 PM Ullrich Hafner <ullrich.haf...@gmail.com> wrote:
> 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 long-standing topics. > 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? -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAFwNDjrAJaJmUbAQnWci3xTz%3DyTAOrGndZm%2BZdMjVg0326rGMQ%40mail.gmail.com.
