I added a couple comments to the Google Doc, but if we’re going to revise the governance, I wonder if we should perhaps revisit the entire concept of the ARB.
We have a list of PTLs:
https://github.com/tungstenfabric/docs/blob/master/Governance/TechnicalCommittee/Project_Team_Leads which is currently less than ideal because Sukhdev is essentially a placeholder for all of the development projects. The ARB allegedly divides the code base
by areas of responsibility, but we haven’t published that division anywhere. The ARB doesn’t hold meetings. The ARB hasn’t conducted any votes. I personally review every spec in the contrail-specs repo, but this isn’t actually a requirement of ARB members
to do so, it’s just something I personally feel I should do. I don’t know if any of the other ARB members review every spec, but I suspect that they probably don’t. We have an ARB mailing list
https://lists.tungsten.io/g/arb/topics but there is exactly ONE post to that mailing list since we established it and that post is from me, just checking that the mailing list works.
Perhaps what we really should do is diversify the list of PTLs and schedule a monthly PTL meeting in place of the never ARB meetings.
Given the tightly interlinked nature of Tungsten Fabric we could grant all PTLs the right to -2 commits in any project (as was granted to ARB members (incidentally, I’m an ARB member and I don’t think my Gerrit permissions were ever updated
to actually grant me -2 privileges across all projects)) and re-review all the ARB privileges and responsibilities that we documented in order to ensure that they are appropriate to the aggregate group of PTLs.
It might also be less confusing to other Open Source communities if we simply have a council of PTLs rather than an Architecture Review Board.
h=6.626 070 15 × 10-34
e=1.602176634 × 10-19
k= 1.380649 × 10-23
NA=6.02214076 x 1023
From: tsc@... <tsc@...>
On Behalf Of Sukhdev Kapur
Sent: Friday, December 07, 2018 19:13
Subject: Re: [TF TSC] Request for discussion: Proposal to update the ARB section of the Community Governance doc
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:
Though the TAC doesn't get to define the governance of the member projects, their feedback is still welcome. In this week's TAC call, during discussion of the TF induction to LFN, some TAC members pointed out
that while the TF TSC has limitations on how many representatives any single company can have, the ARB does not. This was a good catch.
Using the TSC section of the doc as a template, I've put together a proposed change to the ARB section of the Community Governance document. We discussed it in the Community WG call earlier today and the resulting document includes that feedback. The summary
of the proposed changes:
* Decrease ARB term from 24 months to 12. This allows flexibility for individual ARB members without losing potential architectural continuity, since there is no limit on consecutive terms for an individual member.
* Mirror the documented TSC policy of 1 seat per company for the ARB as well. This policy can be overridden by a resolution from the TSC, which will be necessary with the current state of architectural knowledge about TF (right now the folks w/the most knowledge
are from Juniper) but which the community will work to change for future ARB tenures.
The full proposal is here:
On today's Community WG call Casey said he'd like to aim for a vote on this in early January, so comments and discussion are welcome as soon as you feel like sharing them.