Date   

Trusted Compute Framework (TCF) Project Proposal

Yarmosh, Yevgeniy Y
 

Hello,

I have just posted Trusted Compute Framework (TCF) Project Proposal for the review and discussion.

Regards,
Eugene Yarmosh
yevgeniy.y.yarmosh@...


Re: SIGs vs WGs (was Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.)

Christopher Ferris <chrisfer@...>
 

Thanks
 
Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
email: chrisfer@...
twitter: @christo4ferris
IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
phone: +1 508 667 0402
 
 

----- Original message -----
From: "VIPIN BHARATHAN" <vip@...>
Sent by: tsc@...
To: "chris.ferris@..." <chris.ferris@...>
Cc: "tsc@..." <tsc@...>
Subject: [EXTERNAL] Re: SIGs vs WGs (was Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.)
Date: Fri, Aug 16, 2019 10:35 AM
 
Chris,
I think it is quarterly. Some of the SIGs are brand new so they dont have any updates yet like the CMSIG. There should be updates from Telecomm,  Supplychain, Healthcare and Trade Finance.
Best,
Vipin

From: tsc@... <tsc@...> on behalf of Christopher Ferris via Lists.Hyperledger.Org <chris.ferris=gmail.com@...>
Sent: Friday, August 16, 2019 10:26 AM
To: Me
Cc: tsc@...
Subject: Re: SIGs vs WGs (was Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.)
 
Brian wrote: "SIGs are expected to provide a one-presentation-deck-page report each month on their activities and accomplishments, which is provided to the Governing Board for their monthly discussions."
 
I see SIG quarterly reports from a handful of the SIGs (only 3 reported in 2Q?) but I don't see monthly reports anywhere. Is there a reason that they are not also posted on the wiki? Or, are these one and the same (eg not monthly but quarterly), and if so, where are the others?
 
Chris
 
On Fri, Aug 16, 2019 at 9:54 AM Christopher Ferris viaLists.Hyperledger.Org <chris.ferris=gmail.com@...> wrote:
Brian wrote: "Creation of any new working group should partially be gated by whether it's reasonable to expect most of the projects to be able to have people actively following and participating in that new WG."
+100
 
Chris
 
On Thu, Aug 15, 2019 at 2:29 PM Brian Behlendorf <bbehlendorf@...> wrote:
Changing the subject to address a point in Hart's earlier email:
 
On 8/15/19 8:17 AM, hmontgomery@... wrote:
I think a lot of people are, in fact, using SIGs for relatively technical purposes.  Having or starting a SIG is much better right now than a working group:  you get all of the support from the LF that you would for a WG (meeting times, mailing list, etc.), you aren’t mandated to submit time-consuming work products to the TSC (that, let’s be honest, very few people read), and the approval process is far simpler and doesn’t require TSC approval (which could take quite some time and be a huge headache).  If you were looking to start a group—even a very technical one--why on earth would you choose a WG over a SIG? 

I sincerely hope this is not the reason why one would choose to start a SIG rather than a WG.

Working Groups should be thought of as our connective tissue between projects - the cross-project place where discussions about identity, performance/scalability, architectural concerns, learning materials, and even diversity & civility issues can be discussed and iterated upon without that discussion being owned by one project or another.  In particular for anyone who holds architectural or product convergence as a priority, certain Working Groups like identity and architecture should be the place to articulate what that means, and then create specific technical plans that projects can follow.  They only can serve that role well to the degree they are primarily driven by active maintainers and contributors on the projects themselves, but given critical mass there can be other participants on those working groups.  Creation of any new working group should partially be gated by whether it's reasonable to expect most of the projects to be able to have people actively following and participating in that new WG.

Special Interest Groups are intended to be more of a bridge to the outside world - to people deploying our technologies for particular categories of use cases.  Those might be grouped by industrial segment, e.g. "trade finance".  Or they may be grouped by a broad set of functionality, e.g. "supply chain", that is more of a recurring theme across all industries than a specific industry.  But the point is that a SIG should be composed of both insiders and outsiders - of both technologists close to what one or more Hyperledger projects are doing, and of those who may simply be "users" of the technology, perhaps even one or two steps downstream, but who is willing to share their domain expertise and involvement in active projects at a business level to drive adoption.

I think based on the above, a SIG for academic involvement makes more sense than a working group, as it's less about cross-project issues and more about being a bridge to the outside world (and yes, helping those outsiders become insiders).  Marta has been managing our academic outreach efforts to date, so I'd encourage you to connect with her on ways we can make a SIG effective.

Let me also burst your bubble a bit - SIGs are expected to provide a one-presentation-deck-page report each month on their activities and accomplishments, which is provided to the Governing Board for their monthly discussions.  Also, we (HL staff) are very deliberate about launching new SIGs - they can often take months to pull together the right stakeholder set, define the charter crisply enough, and make sure they are managed closely enough by us.  So it may only look easier & quicker.  :)  But given all the interest in improving our relationship with academia I think we'd be able to move on this with reasonable expediency. 

Brian

-- Brian BehlendorfExecutive Director, Hyperledgerbbehlendorf@...Twitter: @brianbehlendorf

 

 

 

 

 


Re: Hyperledger Besu Proposal is Live

Silas Davis
 

Hello list,

Others will be aware that as a maintainer of Hyperledger Burrow - 'the Ethereum project' of Hyperledger - that we are likely to be most affected by the accession of Pantheon/Besu into Hyperledger.

I have had several weeks to reflect on this and talk with various people including meeting with some of the PegaSys team. I believe that on balance the benefits of Pantheon joining Hyperledger outweigh the costs.

The first category of costs and benefits, which are closest to my heart, are those relating to Burrow. Ultimately I think the costs of a technically energetic and competent project joining Hyperledger and competing (or out-competing) an existing project do not in principle justify rejecting such a project. That would be a form of protectionism and ultimately counterproductive. In any case I will enumerate the costs to Burrow as I see them:

1. Ethereum users coming to Hyperledger are unlikely to choose Burrow over Besu - Besu is a drop-in mainnet replacement and Burrow is not. We have a number of minor to medium differences the prevent this - RPC layer, signing, serialisation, p2p layer, consensus layer.

2. So far there has not been sufficient community interest to resolve the issues above. I see no reason to believe that is likely to change soon. However I do think it is _even less likely_ once Besu were to join. And it is reasonable to imagine that Besu will reduce the big end of our contributor funnel (though see my coda on this below)

3. Burrow has so far not implemented the EEA client spec - and is unlikely to in monolithic form. Besu being validated by being in Hyperledger and EEA client spec compliant pressures the space for projects that do things differently (this is a both a good thing in terms of longer term standardisation and a bad thing in terms of innovation).

The benefits to Burrow:

1. This has provided something of a kick up the arse to the Burrow project to do a bit of a better job and describing what we have _outside_ of including an 'EVM' implementation. We are also a bridge to Tendermint/Cosmos, have an innovative state mechanism, a Solidity/SQL mapping layer, and experimental WASM support over the Ethereum account model. As I have mentioned in our previous quarterly report work is underway to do this (start here: http://hyperledger.github.io/burrow/#/ plus we have a blog post coming, plus more docs on core features.

2. Having spoken with members of the PegaSys protocol team we think there might be some fruitful space for us to explore with building a two-way peg between Pantheon and Burrow terminated by Solidity contracts (our lingua franca) - shipping state between the two and providing access to Burrow as a sidechain (including Monax's own Agreements Network, and the wider Cosmos ecosystem in time) from Ethereum and public Ethereum to Burrow for value transfer. This is still a WIP, but there may be something, and we might be able to do something simple that works before the loftier interchain proposals are fully baked.

Moving on to the substance of the proposal I think Pantheon would bring the following benefits to Hyperledger:

1. An EEA client spec compliant eth client, that may help Hyperledger capture Ethereum-land people in a way that Burrow has not be able to.

2. The above but Apache 2 licensed - obvious given our requirements - but this is the core differentiator between Geth, Parity, and Quorum.

3. A high quality codebase - having browsed PRs, issues, and code on Github - _despite_ being written in Java...

4. A rebalancing of Hyperledger towards public and public-permissioned use cases and frameworks - there is an ambivalence towards 'layer 1' that I find surprising

5. The resources of one of the largest blockchain organisations

The downsides being:

1. Fragmentation in terms of languages and tooling - I think this is legitimate, but also a partially solved problem with GRPC, thrift, etc that blur linkable library with micro-service. Sometimes you do want to share code though and that gets worth the more languages we support.

2. Fragmentation in terms of community - this is more severe and I do not know if that would be the effect. Convergence is a slippery term - but I would not like to see us develop a 'public chain people'/'private chain people' divide. To some extent a project like Pantheon is meant to bridge this.

3. The Ethereum community has some engineering peccadilloes that we may not want to inherit, such as Not Invented Here syndrome, need to put everything in 256 bits, sometimes overly grandiose approaches to things. Avoiding 2 above could be good for both communities.

4. 'Besu' would lexicographically sort above all other frameworks - a huge incursion into 'Burrow's domain


Ultimately Pantheon will continue to exist inside or outside Hyperledger. Ethereum is far from perfect, but is has the very strong advantage of being the second most capitalised permissionless blockchain with a smart contract model sufficient for doing interesting things. I think Hyperledger should embrace integrating with that ecosystem, while eschewing being dominated by it.

Silas


On Thu, 8 Aug 2019 at 19:23, <grace.hartley@...> wrote:

Hi All,

We are excited to share that PegaSys, the Protocol Engineering team at ConsenSys, submitted the Proposal for our Ethereum client, Hyperledger Besu (currently known as Pantheon), for your consideration as a new Hyperledger project. 


We welcome your feedback on the Proposal and look forward to engaging with you on it. Feel free to send our team feedback via email or comment directly in the Proposal document.


Thank you,

PegaSys and ConsenSys Team

Joseph Lubin, ConsenSys, joseph.lubin@...
Daniel Heyman, ConsenSys/ PegSys, daniel.heyman@...
Rob Dawson, ConsenSys/ PegaSys, rob.dawson@...
Grace Hartley, ConsenSys/PegaSys, grace.hartley@...
Danno Ferrin, ConsenSys/PegaSys, danno.ferrin@...


Re: SIGs vs WGs (was Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.)

Marta Piekarska <mpiekarska@...>
 

Hi,

The SIG chairs provide a couple of sentences every month which we then convert into slides for the GB. Additionally they do proper reports and updates on quarterly basis. These started when TSC handed off the SIGs to GB and Hyperledger staff – thus there have been only two cycles of it. Indeed two SIGs this quarter did not submit their report. Public Sector Chair is in Rwanda (she’s working with UN and works as a negotiator in conflict zones) and we only got a verbal report from her this time, however the group is in a good shape, they are working on some documents and are having regular presentations which you can find on their wiki.

I am happy to be even more transparent, all the calls are recorded and open so anyone who is interested can listen to them or dial in. It will be amazing if SIGs get more boost to their activities from the TSC, they will definitely appreciate it! And thank you Dan for your participation in the Supply SIG.

 

Have a great day

m

----
Marta Piekarska-Geater
Director of Ecosystem, Hyperledger
 

SCHEDULE A MEETING WITH ME:  calendly.com/mpiekarska


marta@...
+447802336641 (U.K) - Signal and Whatsapp
Wickr: martap

Skype: martapiekarska

 

Based in the U.K.

 

 

From: "tsc@..." <tsc@...> on behalf of VIPIN BHARATHAN <vip@...>
Date: Friday, August 16, 2019 at 3:34 PM
To: "chris.ferris@..." <chris.ferris@...>
Cc: "tsc@..." <tsc@...>
Subject: Re: SIGs vs WGs (was Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.)

 

Chris,

I think it is quarterly. Some of the SIGs are brand new so they dont have any updates yet like the CMSIG. There should be updates from Telecomm,  Supplychain, Healthcare and Trade Finance.

Best,

Vipin


From: tsc@... <tsc@...> on behalf of Christopher Ferris via Lists.Hyperledger.Org <chris.ferris=gmail.com@...>
Sent: Friday, August 16, 2019 10:26 AM
To: Me
Cc: tsc@...
Subject: Re: SIGs vs WGs (was Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.)

 

Brian wrote: "SIGs are expected to provide a one-presentation-deck-page report each month on their activities and accomplishments, which is provided to the Governing Board for their monthly discussions."

 

I see SIG quarterly reports from a handful of the SIGs (only 3 reported in 2Q?) but I don't see monthly reports anywhere. Is there a reason that they are not also posted on the wiki? Or, are these one and the same (eg not monthly but quarterly), and if so, where are the others?

 

Chris

 

On Fri, Aug 16, 2019 at 9:54 AM Christopher Ferris viaLists.Hyperledger.Org <chris.ferris=gmail.com@...> wrote:

Brian wrote: "Creation of any new working group should partially be gated by whether it's reasonable to expect most of the projects to be able to have people actively following and participating in that new WG."

+100

 

Chris

 

On Thu, Aug 15, 2019 at 2:29 PM Brian Behlendorf <bbehlendorf@...> wrote:

Changing the subject to address a point in Hart's earlier email:

 

On 8/15/19 8:17 AM, hmontgomery@... wrote:

I think a lot of people are, in fact, using SIGs for relatively technical purposes.  Having or starting a SIG is much better right now than a working group:  you get all of the support from the LF that you would for a WG (meeting times, mailing list, etc.), you aren’t mandated to submit time-consuming work products to the TSC (that, let’s be honest, very few people read), and the approval process is far simpler and doesn’t require TSC approval (which could take quite some time and be a huge headache).  If you were looking to start a group—even a very technical one--why on earth would you choose a WG over a SIG? 

I sincerely hope this is not the reason why one would choose to start a SIG rather than a WG.

Working Groups should be thought of as our connective tissue between projects - the cross-project place where discussions about identity, performance/scalability, architectural concerns, learning materials, and even diversity & civility issues can be discussed and iterated upon without that discussion being owned by one project or another.  In particular for anyone who holds architectural or product convergence as a priority, certain Working Groups like identity and architecture should be the place to articulate what that means, and then create specific technical plans that projects can follow.  They only can serve that role well to the degree they are primarily driven by active maintainers and contributors on the projects themselves, but given critical mass there can be other participants on those working groups.  Creation of any new working group should partially be gated by whether it's reasonable to expect most of the projects to be able to have people actively following and participating in that new WG.

Special Interest Groups are intended to be more of a bridge to the outside world - to people deploying our technologies for particular categories of use cases.  Those might be grouped by industrial segment, e.g. "trade finance".  Or they may be grouped by a broad set of functionality, e.g. "supply chain", that is more of a recurring theme across all industries than a specific industry.  But the point is that a SIG should be composed of both insiders and outsiders - of both technologists close to what one or more Hyperledger projects are doing, and of those who may simply be "users" of the technology, perhaps even one or two steps downstream, but who is willing to share their domain expertise and involvement in active projects at a business level to drive adoption.

I think based on the above, a SIG for academic involvement makes more sense than a working group, as it's less about cross-project issues and more about being a bridge to the outside world (and yes, helping those outsiders become insiders).  Marta has been managing our academic outreach efforts to date, so I'd encourage you to connect with her on ways we can make a SIG effective.

Let me also burst your bubble a bit - SIGs are expected to provide a one-presentation-deck-page report each month on their activities and accomplishments, which is provided to the Governing Board for their monthly discussions.  Also, we (HL staff) are very deliberate about launching new SIGs - they can often take months to pull together the right stakeholder set, define the charter crisply enough, and make sure they are managed closely enough by us.  So it may only look easier & quicker.  :)  But given all the interest in improving our relationship with academia I think we'd be able to move on this with reasonable expediency. 

Brian

-- Brian BehlendorfExecutive Director, Hyperledgerbbehlendorf@...Twitter: @brianbehlendorf


Re: SIGs vs WGs (was Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.)

VIPIN BHARATHAN
 

Chris,
I think it is quarterly. Some of the SIGs are brand new so they dont have any updates yet like the CMSIG. There should be updates from Telecomm,  Supplychain, Healthcare and Trade Finance.
Best,
Vipin

From: tsc@... <tsc@...> on behalf of Christopher Ferris via Lists.Hyperledger.Org <chris.ferris=gmail.com@...>
Sent: Friday, August 16, 2019 10:26 AM
To: Me
Cc: tsc@...
Subject: Re: SIGs vs WGs (was Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.)
 
Brian wrote: "SIGs are expected to provide a one-presentation-deck-page report each month on their activities and accomplishments, which is provided to the Governing Board for their monthly discussions."

I see SIG quarterly reports from a handful of the SIGs (only 3 reported in 2Q?) but I don't see monthly reports anywhere. Is there a reason that they are not also posted on the wiki? Or, are these one and the same (eg not monthly but quarterly), and if so, where are the others?

Chris

On Fri, Aug 16, 2019 at 9:54 AM Christopher Ferris viaLists.Hyperledger.Org <chris.ferris=gmail.com@...> wrote:

Brian wrote: "Creation of any new working group should partially be gated by whether it's reasonable to expect most of the projects to be able to have people actively following and participating in that new WG."
+100

Chris

On Thu, Aug 15, 2019 at 2:29 PM Brian Behlendorf <bbehlendorf@...> wrote:
Changing the subject to address a point in Hart's earlier email:

On 8/15/19 8:17 AM, hmontgomery@... wrote:
I think a lot of people are, in fact, using SIGs for relatively technical purposes.  Having or starting a SIG is much better right now than a working group:  you get all of the support from the LF that you would for a WG (meeting times, mailing list, etc.), you aren’t mandated to submit time-consuming work products to the TSC (that, let’s be honest, very few people read), and the approval process is far simpler and doesn’t require TSC approval (which could take quite some time and be a huge headache).  If you were looking to start a group—even a very technical one--why on earth would you choose a WG over a SIG? 

I sincerely hope this is not the reason why one would choose to start a SIG rather than a WG.

Working Groups should be thought of as our connective tissue between projects - the cross-project place where discussions about identity, performance/scalability, architectural concerns, learning materials, and even diversity & civility issues can be discussed and iterated upon without that discussion being owned by one project or another.  In particular for anyone who holds architectural or product convergence as a priority, certain Working Groups like identity and architecture should be the place to articulate what that means, and then create specific technical plans that projects can follow.  They only can serve that role well to the degree they are primarily driven by active maintainers and contributors on the projects themselves, but given critical mass there can be other participants on those working groups.  Creation of any new working group should partially be gated by whether it's reasonable to expect most of the projects to be able to have people actively following and participating in that new WG.

Special Interest Groups are intended to be more of a bridge to the outside world - to people deploying our technologies for particular categories of use cases.  Those might be grouped by industrial segment, e.g. "trade finance".  Or they may be grouped by a broad set of functionality, e.g. "supply chain", that is more of a recurring theme across all industries than a specific industry.  But the point is that a SIG should be composed of both insiders and outsiders - of both technologists close to what one or more Hyperledger projects are doing, and of those who may simply be "users" of the technology, perhaps even one or two steps downstream, but who is willing to share their domain expertise and involvement in active projects at a business level to drive adoption.

I think based on the above, a SIG for academic involvement makes more sense than a working group, as it's less about cross-project issues and more about being a bridge to the outside world (and yes, helping those outsiders become insiders).  Marta has been managing our academic outreach efforts to date, so I'd encourage you to connect with her on ways we can make a SIG effective.

Let me also burst your bubble a bit - SIGs are expected to provide a one-presentation-deck-page report each month on their activities and accomplishments, which is provided to the Governing Board for their monthly discussions.  Also, we (HL staff) are very deliberate about launching new SIGs - they can often take months to pull together the right stakeholder set, define the charter crisply enough, and make sure they are managed closely enough by us.  So it may only look easier & quicker.  :)  But given all the interest in improving our relationship with academia I think we'd be able to move on this with reasonable expediency. 

Brian

-- Brian BehlendorfExecutive Director, Hyperledgerbbehlendorf@...Twitter: @brianbehlendorf


Re: [External] Re: SIGs vs WGs (was Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.)

Kuhrt, Tracy A.
 

Hi, Chris.

 

I believe those “quarterly reports” are from when the SIGs originally fell under the TSC purview.

 

Tracy

 

 

From: <tsc@...> on behalf of Christopher Ferris <chris.ferris@...>
Date: Friday, August 16, 2019 at 7:26 AM
To: Me <chris.ferris@...>
Cc: Brian Behlendorf <bbehlendorf@...>, Hyperledger List <tsc@...>
Subject: [External] Re: SIGs vs WGs (was Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.)

 

This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments.


 

Brian wrote: "SIGs are expected to provide a one-presentation-deck-page report each month on their activities and accomplishments, which is provided to the Governing Board for their monthly discussions."

 

I see SIG quarterly reports from a handful of the SIGs (only 3 reported in 2Q?) but I don't see monthly reports anywhere. Is there a reason that they are not also posted on the wiki? Or, are these one and the same (eg not monthly but quarterly), and if so, where are the others?

 

Chris

 

On Fri, Aug 16, 2019 at 9:54 AM Christopher Ferris via Lists.Hyperledger.Org <chris.ferris=gmail.com@...> wrote:

Brian wrote: "Creation of any new working group should partially be gated by whether it's reasonable to expect most of the projects to be able to have people actively following and participating in that new WG."

+100

 

Chris

 

On Thu, Aug 15, 2019 at 2:29 PM Brian Behlendorf <bbehlendorf@...> wrote:

Changing the subject to address a point in Hart's earlier email:

 

On 8/15/19 8:17 AM, hmontgomery@... wrote:

I think a lot of people are, in fact, using SIGs for relatively technical purposes.  Having or starting a SIG is much better right now than a working group:  you get all of the support from the LF that you would for a WG (meeting times, mailing list, etc.), you aren’t mandated to submit time-consuming work products to the TSC (that, let’s be honest, very few people read), and the approval process is far simpler and doesn’t require TSC approval (which could take quite some time and be a huge headache).  If you were looking to start a group—even a very technical one--why on earth would you choose a WG over a SIG? 

I sincerely hope this is not the reason why one would choose to start a SIG rather than a WG.

Working Groups should be thought of as our connective tissue between projects - the cross-project place where discussions about identity, performance/scalability, architectural concerns, learning materials, and even diversity & civility issues can be discussed and iterated upon without that discussion being owned by one project or another.  In particular for anyone who holds architectural or product convergence as a priority, certain Working Groups like identity and architecture should be the place to articulate what that means, and then create specific technical plans that projects can follow.  They only can serve that role well to the degree they are primarily driven by active maintainers and contributors on the projects themselves, but given critical mass there can be other participants on those working groups.  Creation of any new working group should partially be gated by whether it's reasonable to expect most of the projects to be able to have people actively following and participating in that new WG.

Special Interest Groups are intended to be more of a bridge to the outside world - to people deploying our technologies for particular categories of use cases.  Those might be grouped by industrial segment, e.g. "trade finance".  Or they may be grouped by a broad set of functionality, e.g. "supply chain", that is more of a recurring theme across all industries than a specific industry.  But the point is that a SIG should be composed of both insiders and outsiders - of both technologists close to what one or more Hyperledger projects are doing, and of those who may simply be "users" of the technology, perhaps even one or two steps downstream, but who is willing to share their domain expertise and involvement in active projects at a business level to drive adoption.

I think based on the above, a SIG for academic involvement makes more sense than a working group, as it's less about cross-project issues and more about being a bridge to the outside world (and yes, helping those outsiders become insiders).  Marta has been managing our academic outreach efforts to date, so I'd encourage you to connect with her on ways we can make a SIG effective.

Let me also burst your bubble a bit - SIGs are expected to provide a one-presentation-deck-page report each month on their activities and accomplishments, which is provided to the Governing Board for their monthly discussions.  Also, we (HL staff) are very deliberate about launching new SIGs - they can often take months to pull together the right stakeholder set, define the charter crisply enough, and make sure they are managed closely enough by us.  So it may only look easier & quicker.  :)  But given all the interest in improving our relationship with academia I think we'd be able to move on this with reasonable expediency. 

Brian

-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf




This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. Your privacy is important to us. Accenture uses your personal data only in compliance with data protection laws. For further information on how Accenture processes your personal data, please see our privacy statement at https://www.accenture.com/us-en/privacy-policy.
______________________________________________________________________________________

www.accenture.com


Re: SIGs vs WGs (was Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.)

Christopher Ferris <chris.ferris@...>
 

Brian wrote: "SIGs are expected to provide a one-presentation-deck-page report each month on their activities and accomplishments, which is provided to the Governing Board for their monthly discussions."

I see SIG quarterly reports from a handful of the SIGs (only 3 reported in 2Q?) but I don't see monthly reports anywhere. Is there a reason that they are not also posted on the wiki? Or, are these one and the same (eg not monthly but quarterly), and if so, where are the others?

Chris

On Fri, Aug 16, 2019 at 9:54 AM Christopher Ferris via Lists.Hyperledger.Org <chris.ferris=gmail.com@...> wrote:

Brian wrote: "Creation of any new working group should partially be gated by whether it's reasonable to expect most of the projects to be able to have people actively following and participating in that new WG."
+100

Chris

On Thu, Aug 15, 2019 at 2:29 PM Brian Behlendorf <bbehlendorf@...> wrote:
Changing the subject to address a point in Hart's earlier email:

On 8/15/19 8:17 AM, hmontgomery@... wrote:
I think a lot of people are, in fact, using SIGs for relatively technical purposes.  Having or starting a SIG is much better right now than a working group:  you get all of the support from the LF that you would for a WG (meeting times, mailing list, etc.), you aren’t mandated to submit time-consuming work products to the TSC (that, let’s be honest, very few people read), and the approval process is far simpler and doesn’t require TSC approval (which could take quite some time and be a huge headache).  If you were looking to start a group—even a very technical one--why on earth would you choose a WG over a SIG? 

I sincerely hope this is not the reason why one would choose to start a SIG rather than a WG.

Working Groups should be thought of as our connective tissue between projects - the cross-project place where discussions about identity, performance/scalability, architectural concerns, learning materials, and even diversity & civility issues can be discussed and iterated upon without that discussion being owned by one project or another.  In particular for anyone who holds architectural or product convergence as a priority, certain Working Groups like identity and architecture should be the place to articulate what that means, and then create specific technical plans that projects can follow.  They only can serve that role well to the degree they are primarily driven by active maintainers and contributors on the projects themselves, but given critical mass there can be other participants on those working groups.  Creation of any new working group should partially be gated by whether it's reasonable to expect most of the projects to be able to have people actively following and participating in that new WG.

Special Interest Groups are intended to be more of a bridge to the outside world - to people deploying our technologies for particular categories of use cases.  Those might be grouped by industrial segment, e.g. "trade finance".  Or they may be grouped by a broad set of functionality, e.g. "supply chain", that is more of a recurring theme across all industries than a specific industry.  But the point is that a SIG should be composed of both insiders and outsiders - of both technologists close to what one or more Hyperledger projects are doing, and of those who may simply be "users" of the technology, perhaps even one or two steps downstream, but who is willing to share their domain expertise and involvement in active projects at a business level to drive adoption.

I think based on the above, a SIG for academic involvement makes more sense than a working group, as it's less about cross-project issues and more about being a bridge to the outside world (and yes, helping those outsiders become insiders).  Marta has been managing our academic outreach efforts to date, so I'd encourage you to connect with her on ways we can make a SIG effective.

Let me also burst your bubble a bit - SIGs are expected to provide a one-presentation-deck-page report each month on their activities and accomplishments, which is provided to the Governing Board for their monthly discussions.  Also, we (HL staff) are very deliberate about launching new SIGs - they can often take months to pull together the right stakeholder set, define the charter crisply enough, and make sure they are managed closely enough by us.  So it may only look easier & quicker.  :)  But given all the interest in improving our relationship with academia I think we'd be able to move on this with reasonable expediency. 

Brian

-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


Re: SIGs vs WGs (was Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.)

Christopher Ferris <chris.ferris@...>
 

Brian wrote: "Creation of any new working group should partially be gated by whether it's reasonable to expect most of the projects to be able to have people actively following and participating in that new WG."
+100

Chris


On Thu, Aug 15, 2019 at 2:29 PM Brian Behlendorf <bbehlendorf@...> wrote:
Changing the subject to address a point in Hart's earlier email:

On 8/15/19 8:17 AM, hmontgomery@... wrote:
I think a lot of people are, in fact, using SIGs for relatively technical purposes.  Having or starting a SIG is much better right now than a working group:  you get all of the support from the LF that you would for a WG (meeting times, mailing list, etc.), you aren’t mandated to submit time-consuming work products to the TSC (that, let’s be honest, very few people read), and the approval process is far simpler and doesn’t require TSC approval (which could take quite some time and be a huge headache).  If you were looking to start a group—even a very technical one--why on earth would you choose a WG over a SIG? 

I sincerely hope this is not the reason why one would choose to start a SIG rather than a WG.

Working Groups should be thought of as our connective tissue between projects - the cross-project place where discussions about identity, performance/scalability, architectural concerns, learning materials, and even diversity & civility issues can be discussed and iterated upon without that discussion being owned by one project or another.  In particular for anyone who holds architectural or product convergence as a priority, certain Working Groups like identity and architecture should be the place to articulate what that means, and then create specific technical plans that projects can follow.  They only can serve that role well to the degree they are primarily driven by active maintainers and contributors on the projects themselves, but given critical mass there can be other participants on those working groups.  Creation of any new working group should partially be gated by whether it's reasonable to expect most of the projects to be able to have people actively following and participating in that new WG.

Special Interest Groups are intended to be more of a bridge to the outside world - to people deploying our technologies for particular categories of use cases.  Those might be grouped by industrial segment, e.g. "trade finance".  Or they may be grouped by a broad set of functionality, e.g. "supply chain", that is more of a recurring theme across all industries than a specific industry.  But the point is that a SIG should be composed of both insiders and outsiders - of both technologists close to what one or more Hyperledger projects are doing, and of those who may simply be "users" of the technology, perhaps even one or two steps downstream, but who is willing to share their domain expertise and involvement in active projects at a business level to drive adoption.

I think based on the above, a SIG for academic involvement makes more sense than a working group, as it's less about cross-project issues and more about being a bridge to the outside world (and yes, helping those outsiders become insiders).  Marta has been managing our academic outreach efforts to date, so I'd encourage you to connect with her on ways we can make a SIG effective.

Let me also burst your bubble a bit - SIGs are expected to provide a one-presentation-deck-page report each month on their activities and accomplishments, which is provided to the Governing Board for their monthly discussions.  Also, we (HL staff) are very deliberate about launching new SIGs - they can often take months to pull together the right stakeholder set, define the charter crisply enough, and make sure they are managed closely enough by us.  So it may only look easier & quicker.  :)  But given all the interest in improving our relationship with academia I think we'd be able to move on this with reasonable expediency. 

Brian

-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


Re: SIGs vs WGs (was Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.)

mark wagner <mwagner@...>
 


Brian

Thanks for the clear and concise descriptions. I know that sometimes the lines get blurred a bit, but its good to see things spelled out clearly.

Would it possible to share the SIG Update slide deck that was presented in Tokyo?
I didn't see it online but it shows the work going on and may help those folks on this list that are not involved in SIGS  get a better understanding.


Thanks

-mark


On Thu, Aug 15, 2019 at 2:29 PM Brian Behlendorf <bbehlendorf@...> wrote:
Changing the subject to address a point in Hart's earlier email:

On 8/15/19 8:17 AM, hmontgomery@... wrote:
I think a lot of people are, in fact, using SIGs for relatively technical purposes.  Having or starting a SIG is much better right now than a working group:  you get all of the support from the LF that you would for a WG (meeting times, mailing list, etc.), you aren’t mandated to submit time-consuming work products to the TSC (that, let’s be honest, very few people read), and the approval process is far simpler and doesn’t require TSC approval (which could take quite some time and be a huge headache).  If you were looking to start a group—even a very technical one--why on earth would you choose a WG over a SIG? 

I sincerely hope this is not the reason why one would choose to start a SIG rather than a WG.

Working Groups should be thought of as our connective tissue between projects - the cross-project place where discussions about identity, performance/scalability, architectural concerns, learning materials, and even diversity & civility issues can be discussed and iterated upon without that discussion being owned by one project or another.  In particular for anyone who holds architectural or product convergence as a priority, certain Working Groups like identity and architecture should be the place to articulate what that means, and then create specific technical plans that projects can follow.  They only can serve that role well to the degree they are primarily driven by active maintainers and contributors on the projects themselves, but given critical mass there can be other participants on those working groups.  Creation of any new working group should partially be gated by whether it's reasonable to expect most of the projects to be able to have people actively following and participating in that new WG.

Special Interest Groups are intended to be more of a bridge to the outside world - to people deploying our technologies for particular categories of use cases.  Those might be grouped by industrial segment, e.g. "trade finance".  Or they may be grouped by a broad set of functionality, e.g. "supply chain", that is more of a recurring theme across all industries than a specific industry.  But the point is that a SIG should be composed of both insiders and outsiders - of both technologists close to what one or more Hyperledger projects are doing, and of those who may simply be "users" of the technology, perhaps even one or two steps downstream, but who is willing to share their domain expertise and involvement in active projects at a business level to drive adoption.

I think based on the above, a SIG for academic involvement makes more sense than a working group, as it's less about cross-project issues and more about being a bridge to the outside world (and yes, helping those outsiders become insiders).  Marta has been managing our academic outreach efforts to date, so I'd encourage you to connect with her on ways we can make a SIG effective.

Let me also burst your bubble a bit - SIGs are expected to provide a one-presentation-deck-page report each month on their activities and accomplishments, which is provided to the Governing Board for their monthly discussions.  Also, we (HL staff) are very deliberate about launching new SIGs - they can often take months to pull together the right stakeholder set, define the charter crisply enough, and make sure they are managed closely enough by us.  So it may only look easier & quicker.  :)  But given all the interest in improving our relationship with academia I think we'd be able to move on this with reasonable expediency. 

Brian

-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf



--
Mark Wagner
Senior Principal Software Engineer
Performance and Scalability
Red Hat, Inc


Re: TSC elections: electorate should include SIGs and some other suggestions.

Baohua Yang
 

I also want to highlight this link: https://wiki.hyperledger.org/display/HYP/TSC+Election+2019.

And believe most working group/team members are project contributor at the same time.

Thanks!

On Thu, Aug 15, 2019 at 10:44 AM Brian Behlendorf <bbehlendorf@...> wrote:
SIGs aren't "represented on the TSC", but nor are Working Groups or any particular projects.  This isn't a House of Representatives nor a Senate.  TSC members are elected by voters based on whatever criteria a voter may choose, but are not there to represent one project or another - they are there as individuals, and to do right by the full Hyperledger community. 

Voter eligibility is based on connection to technical contributions anywhere across Hyperledger, as the charter says, "Anyone in the technical community that contributes code, documentation or other technical artifacts to the HLP codebase".  SIG participants who also contribute code or participate actively on Working Groups are already included.  If you have been technically active on a SIG but not in the above ways, you can petition to be added.

We use the following methods to collect the email addresses for valid voters:

1) those who have contributed in the last year to a github or gerrit repository (including hyperledger-labs), and we have a good email address to correlate to your gerrit or github account.  We don't always get a clean email address from GH so we are manually maintaining that list and doing our best to connect to other addresses we know of for you.

2) those who were named by Working Group chairs (deadline was last week) who have substantially participated in these working groups.

If you fall into these two buckets, then this past TUESDAY you should have received an invitation to join a groups.io (lists.hyperledger.org) mailing list set up for announcements and links related to the Election.  On Tuesday, ~500 emails went out, and right now ~150 people have confirmed the invitation and are on the list.  We received quite a few bounces, which suggests we have bad email addresses - so please search your inboxes, and spam folders, and either

1) Confirm your invitation to that list, OR

2) Ask us to resend the invitation if you know you should have qualified as above, OR

3) You have made other technical contributions elsewhere, such as on the wiki, or jira artifacts, etc.  You can fill out this form to petition to be added to the pool of voters.  Hyperledger staff will determine whether your response to the form points to valid technical contributions and can thus be added to the list.

For future elections we can consider other algorithmic methods for collecting emails and determining eligibility, beyond github/gerrit commits.

See: https://wiki.hyperledger.org/display/HYP/TSC+Election+2019 for more info, including how to nominate yourself for the election.

Members of that contributor-announcements list will see updates about the process soon, so please make sure you confirm membership to that list.

Hope this helps,

Brian


On 8/15/19 8:32 AM, Arnaud Le Hors wrote:
Thanks for this interesting info but to be clear, I for one never said that SIGs aren't doing any technical work. My only point is that SIGs don't report to the TSC.
And until this changes, I think it'd be odd to have them on the TSC.

I see this as a simple governance issue. The TSC should be formed of people elected among those that are governed by the TSC.

IMO, the argument that SIGs are doing technical work is an argument to bring up in support of moving SIGs under the governance of the TSC (which would then naturally make them eligible for the TSC), not merely to be part of the TSC election.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "hmontgomery@..." <hmontgomery@...>
To:        Arnaud Le Hors <lehors@...>, Vipin Bharathan <vipinsun@...>
Cc:        "tsc@..." <tsc@...>
Date:        08/15/2019 05:17 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.
Sent by:        tsc@...



Hi Arnaud,

 

This is a little bit orthogonal to what you and Vipin are discussing, but it’s still relevant, so I’ll mention it here.

 

I think a lot of people are, in fact, using SIGs for relatively technical purposes.  Having or starting a SIG is much better right now than a working group:  you get all of the support from the LF that you would for a WG (meeting times, mailing list, etc.), you aren’t mandated to submit time-consuming work products to the TSC (that, let’s be honest, very few people read), and the approval process is far simpler and doesn’t require TSC approval (which could take quite some time and be a huge headache).  If you were looking to start a group—even a very technical one--why on earth would you choose a WG over a SIG?  

 

As an example, I’ve been thinking about putting together a group related to academic involvement in Hyperledger.  The goal would be to help get academics to add their work to Hyperledger (in code) and for maintainers/developers to give research problems to academics.  I’ve written up a (very rough) draft of a SIG proposal for this.  Despite the technicality involved, I chose to write a SIG draft proposal instead of a working group proposal for the very reasons I mentioned above.  While I can’t say for certain, I suspect that some of the SIGs that are popular today made the same calculation.

 

I mostly think this is relevant to the WG reform process (thanks Mic for heading this up), and I’m not a common participant in current SIGs.  But I think it is a little much to say that SIGs aren’t doing any technical work.  I don’t’ know how to quantify “technical contributions” from SIG members, though—could a frequent SIG participant comment more on this?

 

I hope this makes sense.  I guess I’m less trying to make a point about the TSC elections than about working group reform.

 

Thanks,

Hart

 

From:tsc@... [mailto:tsc@...] On Behalf Of Arnaud Le Hors
Sent:
Thursday, August 15, 2019 7:04 AM
To:
Vipin Bharathan <vipinsun@...>
Cc:
tsc@...
Subject:
Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.

 

Hi Vipin,

The facts are that while WGs and projects are under the governance of the TSC, and report to them, the SIGs don't.
My point is that if the SIGs are actually doing technical work that should be handled by the TSC they should then be moved (back) under its structure. It would then be natural to have them be part of the TSC but I don't think we should have something in between.


I hope this clarifies what I mean. This is not about being exclusive as much as being consistent.


Regards.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





From:        
"VIPIN BHARATHAN" <vip@...>
To:        
"lehors@..." <lehors@...>, Vipin Bharathan <vipinsun@...>
Cc:        
"tsc@..." <tsc@...>
Date:        
08/14/2019 10:50 PM
Subject:        
[EXTERNAL] Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.
Sent by:        
tsc@...





Arnaud,
Feelings are not what I am after, but facts. Elsewhere  in my email, it was pointed out that SIGs have large, diverse memberships and are very technical in nature. These folks are not protocol(dlt) engineers but bring a technical user perspective. As we are maturing, we need that insight in our tsc, if we are to spur adoption and address usability and a path to production. For example the healthcare SIG has 1000 members in its mailing list. We should not exclude this contributor constituency from our tsc eligibility pools and our rolls.
This will also enhance our DCI metrics. May I remind you that the last I stands for inclusion.
Vipin



From:
tsc@...<tsc@...> on behalf of Arnaud Le Hors via Lists.Hyperledger.Org <lehors=us.ibm.com@...>
Sent:
Wednesday, August 14, 2019 4:38 PM
To:
Vipin Bharathan
Cc:
tsc@...
Subject:
Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.

Vipin,
I'm sorry if my email made you feel I had ignored that part of your email. I hadn't but, I don't share your point of view and my point remains.
Regards.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





From:        
"Vipin Bharathan" <vipinsun@...>
To:        
Arnaud Le Hors <lehors@...>
Cc:        
Hyperledger List <tsc@...>
Date:        
08/14/2019 06:25 PM
Subject:        
[EXTERNAL] Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.
Sent by:        
tsc@...





Arnaud,
I had already addressed this question in my proposal: I quote

  • There has been a case made that SIGs are not under the TSC, and hence are not eligible. WGs and even the projects are only nominally under the control of the TSC, procedures are being worked out to make this involvement even lighter touch as projects, WGs and general technical output proliferates.  
Thanks,
Vipin


On Wed, Aug 14, 2019 at 10:54 AM Arnaud Le Hors <
lehors@...> wrote:
The problem is that SIGs have been placed outside the governance of the TSC so it seems odd to have them sit on a board they have no direct relationship with.
Am I the only one to feel that way?
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





From:        
"Vipin Bharathan" <vipinsun@...>
To:        
Hyperledger List <tsc@...>
Date:        
08/10/2019 08:54 PM
Subject:        
[EXTERNAL] [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.
Sent by:        
tsc@...




Hi all,

As a long time observer, contributor and participant in Hyperledger, I make the following comments about the TSC election process.  

  • SIGs are part of the hyperledger community.
  • SIGs did not exist when the HL charter was setup
  • SIGs focus on specific lines of business, they do have strong technical participation
    • For example the paper written for the Telecomm SIG is technical, the supply chain presentation that I attended presented a port of Grid to Fabric based Oracle Blockchain. Healthcare SIG sponsored labs.
  • SIG calls are very well attended. Participants are often more diverse than the project code contributors and the working groups.
  • There has been a case made that SIGs are not under the TSC, and hence are not eligible. WGs and even the projects are only nominally under the control of the TSC, procedures are being worked out to make this involvement even lighter touch as projects, WGs and general technical output proliferates.  
  • Contributors to SIGs are contributing to the community. They should be part of the electorate for voting as well as standing for the TSC
  • We had to make a similar case for Working Groups
Chris Ferris' (as well many others) suggestion to increase the number of TSC members is welcome.

To increase the transparency of the election process, please include the percentage of electors who voted, the votes garnered by each of the candidates as in a general election. There have been suggestions that doing this may compromise the standing of candidates who got in with the least number of votes. Once elected (or nominated) to the TSC, each vote is worth the same.

In light of many of the suggestions already made, it might be wise to delay the election slightly (as Hart and some of the others have already pointed out)

We have the issue of Enterprises of widely different sizes collaborating on Hyperledger. Alternate forms of choice could be considered for the next election including quadratic voting and other methods, otherwise we risk losing diversity and the voice of smaller teams and groups.

Best,
Vipin













-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf



--
Best wishes!

Baohua Yang


Re: TSC elections: electorate should include SIGs and some other suggestions.

Vipin Bharathan
 

Hi,

Thanks to Brian for bringing the charter into the discussion. I had forgotten about this fragment which was used to add WG participants into the electorate, all those years ago.
Brian's quote from the charter is clear  "Anyone in the technical community that contributes code, documentation or other technical artifacts to the HLP codebase" Now we have to see what "codebase" means, is it only github or does it include the wiki (as documentation and other technical artifacts can be contributed there as well). In fact, nothing to do with whether they report into the TSC.
   
Github was taken as the defacto because harvesting emails from there is easier than from the other places and we are familiar with code contributions into github. 
But now that we have also moved to confluence, is harvesting a technical contributor list easier? 
How do we distinguish between technical contributions and just routine stuff like announcements and other administrivia? The more automated this is the better. Trying to get emails for regular contributors for WGs was a difficult exercise given that we had to do it in about two days.

Best,
Vipin 


On Thu, Aug 15, 2019 at 1:44 PM Brian Behlendorf <bbehlendorf@...> wrote:
SIGs aren't "represented on the TSC", but nor are Working Groups or any particular projects.  This isn't a House of Representatives nor a Senate.  TSC members are elected by voters based on whatever criteria a voter may choose, but are not there to represent one project or another - they are there as individuals, and to do right by the full Hyperledger community. 

Voter eligibility is based on connection to technical contributions anywhere across Hyperledger, as the charter says, "Anyone in the technical community that contributes code, documentation or other technical artifacts to the HLP codebase".  SIG participants who also contribute code or participate actively on Working Groups are already included.  If you have been technically active on a SIG but not in the above ways, you can petition to be added.

We use the following methods to collect the email addresses for valid voters:

1) those who have contributed in the last year to a github or gerrit repository (including hyperledger-labs), and we have a good email address to correlate to your gerrit or github account.  We don't always get a clean email address from GH so we are manually maintaining that list and doing our best to connect to other addresses we know of for you.

2) those who were named by Working Group chairs (deadline was last week) who have substantially participated in these working groups.

If you fall into these two buckets, then this past TUESDAY you should have received an invitation to join a groups.io (lists.hyperledger.org) mailing list set up for announcements and links related to the Election.  On Tuesday, ~500 emails went out, and right now ~150 people have confirmed the invitation and are on the list.  We received quite a few bounces, which suggests we have bad email addresses - so please search your inboxes, and spam folders, and either

1) Confirm your invitation to that list, OR

2) Ask us to resend the invitation if you know you should have qualified as above, OR

3) You have made other technical contributions elsewhere, such as on the wiki, or jira artifacts, etc.  You can fill out this form to petition to be added to the pool of voters.  Hyperledger staff will determine whether your response to the form points to valid technical contributions and can thus be added to the list.

For future elections we can consider other algorithmic methods for collecting emails and determining eligibility, beyond github/gerrit commits.

See: https://wiki.hyperledger.org/display/HYP/TSC+Election+2019 for more info, including how to nominate yourself for the election.

Members of that contributor-announcements list will see updates about the process soon, so please make sure you confirm membership to that list.

Hope this helps,

Brian


On 8/15/19 8:32 AM, Arnaud Le Hors wrote:
Thanks for this interesting info but to be clear, I for one never said that SIGs aren't doing any technical work. My only point is that SIGs don't report to the TSC.
And until this changes, I think it'd be odd to have them on the TSC.

I see this as a simple governance issue. The TSC should be formed of people elected among those that are governed by the TSC.

IMO, the argument that SIGs are doing technical work is an argument to bring up in support of moving SIGs under the governance of the TSC (which would then naturally make them eligible for the TSC), not merely to be part of the TSC election.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "hmontgomery@..." <hmontgomery@...>
To:        Arnaud Le Hors <lehors@...>, Vipin Bharathan <vipinsun@...>
Cc:        "tsc@..." <tsc@...>
Date:        08/15/2019 05:17 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.
Sent by:        tsc@...



Hi Arnaud,

 

This is a little bit orthogonal to what you and Vipin are discussing, but it’s still relevant, so I’ll mention it here.

 

I think a lot of people are, in fact, using SIGs for relatively technical purposes.  Having or starting a SIG is much better right now than a working group:  you get all of the support from the LF that you would for a WG (meeting times, mailing list, etc.), you aren’t mandated to submit time-consuming work products to the TSC (that, let’s be honest, very few people read), and the approval process is far simpler and doesn’t require TSC approval (which could take quite some time and be a huge headache).  If you were looking to start a group—even a very technical one--why on earth would you choose a WG over a SIG?  

 

As an example, I’ve been thinking about putting together a group related to academic involvement in Hyperledger.  The goal would be to help get academics to add their work to Hyperledger (in code) and for maintainers/developers to give research problems to academics.  I’ve written up a (very rough) draft of a SIG proposal for this.  Despite the technicality involved, I chose to write a SIG draft proposal instead of a working group proposal for the very reasons I mentioned above.  While I can’t say for certain, I suspect that some of the SIGs that are popular today made the same calculation.

 

I mostly think this is relevant to the WG reform process (thanks Mic for heading this up), and I’m not a common participant in current SIGs.  But I think it is a little much to say that SIGs aren’t doing any technical work.  I don’t’ know how to quantify “technical contributions” from SIG members, though—could a frequent SIG participant comment more on this?

 

I hope this makes sense.  I guess I’m less trying to make a point about the TSC elections than about working group reform.

 

Thanks,

Hart

 

From:tsc@... [mailto:tsc@...] On Behalf Of Arnaud Le Hors
Sent:
Thursday, August 15, 2019 7:04 AM
To:
Vipin Bharathan <vipinsun@...>
Cc:
tsc@...
Subject:
Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.

 

Hi Vipin,

The facts are that while WGs and projects are under the governance of the TSC, and report to them, the SIGs don't.
My point is that if the SIGs are actually doing technical work that should be handled by the TSC they should then be moved (back) under its structure. It would then be natural to have them be part of the TSC but I don't think we should have something in between.


I hope this clarifies what I mean. This is not about being exclusive as much as being consistent.


Regards.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





From:        
"VIPIN BHARATHAN" <vip@...>
To:        
"lehors@..." <lehors@...>, Vipin Bharathan <vipinsun@...>
Cc:        
"tsc@..." <tsc@...>
Date:        
08/14/2019 10:50 PM
Subject:        
[EXTERNAL] Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.
Sent by:        
tsc@...





Arnaud,
Feelings are not what I am after, but facts. Elsewhere  in my email, it was pointed out that SIGs have large, diverse memberships and are very technical in nature. These folks are not protocol(dlt) engineers but bring a technical user perspective. As we are maturing, we need that insight in our tsc, if we are to spur adoption and address usability and a path to production. For example the healthcare SIG has 1000 members in its mailing list. We should not exclude this contributor constituency from our tsc eligibility pools and our rolls.
This will also enhance our DCI metrics. May I remind you that the last I stands for inclusion.
Vipin



From:
tsc@...<tsc@...> on behalf of Arnaud Le Hors via Lists.Hyperledger.Org <lehors=us.ibm.com@...>
Sent:
Wednesday, August 14, 2019 4:38 PM
To:
Vipin Bharathan
Cc:
tsc@...
Subject:
Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.

Vipin,
I'm sorry if my email made you feel I had ignored that part of your email. I hadn't but, I don't share your point of view and my point remains.
Regards.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





From:        
"Vipin Bharathan" <vipinsun@...>
To:        
Arnaud Le Hors <lehors@...>
Cc:        
Hyperledger List <tsc@...>
Date:        
08/14/2019 06:25 PM
Subject:        
[EXTERNAL] Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.
Sent by:        
tsc@...





Arnaud,
I had already addressed this question in my proposal: I quote

  • There has been a case made that SIGs are not under the TSC, and hence are not eligible. WGs and even the projects are only nominally under the control of the TSC, procedures are being worked out to make this involvement even lighter touch as projects, WGs and general technical output proliferates.  
Thanks,
Vipin


On Wed, Aug 14, 2019 at 10:54 AM Arnaud Le Hors <
lehors@...> wrote:
The problem is that SIGs have been placed outside the governance of the TSC so it seems odd to have them sit on a board they have no direct relationship with.
Am I the only one to feel that way?
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





From:        
"Vipin Bharathan" <vipinsun@...>
To:        
Hyperledger List <tsc@...>
Date:        
08/10/2019 08:54 PM
Subject:        
[EXTERNAL] [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.
Sent by:        
tsc@...




Hi all,

As a long time observer, contributor and participant in Hyperledger, I make the following comments about the TSC election process.  

  • SIGs are part of the hyperledger community.
  • SIGs did not exist when the HL charter was setup
  • SIGs focus on specific lines of business, they do have strong technical participation
    • For example the paper written for the Telecomm SIG is technical, the supply chain presentation that I attended presented a port of Grid to Fabric based Oracle Blockchain. Healthcare SIG sponsored labs.
  • SIG calls are very well attended. Participants are often more diverse than the project code contributors and the working groups.
  • There has been a case made that SIGs are not under the TSC, and hence are not eligible. WGs and even the projects are only nominally under the control of the TSC, procedures are being worked out to make this involvement even lighter touch as projects, WGs and general technical output proliferates.  
  • Contributors to SIGs are contributing to the community. They should be part of the electorate for voting as well as standing for the TSC
  • We had to make a similar case for Working Groups
Chris Ferris' (as well many others) suggestion to increase the number of TSC members is welcome.

To increase the transparency of the election process, please include the percentage of electors who voted, the votes garnered by each of the candidates as in a general election. There have been suggestions that doing this may compromise the standing of candidates who got in with the least number of votes. Once elected (or nominated) to the TSC, each vote is worth the same.

In light of many of the suggestions already made, it might be wise to delay the election slightly (as Hart and some of the others have already pointed out)

We have the issue of Enterprises of widely different sizes collaborating on Hyperledger. Alternate forms of choice could be considered for the next election including quadratic voting and other methods, otherwise we risk losing diversity and the voice of smaller teams and groups.

Best,
Vipin













-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


Re: SIGs vs WGs (was Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.)

Middleton, Dan <dan.middleton@...>
 

Just to reiterate as SIGs are under the gov board right now, there is an open action within the board to define more prescriptive practices. I hope that the outcome will be that the sigs produce domain guidance to the projects in the form of use cases and requirements.

 

Regards,

Dan

 

From: <tsc@...> on behalf of Brian Behlendorf <bbehlendorf@...>
Date: Thursday, August 15, 2019 at 1:49 PM
To: "tsc@..." <tsc@...>
Subject: Re: SIGs vs WGs (was Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.)

 

On 8/15/19 11:40 AM, hmontgomery@... wrote:

Hi Brian,

 

Thanks for the response.  I’m preparing a post on WGs that I’ll make later today on the wiki that should hopefully address the WG concerns here.  I like your description of the differences between SIGs and WGs, and I hope that the WG task force can really pin this down.

 

I have already connected with Marta (and some others) on the academic outreach stuff.  We are working to move this forward, although I have dropped the ball recently due to my schedule.

 

I have a question.  You say, “SIGs are expected to provide a one-presentation-deck-page report each month on their activities and accomplishments, which is provided to the Governing Board for their monthly discussions.”  Where is this written?  I couldn’t find this in any of the SIG documentation in the wiki, and I’m worried that I’m missing more information on SIGs.

It was something we've worked out with SIG chairs when transitioning from TSC oversight to GB/HL staff oversight; and yes, not spelled out.  Heck, I even see we have a "SIG Process" link in the wiki nav bar that leads to a page that hasn't been created yet.  I'll ask folks to work on that.

Brian

 

 

Thanks a lot for your time, and have a great day.

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Brian Behlendorf
Sent: Thursday, August 15, 2019 11:29 AM
To: tsc@...
Subject: SIGs vs WGs (was Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.)

 

Changing the subject to address a point in Hart's earlier email:

 

On 8/15/19 8:17 AM, hmontgomery@... wrote:

I think a lot of people are, in fact, using SIGs for relatively technical purposes.  Having or starting a SIG is much better right now than a working group:  you get all of the support from the LF that you would for a WG (meeting times, mailing list, etc.), you aren’t mandated to submit time-consuming work products to the TSC (that, let’s be honest, very few people read), and the approval process is far simpler and doesn’t require TSC approval (which could take quite some time and be a huge headache).  If you were looking to start a group—even a very technical one--why on earth would you choose a WG over a SIG? 

I sincerely hope this is not the reason why one would choose to start a SIG rather than a WG.

Working Groups should be thought of as our connective tissue between projects - the cross-project place where discussions about identity, performance/scalability, architectural concerns, learning materials, and even diversity & civility issues can be discussed and iterated upon without that discussion being owned by one project or another.  In particular for anyone who holds architectural or product convergence as a priority, certain Working Groups like identity and architecture should be the place to articulate what that means, and then create specific technical plans that projects can follow.  They only can serve that role well to the degree they are primarily driven by active maintainers and contributors on the projects themselves, but given critical mass there can be other participants on those working groups.  Creation of any new working group should partially be gated by whether it's reasonable to expect most of the projects to be able to have people actively following and participating in that new WG.

Special Interest Groups are intended to be more of a bridge to the outside world - to people deploying our technologies for particular categories of use cases.  Those might be grouped by industrial segment, e.g. "trade finance".  Or they may be grouped by a broad set of functionality, e.g. "supply chain", that is more of a recurring theme across all industries than a specific industry.  But the point is that a SIG should be composed of both insiders and outsiders - of both technologists close to what one or more Hyperledger projects are doing, and of those who may simply be "users" of the technology, perhaps even one or two steps downstream, but who is willing to share their domain expertise and involvement in active projects at a business level to drive adoption.

I think based on the above, a SIG for academic involvement makes more sense than a working group, as it's less about cross-project issues and more about being a bridge to the outside world (and yes, helping those outsiders become insiders).  Marta has been managing our academic outreach efforts to date, so I'd encourage you to connect with her on ways we can make a SIG effective.

Let me also burst your bubble a bit - SIGs are expected to provide a one-presentation-deck-page report each month on their activities and accomplishments, which is provided to the Governing Board for their monthly discussions.  Also, we (HL staff) are very deliberate about launching new SIGs - they can often take months to pull together the right stakeholder set, define the charter crisply enough, and make sure they are managed closely enough by us.  So it may only look easier & quicker.  :)  But given all the interest in improving our relationship with academia I think we'd be able to move on this with reasonable expediency. 

Brian

-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf

 

-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


Re: SIGs vs WGs (was Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.)

Brian Behlendorf
 

On 8/15/19 11:40 AM, hmontgomery@... wrote:

Hi Brian,

 

Thanks for the response.  I’m preparing a post on WGs that I’ll make later today on the wiki that should hopefully address the WG concerns here.  I like your description of the differences between SIGs and WGs, and I hope that the WG task force can really pin this down.

 

I have already connected with Marta (and some others) on the academic outreach stuff.  We are working to move this forward, although I have dropped the ball recently due to my schedule.

 

I have a question.  You say, “SIGs are expected to provide a one-presentation-deck-page report each month on their activities and accomplishments, which is provided to the Governing Board for their monthly discussions.”  Where is this written?  I couldn’t find this in any of the SIG documentation in the wiki, and I’m worried that I’m missing more information on SIGs.

It was something we've worked out with SIG chairs when transitioning from TSC oversight to GB/HL staff oversight; and yes, not spelled out.  Heck, I even see we have a "SIG Process" link in the wiki nav bar that leads to a page that hasn't been created yet.  I'll ask folks to work on that.

Brian


 

Thanks a lot for your time, and have a great day.

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Brian Behlendorf
Sent: Thursday, August 15, 2019 11:29 AM
To: tsc@...
Subject: SIGs vs WGs (was Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.)

 

Changing the subject to address a point in Hart's earlier email:

 

On 8/15/19 8:17 AM, hmontgomery@... wrote:

I think a lot of people are, in fact, using SIGs for relatively technical purposes.  Having or starting a SIG is much better right now than a working group:  you get all of the support from the LF that you would for a WG (meeting times, mailing list, etc.), you aren’t mandated to submit time-consuming work products to the TSC (that, let’s be honest, very few people read), and the approval process is far simpler and doesn’t require TSC approval (which could take quite some time and be a huge headache).  If you were looking to start a group—even a very technical one--why on earth would you choose a WG over a SIG? 

I sincerely hope this is not the reason why one would choose to start a SIG rather than a WG.

Working Groups should be thought of as our connective tissue between projects - the cross-project place where discussions about identity, performance/scalability, architectural concerns, learning materials, and even diversity & civility issues can be discussed and iterated upon without that discussion being owned by one project or another.  In particular for anyone who holds architectural or product convergence as a priority, certain Working Groups like identity and architecture should be the place to articulate what that means, and then create specific technical plans that projects can follow.  They only can serve that role well to the degree they are primarily driven by active maintainers and contributors on the projects themselves, but given critical mass there can be other participants on those working groups.  Creation of any new working group should partially be gated by whether it's reasonable to expect most of the projects to be able to have people actively following and participating in that new WG.

Special Interest Groups are intended to be more of a bridge to the outside world - to people deploying our technologies for particular categories of use cases.  Those might be grouped by industrial segment, e.g. "trade finance".  Or they may be grouped by a broad set of functionality, e.g. "supply chain", that is more of a recurring theme across all industries than a specific industry.  But the point is that a SIG should be composed of both insiders and outsiders - of both technologists close to what one or more Hyperledger projects are doing, and of those who may simply be "users" of the technology, perhaps even one or two steps downstream, but who is willing to share their domain expertise and involvement in active projects at a business level to drive adoption.

I think based on the above, a SIG for academic involvement makes more sense than a working group, as it's less about cross-project issues and more about being a bridge to the outside world (and yes, helping those outsiders become insiders).  Marta has been managing our academic outreach efforts to date, so I'd encourage you to connect with her on ways we can make a SIG effective.

Let me also burst your bubble a bit - SIGs are expected to provide a one-presentation-deck-page report each month on their activities and accomplishments, which is provided to the Governing Board for their monthly discussions.  Also, we (HL staff) are very deliberate about launching new SIGs - they can often take months to pull together the right stakeholder set, define the charter crisply enough, and make sure they are managed closely enough by us.  So it may only look easier & quicker.  :)  But given all the interest in improving our relationship with academia I think we'd be able to move on this with reasonable expediency. 

Brian

-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


Re: SIGs vs WGs (was Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.)

hmontgomery@us.fujitsu.com <hmontgomery@...>
 

Hi Brian,

 

Thanks for the response.  I’m preparing a post on WGs that I’ll make later today on the wiki that should hopefully address the WG concerns here.  I like your description of the differences between SIGs and WGs, and I hope that the WG task force can really pin this down.

 

I have already connected with Marta (and some others) on the academic outreach stuff.  We are working to move this forward, although I have dropped the ball recently due to my schedule.

 

I have a question.  You say, “SIGs are expected to provide a one-presentation-deck-page report each month on their activities and accomplishments, which is provided to the Governing Board for their monthly discussions.”  Where is this written?  I couldn’t find this in any of the SIG documentation in the wiki, and I’m worried that I’m missing more information on SIGs.

 

Thanks a lot for your time, and have a great day.

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Brian Behlendorf
Sent: Thursday, August 15, 2019 11:29 AM
To: tsc@...
Subject: SIGs vs WGs (was Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.)

 

Changing the subject to address a point in Hart's earlier email:

 

On 8/15/19 8:17 AM, hmontgomery@... wrote:

I think a lot of people are, in fact, using SIGs for relatively technical purposes.  Having or starting a SIG is much better right now than a working group:  you get all of the support from the LF that you would for a WG (meeting times, mailing list, etc.), you aren’t mandated to submit time-consuming work products to the TSC (that, let’s be honest, very few people read), and the approval process is far simpler and doesn’t require TSC approval (which could take quite some time and be a huge headache).  If you were looking to start a group—even a very technical one--why on earth would you choose a WG over a SIG? 

I sincerely hope this is not the reason why one would choose to start a SIG rather than a WG.

Working Groups should be thought of as our connective tissue between projects - the cross-project place where discussions about identity, performance/scalability, architectural concerns, learning materials, and even diversity & civility issues can be discussed and iterated upon without that discussion being owned by one project or another.  In particular for anyone who holds architectural or product convergence as a priority, certain Working Groups like identity and architecture should be the place to articulate what that means, and then create specific technical plans that projects can follow.  They only can serve that role well to the degree they are primarily driven by active maintainers and contributors on the projects themselves, but given critical mass there can be other participants on those working groups.  Creation of any new working group should partially be gated by whether it's reasonable to expect most of the projects to be able to have people actively following and participating in that new WG.

Special Interest Groups are intended to be more of a bridge to the outside world - to people deploying our technologies for particular categories of use cases.  Those might be grouped by industrial segment, e.g. "trade finance".  Or they may be grouped by a broad set of functionality, e.g. "supply chain", that is more of a recurring theme across all industries than a specific industry.  But the point is that a SIG should be composed of both insiders and outsiders - of both technologists close to what one or more Hyperledger projects are doing, and of those who may simply be "users" of the technology, perhaps even one or two steps downstream, but who is willing to share their domain expertise and involvement in active projects at a business level to drive adoption.

I think based on the above, a SIG for academic involvement makes more sense than a working group, as it's less about cross-project issues and more about being a bridge to the outside world (and yes, helping those outsiders become insiders).  Marta has been managing our academic outreach efforts to date, so I'd encourage you to connect with her on ways we can make a SIG effective.

Let me also burst your bubble a bit - SIGs are expected to provide a one-presentation-deck-page report each month on their activities and accomplishments, which is provided to the Governing Board for their monthly discussions.  Also, we (HL staff) are very deliberate about launching new SIGs - they can often take months to pull together the right stakeholder set, define the charter crisply enough, and make sure they are managed closely enough by us.  So it may only look easier & quicker.  :)  But given all the interest in improving our relationship with academia I think we'd be able to move on this with reasonable expediency. 

Brian

-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


SIGs vs WGs (was Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.)

Brian Behlendorf
 

Changing the subject to address a point in Hart's earlier email:

On 8/15/19 8:17 AM, hmontgomery@... wrote:
I think a lot of people are, in fact, using SIGs for relatively technical purposes.  Having or starting a SIG is much better right now than a working group:  you get all of the support from the LF that you would for a WG (meeting times, mailing list, etc.), you aren’t mandated to submit time-consuming work products to the TSC (that, let’s be honest, very few people read), and the approval process is far simpler and doesn’t require TSC approval (which could take quite some time and be a huge headache).  If you were looking to start a group—even a very technical one--why on earth would you choose a WG over a SIG? 

I sincerely hope this is not the reason why one would choose to start a SIG rather than a WG.

Working Groups should be thought of as our connective tissue between projects - the cross-project place where discussions about identity, performance/scalability, architectural concerns, learning materials, and even diversity & civility issues can be discussed and iterated upon without that discussion being owned by one project or another.  In particular for anyone who holds architectural or product convergence as a priority, certain Working Groups like identity and architecture should be the place to articulate what that means, and then create specific technical plans that projects can follow.  They only can serve that role well to the degree they are primarily driven by active maintainers and contributors on the projects themselves, but given critical mass there can be other participants on those working groups.  Creation of any new working group should partially be gated by whether it's reasonable to expect most of the projects to be able to have people actively following and participating in that new WG.

Special Interest Groups are intended to be more of a bridge to the outside world - to people deploying our technologies for particular categories of use cases.  Those might be grouped by industrial segment, e.g. "trade finance".  Or they may be grouped by a broad set of functionality, e.g. "supply chain", that is more of a recurring theme across all industries than a specific industry.  But the point is that a SIG should be composed of both insiders and outsiders - of both technologists close to what one or more Hyperledger projects are doing, and of those who may simply be "users" of the technology, perhaps even one or two steps downstream, but who is willing to share their domain expertise and involvement in active projects at a business level to drive adoption.

I think based on the above, a SIG for academic involvement makes more sense than a working group, as it's less about cross-project issues and more about being a bridge to the outside world (and yes, helping those outsiders become insiders).  Marta has been managing our academic outreach efforts to date, so I'd encourage you to connect with her on ways we can make a SIG effective.

Let me also burst your bubble a bit - SIGs are expected to provide a one-presentation-deck-page report each month on their activities and accomplishments, which is provided to the Governing Board for their monthly discussions.  Also, we (HL staff) are very deliberate about launching new SIGs - they can often take months to pull together the right stakeholder set, define the charter crisply enough, and make sure they are managed closely enough by us.  So it may only look easier & quicker.  :)  But given all the interest in improving our relationship with academia I think we'd be able to move on this with reasonable expediency. 

Brian

-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


Re: TSC elections: electorate should include SIGs and some other suggestions.

Brian Behlendorf
 

SIGs aren't "represented on the TSC", but nor are Working Groups or any particular projects.  This isn't a House of Representatives nor a Senate.  TSC members are elected by voters based on whatever criteria a voter may choose, but are not there to represent one project or another - they are there as individuals, and to do right by the full Hyperledger community. 

Voter eligibility is based on connection to technical contributions anywhere across Hyperledger, as the charter says, "Anyone in the technical community that contributes code, documentation or other technical artifacts to the HLP codebase".  SIG participants who also contribute code or participate actively on Working Groups are already included.  If you have been technically active on a SIG but not in the above ways, you can petition to be added.

We use the following methods to collect the email addresses for valid voters:

1) those who have contributed in the last year to a github or gerrit repository (including hyperledger-labs), and we have a good email address to correlate to your gerrit or github account.  We don't always get a clean email address from GH so we are manually maintaining that list and doing our best to connect to other addresses we know of for you.

2) those who were named by Working Group chairs (deadline was last week) who have substantially participated in these working groups.

If you fall into these two buckets, then this past TUESDAY you should have received an invitation to join a groups.io (lists.hyperledger.org) mailing list set up for announcements and links related to the Election.  On Tuesday, ~500 emails went out, and right now ~150 people have confirmed the invitation and are on the list.  We received quite a few bounces, which suggests we have bad email addresses - so please search your inboxes, and spam folders, and either

1) Confirm your invitation to that list, OR

2) Ask us to resend the invitation if you know you should have qualified as above, OR

3) You have made other technical contributions elsewhere, such as on the wiki, or jira artifacts, etc.  You can fill out this form to petition to be added to the pool of voters.  Hyperledger staff will determine whether your response to the form points to valid technical contributions and can thus be added to the list.

For future elections we can consider other algorithmic methods for collecting emails and determining eligibility, beyond github/gerrit commits.

See: https://wiki.hyperledger.org/display/HYP/TSC+Election+2019 for more info, including how to nominate yourself for the election.

Members of that contributor-announcements list will see updates about the process soon, so please make sure you confirm membership to that list.

Hope this helps,

Brian


On 8/15/19 8:32 AM, Arnaud Le Hors wrote:
Thanks for this interesting info but to be clear, I for one never said that SIGs aren't doing any technical work. My only point is that SIGs don't report to the TSC.
And until this changes, I think it'd be odd to have them on the TSC.

I see this as a simple governance issue. The TSC should be formed of people elected among those that are governed by the TSC.

IMO, the argument that SIGs are doing technical work is an argument to bring up in support of moving SIGs under the governance of the TSC (which would then naturally make them eligible for the TSC), not merely to be part of the TSC election.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "hmontgomery@..." <hmontgomery@...>
To:        Arnaud Le Hors <lehors@...>, Vipin Bharathan <vipinsun@...>
Cc:        "tsc@..." <tsc@...>
Date:        08/15/2019 05:17 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.
Sent by:        tsc@...



Hi Arnaud,

 

This is a little bit orthogonal to what you and Vipin are discussing, but it’s still relevant, so I’ll mention it here.

 

I think a lot of people are, in fact, using SIGs for relatively technical purposes.  Having or starting a SIG is much better right now than a working group:  you get all of the support from the LF that you would for a WG (meeting times, mailing list, etc.), you aren’t mandated to submit time-consuming work products to the TSC (that, let’s be honest, very few people read), and the approval process is far simpler and doesn’t require TSC approval (which could take quite some time and be a huge headache).  If you were looking to start a group—even a very technical one--why on earth would you choose a WG over a SIG?  

 

As an example, I’ve been thinking about putting together a group related to academic involvement in Hyperledger.  The goal would be to help get academics to add their work to Hyperledger (in code) and for maintainers/developers to give research problems to academics.  I’ve written up a (very rough) draft of a SIG proposal for this.  Despite the technicality involved, I chose to write a SIG draft proposal instead of a working group proposal for the very reasons I mentioned above.  While I can’t say for certain, I suspect that some of the SIGs that are popular today made the same calculation.

 

I mostly think this is relevant to the WG reform process (thanks Mic for heading this up), and I’m not a common participant in current SIGs.  But I think it is a little much to say that SIGs aren’t doing any technical work.  I don’t’ know how to quantify “technical contributions” from SIG members, though—could a frequent SIG participant comment more on this?

 

I hope this makes sense.  I guess I’m less trying to make a point about the TSC elections than about working group reform.

 

Thanks,

Hart

 

From:tsc@... [mailto:tsc@...] On Behalf Of Arnaud Le Hors
Sent:
Thursday, August 15, 2019 7:04 AM
To:
Vipin Bharathan <vipinsun@...>
Cc:
tsc@...
Subject:
Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.

 

Hi Vipin,

The facts are that while WGs and projects are under the governance of the TSC, and report to them, the SIGs don't.
My point is that if the SIGs are actually doing technical work that should be handled by the TSC they should then be moved (back) under its structure. It would then be natural to have them be part of the TSC but I don't think we should have something in between.


I hope this clarifies what I mean. This is not about being exclusive as much as being consistent.


Regards.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





From:        
"VIPIN BHARATHAN" <vip@...>
To:        
"lehors@..." <lehors@...>, Vipin Bharathan <vipinsun@...>
Cc:        
"tsc@..." <tsc@...>
Date:        
08/14/2019 10:50 PM
Subject:        
[EXTERNAL] Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.
Sent by:        
tsc@...





Arnaud,
Feelings are not what I am after, but facts. Elsewhere  in my email, it was pointed out that SIGs have large, diverse memberships and are very technical in nature. These folks are not protocol(dlt) engineers but bring a technical user perspective. As we are maturing, we need that insight in our tsc, if we are to spur adoption and address usability and a path to production. For example the healthcare SIG has 1000 members in its mailing list. We should not exclude this contributor constituency from our tsc eligibility pools and our rolls.
This will also enhance our DCI metrics. May I remind you that the last I stands for inclusion.
Vipin



From:
tsc@...<tsc@...> on behalf of Arnaud Le Hors via Lists.Hyperledger.Org <lehors=us.ibm.com@...>
Sent:
Wednesday, August 14, 2019 4:38 PM
To:
Vipin Bharathan
Cc:
tsc@...
Subject:
Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.

Vipin,
I'm sorry if my email made you feel I had ignored that part of your email. I hadn't but, I don't share your point of view and my point remains.
Regards.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





From:        
"Vipin Bharathan" <vipinsun@...>
To:        
Arnaud Le Hors <lehors@...>
Cc:        
Hyperledger List <tsc@...>
Date:        
08/14/2019 06:25 PM
Subject:        
[EXTERNAL] Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.
Sent by:        
tsc@...





Arnaud,
I had already addressed this question in my proposal: I quote

  • There has been a case made that SIGs are not under the TSC, and hence are not eligible. WGs and even the projects are only nominally under the control of the TSC, procedures are being worked out to make this involvement even lighter touch as projects, WGs and general technical output proliferates.  
Thanks,
Vipin


On Wed, Aug 14, 2019 at 10:54 AM Arnaud Le Hors <
lehors@...> wrote:
The problem is that SIGs have been placed outside the governance of the TSC so it seems odd to have them sit on a board they have no direct relationship with.
Am I the only one to feel that way?
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





From:        
"Vipin Bharathan" <vipinsun@...>
To:        
Hyperledger List <tsc@...>
Date:        
08/10/2019 08:54 PM
Subject:        
[EXTERNAL] [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.
Sent by:        
tsc@...




Hi all,

As a long time observer, contributor and participant in Hyperledger, I make the following comments about the TSC election process.  

  • SIGs are part of the hyperledger community.
  • SIGs did not exist when the HL charter was setup
  • SIGs focus on specific lines of business, they do have strong technical participation
    • For example the paper written for the Telecomm SIG is technical, the supply chain presentation that I attended presented a port of Grid to Fabric based Oracle Blockchain. Healthcare SIG sponsored labs.
  • SIG calls are very well attended. Participants are often more diverse than the project code contributors and the working groups.
  • There has been a case made that SIGs are not under the TSC, and hence are not eligible. WGs and even the projects are only nominally under the control of the TSC, procedures are being worked out to make this involvement even lighter touch as projects, WGs and general technical output proliferates.  
  • Contributors to SIGs are contributing to the community. They should be part of the electorate for voting as well as standing for the TSC
  • We had to make a similar case for Working Groups
Chris Ferris' (as well many others) suggestion to increase the number of TSC members is welcome.

To increase the transparency of the election process, please include the percentage of electors who voted, the votes garnered by each of the candidates as in a general election. There have been suggestions that doing this may compromise the standing of candidates who got in with the least number of votes. Once elected (or nominated) to the TSC, each vote is worth the same.

In light of many of the suggestions already made, it might be wise to delay the election slightly (as Hart and some of the others have already pointed out)

We have the issue of Enterprises of widely different sizes collaborating on Hyperledger. Alternate forms of choice could be considered for the next election including quadratic voting and other methods, otherwise we risk losing diversity and the voice of smaller teams and groups.

Best,
Vipin













-- 
Brian Behlendorf
Executive Director, Hyperledger
bbehlendorf@...
Twitter: @brianbehlendorf


Re: TSC elections: electorate should include SIGs and some other suggestions.

hmontgomery@us.fujitsu.com <hmontgomery@...>
 

Hi Arnaud,

 

Thanks for the clarification, and sorry I misinterpreted your original emails.  Your argument makes complete sense. 

 

Do you think we should roll the SIG status into the discussion on WG reform?  That would seem to make a lot of sense since, at least from my perspective, WGs are just SIGs with extra responsibilities (and not many real benefits).

 

Thanks,

Hart

 

From: Arnaud Le Hors [mailto:lehors@...]
Sent: Thursday, August 15, 2019 8:32 AM
To: Montgomery, Hart <hmontgomery@...>
Cc: tsc@...; Vipin Bharathan <vipinsun@...>
Subject: RE: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.

 

Thanks for this interesting info but to be clear, I for one never said that SIGs aren't doing any technical work. My only point is that SIGs don't report to the TSC.
And until this changes, I think it'd be odd to have them on the TSC.

I see this as a simple governance issue. The TSC should be formed of people elected among those that are governed by the TSC.

IMO, the argument that SIGs are doing technical work is an argument to bring up in support of moving SIGs under the governance of the TSC (which would then naturally make them eligible for the TSC), not merely to be part of the TSC election.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "hmontgomery@..." <hmontgomery@...>
To:        Arnaud Le Hors <lehors@...>, Vipin Bharathan <vipinsun@...>
Cc:        "tsc@..." <tsc@...>
Date:        08/15/2019 05:17 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.
Sent by:        tsc@...


 

Hi Arnaud,

 

This is a little bit orthogonal to what you and Vipin are discussing, but it’s still relevant, so I’ll mention it here.

 

I think a lot of people are, in fact, using SIGs for relatively technical purposes.  Having or starting a SIG is much better right now than a working group:  you get all of the support from the LF that you would for a WG (meeting times, mailing list, etc.), you aren’t mandated to submit time-consuming work products to the TSC (that, let’s be honest, very few people read), and the approval process is far simpler and doesn’t require TSC approval (which could take quite some time and be a huge headache).  If you were looking to start a group—even a very technical one--why on earth would you choose a WG over a SIG?  

 

As an example, I’ve been thinking about putting together a group related to academic involvement in Hyperledger.  The goal would be to help get academics to add their work to Hyperledger (in code) and for maintainers/developers to give research problems to academics.  I’ve written up a (very rough) draft of a SIG proposal for this.  Despite the technicality involved, I chose to write a SIG draft proposal instead of a working group proposal for the very reasons I mentioned above.  While I can’t say for certain, I suspect that some of the SIGs that are popular today made the same calculation.

 

I mostly think this is relevant to the WG reform process (thanks Mic for heading this up), and I’m not a common participant in current SIGs.  But I think it is a little much to say that SIGs aren’t doing any technical work.  I don’t’ know how to quantify “technical contributions” from SIG members, though—could a frequent SIG participant comment more on this?

 

I hope this makes sense.  I guess I’m less trying to make a point about the TSC elections than about working group reform.

 

Thanks,

Hart

 

From:tsc@... [mailto:tsc@...] On Behalf Of Arnaud Le Hors
Sent:
Thursday, August 15, 2019 7:04 AM
To:
Vipin Bharathan <vipinsun@...>
Cc:
tsc@...
Subject:
Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.

 

Hi Vipin,

The facts are that while WGs and projects are under the governance of the TSC, and report to them, the SIGs don't.
My point is that if the SIGs are actually doing technical work that should be handled by the TSC they should then be moved (back) under its structure. It would then be natural to have them be part of the TSC but I don't think we should have something in between.


I hope this clarifies what I mean. This is not about being exclusive as much as being consistent.


Regards.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





From:        
"VIPIN BHARATHAN" <vip@...>
To:        
"
lehors@..." <lehors@...>, Vipin Bharathan <vipinsun@...>
Cc:        
"
tsc@..." <tsc@...>
Date:        
08/14/2019 10:50 PM
Subject:        
[EXTERNAL] Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.
Sent by:        
tsc@...





Arnaud,
Feelings are not what I am after, but facts. Elsewhere  in my email, it was pointed out that SIGs have large, diverse memberships and are very technical in nature. These folks are not protocol(dlt) engineers but bring a technical user perspective. As we are maturing, we need that insight in our tsc, if we are to spur adoption and address usability and a path to production. For example the healthcare SIG has 1000 members in its mailing list. We should not exclude this contributor constituency from our tsc eligibility pools and our rolls.
This will also enhance our DCI metrics. May I remind you that the last I stands for inclusion.
Vipin



From:
tsc@...<tsc@...> on behalf of Arnaud Le Hors via Lists.Hyperledger.Org <lehors=us.ibm.com@...>
Sent:
Wednesday, August 14, 2019 4:38 PM
To:
Vipin Bharathan
Cc:
tsc@...
Subject:
Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.

Vipin,
I'm sorry if my email made you feel I had ignored that part of your email. I hadn't but, I don't share your point of view and my point remains.
Regards.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





From:        
"Vipin Bharathan" <vipinsun@...>
To:        
Arnaud Le Hors <lehors@...>
Cc:        
Hyperledger List <tsc@...>
Date:        
08/14/2019 06:25 PM
Subject:        
[EXTERNAL] Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.
Sent by:        
tsc@...





Arnaud,
I had already addressed this question in my proposal: I quote

  • There has been a case made that SIGs are not under the TSC, and hence are not eligible. WGs and even the projects are only nominally under the control of the TSC, procedures are being worked out to make this involvement even lighter touch as projects, WGs and general technical output proliferates.  

Thanks,
Vipin


On Wed, Aug 14, 2019 at 10:54 AM Arnaud Le Hors <
lehors@...> wrote:
The problem is that SIGs have been placed outside the governance of the TSC so it seems odd to have them sit on a board they have no direct relationship with.
Am I the only one to feel that way?
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





From:        
"Vipin Bharathan" <vipinsun@...>
To:        
Hyperledger List <tsc@...>
Date:        
08/10/2019 08:54 PM
Subject:        
[EXTERNAL] [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.
Sent by:        
tsc@...





Hi all,

As a long time observer, contributor and participant in Hyperledger, I make the following comments about the TSC election process.  

  • SIGs are part of the hyperledger community.
  • SIGs did not exist when the HL charter was setup
  • SIGs focus on specific lines of business, they do have strong technical participation
    • For example the paper written for the Telecomm SIG is technical, the supply chain presentation that I attended presented a port of Grid to Fabric based Oracle Blockchain. Healthcare SIG sponsored labs.
  • SIG calls are very well attended. Participants are often more diverse than the project code contributors and the working groups.
  • There has been a case made that SIGs are not under the TSC, and hence are not eligible. WGs and even the projects are only nominally under the control of the TSC, procedures are being worked out to make this involvement even lighter touch as projects, WGs and general technical output proliferates.  
  • Contributors to SIGs are contributing to the community. They should be part of the electorate for voting as well as standing for the TSC
  • We had to make a similar case for Working Groups

Chris Ferris' (as well many others) suggestion to increase the number of TSC members is welcome.

To increase the transparency of the election process, please include the percentage of electors who voted, the votes garnered by each of the candidates as in a general election. There have been suggestions that doing this may compromise the standing of candidates who got in with the least number of votes. Once elected (or nominated) to the TSC, each vote is worth the same.

In light of many of the suggestions already made, it might be wise to delay the election slightly (as Hart and some of the others have already pointed out)

We have the issue of Enterprises of widely different sizes collaborating on Hyperledger. Alternate forms of choice could be considered for the next election including quadratic voting and other methods, otherwise we risk losing diversity and the voice of smaller teams and groups.

Best,
Vipin












Hyperledger Mentorship/Internship Program Update August 2019

Min Yu
 

The expanded internship/mentorship program this year has seen tremendous contributions from the mentees and mentors. You can learn more about their work by:
What's coming up?
  • plans are in the works to highlight their work and contributions in upcoming blog posts.
  • mentees/mentors will share their work more broadly with the community at an upcoming Hyperledger conference
How can you support the mentees/mentors and this program?
  • We recommend that the TSC gives each mentee a 5-minute-slot to present at the beginning of the weekly TSC calls. Or let us know if you have other suggestions to bring greater visibility for their work and contributions.
  • Consider volunteering being a mentor to teach/guide/mentor next year - program timeline will be similar to this year's as you plan your involvement: https://wiki.hyperledger.org/display/INTERN/Hyperledger+Mentorship+Program
Last but not least, thank you to all the mentors who volunteer their time to work with this year's cohort. Your contributions are much appreciated.

Regards,
Min
--
Min Yu
Operations Manager
The Linux Foundation
+1(530) 902-6464 (m)


Re: TSC elections: electorate should include SIGs and some other suggestions.

Arnaud Le Hors
 

Thanks for this interesting info but to be clear, I for one never said that SIGs aren't doing any technical work. My only point is that SIGs don't report to the TSC.
And until this changes, I think it'd be odd to have them on the TSC.

I see this as a simple governance issue. The TSC should be formed of people elected among those that are governed by the TSC.

IMO, the argument that SIGs are doing technical work is an argument to bring up in support of moving SIGs under the governance of the TSC (which would then naturally make them eligible for the TSC), not merely to be part of the TSC election.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "hmontgomery@..." <hmontgomery@...>
To:        Arnaud Le Hors <lehors@...>, Vipin Bharathan <vipinsun@...>
Cc:        "tsc@..." <tsc@...>
Date:        08/15/2019 05:17 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.
Sent by:        tsc@...



Hi Arnaud,

 

This is a little bit orthogonal to what you and Vipin are discussing, but it’s still relevant, so I’ll mention it here.

 

I think a lot of people are, in fact, using SIGs for relatively technical purposes.  Having or starting a SIG is much better right now than a working group:  you get all of the support from the LF that you would for a WG (meeting times, mailing list, etc.), you aren’t mandated to submit time-consuming work products to the TSC (that, let’s be honest, very few people read), and the approval process is far simpler and doesn’t require TSC approval (which could take quite some time and be a huge headache).  If you were looking to start a group—even a very technical one--why on earth would you choose a WG over a SIG?  

 

As an example, I’ve been thinking about putting together a group related to academic involvement in Hyperledger.  The goal would be to help get academics to add their work to Hyperledger (in code) and for maintainers/developers to give research problems to academics.  I’ve written up a (very rough) draft of a SIG proposal for this.  Despite the technicality involved, I chose to write a SIG draft proposal instead of a working group proposal for the very reasons I mentioned above.  While I can’t say for certain, I suspect that some of the SIGs that are popular today made the same calculation.

 

I mostly think this is relevant to the WG reform process (thanks Mic for heading this up), and I’m not a common participant in current SIGs.  But I think it is a little much to say that SIGs aren’t doing any technical work.  I don’t’ know how to quantify “technical contributions” from SIG members, though—could a frequent SIG participant comment more on this?

 

I hope this makes sense.  I guess I’m less trying to make a point about the TSC elections than about working group reform.

 

Thanks,

Hart

 

From:tsc@... [mailto:tsc@...] On Behalf Of Arnaud Le Hors

Sent: Thursday, August 15, 2019 7:04 AM
To:
Vipin Bharathan <vipinsun@...>
Cc:
tsc@...
Subject:
Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.

 

Hi Vipin,

The facts are that while WGs and projects are under the governance of the TSC, and report to them, the SIGs don't.
My point is that if the SIGs are actually doing technical work that should be handled by the TSC they should then be moved (back) under its structure. It would then be natural to have them be part of the TSC but I don't think we should have something in between.


I hope this clarifies what I mean. This is not about being exclusive as much as being consistent.


Regards.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





From:        
"VIPIN BHARATHAN" <vip@...>
To:        
"lehors@..." <lehors@...>, Vipin Bharathan <vipinsun@...>
Cc:        
"tsc@..." <tsc@...>
Date:        
08/14/2019 10:50 PM
Subject:        
[EXTERNAL] Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.
Sent by:        
tsc@...





Arnaud,
Feelings are not what I am after, but facts. Elsewhere  in my email, it was pointed out that SIGs have large, diverse memberships and are very technical in nature. These folks are not protocol(dlt) engineers but bring a technical user perspective. As we are maturing, we need that insight in our tsc, if we are to spur adoption and address usability and a path to production. For example the healthcare SIG has 1000 members in its mailing list. We should not exclude this contributor constituency from our tsc eligibility pools and our rolls.
This will also enhance our DCI metrics. May I remind you that the last I stands for inclusion.
Vipin



From:
tsc@...<tsc@...> on behalf of Arnaud Le Hors via Lists.Hyperledger.Org <lehors=us.ibm.com@...>
Sent:
Wednesday, August 14, 2019 4:38 PM
To:
Vipin Bharathan
Cc:
tsc@...
Subject:
Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.

Vipin,
I'm sorry if my email made you feel I had ignored that part of your email. I hadn't but, I don't share your point of view and my point remains.
Regards.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





From:        
"Vipin Bharathan" <vipinsun@...>
To:        
Arnaud Le Hors <lehors@...>
Cc:        
Hyperledger List <tsc@...>
Date:        
08/14/2019 06:25 PM
Subject:        
[EXTERNAL] Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.
Sent by:        
tsc@...





Arnaud,
I had already addressed this question in my proposal: I quote

  • There has been a case made that SIGs are not under the TSC, and hence are not eligible. WGs and even the projects are only nominally under the control of the TSC, procedures are being worked out to make this involvement even lighter touch as projects, WGs and general technical output proliferates.  
Thanks,
Vipin


On Wed, Aug 14, 2019 at 10:54 AM Arnaud Le Hors <
lehors@...> wrote:
The problem is that SIGs have been placed outside the governance of the TSC so it seems odd to have them sit on a board they have no direct relationship with.
Am I the only one to feel that way?
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





From:        
"Vipin Bharathan" <vipinsun@...>
To:        
Hyperledger List <tsc@...>
Date:        
08/10/2019 08:54 PM
Subject:        
[EXTERNAL] [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.
Sent by:        
tsc@...




Hi all,

As a long time observer, contributor and participant in Hyperledger, I make the following comments about the TSC election process.  

  • SIGs are part of the hyperledger community.
  • SIGs did not exist when the HL charter was setup
  • SIGs focus on specific lines of business, they do have strong technical participation
    • For example the paper written for the Telecomm SIG is technical, the supply chain presentation that I attended presented a port of Grid to Fabric based Oracle Blockchain. Healthcare SIG sponsored labs.
  • SIG calls are very well attended. Participants are often more diverse than the project code contributors and the working groups.
  • There has been a case made that SIGs are not under the TSC, and hence are not eligible. WGs and even the projects are only nominally under the control of the TSC, procedures are being worked out to make this involvement even lighter touch as projects, WGs and general technical output proliferates.  
  • Contributors to SIGs are contributing to the community. They should be part of the electorate for voting as well as standing for the TSC
  • We had to make a similar case for Working Groups
Chris Ferris' (as well many others) suggestion to increase the number of TSC members is welcome.

To increase the transparency of the election process, please include the percentage of electors who voted, the votes garnered by each of the candidates as in a general election. There have been suggestions that doing this may compromise the standing of candidates who got in with the least number of votes. Once elected (or nominated) to the TSC, each vote is worth the same.

In light of many of the suggestions already made, it might be wise to delay the election slightly (as Hart and some of the others have already pointed out)

We have the issue of Enterprises of widely different sizes collaborating on Hyperledger. Alternate forms of choice could be considered for the next election including quadratic voting and other methods, otherwise we risk losing diversity and the voice of smaller teams and groups.

Best,
Vipin













Re: TSC elections: electorate should include SIGs and some other suggestions.

hmontgomery@us.fujitsu.com <hmontgomery@...>
 

Hi Arnaud,

 

This is a little bit orthogonal to what you and Vipin are discussing, but it’s still relevant, so I’ll mention it here.

 

I think a lot of people are, in fact, using SIGs for relatively technical purposes.  Having or starting a SIG is much better right now than a working group:  you get all of the support from the LF that you would for a WG (meeting times, mailing list, etc.), you aren’t mandated to submit time-consuming work products to the TSC (that, let’s be honest, very few people read), and the approval process is far simpler and doesn’t require TSC approval (which could take quite some time and be a huge headache).  If you were looking to start a group—even a very technical one--why on earth would you choose a WG over a SIG? 

 

As an example, I’ve been thinking about putting together a group related to academic involvement in Hyperledger.  The goal would be to help get academics to add their work to Hyperledger (in code) and for maintainers/developers to give research problems to academics.  I’ve written up a (very rough) draft of a SIG proposal for this.  Despite the technicality involved, I chose to write a SIG draft proposal instead of a working group proposal for the very reasons I mentioned above.  While I can’t say for certain, I suspect that some of the SIGs that are popular today made the same calculation.

 

I mostly think this is relevant to the WG reform process (thanks Mic for heading this up), and I’m not a common participant in current SIGs.  But I think it is a little much to say that SIGs aren’t doing any technical work.  I don’t’ know how to quantify “technical contributions” from SIG members, though—could a frequent SIG participant comment more on this?

 

I hope this makes sense.  I guess I’m less trying to make a point about the TSC elections than about working group reform.

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Arnaud Le Hors
Sent: Thursday, August 15, 2019 7:04 AM
To: Vipin Bharathan <vipinsun@...>
Cc: tsc@...
Subject: Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.

 

Hi Vipin,

The facts are that while WGs and projects are under the governance of the TSC, and report to them, the SIGs don't.
My point is that if the SIGs are actually doing technical work that should be handled by the TSC they should then be moved (back) under its structure. It would then be natural to have them be part of the TSC but I don't think we should have something in between.

I hope this clarifies what I mean. This is not about being exclusive as much as being consistent.

Regards.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "VIPIN BHARATHAN" <vip@...>
To:        "lehors@..." <lehors@...>, Vipin Bharathan <vipinsun@...>
Cc:        "tsc@..." <tsc@...>
Date:        08/14/2019 10:50 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.
Sent by:        tsc@...





Arnaud,
Feelings are not what I am after, but facts. Elsewhere  in my email, it was pointed out that SIGs have large, diverse memberships and are very technical in nature. These folks are not protocol(dlt) engineers but bring a technical user perspective. As we are maturing, we need that insight in our tsc, if we are to spur adoption and address usability and a path to production. For example the healthcare SIG has 1000 members in its mailing list. We should not exclude this contributor constituency from our tsc eligibility pools and our rolls.
This will also enhance our DCI metrics. May I remind you that the last I stands for inclusion.
Vipin



From: tsc@... <tsc@...> on behalf of Arnaud Le Hors via Lists.Hyperledger.Org <lehors=us.ibm.com@...>
Sent:
Wednesday, August 14, 2019 4:38 PM
To:
Vipin Bharathan
Cc:
tsc@...
Subject:
Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.

 
Vipin,
I'm sorry if my email made you feel I had ignored that part of your email. I hadn't but, I don't share your point of view and my point remains.
Regards.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





From:        
"Vipin Bharathan" <vipinsun@...>
To:        
Arnaud Le Hors <lehors@...>
Cc:        
Hyperledger List <tsc@...>
Date:        
08/14/2019 06:25 PM
Subject:        
[EXTERNAL] Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.
Sent by:        
tsc@...





Arnaud,
I had already addressed this question in my proposal: I quote

  • There has been a case made that SIGs are not under the TSC, and hence are not eligible. WGs and even the projects are only nominally under the control of the TSC, procedures are being worked out to make this involvement even lighter touch as projects, WGs and general technical output proliferates.  

Thanks,
Vipin


On Wed, Aug 14, 2019 at 10:54 AM Arnaud Le Hors <
lehors@...> wrote:
The problem is that SIGs have been placed outside the governance of the TSC so it seems odd to have them sit on a board they have no direct relationship with.
Am I the only one to feel that way?
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





From:        
"Vipin Bharathan" <vipinsun@...>
To:        
Hyperledger List <tsc@...>
Date:        
08/10/2019 08:54 PM
Subject:        
[EXTERNAL] [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.
Sent by:        
tsc@...





Hi all,

As a long time observer, contributor and participant in Hyperledger, I make the following comments about the TSC election process.  

  • SIGs are part of the hyperledger community.
  • SIGs did not exist when the HL charter was setup
  • SIGs focus on specific lines of business, they do have strong technical participation
    • For example the paper written for the Telecomm SIG is technical, the supply chain presentation that I attended presented a port of Grid to Fabric based Oracle Blockchain. Healthcare SIG sponsored labs.
  • SIG calls are very well attended. Participants are often more diverse than the project code contributors and the working groups.
  • There has been a case made that SIGs are not under the TSC, and hence are not eligible. WGs and even the projects are only nominally under the control of the TSC, procedures are being worked out to make this involvement even lighter touch as projects, WGs and general technical output proliferates.  
  • Contributors to SIGs are contributing to the community. They should be part of the electorate for voting as well as standing for the TSC
  • We had to make a similar case for Working Groups

Chris Ferris' (as well many others) suggestion to increase the number of TSC members is welcome.

To increase the transparency of the election process, please include the percentage of electors who voted, the votes garnered by each of the candidates as in a general election. There have been suggestions that doing this may compromise the standing of candidates who got in with the least number of votes. Once elected (or nominated) to the TSC, each vote is worth the same.

In light of many of the suggestions already made, it might be wise to delay the election slightly (as Hart and some of the others have already pointed out)

We have the issue of Enterprises of widely different sizes collaborating on Hyperledger. Alternate forms of choice could be considered for the next election including quadratic voting and other methods, otherwise we risk losing diversity and the voice of smaller teams and groups.

Best,
Vipin









1341 - 1360 of 3892