Re: [dpdk-moving] description of technical governance

[Matt Spencer <Matt.Spencer@arm.com>]

[-- Attachment #1.1: Type: text/plain, Size: 7603 bytes --]

Hi Guys


I have a few thoughts on the TSC membership as is outlined by the OVS model that we appear to be wanting to adopt.  The information I have here is taken from a snapshot of the MAINTAINERS file in the latest release of DPDK, and does not take into account what Tim mentions below.


Attached is a spreadsheet that shows how the TSC would look if we were to adopt the OVS model today, and I believe it highlights why a variation of the model be adopted.  As it stands today, it would be heavily biassed towards one company to the point that one organisation would have a virtual veto within the TSC.  I also believe that there would be too many members of the TSC which would hinder it from being an effective governing body for DPDK.


I would the therefor like to put forward a few additional models for suggestion:


1 - we adopt the model as is - one TSC member per committer

       o As this stands today, that would give us 56 TSC members, with almost half of them from one company


2 - we adopt the model as is - one TSC member per committer - to a maximum of 20% membership of the TSC

       o This would ensure that no one company can 'own' the TSC - 56 committers, so max TSC membership from one company would be 11


3 - Maximum one member of TSC per committing company, plus one TSC assignee per paid member

       o This would keep the TSC to a manageable level, give companies an incentive to join, but not require membership to be on the TSC


4 - Something else?


My current thoughts are with 3 because we should end up with a representative cross section of the stakeholders of the project, whilst still incentivising membership of the foundation.


My 2c, let me know what you think.


Regards


Matt

________________________________
From: moving <moving-bounces@dpdk.org> on behalf of O'Driscoll, Tim <tim.odriscoll@intel.com>
Sent: 28 October 2016 10:13:51
To: O'Driscoll, Tim; Thomas Monjalon; moving@dpdk.org
Subject: Re: [dpdk-moving] description of technical governance


> -----Original Message-----
> From: moving [mailto:moving-bounces@dpdk.org] On Behalf Of O'Driscoll,
> Tim
> Sent: Wednesday, October 26, 2016 11:22 AM
> To: Thomas Monjalon <thomas.monjalon@6wind.com>; moving@dpdk.org
> Subject: Re: [dpdk-moving] description of technical governance
>
>
> > -----Original Message-----
> > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> > Sent: Tuesday, October 25, 2016 3:00 PM
> > To: moving@dpdk.org
> > Cc: O'Driscoll, Tim <tim.odriscoll@intel.com>
> > Subject: Re: [dpdk-moving] description of technical governance
> >
> > 2016-10-25 11:27, O'Driscoll, Tim:
> > > We also have a gap in terms of documenting technical governance.
> > > Even ignoring the move to LF, Matt in particular was looking for
> > > more clarity on this.
> > > Thomas: would you be willing to create and post a proposal on this?
> >
> > The technical governance is consensus-based.
> > The board was built in case a consensus is not found.
> >
> > There are several projects with their own git trees.
> > DPDK and the web site are two of them.
> >
> > The DPDK project is organized around some git subtrees
> > and the mainline gathers every contributions accepted in the subtrees.
> > The component maintainers are quality responsibles for the code and
> > the git history. They coordinate how improvements and fixes are done.
> > The git tree committers are responsibles of the pace, giving time for
> > reviews and tests while releasing in time. They also do the last
> checks
> > or call for help when there is no progress on a patch.
> >
> > Is it the kind of information you are looking for?
> > I think the technical governance must be described on the web site
> > in the "development" page.
> > It is already partly described but it may requires more details and
> > updates.
>
> Yes, it's the additional detail that I was asking about. If you look at
> what we have at the moment (http://dpdk.org/dev), it's quite brief.
> Other projects typically have more detail, for example:
> - FD.io Technical Community Charter: https://fd.io/governance/technical-
> community-charter
> - OvS technical governance including committer responsibilities and
> process for adding and removing committers:
> http://openvswitch.github.io/contributors/
> - ODL TSC Charter: https://www.opendaylight.org/tsc-charter
>
> We don't necessarily need as much detail as they have, but I think we do
> need a bit more than we have at the moment. From a brief discussion with
> Mike Dolan during our previous engagement with the LF earlier in the
> year, the LF would simply be looking for DPDK technical governance to be
> properly documented, and for it to be meritocratic (e.g. committers
> chosen based on history of contributions rather than the company they
> work for).
>
> Matt also had some thoughts during our discussion in Dublin on things
> he'd like to see added to the technical governance. Perhaps he can
> comment further on what he'd like to see.
>
> In terms of where this is documented, I don't think that matters, and
> adding some additional detail to the existing Development page seems
> like a good solution to me.

I haven't seen anybody else comment on aspects of the technical governance that should be clarified, so here are a few comments/questions from me that might help to prompt some discussion.

We have a few different types of maintainers: 1) those responsible for reviewing changes in individual libraries who are identified in the MAINTAINERS file; 2) sub-tree maintainers who submit pull requests to the main tree; 3) stable release maintainer; 4) main tree maintainer; 5) maintainers for other projects hosted on dpdk.org (pktgen, spp etc.). We should document the responsibilities of each of these, and the process for adding and removing them.

At the moment, the MAINTAINERS file doesn't identify the sub-tree maintainers or the stable release maintainer. I think they should be included.

At the moment, other projects hosted on dpdk.org (pktgen, spp etc.) don't have a MAINTAINERS file. I think this should be mandatory for all sub-projects within DPDK.

Should every repo have more than one person with commit rights so that we're not dependent on a single person? They would obviously have to coordinate on who does what, which could involve sharing the workload or operating on an active/backup basis.

We should document how members of the Tech Board get added/removed. We should also clarify the scope. Is the scope of the Tech Board just DPDK itself (http://dpdk.org/browse/dpdk/tree/), or does it also cover the other projects hosted on dpdk.org (http://dpdk.org/browse/)? If it's just DPDK, then who provides the technical oversight for the other projects? My preference would be for the existing board to cover all sub-projects.

We should document the process for adding a new sub-project like pktgen or SPP. At the moment I think it's proposed on the dev mailing list and added if there's a consensus. Should it be mandatory that new project proposals are reviewed and approved by the Tech Board, to make sure there's consistency and nothing gets missed in a flood of email?

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

[-- Attachment #1.2: Type: text/html, Size: 9890 bytes --]

[-- Attachment #2: TSC Members by company.xlsx --]
[-- Type: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet, Size: 54665 bytes --]