Re: [dpdk-dev] Architecture Board Proposal

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

In order to progress this, I'd like to summarise what's been discussed on the mailing list so far (both in this thread and in the one Dave Neary started on governance proposals from the Userspace event) and give a final chance to people to provide any additional input. The main things that came up in the discussion were:

- We need to agree whether the scope of the board is just DPDK (http://dpdk.org/browse/dpdk/) or if it's all projects hosted on dpdk.org (http://dpdk.org/browse/). The consensus seemed to be just DPDK.

- It was reiterated that the board should only make decisions when a consensus isn't reached on the mailing this. This should not happen often, so the workload should be light.

- Membership needs to be based on contributions. There were requests for ARM SoC representation on the board, but most people felt that contributions should come from the SoC vendors first. Now that we're seeing more ARM-related contributions this may be less of an issue as we would have at least one ARM SoC rep to consider for membership based on recent contributions.

We do still have the difficult topic of membership to agree on. For now though, I want to make sure that we have agreement on the scope and purpose of the board. We can address membership once we've finalized that.


Tim

> -----Original Message-----
> From: O'Driscoll, Tim
> Sent: Thursday, October 29, 2015 3:22 PM
> To: dev@dpdk.org
> Subject: Architecture Board Proposal
> 
> 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