From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f46.google.com (mail-vk0-f46.google.com [209.85.213.46]) by dpdk.org (Postfix) with ESMTP id DA9AB914 for ; Mon, 31 Oct 2016 17:33:53 +0100 (CET) Received: by mail-vk0-f46.google.com with SMTP id x186so50158262vkd.1 for ; Mon, 31 Oct 2016 09:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WyaF/U1M8k3Z8YZ+kUFEZ4KEIL2GKG5C0tS1g9lHMl0=; b=eMMANZjcnDwHK2VDd6bBQn/RIxGIoXj3U++FTX5o938lD2OgFadmWJTrfDcI/DGOUU Z8E9/oC9YcIWOrazQTEVAeSkGj1+D2jzHbzN4HqhfZNKVWkzpK9litieSpW3yowgJ608 RMxYPyfFgqYVsVrihc5W/xps0yJfYQwh+O3Iw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WyaF/U1M8k3Z8YZ+kUFEZ4KEIL2GKG5C0tS1g9lHMl0=; b=ZX1yF5sBx7+xgOJtWAIISeylrpdqHbhYQn0UM8NuccoDBqLni75JgGp0+okWHbtg81 Jf1gth1M16Sw3gAt1q2owq/2suYXLXMz0I3c0uDc/J6magNDnXyZfbQlhXDXDfBwoyo5 S0EEWu7OedwVQnh7ObJ3OXIj86ghi7atqQ1fl6XOwItpP11VTvqAzWk6xsKK6C9nl8nl +vaW+ci13BvNUD3U8NJkrWsqNXVCbVuacjMGqcmjrCF0f+8VU7uy7qjVZ2pb6clJS3S+ E2mUf76DWKsC4pRoWAPCk1wONtQqN4YCk8iCyd+oMZRFM4+T7X+D3l6ULXfOq0MtXEN+ v40w== X-Gm-Message-State: ABUngvdmrFdtGKu6Ss2cqT5mwYoPTVBnIGEZmFoMGKb18gbeIrR0H0L4ev2GMk3BEnDH2qyg0Ay2Tv3FThQr8K6Z X-Received: by 10.31.149.138 with SMTP id x132mr5687124vkd.86.1477931633147; Mon, 31 Oct 2016 09:33:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.65.33 with HTTP; Mon, 31 Oct 2016 09:33:52 -0700 (PDT) In-Reply-To: References: <26FA93C7ED1EAA44AB77D62FBE1D27BA676091C7@IRSMSX108.ger.corp.intel.com> <2677739.KbWyRmNgFH@xps13> <1580d802a08.27fc.bb328046f2889bc8f44aafa891a44dd2@6wind.com> From: Michael Dolan Date: Mon, 31 Oct 2016 12:33:52 -0400 Message-ID: To: Matt Spencer Content-Type: multipart/alternative; boundary=001a1141003aff166a05402bc54b Cc: "moving@dpdk.org" Subject: Re: [dpdk-moving] description of technical governance X-BeenThere: moving@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK community structure changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Oct 2016 16:33:54 -0000 --001a1141003aff166a05402bc54b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Matt, happy to. If you look at the third paragraph in my email I do refer to setting up a TSC in order to encourage/force company diversity of contributors in a project. FD.io was setup with one initial project called VPP. In that case, it was 100% Cisco developers/engineers working on it. The TSC does not make any code decisions. The TSC becomes a place for discussing architecture, accepting new projects into FD.io or discussing future roadmap ideas, but the TSC does not make contributions - that happens in the projects/sub-projects through developers and engineers making contributions. So, yes, some projects do have the option for a top tier member to appoint a participant onto the TSC - but that's most often to encourage diversity of companies contributing to the project. If we had setup FD.io with 1 project VPP and 100% Cisco maintainers... that's pretty tough for anyone else to support. So we're artificially creating a more diverse structure so 1 company couldn't just make all the decisions and direct the future of the Project. Further, the TSC sets the rules for becoming a committer/maintainer. However, you should also take into account that while a top tier member in FD.io can appoint a representative to the TSC, our TSC's also include the PTLs from the main projects. I stated this in my long email, but to put it bluntly here - in my view, putting top tier members on a TSC is tool to use when you want to improve the corporate diversity of contribution. This is usually most beneficial in Projects that start with 1 company's codebase. Where we don't have a top tier membership appointing seats on a TSC, our projects typically default to the top level project Maintainers or some representation of Maintainers (e.g. an annual election) so that cross-project decisions can be made. Whether DPDK has a diverse enough contributor community is not something I can opine on - it does appear there are many companies involved in using DPDK but I've not analyzed the code contributions and where they're coming from. I'll leave that to you all who probably know far better than I do. Does this help Matt? -- Mike --- Mike Dolan VP of Strategic Programs The Linux Foundation Office: +1.330.460.3250 Cell: +1.440.552.5322 Skype: michaelkdolan mdolan@linuxfoundation.org --- On Mon, Oct 31, 2016 at 12:18 PM, Matt Spencer wrote= : > Hi Michael > > > Can you give me some clarification then. I understand that we are not > 'buying a vote', but if I look at the model for FD.io for example ( > https://fd.io/sites/cpstandard/files/pages/files/ > exhibit_a_-_fd.io_project_by-laws.pdf) , the Platinum level membership > gets you a seat on the Board, plus in section 2.3.b '*designate one > representative to serve as a member of the TSC*'. When the TSC is used > to vote on architectural issues/direction of the project this really does > look like 'buying a vote' to me? > > > I hope you can understand why I am a little confused by your comments now= ? > > > Regards > > > Matt > ------------------------------ > *From:* Michael Dolan > *Sent:* 31 October 2016 16:07:03 > *To:* Matt Spencer > *Cc:* Vincent Jardin; Thomas Monjalon; moving@dpdk.org > > *Subject:* Re: [dpdk-moving] description of technical governance > > Hi everyone, it's great to see the discussion and thoughts. I'll point ou= t > a few nuances to how we run projects to help with expectations and > structural understanding. > > First, for technical governance, the project/sub-projects always make > technical decisions. There is no option to "buy a vote" - you "vote" with > contributions, technical merit and becoming a committer/maintainer over > time based on prior contribution and technical leadership. > > Some Projects do setup a TSC ("Technical Steering Committee") that > oversees the Project structure (e.g. sub-projects, modules, etc), the > technical community (e.g. elevating new Maintainers/Committers) and any > technical policies / rules (e.g. tabs vs spacing, release timelines and > milestones, etc). Some Projects do give funders a role on the TSC, but th= at > varies widely and we try to avoid it if a community already has a diverse > technical contribution community. It's generally most helpful when starti= ng > a Project based entirely on 1 company's codebase and it gives others a sa= y > to ensure it's neutral while new committers are ramping up/learning the > codebase. > > Second, we do host projects that do not raise any funds at all. They're > projects we'll host for LF members if there's a community interested in i= t. > However, please understand up front that those projects receives no > resources from the LF. E.g. we don't run an OVS infrastructure for CI. Th= e > LF simply becomes the neutral home for key community assets like the > trademark and domain so 1 participant in the community doesn't control > everything. Please understand the LF is a non-profit and we receive funds > from various projects but those funds are for those projects and we can't > take funds from some other effort and apply them to DPDK - our auditors a= nd > members of the other projects we took funds from would not be happy to sa= y > the least. > > Third, when there is funding involved in a project, we typically setup a > Governing Board that owns responsibility for how to spend the funding. Th= e > Governing Board does not make technical decisions or tell the technical > projects what to do. The Governing Board is simply for those contributing > funds to have a say in how those funds are spent. Often some projects wil= l > also setup the Governing Board to work on any marketing or legal topics a= s > well. Ultimately the LF will not be making decisions on how Project funds > are spent, so we rely on the funders to make those decisions. > > Typically there's a single or multi-tier membership structure. If > multi-tier, the top tier usually gets an automatic seat on the Governing > Board and a lower tier usually has a representation model (e.g. 1 seat pe= r > every X lower tier members). Typically the ratio is based on roughly what > the contribution of X is relative to the higher tier members. E.g. if > there's a top tier "Premier" at $50k/year and a lower tier "General" and = it > has a blended average of $5k/year, then there would be 1 General Member > seat for ever 10 General Members to roughly equal what the Premier Member= s > are paying. > > Note that this investment at any level does not "buy" technical decisions= . > Members who contribute funds do so to make sure there is something they > want available for the community (e.g. if build/CI infrastructure is > desired). What they get is a leveraged investment - e.g. they're not payi= ng > to build the entire infrastructure themselves, but sharing the cost with > others. Typically a "hook" is to have a logo or something available to sh= ow > your company is a "DPDK Project Member" or "Sponsor" and then to have an > opportunity to be on the Governing Board. > > Without the funding, the community resources would not exist or would hav= e > to be provided by someone in the community unilaterally. Node.js for > example receives a lot of contributions of various resources (e.g. CDN) f= or > free from members of their ecosystem - which means they can raise a much > lower amount in membership fees. And for some communities like OVS, they > really don't need any public community resources other than GitHub and a > webpage - and that's just fine for them. > > I apologize for the length, but hopefully this will be helpful in guiding > discussions about how LF Projects are structured and some of the rational= e > behind it. > > Thanks, > > Mike > > > --- > Mike Dolan > VP of Strategic Programs > The Linux Foundation > Office: +1.330.460.3250 Cell: +1.440.552.5322 Skype: michaelkdolan > mdolan@linuxfoundation.org > --- > > On Mon, Oct 31, 2016 at 11:20 AM, Matt Spencer > wrote: > >> Thanks for the responses. I'm really looking forward to the debate late= r >> today! >> >> >> One point I would raise, and it is one that Thomas picked up on a bit. = I >> don't think we can have a pure meritocracy /and/ expect some of the >> membership to pay to support the project management. I am going to have= a >> very hard time explaining to my exec why we should be spending $$$ on DP= DK >> when there is no clear benefit to membership. >> >> >> Comparisons have ben made to the OVS project, which is fine, but OVS doe= s >> not have any membership costs (as far as I can see) and LF host this >> project for free. >> >> >> I don't think we can have both of these positions hold true. We either >> have >> >> 1 - a pure meritocracy - ie the governance does not change and I believ= e >> we are in the same position as we are today >> >> 2 - Something a bit more like FD.io, with paid membership and paid >> access to a board/TSC >> >> >> Regards >> >> >> Matt >> ------------------------------ >> *From:* Vincent Jardin >> *Sent:* 28 October 2016 23:54:13 >> *To:* Thomas Monjalon; moving@dpdk.org; Matt Spencer >> *Subject:* Re: [dpdk-moving] description of technical governance >> >> >> >> Le 28 octobre 2016 9:22:43 PM Thomas Monjalon >> a >> =C3=A9crit : >> >> > 2016-10-28 16:52, Matt Spencer: >> >> 1 - we adopt the model as is - one TSC member per committer >> >> 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 >> >> 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 >> >> 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. >> > >> > Thanks for sharing your view. >> > >> > I'm an Open Source guy and I might lack some politician skills. >> > So please excuse me if I take the freedom to talk really frankly :) >> > >> > First of all, this email thread was dedicated to the technical >> governance. >> > And Matt is introducing money in this topic by talking about incentive= s. >> > I think it is a very interesting point that we must discuss. >> > From the beginning, everybody were saying that we must keep technical >> > governance and legal structure separate. >> > However one question has still no good answer: what is the incentive >> > for contributing money in the structure? >> > Is money going to biase the desired meritocratic system? >> > >> > My second comment is about having one company controlling the technica= l >> > governance. >> > I won't enter into the number details, and it's true that Intel provid= es >> > at least 50% of the contributions nowadays. Intel is also the biggest >> > contributor to Linux. No surprise. >> > I understand that a voice from ARM is requiring to mitigate this fact. >> > I would prefer ARM related companies working to achieve the same >> > level of commitment as Intel. They are increasing their contribution >> pace >> > but may never really compete with a giant like Intel. >> > That's why I second Matt to say that we must give a chance to every >> > vendors to influence the technical decisions. >> > Introducing a membership threshold looks to be a good idea. >> > >> > Having said that, I must state that the DPDK reality is a lot more >> > complex than a competition between vendors. >> > We are proving that a consensus based model works very well without >> > the need of a TSC or a board. >> > We can create such organization, but please keep in mind that it shoul= d >> > not be really helpful in the day-to-day job. >> >> +2 >> >> From contributions, meritocracy is applied. >> >> >> 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 t= he >> information in any medium. Thank you. >> > > 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 th= e > information in any medium. Thank you. > --001a1141003aff166a05402bc54b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Matt, happy to. If you look at the third paragraph in m= y email I do refer to setting up a TSC in order to encourage/force company = diversity of contributors in a project. FD.io was setup with one initial pr= oject called VPP. In that case, it was 100% Cisco developers/engineers work= ing on it. The TSC does not make any code decisions. The TSC becomes a plac= e for discussing architecture, accepting new projects into FD.io or discuss= ing future roadmap ideas, but the TSC does not make contributions - that ha= ppens in the projects/sub-projects through developers and engineers making = contributions. So, yes, some projects do have the option for a top tier mem= ber to appoint a participant onto the TSC - but that's most often to en= courage diversity of companies contributing to the project. If we had setup= FD.io with 1 project VPP and 100% Cisco maintainers... that's pretty t= ough for anyone else to support. So we're artificially creating a more = diverse structure so 1 company couldn't just make all the decisions and= direct the future of the Project. Further, the TSC sets the rules for beco= ming a committer/maintainer.=C2=A0

However, you should a= lso take into account that while a top tier member in FD.io can appoint a r= epresentative to the TSC, our TSC's also include the PTLs from the main= projects.=C2=A0 I stated this in my long email, but to put it bluntly here= - in my view, putting top tier members on a TSC is tool to use when you wa= nt to improve the corporate diversity of contribution. This is usually most= beneficial in Projects that start with 1 company's codebase.=C2=A0

Where we don't have a top tier membership appoint= ing seats on a TSC, our projects typically default to the top level project= Maintainers or some representation of Maintainers (e.g. an annual election= ) so that cross-project decisions can be made.=C2=A0

Whether DPDK has a diverse enough contributor community is not something= I can opine on - it does appear there are many companies involved in using= DPDK but I've not analyzed the code contributions and where they'r= e coming from. I'll leave that to you all who probably know far better = than I do.=C2=A0

Does this help Matt?
-- Mike

---
Mike Dolan
VP of Strategic Programs
The Li= nux Foundation
Office: +1.330.460.3250 =C2=A0=C2=A0Cell: +1.440.552.5322= =C2=A0Skype: michaelkdolan
mdolan@linuxfoundation.org
---

<= /div>

On Mon, Oct 31, 2016 at 12:18 PM, Matt Spenc= er <Matt.Spencer@arm.com> wrote:

Hi Michael


Can you give me some clarification then.=C2=A0 I understand that we are = not 'buying a vote', but if I look at the model for FD.io for examp= le (https://fd.io/sites/cpstandard/files/pages/files/exh= ibit_a_-_fd.io_project_by-laws.pdf)=C2=A0, the Platinum level membership gets you a seat on the Board, plus in sectio= n 2.3.b 'designate one representative to serve as a member of = the TSC'.=C2=A0 When the TSC is used to vote on architectural issue= s/direction of the project this really does look like 'buying a vote' to me?


I hope you can understand why I am a little confused by your comme= nts now?


Regards


Matt

From: M= ichael Dolan <mdolan@linuxfoundation.org>
Sent: 31 October 2016 16:07:03
To: Matt Spencer
Cc: Vincent Jardin; Thomas Monjalon; moving@dpdk.org

Subject: Re: [dpdk-moving] description of technical governance
=
=C2=A0
Hi everyone, it's great to see the discussion and thou= ghts. I'll point out a few nuances to how we run projects to help with = expectations and structural understanding.=C2=A0

First, for technical governance, the project/sub-projects always make = technical decisions. There is no option to "buy a vote" - you &qu= ot;vote" with contributions, technical merit and becoming a committer/= maintainer over time based on prior contribution and technical leadership.=C2=A0

Some Projects do setup a TSC ("Technical Steering Committee"= ) that oversees the Project structure (e.g. sub-projects, modules, etc), th= e technical community (e.g. elevating new Maintainers/Committers) and any t= echnical policies / rules (e.g. tabs vs spacing, release timelines and milestones, etc). Some Projects do give funders a ro= le on the TSC, but that varies widely and we try to avoid it if a community= already has a diverse technical contribution community. It's generally= most helpful when starting a Project based entirely on 1 company's codebase and it gives others a say to en= sure it's neutral while new committers are ramping up/learning the code= base.=C2=A0

Second, we do host projects that do not raise any funds at all. They&#= 39;re projects we'll host for LF members if there's a community int= erested in it. However, please understand up front that those projects rece= ives no resources from the LF. E.g. we don't run an OVS infrastructure for CI. The LF simply becomes the neutral home f= or key community assets like the trademark and domain so 1 participant in t= he community doesn't control everything. Please understand the LF is a = non-profit and we receive funds from various projects but those funds are for those projects and we can't t= ake funds from some other effort and apply them to DPDK - our auditors and = members of the other projects we took funds from would not be happy to say = the least.

Third, when there is funding involved in a project, we typically setup= a Governing Board that owns responsibility for how to spend the funding. T= he Governing Board does not make technical decisions or tell the technical = projects what to do. The Governing Board is simply for those contributing funds to have a say in how those fu= nds are spent. Often some projects will also setup the Governing Board to w= ork on any marketing or legal topics as well. Ultimately the LF will not be= making decisions on how Project funds are spent, so we rely on the funders to make those decisions.=C2=A0<= /div>

Typically there's a single or multi-tier membership structure. If = multi-tier, the top tier usually gets an automatic seat on the Governing Bo= ard and a lower tier usually has a representation model (e.g. 1 seat per ev= ery X lower tier members). Typically the ratio is based on roughly what the contribution of X is relative to th= e higher tier members. E.g. if there's a top tier "Premier" a= t $50k/year and a lower tier "General" and it has a blended avera= ge of $5k/year, then there would be 1 General Member seat for ever 10 General Members to roughly equal what the Premier Members are = paying.

Note that this investment at any level does not "buy" techni= cal decisions. Members who contribute funds do so to make sure there is som= ething they want available for the community (e.g. if build/CI infrastructu= re is desired). What they get is a leveraged investment - e.g. they're not paying to build the entire infrastructur= e themselves, but sharing the cost with others. Typically a "hook"= ; is to have a logo or something available to show your company is a "= DPDK Project Member" or "Sponsor" and then to have an opportunity to be on the Governing Board.=C2=A0

Without the funding, the community resources would not exist or would = have to be provided by someone in the community unilaterally. Node.js for e= xample receives a lot of contributions of various resources (e.g. CDN) for = free from members of their ecosystem - which means they can raise a much lower amount in membership fees. And f= or some communities like OVS, they really don't need any public communi= ty resources other than GitHub and a webpage - and that's just fine for= them.

I apologize for the length, but hopefully this will be helpful in guid= ing discussions about how LF Projects are structured and some of the ration= ale behind it.

Thanks,

Mike


---
Mike Dolan
VP of Strategic Programs
The Linux Foundation
Office: +1.330.460.3250 =C2=A0=C2=A0Cell: +1.440.552.5322 =C2=A0Sky= pe: michaelkdolan
mdolan@linu= xfoundation.org
---


On Mon, Oct 31, 2016 at 11:20 AM, Matt Spencer <= span dir=3D"ltr"> <Matt.Spencer@= arm.com> wrote:

Thanks for the responses.=C2=A0 I'm really looking forward to the de= bate later today!


One point I would raise, and it is one that Thomas picked up on a bit.= =C2=A0 I don't think we can have a pure meritocracy /and/ expect some o= f the membership to pay to support the project management.=C2=A0 I am going= to have a very hard time explaining to my exec why we should be spending $$$ on DPDK when there is no clear benefit to me= mbership.


Comparisons have ben made to the OVS project, which is fine, but OVS doe= s not have any membership costs (as far as I can see) and LF host this proj= ect for free.


I don't think we can have both of these positions hold true.=C2=A0 W= e either have

=C2=A01 - a=C2=A0pure=C2=A0meritocracy - ie the governance does not chan= ge and I believe we are in the same position as we are today

=C2=A02 - Something a bit more like FD.io, with paid membership and paid= access to a board/TSC


Regards


Matt

From: Vincent Jardin <vincent.jardin@6wind.com>
Sent: 28 October 2016 23:54:13
To: Thomas Monjalon; moving@dpdk.org; Matt Spencer
Subject: Re: [dpdk-moving] description of technical governance
=C2=A0


Le 28 octobre 2016 9:22:43 PM Thomas Monjalon <thomas.monjalon@6wind.com> a
=C3=A9crit :

> 2016-10-28 16:52, Matt Spencer:
>> 1 - we adopt the model as is - one TSC member per committer
>> 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
>> This would ensure that no one company can 'own' the TSC -<= br> >> 56 committers, so max TSC membership from one company would be 11<= br> >>
>> 3 - Maximum one member of TSC per committing company,
>> plus one TSC assignee per paid member
>> This would keep the TSC to a manageable level, give companies
>> an incentive to join, but not require membership to be on the TSC<= br> >>
>> 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.
>
> Thanks for sharing your view.
>
> I'm an Open Source guy and I might lack some politician skills. > So please excuse me if I take the freedom to talk really frankly :) >
> First of all, this email thread was dedicated to the technical governa= nce.
> And Matt is introducing money in this topic by talking about incentive= s.
> I think it is a very interesting point that we must discuss.
> From the beginning, everybody were saying that we must keep technical<= br> > governance and legal structure separate.
> However one question has still no good answer: what is the incentive > for contributing money in the structure?
> Is money going to biase the desired meritocratic system?
>
> My second comment is about having one company controlling the technica= l
> governance.
> I won't enter into the number details, and it's true that Inte= l provides
> at least 50% of the contributions nowadays. Intel is also the biggest<= br> > contributor to Linux. No surprise.
> I understand that a voice from ARM is requiring to mitigate this fact.=
> I would prefer ARM related companies working to achieve the same
> level of commitment as Intel. They are increasing their contribution p= ace
> but may never really compete with a giant like Intel.
> That's why I second Matt to say that we must give a chance to ever= y
> vendors to influence the technical decisions.
> Introducing a membership threshold looks to be a good idea.
>
> Having said that, I must state that the DPDK reality is a lot more
> complex than a competition between vendors.
> We are proving that a consensus based model works very well without > the need of a TSC or a board.
> We can create such organization, but please keep in mind that it shoul= d
> not be really helpful in the day-to-day job.

+2

=C2=A0From contributions, meritocracy is applied.


IMPORTANT NOTICE: The contents of this email and any at= tachments are confidential and may also be privileged. If you are not the i= ntended 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 me= dium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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.

--001a1141003aff166a05402bc54b--