Re: Request for discussion: Proposal to update the ARB section of the Community Governance doc
Thank you, Sukhdev. I appreciate this perspective, but I’m going to disagree.
As background, the ARB was initially my brainchild and as conceived was really about protecting us through the transition from an architectural perspective. It was not about retaining control for Juniper over the long haul. Some of the current structure for the ARB governance can be interpreted as helping Juniper maintain “dominance” of the project. I don’t like that word and I don’t like the connotations it implies, but that’s what was thrown around on the recent LFN TAC call.
If we want to play nice with LFN, then I think we need to look hard at the ARB governance model and make certain it lines up more closely with the rest of the governance models of both TF and our sister projects at the LFN.
Also, to be honest, I think my initial intentions around the ARB are less relevant today. Sadly, it’s taking longer to get to finalize our entry to the LFN combined with taking longer to see more non-Juniper developers coming to the project, than I expected. It’s all happening, but much more slowly than anyone anticipated. Given this, the usefulness of the ARB from a transition perspective is less. The longer we take, the more the architectural integrity becomes part of the community.
I think putting in language that is about “non-Juniper contributors” doing X or Y is kind of taking us backwards from where we need to be. We don’t need to protect the architectural integrity of the project that tightly any more and we certainly don’t need to use wording like “non-Juniper contributors” in any charter or governance document. That would not serve us well. It’s best if we just make the playing field level and move forward. We have a lot more important stuff to work on in 2019.
Vice President, Technology - OSS
+1 (415) 787-2253 [Google Voice]
From: <tsc@...> on behalf of Sukhdev Kapur <sukhdevkapur@...>
There was a reason to have the ARB structure the way it is. I would like to propose a modification to the proposed draft.
The proposed enhancement can be activated by TSC only if the code contribution from non Juniper contributors exceeds the code contribution from the Juniper contributors - both in terms of number of patches and number of lines of code. Otherwise, we risk risking the integrity of the code base.
If anybody has a different opinion, I would love to hear your thoughts.
On Fri, Dec 7, 2018 at 3:36 PM VM (Vicky) Brasseur <vmb@...> wrote: