Topics

Congratulations to the members of the 2019-2020 TSC!

Ry Jones
 

Angelo De Caro
Arnaud J Le Hors
Christopher Ferris
Dan Middleton
Gari Singh
Hart Montgomery
Mark Wagner
Nathan George
Swetha Repakula
Tracy Kuhrt
Troy Ronda


--
Ry Jones
Community Architect, Hyperledger

Todd Little
 

Hi TSC and Hyperledger in general,

While I don't doubt the results of the election, I do have to question whether this is the sort of outcome Hyperledger desires.  For projects to exit incubation they must exhibit diversity of contributions such that a project is not "controlled" by a single organization.  Why would the TSC find that TSC membership adheres to a lesser standard?  It is very clear that IBM now controls the TSC and is that the direction Hyperledger wants to take?

-tl

Brian Behlendorf
 

Hi Todd,

First, let me express congratulations to the newly elected TSC, particularly the new members who will bring fresh energy and perspectives to our conversations.  You are the heart of the technical credibility of this project, and I could not be happier to see it in such good hands.  (apologies for the delay, I've been traveling)

Todd: thank you for expression of concerns that no doubt are latent on other people's minds.  I am sure they are also on the minds of each of the TSC members, too.

We have been very careful at Hyperledger to separate out the sponsoring-member-consortium layer from the developer-driven product and technical layer.  The former is intended to run very much like any ordinary consortium would; the latter, like any well functioning open source project.  I may be projecting from my experience with Apache, and perhaps over-assuming that the following is obvious, but I always felt it's been clear that developers are expected to participate and contribute as individuals first, and as employees second.  For example:

* If a maintainer on a project, or a member of the TSC, changes employers, they do not lose their status; their "seat" is not conferred to someone else from the same employer, they keep it wherever they go. 

* If a developer is asked by their employer to submit code that the developer does not believe is the right thing to do, the developer should not submit that code.  In no case is "we were asked to do it this way" acceptable as a rationale for submitting or accepting a pull request or other technical decision, and they can ask us (HL staff) to delicately intervene if necessary.

* While we (Hyperledger staff) encourage companies to commit their developers to projects, and argue that they'll realize benefit from doing so, we constantly warn them that the public processes must rule the day; that project proposals, pull requests, even discussions will go whatever way the developer community decides it should, no matter how unfair or subject that may feel.  We also make it clear that a company's sponsoring membership in Hyperledger has no bearing on their technical contributions; and that conversely, non-member companies can realize the full benefit of using and contributing to Hyperledger projects.  We have several companies who contribute major amounts of code, and it's running code that usually dictates what happens (the do-ocracy).  Of course this swings both ways - it would be inappropriate for us to change the TSC election outcome because it didn't look the way we think it should.

Obviously, developers may feel pressure from their employers, and some will be able to push back but others won't feel so empowered.  The market for talent in this space is so hot, and the profile accrued to TSC members and project maintainers so high, that job security is likely not the overwhelming issue.  Others will act out of loyalty to their employers.  However, this community is capable of watching for, and calling out, behavior they feel might cross that line.  And we as HL staff have given feedback privately when we've seen that too.

By any metric, to date, IBM's technical contributions to Hyperledger have been substantial, and more than any other company.  They deserve credit for that.  Early on, that contribution level was so high that it led to public perception issues of "control", and a sense that technical decisions were being made on white boards and phone calls offline rather than online.  I won't speak for them, but it was made clear to us that IBM did not want that outcome - they brought Fabric to Hyperledger to get developer leverage, so that their headcount would be complemented by the efforts of many others.  And, they knew it was essential that Fabric not be a single-vendor product, but an industry movement.  So we worked with them on both the technical process issues, and the public perception issues, and I believe these are in the past.  They no longer are more than half the contributions into Fabric, as per Chris Ferris's numbers.  There are many other projects beyond Fabric in Hyperledger, and IBM has supported those, boosting Indy and Sawtooth and now even welcoming Besu.  Perhaps this is one reason the other electors felt comfortable voting for the IBM-employed candidates.

Now that every major public cloud provider offers a managed Fabric as a service, and those companies are now getting commercial traction, we expect those other companies to increase their investments into Fabric, entirely out of self-interest.  That will, no doubt, also increase the representation from those companies in the maintainer community in Fabric, into other Hyperledger projects, and in the next TSC election.

But all that said, there was talk about increasing the size of the TSC, to increase the prospect that more projects at Hyperledger will see one of their maintainers onboard, and to account for the growing developer community.  I think that would address both the perception of an issue here, and any actual attempt by a single vendor to exert "control" over their employees who become TSC members.  The new TSC can discuss this.  They could decide to ask the Governing Board to adjust the Hyperledger bylaws to increase the size of the TSC for the next election.  They could also ask the Governing Board to approve a one-time add of a set of new TSC members, so that this greater representation can happen in the current TSC term.  I think there are a lot of great reasons for either approach.

Again, I'm excited by the new TSC.  There's a lot of new hard work to do together!

Hope this helps,

Brian


On 9/6/19 3:04 PM, Todd Little wrote:
Hi TSC and Hyperledger in general,

While I don't doubt the results of the election, I do have to question whether this is the sort of outcome Hyperledger desires.  For projects to exit incubation they must exhibit diversity of contributions such that a project is not "controlled" by a single organization.  Why would the TSC find that TSC membership adheres to a lesser standard?  It is very clear that IBM now controls the TSC and is that the direction Hyperledger wants to take?

-tl


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

Bob Summerwill <bob@...>
 

I wrote a blog post on diversity while I was standing for the TSC in 2018, which triggered some debate:

https://bobsummerwill.com/2018/08/15/hyperledger-tsc-candidates-and-thoughts-on-diversity/

While I would agree that the high level of IBM affiliation on the 2019-2020 committee is less than ideal, I must take the opportunity to congratulate Tracy and Swetha both on standing for AND winning election to the TSC following years of 100% male candidates.

That is a big step in the right direction on diversity of representation in the TSC which should not be overlooked.   Bravo!


Bob Summerwill
Executive Director
Ethereum Classic Cooperative

On Fri., Sep. 6, 2019, 5:33 p.m. Brian Behlendorf, <bbehlendorf@...> wrote:
Hi Todd,

First, let me express congratulations to the newly elected TSC, particularly the new members who will bring fresh energy and perspectives to our conversations.  You are the heart of the technical credibility of this project, and I could not be happier to see it in such good hands.  (apologies for the delay, I've been traveling)

Todd: thank you for expression of concerns that no doubt are latent on other people's minds.  I am sure they are also on the minds of each of the TSC members, too.

We have been very careful at Hyperledger to separate out the sponsoring-member-consortium layer from the developer-driven product and technical layer.  The former is intended to run very much like any ordinary consortium would; the latter, like any well functioning open source project.  I may be projecting from my experience with Apache, and perhaps over-assuming that the following is obvious, but I always felt it's been clear that developers are expected to participate and contribute as individuals first, and as employees second.  For example:

* If a maintainer on a project, or a member of the TSC, changes employers, they do not lose their status; their "seat" is not conferred to someone else from the same employer, they keep it wherever they go. 

* If a developer is asked by their employer to submit code that the developer does not believe is the right thing to do, the developer should not submit that code.  In no case is "we were asked to do it this way" acceptable as a rationale for submitting or accepting a pull request or other technical decision, and they can ask us (HL staff) to delicately intervene if necessary.

* While we (Hyperledger staff) encourage companies to commit their developers to projects, and argue that they'll realize benefit from doing so, we constantly warn them that the public processes must rule the day; that project proposals, pull requests, even discussions will go whatever way the developer community decides it should, no matter how unfair or subject that may feel.  We also make it clear that a company's sponsoring membership in Hyperledger has no bearing on their technical contributions; and that conversely, non-member companies can realize the full benefit of using and contributing to Hyperledger projects.  We have several companies who contribute major amounts of code, and it's running code that usually dictates what happens (the do-ocracy).  Of course this swings both ways - it would be inappropriate for us to change the TSC election outcome because it didn't look the way we think it should.

Obviously, developers may feel pressure from their employers, and some will be able to push back but others won't feel so empowered.  The market for talent in this space is so hot, and the profile accrued to TSC members and project maintainers so high, that job security is likely not the overwhelming issue.  Others will act out of loyalty to their employers.  However, this community is capable of watching for, and calling out, behavior they feel might cross that line.  And we as HL staff have given feedback privately when we've seen that too.

By any metric, to date, IBM's technical contributions to Hyperledger have been substantial, and more than any other company.  They deserve credit for that.  Early on, that contribution level was so high that it led to public perception issues of "control", and a sense that technical decisions were being made on white boards and phone calls offline rather than online.  I won't speak for them, but it was made clear to us that IBM did not want that outcome - they brought Fabric to Hyperledger to get developer leverage, so that their headcount would be complemented by the efforts of many others.  And, they knew it was essential that Fabric not be a single-vendor product, but an industry movement.  So we worked with them on both the technical process issues, and the public perception issues, and I believe these are in the past.  They no longer are more than half the contributions into Fabric, as per Chris Ferris's numbers.  There are many other projects beyond Fabric in Hyperledger, and IBM has supported those, boosting Indy and Sawtooth and now even welcoming Besu.  Perhaps this is one reason the other electors felt comfortable voting for the IBM-employed candidates.

Now that every major public cloud provider offers a managed Fabric as a service, and those companies are now getting commercial traction, we expect those other companies to increase their investments into Fabric, entirely out of self-interest.  That will, no doubt, also increase the representation from those companies in the maintainer community in Fabric, into other Hyperledger projects, and in the next TSC election.

But all that said, there was talk about increasing the size of the TSC, to increase the prospect that more projects at Hyperledger will see one of their maintainers onboard, and to account for the growing developer community.  I think that would address both the perception of an issue here, and any actual attempt by a single vendor to exert "control" over their employees who become TSC members.  The new TSC can discuss this.  They could decide to ask the Governing Board to adjust the Hyperledger bylaws to increase the size of the TSC for the next election.  They could also ask the Governing Board to approve a one-time add of a set of new TSC members, so that this greater representation can happen in the current TSC term.  I think there are a lot of great reasons for either approach.

Again, I'm excited by the new TSC.  There's a lot of new hard work to do together!

Hope this helps,

Brian


On 9/6/19 3:04 PM, Todd Little wrote:
Hi TSC and Hyperledger in general,

While I don't doubt the results of the election, I do have to question whether this is the sort of outcome Hyperledger desires.  For projects to exit incubation they must exhibit diversity of contributions such that a project is not "controlled" by a single organization.  Why would the TSC find that TSC membership adheres to a lesser standard?  It is very clear that IBM now controls the TSC and is that the direction Hyperledger wants to take?

-tl


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

Todd Little
 

Hi Brian,

Thanks for your well reasoned response.  I don't want to drag this down into a rat hole or spilt milk debate.  I was merely trying to point out the irony of lack of diversity in the TSC vs the other Hyperledger bodies.  The governing body by it's membership definition forces diversity and allows anyone with sufficient financial resources to have a seat at the table.  For Hyperledger projects to exit incubation they must show sufficient diversity of contributors, although that can be hard to measure as Ry has discovered in this last election process.  So it just seems a little odd to me that there aren't any diversity requirements for the TSC.  What would your response be if after the TSC elections next year, every member was employed by some organization that wasn't even a member of Hyperledger?  It is theoretically possible and given the voting process, i.e., who can vote, completely feasible.

You are correct in that the TSC members are individuals and not companies, but everyone one of them knows who butters their bread.  I also sense that there is some dissatisfaction over the common use of Hyperledger as some single thing when the reference is really referring to Fabric.  Fabric and Hyperledger when talking about projects are often used interchangeably.  For good or bad, this is likely a result of IBM's significant contributions to Fabric, and the ability for Fabric to run without specific hardware (sorry Mic!).  Having nearly half the TSC membership made up of individuals (not lost on me) working for one company (hopefully not lost on you), seems specious at best and doesn't help elevate the other Hyperledger projects to be on par with Fabric.

I also wonder at times about the role of the TSC as it seems that much of the TSC time is spent on things that aren't technical, at least not deeply so.  Is the whole project lifecycle debate a technical debate?  The current discussions about working groups and their roles really a technical issue the TSC should be debating?  I also wonder about what control or sway the TSC has on any project or should have on any project.  Are the Hyperledger projects just a bunch of technology projects with little intersection and no goal of convergence?  I mean every blockchain needs identity, but what is happening in the platforms to consolidate around an identity project such as Indy?  Likewise there are lots of issues around privacy and confidentiality, yet the privacy and confidentiality working group has serious concerns about what if any impact their work will have on the platforms.  If there is no impact, why should we continue the working group?  If there is no impact, what makes something a Hyperledger project other than the blessing of the TSC?  And why would a project want to join Hyperledger other than for the marketing value it brings if joining has effectively zero impact on the project direction?

Respectfully,
Todd

VIPIN BHARATHAN
 


Hi Brian/Todd/Bob/all,

It is unfortunate that the happy incidence of having gender diversity is tied  to the debate about over-representation of a single firm on the TSC. The result is more diversity in one dimension as we lose diversity in another.

A 33%  turnout is not good for both.  It has been shown that in a low turnout election, committed and well organized groups dominate. 

If gender diversity was the result of a 60+% turnout, it would have appeared "more real".
A 60+% turnout would have been better to justify the domination of a single firm on the TSC.  

Increasing turnout is also needed for truer democracy in general. Increasing turnout is quite difficult in this age of cynicism and apathy. How do we break through the ice? A question that needs to be answered through concrete steps for stimulating turnout in the next election. I had provided some pointers to the election officer, maybe a little too late. There are well known techniques for this. We need to adopt them.

This is in addition to "who gets to participate in the election" which should be "everyone that contributes technical artifacts to Hyperledger"; including the contributors on the wiki and the SIG participants in my view. The github query does not measure technical artifacts. I could contribute a single spelling correction in github and be included very easily; whereas someone who contributes only an extensive technical blog or article is excluded; if they are not on a Working Group list.

Best,
Vipin
 

dlt.nyc
Vipin Bharathan
Enterprise Blockchain Consultant
vip@...


From: tsc@... <tsc@...> on behalf of Todd Little via Lists.Hyperledger.Org <todd.little=oracle.com@...>
Sent: Saturday, September 7, 2019 1:45 PM
To: tsc@... <tsc@...>
Cc: tsc@... <tsc@...>
Subject: Re: [Hyperledger TSC] Congratulations to the members of the 2019-2020 TSC!
 
Hi Brian,

Thanks for your well reasoned response.  I don't want to drag this down into a rat hole or spilt milk debate.  I was merely trying to point out the irony of lack of diversity in the TSC vs the other Hyperledger bodies.  The governing body by it's membership definition forces diversity and allows anyone with sufficient financial resources to have a seat at the table.  For Hyperledger projects to exit incubation they must show sufficient diversity of contributors, although that can be hard to measure as Ry has discovered in this last election process.  So it just seems a little odd to me that there aren't any diversity requirements for the TSC.  What would your response be if after the TSC elections next year, every member was employed by some organization that wasn't even a member of Hyperledger?  It is theoretically possible and given the voting process, i.e., who can vote, completely feasible.

You are correct in that the TSC members are individuals and not companies, but everyone one of them knows who butters their bread.  I also sense that there is some dissatisfaction over the common use of Hyperledger as some single thing when the reference is really referring to Fabric.  Fabric and Hyperledger when talking about projects are often used interchangeably.  For good or bad, this is likely a result of IBM's significant contributions to Fabric, and the ability for Fabric to run without specific hardware (sorry Mic!).  Having nearly half the TSC membership made up of individuals (not lost on me) working for one company (hopefully not lost on you), seems specious at best and doesn't help elevate the other Hyperledger projects to be on par with Fabric.

I also wonder at times about the role of the TSC as it seems that much of the TSC time is spent on things that aren't technical, at least not deeply so.  Is the whole project lifecycle debate a technical debate?  The current discussions about working groups and their roles really a technical issue the TSC should be debating?  I also wonder about what control or sway the TSC has on any project or should have on any project.  Are the Hyperledger projects just a bunch of technology projects with little intersection and no goal of convergence?  I mean every blockchain needs identity, but what is happening in the platforms to consolidate around an identity project such as Indy?  Likewise there are lots of issues around privacy and confidentiality, yet the privacy and confidentiality working group has serious concerns about what if any impact their work will have on the platforms.  If there is no impact, why should we continue the working group?  If there is no impact, what makes something a Hyperledger project other than the blessing of the TSC?  And why would a project want to join Hyperledger other than for the marketing value it brings if joining has effectively zero impact on the project direction?

Respectfully,
Todd

Silas Davis
 

From my experience of the people elected, the TSC looks like a good TSC.

I think we should enlarge the TSC as a tactical manoeuvre (which may not work) to nudge Hyperledger towards a more project-diverse TSC.

The preponderance of IBM employees is a symptom of the dominance of Fabric in Hyperledger and the relative dominance of IBM in the Fabric project as other's have pointed out. One can only vote for those one knows and Fabric contributors are a highly connected subset of Hyperledger. The solution (he says blithely) is for other projects to become more relevant (to those inside and outside Hyperledger), attract more contributors, and then to apply more democracy. Which is to say I don't think medicating the imbalance of the TSC directly is probably the right way to go.

However it is not a given that the positive feedback above will happen on its own given the inertia associated with project adoption, public mindshare, etc. It is hard to know where the momentum is with Hyperledger in this respect but some small interventions now might pay dividends later.

It's worth questioning whether having greater project/company diversity on the TSC is even a Good Thing. It's not like IBM or Fabric people are a homogeneous block. However I would suggest:

- Diversity of ideas - I think the well rehearsed ideas about avoiding groupthink etc apply here. Different projects are exploring different parts of the space of distributed ledgers useful to have these ideas injected.
- Representation of projects - so long as Hyperledger is a multiple project umbrella it is useful to have representation on decision-making boards that affect projects. The TSC may not be a house of representatives but seems that function is there
- Politics - occasionally decisions come up that have more commercial/ideological significance (i.e. whether to accept a new project), this is where a balance of forces are important particularly amongst cooperating competitors
- Competence - it is difficult for people with no exposure to a project's code or design outside of surveying it in order to answer a question coming to the TSC to decide on finely balanced technical matters. Usually the right thing to do is for the TSC to defer to those with more context. But having people experienced with a greater range of projects means those people can help spread that context to other TSC members aided by an existing relationship with those other TSC members.

For my part I was planning to stick around the TSC meetings and list despite no longer being a  member, the general prospect of which was noted by Mark and Arnaud on a previous call. However I would note that in the same way that getting elected to the TSC was a spur to apportion more of my time and effort to Hyperledger, losing the franchise does remove some of that impetus (although rather less since now I feel more involved) so even if TSC votes are rather consensual after discussions (as Arnaud noted) I would not discount the effect of the responsibility of being a bona fide TSC member as a human motivator to do more work.

Thinking about some of Todd's criticisms of the technical import of things discussed at the TSC. I would argue that things such as project lifecycle are relevant to the technical output of Hyperledger given software engineering is a team sport. I'd agree they are not deeply technical as defining a consensus interface or standardising on a choice of stream cipher might be. I too would like to see more deeply technical matters considered at the TSC, however I think the reason this is hard is the same as mentioned in the 'competence' bullet-point above. We generally need to be way more up inside each other's projects.

> There are well known techniques for this. We need to adopt them.

What are they?

> This is in addition to "who gets to participate in the election" which should be "everyone that contributes technical artifacts to Hyperledger"

How about a roll of credits stored as lines in a plain text file of the form `Date of contribution - nature of contribution` which could be stored in the repo and for which each commit adding a credit would need to be signed by a project maintainer or possibly existing contributor? This would put the definition of a contribution under the control of projects themselves.

Silas


On Mon, 9 Sep 2019 at 02:38, VIPIN BHARATHAN <vip@...> wrote:

Hi Brian/Todd/Bob/all,

It is unfortunate that the happy incidence of having gender diversity is tied  to the debate about over-representation of a single firm on the TSC. The result is more diversity in one dimension as we lose diversity in another.

A 33%  turnout is not good for both.  It has been shown that in a low turnout election, committed and well organized groups dominate. 

If gender diversity was the result of a 60+% turnout, it would have appeared "more real".
A 60+% turnout would have been better to justify the domination of a single firm on the TSC.  

Increasing turnout is also needed for truer democracy in general. Increasing turnout is quite difficult in this age of cynicism and apathy. How do we break through the ice? A question that needs to be answered through concrete steps for stimulating turnout in the next election. I had provided some pointers to the election officer, maybe a little too late. There are well known techniques for this. We need to adopt them.

This is in addition to "who gets to participate in the election" which should be "everyone that contributes technical artifacts to Hyperledger"; including the contributors on the wiki and the SIG participants in my view. The github query does not measure technical artifacts. I could contribute a single spelling correction in github and be included very easily; whereas someone who contributes only an extensive technical blog or article is excluded; if they are not on a Working Group list.

Best,
Vipin
 

dlt.nyc
Vipin Bharathan
Enterprise Blockchain Consultant


From: tsc@... <tsc@...> on behalf of Todd Little via Lists.Hyperledger.Org <todd.little=oracle.com@...>
Sent: Saturday, September 7, 2019 1:45 PM
To: tsc@... <tsc@...>
Cc: tsc@... <tsc@...>
Subject: Re: [Hyperledger TSC] Congratulations to the members of the 2019-2020 TSC!
 
Hi Brian,

Thanks for your well reasoned response.  I don't want to drag this down into a rat hole or spilt milk debate.  I was merely trying to point out the irony of lack of diversity in the TSC vs the other Hyperledger bodies.  The governing body by it's membership definition forces diversity and allows anyone with sufficient financial resources to have a seat at the table.  For Hyperledger projects to exit incubation they must show sufficient diversity of contributors, although that can be hard to measure as Ry has discovered in this last election process.  So it just seems a little odd to me that there aren't any diversity requirements for the TSC.  What would your response be if after the TSC elections next year, every member was employed by some organization that wasn't even a member of Hyperledger?  It is theoretically possible and given the voting process, i.e., who can vote, completely feasible.

You are correct in that the TSC members are individuals and not companies, but everyone one of them knows who butters their bread.  I also sense that there is some dissatisfaction over the common use of Hyperledger as some single thing when the reference is really referring to Fabric.  Fabric and Hyperledger when talking about projects are often used interchangeably.  For good or bad, this is likely a result of IBM's significant contributions to Fabric, and the ability for Fabric to run without specific hardware (sorry Mic!).  Having nearly half the TSC membership made up of individuals (not lost on me) working for one company (hopefully not lost on you), seems specious at best and doesn't help elevate the other Hyperledger projects to be on par with Fabric.

I also wonder at times about the role of the TSC as it seems that much of the TSC time is spent on things that aren't technical, at least not deeply so.  Is the whole project lifecycle debate a technical debate?  The current discussions about working groups and their roles really a technical issue the TSC should be debating?  I also wonder about what control or sway the TSC has on any project or should have on any project.  Are the Hyperledger projects just a bunch of technology projects with little intersection and no goal of convergence?  I mean every blockchain needs identity, but what is happening in the platforms to consolidate around an identity project such as Indy?  Likewise there are lots of issues around privacy and confidentiality, yet the privacy and confidentiality working group has serious concerns about what if any impact their work will have on the platforms.  If there is no impact, why should we continue the working group?  If there is no impact, what makes something a Hyperledger project other than the blessing of the TSC?  And why would a project want to join Hyperledger other than for the marketing value it brings if joining has effectively zero impact on the project direction?

Respectfully,
Todd

Christopher Ferris
 

Silas,

Thanks for your thoughtful note. I agree pretty much completely with all that you wrote.

I was also very pleased to read that you intend to stay engaged. You always bring a great perspective.

Cheers,

Chris


On Fri, Sep 20, 2019 at 7:40 AM Silas Davis via Lists.Hyperledger.Org <silas=monax.io@...> wrote:
From my experience of the people elected, the TSC looks like a good TSC.

I think we should enlarge the TSC as a tactical manoeuvre (which may not work) to nudge Hyperledger towards a more project-diverse TSC.

The preponderance of IBM employees is a symptom of the dominance of Fabric in Hyperledger and the relative dominance of IBM in the Fabric project as other's have pointed out. One can only vote for those one knows and Fabric contributors are a highly connected subset of Hyperledger. The solution (he says blithely) is for other projects to become more relevant (to those inside and outside Hyperledger), attract more contributors, and then to apply more democracy. Which is to say I don't think medicating the imbalance of the TSC directly is probably the right way to go.

However it is not a given that the positive feedback above will happen on its own given the inertia associated with project adoption, public mindshare, etc. It is hard to know where the momentum is with Hyperledger in this respect but some small interventions now might pay dividends later.

It's worth questioning whether having greater project/company diversity on the TSC is even a Good Thing. It's not like IBM or Fabric people are a homogeneous block. However I would suggest:

- Diversity of ideas - I think the well rehearsed ideas about avoiding groupthink etc apply here. Different projects are exploring different parts of the space of distributed ledgers useful to have these ideas injected.
- Representation of projects - so long as Hyperledger is a multiple project umbrella it is useful to have representation on decision-making boards that affect projects. The TSC may not be a house of representatives but seems that function is there
- Politics - occasionally decisions come up that have more commercial/ideological significance (i.e. whether to accept a new project), this is where a balance of forces are important particularly amongst cooperating competitors
- Competence - it is difficult for people with no exposure to a project's code or design outside of surveying it in order to answer a question coming to the TSC to decide on finely balanced technical matters. Usually the right thing to do is for the TSC to defer to those with more context. But having people experienced with a greater range of projects means those people can help spread that context to other TSC members aided by an existing relationship with those other TSC members.

For my part I was planning to stick around the TSC meetings and list despite no longer being a  member, the general prospect of which was noted by Mark and Arnaud on a previous call. However I would note that in the same way that getting elected to the TSC was a spur to apportion more of my time and effort to Hyperledger, losing the franchise does remove some of that impetus (although rather less since now I feel more involved) so even if TSC votes are rather consensual after discussions (as Arnaud noted) I would not discount the effect of the responsibility of being a bona fide TSC member as a human motivator to do more work.

Thinking about some of Todd's criticisms of the technical import of things discussed at the TSC. I would argue that things such as project lifecycle are relevant to the technical output of Hyperledger given software engineering is a team sport. I'd agree they are not deeply technical as defining a consensus interface or standardising on a choice of stream cipher might be. I too would like to see more deeply technical matters considered at the TSC, however I think the reason this is hard is the same as mentioned in the 'competence' bullet-point above. We generally need to be way more up inside each other's projects.

> There are well known techniques for this. We need to adopt them.

What are they?

> This is in addition to "who gets to participate in the election" which should be "everyone that contributes technical artifacts to Hyperledger"

How about a roll of credits stored as lines in a plain text file of the form `Date of contribution - nature of contribution` which could be stored in the repo and for which each commit adding a credit would need to be signed by a project maintainer or possibly existing contributor? This would put the definition of a contribution under the control of projects themselves.

Silas

On Mon, 9 Sep 2019 at 02:38, VIPIN BHARATHAN <vip@...> wrote:

Hi Brian/Todd/Bob/all,

It is unfortunate that the happy incidence of having gender diversity is tied  to the debate about over-representation of a single firm on the TSC. The result is more diversity in one dimension as we lose diversity in another.

A 33%  turnout is not good for both.  It has been shown that in a low turnout election, committed and well organized groups dominate. 

If gender diversity was the result of a 60+% turnout, it would have appeared "more real".
A 60+% turnout would have been better to justify the domination of a single firm on the TSC.  

Increasing turnout is also needed for truer democracy in general. Increasing turnout is quite difficult in this age of cynicism and apathy. How do we break through the ice? A question that needs to be answered through concrete steps for stimulating turnout in the next election. I had provided some pointers to the election officer, maybe a little too late. There are well known techniques for this. We need to adopt them.

This is in addition to "who gets to participate in the election" which should be "everyone that contributes technical artifacts to Hyperledger"; including the contributors on the wiki and the SIG participants in my view. The github query does not measure technical artifacts. I could contribute a single spelling correction in github and be included very easily; whereas someone who contributes only an extensive technical blog or article is excluded; if they are not on a Working Group list.

Best,
Vipin
 

dlt.nyc
Vipin Bharathan
Enterprise Blockchain Consultant


From: tsc@... <tsc@...> on behalf of Todd Little via Lists.Hyperledger.Org <todd.little=oracle.com@...>
Sent: Saturday, September 7, 2019 1:45 PM
To: tsc@... <tsc@...>
Cc: tsc@... <tsc@...>
Subject: Re: [Hyperledger TSC] Congratulations to the members of the 2019-2020 TSC!
 
Hi Brian,

Thanks for your well reasoned response.  I don't want to drag this down into a rat hole or spilt milk debate.  I was merely trying to point out the irony of lack of diversity in the TSC vs the other Hyperledger bodies.  The governing body by it's membership definition forces diversity and allows anyone with sufficient financial resources to have a seat at the table.  For Hyperledger projects to exit incubation they must show sufficient diversity of contributors, although that can be hard to measure as Ry has discovered in this last election process.  So it just seems a little odd to me that there aren't any diversity requirements for the TSC.  What would your response be if after the TSC elections next year, every member was employed by some organization that wasn't even a member of Hyperledger?  It is theoretically possible and given the voting process, i.e., who can vote, completely feasible.

You are correct in that the TSC members are individuals and not companies, but everyone one of them knows who butters their bread.  I also sense that there is some dissatisfaction over the common use of Hyperledger as some single thing when the reference is really referring to Fabric.  Fabric and Hyperledger when talking about projects are often used interchangeably.  For good or bad, this is likely a result of IBM's significant contributions to Fabric, and the ability for Fabric to run without specific hardware (sorry Mic!).  Having nearly half the TSC membership made up of individuals (not lost on me) working for one company (hopefully not lost on you), seems specious at best and doesn't help elevate the other Hyperledger projects to be on par with Fabric.

I also wonder at times about the role of the TSC as it seems that much of the TSC time is spent on things that aren't technical, at least not deeply so.  Is the whole project lifecycle debate a technical debate?  The current discussions about working groups and their roles really a technical issue the TSC should be debating?  I also wonder about what control or sway the TSC has on any project or should have on any project.  Are the Hyperledger projects just a bunch of technology projects with little intersection and no goal of convergence?  I mean every blockchain needs identity, but what is happening in the platforms to consolidate around an identity project such as Indy?  Likewise there are lots of issues around privacy and confidentiality, yet the privacy and confidentiality working group has serious concerns about what if any impact their work will have on the platforms.  If there is no impact, why should we continue the working group?  If there is no impact, what makes something a Hyperledger project other than the blessing of the TSC?  And why would a project want to join Hyperledger other than for the marketing value it brings if joining has effectively zero impact on the project direction?

Respectfully,
Todd

Duncan Johnston-Watt
 

+1. Didn't Silas get elected as a people's representative or something? Or am I making this up?

On Fri, Sep 20, 2019 at 6:26 AM Christopher Ferris <chris.ferris@...> wrote:
Silas,

Thanks for your thoughtful note. I agree pretty much completely with all that you wrote.

I was also very pleased to read that you intend to stay engaged. You always bring a great perspective.

Cheers,

Chris

On Fri, Sep 20, 2019 at 7:40 AM Silas Davis via Lists.Hyperledger.Org <silas=monax.io@...> wrote:
From my experience of the people elected, the TSC looks like a good TSC.

I think we should enlarge the TSC as a tactical manoeuvre (which may not work) to nudge Hyperledger towards a more project-diverse TSC.

The preponderance of IBM employees is a symptom of the dominance of Fabric in Hyperledger and the relative dominance of IBM in the Fabric project as other's have pointed out. One can only vote for those one knows and Fabric contributors are a highly connected subset of Hyperledger. The solution (he says blithely) is for other projects to become more relevant (to those inside and outside Hyperledger), attract more contributors, and then to apply more democracy. Which is to say I don't think medicating the imbalance of the TSC directly is probably the right way to go.

However it is not a given that the positive feedback above will happen on its own given the inertia associated with project adoption, public mindshare, etc. It is hard to know where the momentum is with Hyperledger in this respect but some small interventions now might pay dividends later.

It's worth questioning whether having greater project/company diversity on the TSC is even a Good Thing. It's not like IBM or Fabric people are a homogeneous block. However I would suggest:

- Diversity of ideas - I think the well rehearsed ideas about avoiding groupthink etc apply here. Different projects are exploring different parts of the space of distributed ledgers useful to have these ideas injected.
- Representation of projects - so long as Hyperledger is a multiple project umbrella it is useful to have representation on decision-making boards that affect projects. The TSC may not be a house of representatives but seems that function is there
- Politics - occasionally decisions come up that have more commercial/ideological significance (i.e. whether to accept a new project), this is where a balance of forces are important particularly amongst cooperating competitors
- Competence - it is difficult for people with no exposure to a project's code or design outside of surveying it in order to answer a question coming to the TSC to decide on finely balanced technical matters. Usually the right thing to do is for the TSC to defer to those with more context. But having people experienced with a greater range of projects means those people can help spread that context to other TSC members aided by an existing relationship with those other TSC members.

For my part I was planning to stick around the TSC meetings and list despite no longer being a  member, the general prospect of which was noted by Mark and Arnaud on a previous call. However I would note that in the same way that getting elected to the TSC was a spur to apportion more of my time and effort to Hyperledger, losing the franchise does remove some of that impetus (although rather less since now I feel more involved) so even if TSC votes are rather consensual after discussions (as Arnaud noted) I would not discount the effect of the responsibility of being a bona fide TSC member as a human motivator to do more work.

Thinking about some of Todd's criticisms of the technical import of things discussed at the TSC. I would argue that things such as project lifecycle are relevant to the technical output of Hyperledger given software engineering is a team sport. I'd agree they are not deeply technical as defining a consensus interface or standardising on a choice of stream cipher might be. I too would like to see more deeply technical matters considered at the TSC, however I think the reason this is hard is the same as mentioned in the 'competence' bullet-point above. We generally need to be way more up inside each other's projects.

> There are well known techniques for this. We need to adopt them.

What are they?

> This is in addition to "who gets to participate in the election" which should be "everyone that contributes technical artifacts to Hyperledger"

How about a roll of credits stored as lines in a plain text file of the form `Date of contribution - nature of contribution` which could be stored in the repo and for which each commit adding a credit would need to be signed by a project maintainer or possibly existing contributor? This would put the definition of a contribution under the control of projects themselves.

Silas

On Mon, 9 Sep 2019 at 02:38, VIPIN BHARATHAN <vip@...> wrote:

Hi Brian/Todd/Bob/all,

It is unfortunate that the happy incidence of having gender diversity is tied  to the debate about over-representation of a single firm on the TSC. The result is more diversity in one dimension as we lose diversity in another.

A 33%  turnout is not good for both.  It has been shown that in a low turnout election, committed and well organized groups dominate. 

If gender diversity was the result of a 60+% turnout, it would have appeared "more real".
A 60+% turnout would have been better to justify the domination of a single firm on the TSC.  

Increasing turnout is also needed for truer democracy in general. Increasing turnout is quite difficult in this age of cynicism and apathy. How do we break through the ice? A question that needs to be answered through concrete steps for stimulating turnout in the next election. I had provided some pointers to the election officer, maybe a little too late. There are well known techniques for this. We need to adopt them.

This is in addition to "who gets to participate in the election" which should be "everyone that contributes technical artifacts to Hyperledger"; including the contributors on the wiki and the SIG participants in my view. The github query does not measure technical artifacts. I could contribute a single spelling correction in github and be included very easily; whereas someone who contributes only an extensive technical blog or article is excluded; if they are not on a Working Group list.

Best,
Vipin
 

dlt.nyc
Vipin Bharathan
Enterprise Blockchain Consultant


From: tsc@... <tsc@...> on behalf of Todd Little via Lists.Hyperledger.Org <todd.little=oracle.com@...>
Sent: Saturday, September 7, 2019 1:45 PM
To: tsc@... <tsc@...>
Cc: tsc@... <tsc@...>
Subject: Re: [Hyperledger TSC] Congratulations to the members of the 2019-2020 TSC!
 
Hi Brian,

Thanks for your well reasoned response.  I don't want to drag this down into a rat hole or spilt milk debate.  I was merely trying to point out the irony of lack of diversity in the TSC vs the other Hyperledger bodies.  The governing body by it's membership definition forces diversity and allows anyone with sufficient financial resources to have a seat at the table.  For Hyperledger projects to exit incubation they must show sufficient diversity of contributors, although that can be hard to measure as Ry has discovered in this last election process.  So it just seems a little odd to me that there aren't any diversity requirements for the TSC.  What would your response be if after the TSC elections next year, every member was employed by some organization that wasn't even a member of Hyperledger?  It is theoretically possible and given the voting process, i.e., who can vote, completely feasible.

You are correct in that the TSC members are individuals and not companies, but everyone one of them knows who butters their bread.  I also sense that there is some dissatisfaction over the common use of Hyperledger as some single thing when the reference is really referring to Fabric.  Fabric and Hyperledger when talking about projects are often used interchangeably.  For good or bad, this is likely a result of IBM's significant contributions to Fabric, and the ability for Fabric to run without specific hardware (sorry Mic!).  Having nearly half the TSC membership made up of individuals (not lost on me) working for one company (hopefully not lost on you), seems specious at best and doesn't help elevate the other Hyperledger projects to be on par with Fabric.

I also wonder at times about the role of the TSC as it seems that much of the TSC time is spent on things that aren't technical, at least not deeply so.  Is the whole project lifecycle debate a technical debate?  The current discussions about working groups and their roles really a technical issue the TSC should be debating?  I also wonder about what control or sway the TSC has on any project or should have on any project.  Are the Hyperledger projects just a bunch of technology projects with little intersection and no goal of convergence?  I mean every blockchain needs identity, but what is happening in the platforms to consolidate around an identity project such as Indy?  Likewise there are lots of issues around privacy and confidentiality, yet the privacy and confidentiality working group has serious concerns about what if any impact their work will have on the platforms.  If there is no impact, why should we continue the working group?  If there is no impact, what makes something a Hyperledger project other than the blessing of the TSC?  And why would a project want to join Hyperledger other than for the marketing value it brings if joining has effectively zero impact on the project direction?

Respectfully,
Todd



Christopher Ferris
 

Silas for the people, 2020!

Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
IBM Digital Business Group, Open Technologies
email: chrisfer@...
twitter: @christo4ferris

On Sep 20, 2019, at 9:46 AM, Duncan Johnston-Watt <duncan@...> wrote:

+1. Didn't Silas get elected as a people's representative or something? Or am I making this up?

On Fri, Sep 20, 2019 at 6:26 AM Christopher Ferris <chris.ferris@...> wrote:
Silas,

Thanks for your thoughtful note. I agree pretty much completely with all that you wrote.

I was also very pleased to read that you intend to stay engaged. You always bring a great perspective.

Cheers,

Chris

On Fri, Sep 20, 2019 at 7:40 AM Silas Davis via Lists.Hyperledger.Org <silas=monax.io@...> wrote:
From my experience of the people elected, the TSC looks like a good TSC.

I think we should enlarge the TSC as a tactical manoeuvre (which may not work) to nudge Hyperledger towards a more project-diverse TSC.

The preponderance of IBM employees is a symptom of the dominance of Fabric in Hyperledger and the relative dominance of IBM in the Fabric project as other's have pointed out. One can only vote for those one knows and Fabric contributors are a highly connected subset of Hyperledger. The solution (he says blithely) is for other projects to become more relevant (to those inside and outside Hyperledger), attract more contributors, and then to apply more democracy. Which is to say I don't think medicating the imbalance of the TSC directly is probably the right way to go.

However it is not a given that the positive feedback above will happen on its own given the inertia associated with project adoption, public mindshare, etc. It is hard to know where the momentum is with Hyperledger in this respect but some small interventions now might pay dividends later.

It's worth questioning whether having greater project/company diversity on the TSC is even a Good Thing. It's not like IBM or Fabric people are a homogeneous block. However I would suggest:

- Diversity of ideas - I think the well rehearsed ideas about avoiding groupthink etc apply here. Different projects are exploring different parts of the space of distributed ledgers useful to have these ideas injected.
- Representation of projects - so long as Hyperledger is a multiple project umbrella it is useful to have representation on decision-making boards that affect projects. The TSC may not be a house of representatives but seems that function is there
- Politics - occasionally decisions come up that have more commercial/ideological significance (i.e. whether to accept a new project), this is where a balance of forces are important particularly amongst cooperating competitors
- Competence - it is difficult for people with no exposure to a project's code or design outside of surveying it in order to answer a question coming to the TSC to decide on finely balanced technical matters. Usually the right thing to do is for the TSC to defer to those with more context. But having people experienced with a greater range of projects means those people can help spread that context to other TSC members aided by an existing relationship with those other TSC members.

For my part I was planning to stick around the TSC meetings and list despite no longer being a  member, the general prospect of which was noted by Mark and Arnaud on a previous call. However I would note that in the same way that getting elected to the TSC was a spur to apportion more of my time and effort to Hyperledger, losing the franchise does remove some of that impetus (although rather less since now I feel more involved) so even if TSC votes are rather consensual after discussions (as Arnaud noted) I would not discount the effect of the responsibility of being a bona fide TSC member as a human motivator to do more work.

Thinking about some of Todd's criticisms of the technical import of things discussed at the TSC. I would argue that things such as project lifecycle are relevant to the technical output of Hyperledger given software engineering is a team sport. I'd agree they are not deeply technical as defining a consensus interface or standardising on a choice of stream cipher might be. I too would like to see more deeply technical matters considered at the TSC, however I think the reason this is hard is the same as mentioned in the 'competence' bullet-point above. We generally need to be way more up inside each other's projects.

> There are well known techniques for this. We need to adopt them.

What are they?

> This is in addition to "who gets to participate in the election" which should be "everyone that contributes technical artifacts to Hyperledger"

How about a roll of credits stored as lines in a plain text file of the form `Date of contribution - nature of contribution` which could be stored in the repo and for which each commit adding a credit would need to be signed by a project maintainer or possibly existing contributor? This would put the definition of a contribution under the control of projects themselves.

Silas

On Mon, 9 Sep 2019 at 02:38, VIPIN BHARATHAN <vip@...> wrote:

Hi Brian/Todd/Bob/all,

It is unfortunate that the happy incidence of having gender diversity is tied  to the debate about over-representation of a single firm on the TSC. The result is more diversity in one dimension as we lose diversity in another.

A 33%  turnout is not good for both.  It has been shown that in a low turnout election, committed and well organized groups dominate. 

If gender diversity was the result of a 60+% turnout, it would have appeared "more real".
A 60+% turnout would have been better to justify the domination of a single firm on the TSC.  

Increasing turnout is also needed for truer democracy in general. Increasing turnout is quite difficult in this age of cynicism and apathy. How do we break through the ice? A question that needs to be answered through concrete steps for stimulating turnout in the next election. I had provided some pointers to the election officer, maybe a little too late. There are well known techniques for this. We need to adopt them.

This is in addition to "who gets to participate in the election" which should be "everyone that contributes technical artifacts to Hyperledger"; including the contributors on the wiki and the SIG participants in my view. The github query does not measure technical artifacts. I could contribute a single spelling correction in github and be included very easily; whereas someone who contributes only an extensive technical blog or article is excluded; if they are not on a Working Group list.

Best,
Vipin
 

Vipin Bharathan
Enterprise Blockchain Consultant


From: tsc@... <tsc@...> on behalf of Todd Little via Lists.Hyperledger.Org <todd.little=oracle.com@...>
Sent: Saturday, September 7, 2019 1:45 PM
To: tsc@... <tsc@...>
Cc: tsc@... <tsc@...>
Subject: Re: [Hyperledger TSC] Congratulations to the members of the 2019-2020 TSC!
 
Hi Brian,

Thanks for your well reasoned response.  I don't want to drag this down into a rat hole or spilt milk debate.  I was merely trying to point out the irony of lack of diversity in the TSC vs the other Hyperledger bodies.  The governing body by it's membership definition forces diversity and allows anyone with sufficient financial resources to have a seat at the table.  For Hyperledger projects to exit incubation they must show sufficient diversity of contributors, although that can be hard to measure as Ry has discovered in this last election process.  So it just seems a little odd to me that there aren't any diversity requirements for the TSC.  What would your response be if after the TSC elections next year, every member was employed by some organization that wasn't even a member of Hyperledger?  It is theoretically possible and given the voting process, i.e., who can vote, completely feasible.

You are correct in that the TSC members are individuals and not companies, but everyone one of them knows who butters their bread.  I also sense that there is some dissatisfaction over the common use of Hyperledger as some single thing when the reference is really referring to Fabric.  Fabric and Hyperledger when talking about projects are often used interchangeably.  For good or bad, this is likely a result of IBM's significant contributions to Fabric, and the ability for Fabric to run without specific hardware (sorry Mic!).  Having nearly half the TSC membership made up of individuals (not lost on me) working for one company (hopefully not lost on you), seems specious at best and doesn't help elevate the other Hyperledger projects to be on par with Fabric.

I also wonder at times about the role of the TSC as it seems that much of the TSC time is spent on things that aren't technical, at least not deeply so.  Is the whole project lifecycle debate a technical debate?  The current discussions about working groups and their roles really a technical issue the TSC should be debating?  I also wonder about what control or sway the TSC has on any project or should have on any project.  Are the Hyperledger projects just a bunch of technology projects with little intersection and no goal of convergence?  I mean every blockchain needs identity, but what is happening in the platforms to consolidate around an identity project such as Indy?  Likewise there are lots of issues around privacy and confidentiality, yet the privacy and confidentiality working group has serious concerns about what if any impact their work will have on the platforms.  If there is no impact, why should we continue the working group?  If there is no impact, what makes something a Hyperledger project other than the blessing of the TSC?  And why would a project want to join Hyperledger other than for the marketing value it brings if joining has effectively zero impact on the project direction?

Respectfully,
Todd



--

Vipin Bharathan
 

Silas,

Thanks for a detailed response
> There are well known techniques for this. We need to adopt them.
>What are they?

For example, (from "Nudge") - it is shown that reminders during the election unfavorably comparing the current turnout to global averages raises the turnout. Reachability is very important as well. The eligibility lists should be probed for reachability at well publicized intervals. Let us come up with some methods that may apply in our case.

>How about a roll of credits stored as lines in a plain text file of the form `Date of contribution - nature of contribution` which could be stored in the repo and for which each commit adding a credit would need to be signed by a project maintainer or possibly existing contributor? This would put the definition of a contribution under the control of projects themselves.  

This goes back to the idea that only code contributions matter- please broaden your outlook on what "technical contributions" are. Also this signed list will be extremely difficult to maintain. Right now, even the equivalent of a "touch" (I am exaggerating here) can get you into the rolls. Which is OK.

Vipin


On Fri, Sep 20, 2019 at 7:40 AM Silas Davis <silas@...> wrote:
From my experience of the people elected, the TSC looks like a good TSC.

I think we should enlarge the TSC as a tactical manoeuvre (which may not work) to nudge Hyperledger towards a more project-diverse TSC.

The preponderance of IBM employees is a symptom of the dominance of Fabric in Hyperledger and the relative dominance of IBM in the Fabric project as other's have pointed out. One can only vote for those one knows and Fabric contributors are a highly connected subset of Hyperledger. The solution (he says blithely) is for other projects to become more relevant (to those inside and outside Hyperledger), attract more contributors, and then to apply more democracy. Which is to say I don't think medicating the imbalance of the TSC directly is probably the right way to go.

However it is not a given that the positive feedback above will happen on its own given the inertia associated with project adoption, public mindshare, etc. It is hard to know where the momentum is with Hyperledger in this respect but some small interventions now might pay dividends later.

It's worth questioning whether having greater project/company diversity on the TSC is even a Good Thing. It's not like IBM or Fabric people are a homogeneous block. However I would suggest:

- Diversity of ideas - I think the well rehearsed ideas about avoiding groupthink etc apply here. Different projects are exploring different parts of the space of distributed ledgers useful to have these ideas injected.
- Representation of projects - so long as Hyperledger is a multiple project umbrella it is useful to have representation on decision-making boards that affect projects. The TSC may not be a house of representatives but seems that function is there
- Politics - occasionally decisions come up that have more commercial/ideological significance (i.e. whether to accept a new project), this is where a balance of forces are important particularly amongst cooperating competitors
- Competence - it is difficult for people with no exposure to a project's code or design outside of surveying it in order to answer a question coming to the TSC to decide on finely balanced technical matters. Usually the right thing to do is for the TSC to defer to those with more context. But having people experienced with a greater range of projects means those people can help spread that context to other TSC members aided by an existing relationship with those other TSC members.

For my part I was planning to stick around the TSC meetings and list despite no longer being a  member, the general prospect of which was noted by Mark and Arnaud on a previous call. However I would note that in the same way that getting elected to the TSC was a spur to apportion more of my time and effort to Hyperledger, losing the franchise does remove some of that impetus (although rather less since now I feel more involved) so even if TSC votes are rather consensual after discussions (as Arnaud noted) I would not discount the effect of the responsibility of being a bona fide TSC member as a human motivator to do more work.

Thinking about some of Todd's criticisms of the technical import of things discussed at the TSC. I would argue that things such as project lifecycle are relevant to the technical output of Hyperledger given software engineering is a team sport. I'd agree they are not deeply technical as defining a consensus interface or standardising on a choice of stream cipher might be. I too would like to see more deeply technical matters considered at the TSC, however I think the reason this is hard is the same as mentioned in the 'competence' bullet-point above. We generally need to be way more up inside each other's projects.

> There are well known techniques for this. We need to adopt them.

What are they?

> This is in addition to "who gets to participate in the election" which should be "everyone that contributes technical artifacts to Hyperledger"

How about a roll of credits stored as lines in a plain text file of the form `Date of contribution - nature of contribution` which could be stored in the repo and for which each commit adding a credit would need to be signed by a project maintainer or possibly existing contributor? This would put the definition of a contribution under the control of projects themselves.

Silas

On Mon, 9 Sep 2019 at 02:38, VIPIN BHARATHAN <vip@...> wrote:

Hi Brian/Todd/Bob/all,

It is unfortunate that the happy incidence of having gender diversity is tied  to the debate about over-representation of a single firm on the TSC. The result is more diversity in one dimension as we lose diversity in another.

A 33%  turnout is not good for both.  It has been shown that in a low turnout election, committed and well organized groups dominate. 

If gender diversity was the result of a 60+% turnout, it would have appeared "more real".
A 60+% turnout would have been better to justify the domination of a single firm on the TSC.  

Increasing turnout is also needed for truer democracy in general. Increasing turnout is quite difficult in this age of cynicism and apathy. How do we break through the ice? A question that needs to be answered through concrete steps for stimulating turnout in the next election. I had provided some pointers to the election officer, maybe a little too late. There are well known techniques for this. We need to adopt them.

This is in addition to "who gets to participate in the election" which should be "everyone that contributes technical artifacts to Hyperledger"; including the contributors on the wiki and the SIG participants in my view. The github query does not measure technical artifacts. I could contribute a single spelling correction in github and be included very easily; whereas someone who contributes only an extensive technical blog or article is excluded; if they are not on a Working Group list.

Best,
Vipin
 

dlt.nyc
Vipin Bharathan
Enterprise Blockchain Consultant


From: tsc@... <tsc@...> on behalf of Todd Little via Lists.Hyperledger.Org <todd.little=oracle.com@...>
Sent: Saturday, September 7, 2019 1:45 PM
To: tsc@... <tsc@...>
Cc: tsc@... <tsc@...>
Subject: Re: [Hyperledger TSC] Congratulations to the members of the 2019-2020 TSC!
 
Hi Brian,

Thanks for your well reasoned response.  I don't want to drag this down into a rat hole or spilt milk debate.  I was merely trying to point out the irony of lack of diversity in the TSC vs the other Hyperledger bodies.  The governing body by it's membership definition forces diversity and allows anyone with sufficient financial resources to have a seat at the table.  For Hyperledger projects to exit incubation they must show sufficient diversity of contributors, although that can be hard to measure as Ry has discovered in this last election process.  So it just seems a little odd to me that there aren't any diversity requirements for the TSC.  What would your response be if after the TSC elections next year, every member was employed by some organization that wasn't even a member of Hyperledger?  It is theoretically possible and given the voting process, i.e., who can vote, completely feasible.

You are correct in that the TSC members are individuals and not companies, but everyone one of them knows who butters their bread.  I also sense that there is some dissatisfaction over the common use of Hyperledger as some single thing when the reference is really referring to Fabric.  Fabric and Hyperledger when talking about projects are often used interchangeably.  For good or bad, this is likely a result of IBM's significant contributions to Fabric, and the ability for Fabric to run without specific hardware (sorry Mic!).  Having nearly half the TSC membership made up of individuals (not lost on me) working for one company (hopefully not lost on you), seems specious at best and doesn't help elevate the other Hyperledger projects to be on par with Fabric.

I also wonder at times about the role of the TSC as it seems that much of the TSC time is spent on things that aren't technical, at least not deeply so.  Is the whole project lifecycle debate a technical debate?  The current discussions about working groups and their roles really a technical issue the TSC should be debating?  I also wonder about what control or sway the TSC has on any project or should have on any project.  Are the Hyperledger projects just a bunch of technology projects with little intersection and no goal of convergence?  I mean every blockchain needs identity, but what is happening in the platforms to consolidate around an identity project such as Indy?  Likewise there are lots of issues around privacy and confidentiality, yet the privacy and confidentiality working group has serious concerns about what if any impact their work will have on the platforms.  If there is no impact, why should we continue the working group?  If there is no impact, what makes something a Hyperledger project other than the blessing of the TSC?  And why would a project want to join Hyperledger other than for the marketing value it brings if joining has effectively zero impact on the project direction?

Respectfully,
Todd

Shawn Amundson
 

On Fri, Sep 20, 2019 at 12:32 PM Vipin Bharathan <vipinsun@...> wrote:
...

This goes back to the idea that only code contributions matter- please broaden your outlook on what "technical contributions" are. Also this signed list will be extremely difficult to maintain. Right now, even the equivalent of a "touch" (I am exaggerating here) can get you into the rolls. Which is OK.
 
...

No, let's not broaden it. Let's not try and lessen the value of the hard work done by developers. Code contributions are what moves the projects forward. If you are doing architecture or design work that makes it into the code, but someone else did the coding and commits, yes, you contributed. Probably your designs should have been committed to git as RFCs or similar. If you can't make that connection, it should not be considered the same thing. Meeting attendance, for example, is irrelevant.

-Shawn

Mohan Venkataraman
 

Glad to welcome the new TSC. 

Just my two cents in this ongoing email.
Should all paying members also have some small voting opportunity in addition to code contributors. Its their money that fuels some of the work. While its technical, there is plrnty of commercial interest in this noble work.

Mohan



On Sat, Sep 21, 2019, 12:37 AM Shawn Amundson <amundson@...> wrote:
On Fri, Sep 20, 2019 at 12:32 PM Vipin Bharathan <vipinsun@...> wrote:
...

This goes back to the idea that only code contributions matter- please broaden your outlook on what "technical contributions" are. Also this signed list will be extremely difficult to maintain. Right now, even the equivalent of a "touch" (I am exaggerating here) can get you into the rolls. Which is OK.
 
...

No, let's not broaden it. Let's not try and lessen the value of the hard work done by developers. Code contributions are what moves the projects forward. If you are doing architecture or design work that makes it into the code, but someone else did the coding and commits, yes, you contributed. Probably your designs should have been committed to git as RFCs or similar. If you can't make that connection, it should not be considered the same thing. Meeting attendance, for example, is irrelevant.

-Shawn

Silas Davis
 

> +1. Didn't Silas get elected as a people's representative or something? Or am I making this up?
> Silas for the people, 2020!

Ha. I'm thinking of taking a run for British PM, populist demagoguery is in right now.

> This goes back to the idea that only code contributions matter

Not the intention of the suggestion, just that the code repos be the canonical source of truth for such things, the credits would just be a log stored there. I agree it could be a burden to maintain but then so are changelogs. For that matter, maybe adding credits with the changelog would be a better place to do it rather than introducing another thing. The point is to provide a canonical location for providing credit to contributions that are not code, have it defined by project maintainers, and keep it easy to harvest when generating the electoral roll. Just an idea I haven't thought through the implications thoroughly.

> No, let's not broaden it. Let's not try and lessen the value of the hard work done by developers. Code contributions are what moves the projects forward.

I think I conditionally agree with this. It's not that I would want to devalue non-code contributions, but if Hyperledger is an organisation for implementations _not_ a standards or research organisation then I think it is a reasonable (if imperfect) indicator of the practical value of non-code contributions if there is evidence for them in the form of some checked-in artefact. If there is some serious cross-project technical work embedded on the wiki then I can see the unfairness of it not being considered a contribution, but on the other hand I think a wiki 'touch' is too low a bar. At least with a PR it has been accepted by a maintainer. That said I have received a number of really trivial text corrections of very low value which I suspect may have been to gain classification as a contributor or possibly just contribution farming for CV purposes... Not sure what the right answer is here.

> Should all paying members also have some small voting opportunity in addition to code contributors.

Not at all keen on deliberately building a plutocracy. People are willing to make out-sized contributions because Hyperledger just about manages to be a grass-roots open source engineering organisation. If it was so explicitly 'run by the money' this would put me and many contributors I know off Hyperledger.

> Its their money that fuels some of the work.

Not really. Hyperledger tries to act as catalyst but they don't buy my dinner, that would be my employer. Members already get benefit from the access to events, developers, information, the free software itself.

Silas


On Sat, 21 Sep 2019 at 02:41, Mohan Venkataraman <mohan.venkataraman@...> wrote:
Glad to welcome the new TSC. 

Just my two cents in this ongoing email.
Should all paying members also have some small voting opportunity in addition to code contributors. Its their money that fuels some of the work. While its technical, there is plrnty of commercial interest in this noble work.

Mohan



On Sat, Sep 21, 2019, 12:37 AM Shawn Amundson <amundson@...> wrote:
On Fri, Sep 20, 2019 at 12:32 PM Vipin Bharathan <vipinsun@...> wrote:
...

This goes back to the idea that only code contributions matter- please broaden your outlook on what "technical contributions" are. Also this signed list will be extremely difficult to maintain. Right now, even the equivalent of a "touch" (I am exaggerating here) can get you into the rolls. Which is OK.
 
...

No, let's not broaden it. Let's not try and lessen the value of the hard work done by developers. Code contributions are what moves the projects forward. If you are doing architecture or design work that makes it into the code, but someone else did the coding and commits, yes, you contributed. Probably your designs should have been committed to git as RFCs or similar. If you can't make that connection, it should not be considered the same thing. Meeting attendance, for example, is irrelevant.

-Shawn