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