Deferring final resolution on the size makes good sense to me. 

We should decide for the phase 2 transition how many at large members we want to add, 1, 2, or 3.

Yours,

Joel

Got your points, I agree with you that we don’t have to force the size to be big unless we see needs. Since during transition, most likely there would be 7 TSC (I assume 2 core PTL + 1 CAL TSC), at the end of the transition, we should have a better feeling about TSC size,  then TSC can vote how many of those 4 company reserved seats to be put into CAL category.

BR,

George

I guess I am more worried about the balance between Core and at-large than I am about the TSC size.  Part of our disagreement is that given the limited role of the TSC, I do not see making it larger a benefit in and of itself.  The TSC lists and meetings are open to all, so I do not want to turn membership into a proxy for information distribution.

So while the transition will result in an 8 or 9 member TSC for some period of time, I am concerned about aiming for 8 members after the Platinum members no longer hold reserved seats.  That would be 2 Core projects and 6 or 7 at large members.

I am also concerned that with the size of our active pool, and the intended limitations on the number of people from any single company, it can seems likely to be hard to fill 7 at large TSC seats.

Yours,

Joel

Joel did a very good draft.

As I said in the TSC meeting, DPDK has 9 technical board members, I think FD.io TSC probably should or would grow to that size, personally, I think 7-9 TSC is a reasonable number.

During transition time period, we can have platinum designates(4) + Core PTL(2) + CAL (?0-3), after transition period we can determine how many of the 4 seats to be put to CAL pool if not all, and there might be more projects promoted as core project. I think transition period should be one TSC term.

Just my 2 cents.

Thanks,

George

+1... Thanks… Dave

Hi Dave,

I stand corrected on pruning on VPP (and I imagine CSIT as well).

I do think a general revision of committers status in fd.io sub-projects in advance of a TSC election is warranted.

Ray K

Dear Ray,

We have pruned vpp project committers who stopped contributing by soliciting resignations. In these cases, we waited a good long time; by the time we asked the question, folks were perfectly OK with it.

Hi Joel,

Thank for this – this is really good work.

Some additional questions/points I would add for discussion.

1. Over the past year FD.io VPP added a MAINTAINERS file, listing those folks responsible for maintaining different functional areas in VPP and as a stepping stone to ‘COMMITTER’ status.
   
   Should consider giving some formal recognition to the role and allow MAINTAINERS to have an equal vote in which COMMITTER is elected from a given core project? In practice I think it ends up being largely the same set of folks, but my feeling it is fair for MAINTAINERS to have an equal say in which COMMITTER is appointed from a core project.

1. On the aging out of COMMITTERS – to the best of my knowledge in the lifespan FD.io we have never actually pruned any committers from a project. In addition there is a small a number of committers that got added at a sub-project inception – that have never actually made any commits to that sub-project.
   
   Should we consider asking each sub-project to consider revising their committer list to just those folks currently actively contributing and those who have substantial historical commits?

Thanks,

Ray K

Can be found at:

https://wiki.fd.io/view/TSC/draft_election_procedures

Please comment here.

Please fix typographic and grammatical errors on the wiki.

Thank you,

Joel