[dpdk-dev] Technical Steering Committee (TSC)

["O'Driscoll, Tim" <tim.o'driscoll@intel.com>]

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.