Thanks Tim,

Great to see some momentum coming out of DPDK Userspace.

On 10/29/2015 11:21 AM, O'Driscoll, Tim wrote:

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.

Speaking personally, I don't mind what we call it once there is an
agreed scope, membership process, and decision making process.
Architecture Board seems OK to me.

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?

I agree with Thomas here that this seems like it would be a separate
project under dpdk.org, rather than part of DPDK - I think it's OK for
the Architecture Board to own the scope of "projects on dpdk.org" rather
than just DPDK.

- 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.

In general I would summarise these as "act as a decision making body
when there is a difficulty converging to a decision in the community".
That includes competing technology, priorities and in general
non-converging discussions.

I think it's important to say that this body kicks in after a decision
has not converged, it is not (apart from project scope considerations,
wich will not evolve very often) a leading body, rather, it's a "last
resort" providing clarity when the community does not generate a consensus.

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?

I like co-option in this case, but I would like to have some kind of
criteria for how board removals can happen - that might be a detail, but
it's important that the architect board continue to represent the most
influential participants in the community, and I could imagine a
scenario where someone named to the board moves to a different position
and over the course of 6-12 months is less active in the project - would
they be expected to nominate a successor? Withdraw and alow others to
nominate? If they don't volunteer to withdraw, what criteria can the
board use to request that they withdrawal?

One thing I think is important is that seats are not considered "owned"
by a company. There isn't a 6WIND seat or an Intel seat - seats are held
by individuals representing the interests of the technical community,
not companies invested in the project. In general, though, I think 2
seats per company may is a good number, I would not want to have even
the perception of a majority voting block by one company.

Overall, thanks Tim! I think this is a really solid proposal.

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