Re: Architecture Board Proposal

[Dave Neary <dneary@redhat.com>]

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