At the recent DPDK Userspace event we agreed that we need a body to make technical decisions for the project. In Dublin we referred to this as a Technical Steering Committee, but that term is often used on other projects to describe a body with a more political charter. To avoid confusion, and clarify that the scope of this body for DPDK is purely technical, I propose calling it the DPDK Architecture Board.
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 an Architecture Board will 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. Scope ----- Issues that are within the scope of the Architecture Board 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. If there's a new implementation of an existing DPDK capability that performs better in some use cases but worse in others, does that get accepted and replace the existing implementation, does it get accepted as an alternative, or does it get rejected? - Unresolved issues. Provide a decision on issues that don't reach a consensus on the mailing list in a timely manner. Composition ----------- For composition of the Architecture Board, I'd propose the following: - It needs to be kept to a manageable size. I propose limiting it to 5 initially (it should be an odd number to minimize deadlocks). - Membership should be based on: number and quality of contributions, technical standing in the community, breadth of involvement (involvement in many areas, not just a single part of DPDK). - No single company/organization can have more than 2 members. - The Architecture Board will elect its own chair, who will have the deciding vote in the event of a deadlock. - The board will review its own composition and co-opt/approve any new members on an annual basis. There are three main options for determining who is on the board: 1. Nomination of representatives by contributing companies. We could allocate a number of positions on the board based on the contributions from each company and then allow those companies to nominate their representatives. The downsides are that many companies contribute but not all can be represented on the board so we'd need a way to decide which companies get a seat and which don't, and that this focuses the discussion on company contributions rather than individuals with the best technical standing 2. Election of representatives. We could poll for candidates and then vote. This is likely to take time because we'll need to agree and implement the process to support an election. 3. Seed the board with those who have the best technical standing in the community. We could determine the initial composition by consensus. I think the prime candidates for an Architecture Board will be obvious to most of us. My preference would be for option 3. Any other opinions or comments on this proposal? Tim
