[dpdk-dev] Technical Steering Committee (TSC)

[dpdk-dev] Technical Steering Committee (TSC)

[O'Driscoll, Tim]

At Tuesday's Beyond DPDK 2.0 call, one topic we discussed was decision making and whether we need a Technical Steering Committee (TSC). As a follow-up to that discussion, I'd like to propose that we create a TSC for DPDK to guide the long-term strategic direction of the project.


Justification
-------------

The role of the Maintainer is to be the gate-keeper for the project, and to only accept contributions that are properly implemented, properly reviewed, and consistent with the agreed project scope/charter. However, it shouldn't be the responsibility of the Maintainer to be the final decision maker (after community discussion) on issues affecting the strategic direction of the project. Instead, this should be determined by a higher level body that's representative of the DPDK community.

Having a TSC should help to provide a clear direction/strategy for the project, and help to resolve complex issues which don't reach a consensus on the mailing list in a timely manner.

There were arguments at the call that a TSC is not required. The alternative view though is why would we not put one in place? The TSC could review its own progress after 6 months, and if the members don't consider it to be productive, then it could be disbanded. I see little effort and zero risk in trying this, with the potential gain of a clearer decision making process and a better defined project strategy. 


Scope
----- 

Issues the TSC should consider should include:
- Project scope/charter. What is and isn't within the scope of the project? What happens if somebody wants to upstream a new library/capability and it's not clear whether it fits within DPDK or not? As a random example, if somebody wanted to upstream a DPDK-enabled TCP/IP stack to dpdk.org, should that be accepted or rejected?
- Performance vs functionality considerations. If we need to make a change and there's an unavoidable performance impact to doing so (maybe something like extending the mbuf again), does that change get accepted or not? In most cases you can probably work around situations like this by making them optional, but that might not always be possible. If it's not, who decides whether performance or functionality is more important?
- Replacing existing functionality versus adding new alternatives. An example of this might be Cuckoo Hash. Does that replace the existing hash implementation, or should it be provided as an alternative? Who decides this? That could be more of an operational issue, but it's borderline.
- Competitive Positioning. Monitor the competitive landscape and determine any impacts to future DPDK strategy. 
- Unresolved issues. Provide a decision on issues that don't reach a consensus on the mailing list in a timely manner.


Composition
-----------

Composition of the TSC should reflect contributions to the project, but be balanced so that no single party has an undue influence. It should also be kept to a manageable size(maybe 7?).

The TSC should elect its own chair, who would have the deciding vote in the event that the TSC was deadlocked. Once in place, the TSC should approve any new members.

Specific details on membership can be discussed and agreed later, if we agree on the creation of a TSC.

Re: [dpdk-dev] Technical Steering Committee (TSC)

[Stephen Hemminger]

>
>
>
> Composition of the TSC should reflect contributions to the project, but be
> balanced so that no single party has an undue influence. It should also be
> kept to a manageable size(maybe 7?).
>
> The TSC should elect its own chair, who would have the deciding vote in
> the event that the TSC was deadlocked. Once in place, the TSC should
> approve any new members.
>
> Specific details on membership can be discussed and agreed later, if we
> agree on the creation of a TSC.
>

TSC should be limited to those individuals and companies that have
contributed in a non-trivial way to the DPDK distributed code base.
It should not be a users group, or place for network vendors who take but
never give back.

Re: [dpdk-dev] Technical Steering Committee (TSC)

[Neil Horman]

On Tue, May 19, 2015 at 07:43:14AM -0700, Stephen Hemminger wrote:
> >
> >
> >
> > Composition of the TSC should reflect contributions to the project, but be
> > balanced so that no single party has an undue influence. It should also be
> > kept to a manageable size(maybe 7?).
> >
> > The TSC should elect its own chair, who would have the deciding vote in
> > the event that the TSC was deadlocked. Once in place, the TSC should
> > approve any new members.
> >
> > Specific details on membership can be discussed and agreed later, if we
> > agree on the creation of a TSC.
> >
> 
> TSC should be limited to those individuals and companies that have
> contributed in a non-trivial way to the DPDK distributed code base.
> It should not be a users group, or place for network vendors who take but
> never give back.
> 
+1

It should also endavour to only act as a fallback body for any issues commonly
handled by the development communtiy (patch acceptance/review, etc)
Neil

Re: [dpdk-dev] Technical Steering Committee (TSC)

[Thomas Monjalon]

2015-05-19 11:34, Neil Horman:
> On Tue, May 19, 2015 at 07:43:14AM -0700, Stephen Hemminger wrote:
> > > Composition of the TSC should reflect contributions to the project, but be
> > > balanced so that no single party has an undue influence. It should also be
> > > kept to a manageable size(maybe 7?).
> > >
> > > The TSC should elect its own chair, who would have the deciding vote in
> > > the event that the TSC was deadlocked. Once in place, the TSC should
> > > approve any new members.
> > >
> > > Specific details on membership can be discussed and agreed later, if we
> > > agree on the creation of a TSC.
> > 
> > TSC should be limited to those individuals and companies that have
> > contributed in a non-trivial way to the DPDK distributed code base.
> > It should not be a users group, or place for network vendors who take but
> > never give back.
> > 
> +1
> 
> It should also endavour to only act as a fallback body for any issues commonly
> handled by the development communtiy (patch acceptance/review, etc)

I agree that it should be a fallback.
And I'm wondering how useful it would be: have we ever known such discussion or
conflict without finding a solution or a consensus?
By the way, is there a TSC in Linux netdev?

Re: [dpdk-dev] Technical Steering Committee (TSC)

[Neil Horman]

On Tue, May 19, 2015 at 05:45:05PM +0200, Thomas Monjalon wrote:
> 2015-05-19 11:34, Neil Horman:
> > On Tue, May 19, 2015 at 07:43:14AM -0700, Stephen Hemminger wrote:
> > > > Composition of the TSC should reflect contributions to the project, but be
> > > > balanced so that no single party has an undue influence. It should also be
> > > > kept to a manageable size(maybe 7?).
> > > >
> > > > The TSC should elect its own chair, who would have the deciding vote in
> > > > the event that the TSC was deadlocked. Once in place, the TSC should
> > > > approve any new members.
> > > >
> > > > Specific details on membership can be discussed and agreed later, if we
> > > > agree on the creation of a TSC.
> > > 
> > > TSC should be limited to those individuals and companies that have
> > > contributed in a non-trivial way to the DPDK distributed code base.
> > > It should not be a users group, or place for network vendors who take but
> > > never give back.
> > > 
> > +1
> > 
> > It should also endavour to only act as a fallback body for any issues commonly
> > handled by the development communtiy (patch acceptance/review, etc)
> 
> I agree that it should be a fallback.
> And I'm wondering how useful it would be: have we ever known such discussion or
> conflict without finding a solution or a consensus?
Well, I suppose the jury is still out on that, since there are ongoing problems,
in the form of patch latency, and such.  But for the most part, no, problems
tend to reach consensus resolution IMO

> By the way, is there a TSC in Linux netdev?
> 
No, but there are TSC for many projects, including Openshift, freedesktop.org,
etc.

Neil

Re: [dpdk-dev] Technical Steering Committee (TSC)

[O'Driscoll, Tim]

> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Neil Horman
> 
> On Tue, May 19, 2015 at 05:45:05PM +0200, Thomas Monjalon wrote:
> > 2015-05-19 11:34, Neil Horman:
> > > On Tue, May 19, 2015 at 07:43:14AM -0700, Stephen Hemminger wrote:
> > > > > Composition of the TSC should reflect contributions to the
> project, but be
> > > > > balanced so that no single party has an undue influence. It
> should also be
> > > > > kept to a manageable size(maybe 7?).
> > > > >
> > > > > The TSC should elect its own chair, who would have the deciding
> vote in
> > > > > the event that the TSC was deadlocked. Once in place, the TSC
> should
> > > > > approve any new members.
> > > > >
> > > > > Specific details on membership can be discussed and agreed
> later, if we
> > > > > agree on the creation of a TSC.
> > > >
> > > > TSC should be limited to those individuals and companies that have
> > > > contributed in a non-trivial way to the DPDK distributed code
> base.
> > > > It should not be a users group, or place for network vendors who
> take but
> > > > never give back.
> > > >
> > > +1
> > >
> > > It should also endavour to only act as a fallback body for any
> issues commonly
> > > handled by the development communtiy (patch acceptance/review, etc)
> >
> > I agree that it should be a fallback.
> > And I'm wondering how useful it would be: have we ever known such
> discussion or
> > conflict without finding a solution or a consensus?
> Well, I suppose the jury is still out on that, since there are ongoing
> problems,
> in the form of patch latency, and such.  But for the most part, no,
> problems
> tend to reach consensus resolution IMO

It's true that there aren't many obvious examples, although as Neil points out there are still some things that are ongoing. One issue that springs to mind where we didn't reach consensus was inclusion of ABI Versioning in 1.8. It was subsequently included in 2.0, but there were people who believed it should have been in 1.8.

The other issue with having to reach consensus on everything is that it tends to a lowest common denominator approach, and can slow things down. There are times where a clear decision and then everybody moving forward is preferable.

> > By the way, is there a TSC in Linux netdev?
> >
> No, but there are TSC for many projects, including Openshift,
> freedesktop.org,
> etc.
> 
> Neil

Re: [dpdk-dev] Technical Steering Committee (TSC)

[Dave Neary]

Hi,

On 05/14/2015 01:55 PM, O'Driscoll, Tim wrote:
> At Tuesday's Beyond DPDK 2.0 call, one topic we discussed was decision making and whether we need a Technical Steering Committee (TSC). As a follow-up to that discussion, I'd like to propose that we create a TSC for DPDK to guide the long-term strategic direction of the project.

As others have said, I think a TSC can have value, more as the "guardian
of the roadmap", a place to engage to set high level goals and
priorities for the project. And as Neil and Thomas said, I also agree
that it does not make sense for the TSC to get involved in the
day-to-day of the project (patch review, for example).

There is a danger with TSCs that you end up with "design by committee" -
but I think that is a risk that can be mitigated by limiting the scope.

In terms of membership: I do think it's important to have the voice of
users in the technical community, but I agree with Stephen that the TSC
would not be the appropriate forum for that.

Thanks,
Dave.

-- 
Dave Neary - NFV/SDN Community Strategy
Open Source and Standards, Red Hat - http://community.redhat.com
Ph: +1-978-399-2182 / Cell: +1-978-799-3338