Date   

Re: Congratulations to the members of the 2019-2020 TSC!

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


Proposal: remove pinned repo list on GitHub

Ry Jones
 

GitHub has a limit of six pinned repos. When we added these pins, we didn't have six top level projects. Now we have over six.

I propose to either pin one repo - this one - or none at all.

CNCF has three repos, for instance.

I would prefer to unpin all repos, and later decide if we would like to pin one or two more general repos.
Ry

--
Ry Jones
Community Architect, Hyperledger


Re: Congratulations to the members of the 2019-2020 TSC!

Christopher Ferris <chrisfer@...>
 

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



--


Re: Congratulations to the members of the 2019-2020 TSC!

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




Re: Congratulations to the members of the 2019-2020 TSC!

Christopher Ferris <chris.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


Re: Congratulations to the members of the 2019-2020 TSC!

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


Upcoming Event: Hyperledger Caliper Quarterly Update Due #tsc-project-update - Thu, 09/26/2019 #tsc-project-update #cal-reminder

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Reminder: Hyperledger Caliper Quarterly Update Due #tsc-project-update

When: Thursday, 26 September 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Caliper update to the TSC was due 23 September, 2019, and it will be presented to the TSC on 26 September, 2019. Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


Sep 19 TSC call canceled

Arnaud Le Hors
 

Hi all,
I apologize for the late notice but I'm going to cancel this week's call due to a combination of a light agenda and logistical challenges on my end.

I do want to point out that several quarterly reports are overdue. And I encourage TSC members to chime in on the various open issues so that we can make progress towards proposed resolutions that can be brought up to the TSC for approval. See: https://wiki.hyperledger.org/display/HYP/Pending+topics+for+the+TSC
Thanks.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM


Re: working groups

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

Hi Everyone,

 

Some points on this:

 

I don’t think it matters what we name these groups.  If we want to keep the name of “working group,” that’s fine.

 

The main point we have noticed is that long-term, work-product focused groups haven’t really worked.  So we want to subdivide into two things:  non-work product-focused groups that are long-term, and short-term work product-focused groups that have clear deliverables and a clear timeframe.  We would call the first “working groups” and the second “task forces.”  This is more or less what is written in the proposal.

 

Active maintainers and contributors are going to be more likely to put work into short efforts with clear timeframes and outcomes, even if there is a distinct possibility of failure.  So I think task forces are our best shot at getting cross-project collaboration and integration.  We can set bite-sized goals and tackle things little by little.

 

In an ideal world, the non-work product-focused groups can function as “motherships” that “spin off” task forces.

 

If you’ve made it this far, thanks for reading my rambling email. 

 

Thanks,

Hart

 

From: tsc@... [mailto:tsc@...] On Behalf Of Mic Bowman
Sent: Friday, September 13, 2019 9:48 AM
To: Brian Behlendorf <bbehlendorf@...>
Cc: Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] working groups

 

 

> I believe if we set the expectation that the working groups be 

> driven by the projects themselves - that is, the rationale for 

> their formation, the bulk of activity, the work products created - 

> come from active maintainers and developers on the existing 

> projects, and not from people who are not writing code, that will 

> self-regulate the number well and I believe give them more

> implicit teeth.  

 

Given where we're at for project participation in working groups... i think this effectively kills working groups (which at this point is a good thing IMO). cross project collaboration doesn't require a working group; in places where it is appropriate it is already happening. the work being done in working groups right now has little impact on the projects themselves. 

 

And I don't really care if we call the "discussive" form a working group or a SIG (its just a label). But... drop expectations of work products from them (move all work product focused activity to a task force that can complete a focused, time-bounded effort.. these have been very successful). Hart suggested quarterly (too frequent) or yearly (probably not frequent enough) reports on who's been participating & what's been discussed is sufficient.

 

--mic

 

 

On Thu, Sep 12, 2019 at 11:21 PM Brian Behlendorf <bbehlendorf@...> wrote:

Please please please let's not call them SIGs! For the sake of avoiding confusion with the existing SIGs and their reporting structure.   I realize that we use WG in a slightly non-standard way compared to other orgs, but if we have ongoing persistent cross-project thematically-organized groups, let's keep calling them Working Groups, OK?  Adding time-bound tightly scoped Task Forces is fine (and what we're already doing, essentially).  Too much semantic thrash makes it difficult to keep everyone on board, is my main point.

 

I am for considering cutting down on the number of Working Groups by rebooting from zero and re-chartering.  I believe if we set the expectation that the working groups be driven by the projects themselves - that is, the rationale for their formation, the bulk of activity, the work products created - come from active maintainers and developers on the existing projects, and not from people who are not writing code, that will self-regulate the number well and I believe give them more implicit teeth.  Imagine restarting from zero WGs, and saying to add a new one, there must be not just interest but commitment from a majority of projects to have at least a representative attend and use it to coordinate their related efforts.  E.g., if the projects don't care enough about coordinating cross-project around the topic of Architecture or Identity to ensure they are involved and attending the calls and participating in conversations and aligning their dev roadmaps, then don't create it.  We need some form of cross-project info sharing outside the context of TSC calls, thematically scoped and ongoing, but not so many that efforts are diffused or fail to hit critical mass. I think that would address criticisms of the WG model to date.

 

Brian

 

On 9/12/19 9:22 AM, Mic Bowman wrote:

per the brief discussion in the TSC this morning, the core proposal from the WG task force is that we replace working groups with technology focused SIGs (where discussions happen) and task forces focused on a short term deliverable (where the deliverable must be completed in less than 6 months, for example). 

 

the list of proposals is here:

 

please comment (and, while we have withdrawn proposals 1 and 2, please read the discussion on them for context). 

 

specifically... here's where we're at:

 

  • Proposal 3: Working groups should be dropped.
  • Proposal 4: Formalize "task force" as a task-specific group with limited scope and fixed time to complete.
  • Proposal 5: A task-force will be required to create a "proposal" and the TSC must approve the proposal.
  • Proposal 6: The task-force leader will be required to report on completion of deliverables.
  • Proposal 7: A task-force that requires additional time, must request an extension from the TSC.
  • Proposal 8: Existing working groups will be converted into a technology focused SIG.

--mic

 

 

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


Re: working groups

Mic Bowman
 


> I believe if we set the expectation that the working groups be 
> driven by the projects themselves - that is, the rationale for 
> their formation, the bulk of activity, the work products created - 
> come from active maintainers and developers on the existing 
> projects, and not from people who are not writing code, that will 
> self-regulate the number well and I believe give them more
> implicit teeth.  

Given where we're at for project participation in working groups... i think this effectively kills working groups (which at this point is a good thing IMO). cross project collaboration doesn't require a working group; in places where it is appropriate it is already happening. the work being done in working groups right now has little impact on the projects themselves. 

And I don't really care if we call the "discussive" form a working group or a SIG (its just a label). But... drop expectations of work products from them (move all work product focused activity to a task force that can complete a focused, time-bounded effort.. these have been very successful). Hart suggested quarterly (too frequent) or yearly (probably not frequent enough) reports on who's been participating & what's been discussed is sufficient.

--mic


On Thu, Sep 12, 2019 at 11:21 PM Brian Behlendorf <bbehlendorf@...> wrote:
Please please please let's not call them SIGs! For the sake of avoiding confusion with the existing SIGs and their reporting structure.   I realize that we use WG in a slightly non-standard way compared to other orgs, but if we have ongoing persistent cross-project thematically-organized groups, let's keep calling them Working Groups, OK?  Adding time-bound tightly scoped Task Forces is fine (and what we're already doing, essentially).  Too much semantic thrash makes it difficult to keep everyone on board, is my main point.

I am for considering cutting down on the number of Working Groups by rebooting from zero and re-chartering.  I believe if we set the expectation that the working groups be driven by the projects themselves - that is, the rationale for their formation, the bulk of activity, the work products created - come from active maintainers and developers on the existing projects, and not from people who are not writing code, that will self-regulate the number well and I believe give them more implicit teeth.  Imagine restarting from zero WGs, and saying to add a new one, there must be not just interest but commitment from a majority of projects to have at least a representative attend and use it to coordinate their related efforts.  E.g., if the projects don't care enough about coordinating cross-project around the topic of Architecture or Identity to ensure they are involved and attending the calls and participating in conversations and aligning their dev roadmaps, then don't create it.  We need some form of cross-project info sharing outside the context of TSC calls, thematically scoped and ongoing, but not so many that efforts are diffused or fail to hit critical mass. I think that would address criticisms of the WG model to date.

Brian

On 9/12/19 9:22 AM, Mic Bowman wrote:
per the brief discussion in the TSC this morning, the core proposal from the WG task force is that we replace working groups with technology focused SIGs (where discussions happen) and task forces focused on a short term deliverable (where the deliverable must be completed in less than 6 months, for example). 

the list of proposals is here:

please comment (and, while we have withdrawn proposals 1 and 2, please read the discussion on them for context). 

specifically... here's where we're at:

  • Proposal 3: Working groups should be dropped.
  • Proposal 4: Formalize "task force" as a task-specific group with limited scope and fixed time to complete.
  • Proposal 5: A task-force will be required to create a "proposal" and the TSC must approve the proposal.
  • Proposal 6: The task-force leader will be required to report on completion of deliverables.
  • Proposal 7: A task-force that requires additional time, must request an extension from the TSC.
  • Proposal 8: Existing working groups will be converted into a technology focused SIG.
--mic


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


Re: working groups

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

I agree with this idea of rebooting anything not formed in the last 6 months and structuring them around a clear time-bounded deliverable based on project involvement.

 

Dan

 

From: <tsc@...> on behalf of Brian Behlendorf <bbehlendorf@...>
Date: Friday, September 13, 2019 at 9:21 AM
To: "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] working groups

 

Please please please let's not call them SIGs! For the sake of avoiding confusion with the existing SIGs and their reporting structure.   I realize that we use WG in a slightly non-standard way compared to other orgs, but if we have ongoing persistent cross-project thematically-organized groups, let's keep calling them Working Groups, OK?  Adding time-bound tightly scoped Task Forces is fine (and what we're already doing, essentially).  Too much semantic thrash makes it difficult to keep everyone on board, is my main point.

 

I am for considering cutting down on the number of Working Groups by rebooting from zero and re-chartering.  I believe if we set the expectation that the working groups be driven by the projects themselves - that is, the rationale for their formation, the bulk of activity, the work products created - come from active maintainers and developers on the existing projects, and not from people who are not writing code, that will self-regulate the number well and I believe give them more implicit teeth.  Imagine restarting from zero WGs, and saying to add a new one, there must be not just interest but commitment from a majority of projects to have at least a representative attend and use it to coordinate their related efforts.  E.g., if the projects don't care enough about coordinating cross-project around the topic of Architecture or Identity to ensure they are involved and attending the calls and participating in conversations and aligning their dev roadmaps, then don't create it.  We need some form of cross-project info sharing outside the context of TSC calls, thematically scoped and ongoing, but not so many that efforts are diffused or fail to hit critical mass. I think that would address criticisms of the WG model to date.

 

Brian

 

On 9/12/19 9:22 AM, Mic Bowman wrote:

per the brief discussion in the TSC this morning, the core proposal from the WG task force is that we replace working groups with technology focused SIGs (where discussions happen) and task forces focused on a short term deliverable (where the deliverable must be completed in less than 6 months, for example). 

 

the list of proposals is here:

 

please comment (and, while we have withdrawn proposals 1 and 2, please read the discussion on them for context). 

 

specifically... here's where we're at:

 

  • Proposal 3: Working groups should be dropped.
  • Proposal 4: Formalize "task force" as a task-specific group with limited scope and fixed time to complete.
  • Proposal 5: A task-force will be required to create a "proposal" and the TSC must approve the proposal.
  • Proposal 6: The task-force leader will be required to report on completion of deliverables.
  • Proposal 7: A task-force that requires additional time, must request an extension from the TSC.
  • Proposal 8: Existing working groups will be converted into a technology focused SIG.

--mic

 

 

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


Re: working groups

Brian Behlendorf
 

Please please please let's not call them SIGs! For the sake of avoiding confusion with the existing SIGs and their reporting structure.   I realize that we use WG in a slightly non-standard way compared to other orgs, but if we have ongoing persistent cross-project thematically-organized groups, let's keep calling them Working Groups, OK?  Adding time-bound tightly scoped Task Forces is fine (and what we're already doing, essentially).  Too much semantic thrash makes it difficult to keep everyone on board, is my main point.

I am for considering cutting down on the number of Working Groups by rebooting from zero and re-chartering.  I believe if we set the expectation that the working groups be driven by the projects themselves - that is, the rationale for their formation, the bulk of activity, the work products created - come from active maintainers and developers on the existing projects, and not from people who are not writing code, that will self-regulate the number well and I believe give them more implicit teeth.  Imagine restarting from zero WGs, and saying to add a new one, there must be not just interest but commitment from a majority of projects to have at least a representative attend and use it to coordinate their related efforts.  E.g., if the projects don't care enough about coordinating cross-project around the topic of Architecture or Identity to ensure they are involved and attending the calls and participating in conversations and aligning their dev roadmaps, then don't create it.  We need some form of cross-project info sharing outside the context of TSC calls, thematically scoped and ongoing, but not so many that efforts are diffused or fail to hit critical mass. I think that would address criticisms of the WG model to date.

Brian

On 9/12/19 9:22 AM, Mic Bowman wrote:
per the brief discussion in the TSC this morning, the core proposal from the WG task force is that we replace working groups with technology focused SIGs (where discussions happen) and task forces focused on a short term deliverable (where the deliverable must be completed in less than 6 months, for example). 

the list of proposals is here:

please comment (and, while we have withdrawn proposals 1 and 2, please read the discussion on them for context). 

specifically... here's where we're at:

  • Proposal 3: Working groups should be dropped.
  • Proposal 4: Formalize "task force" as a task-specific group with limited scope and fixed time to complete.
  • Proposal 5: A task-force will be required to create a "proposal" and the TSC must approve the proposal.
  • Proposal 6: The task-force leader will be required to report on completion of deliverables.
  • Proposal 7: A task-force that requires additional time, must request an extension from the TSC.
  • Proposal 8: Existing working groups will be converted into a technology focused SIG.
--mic


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


working groups

Mic Bowman
 

per the brief discussion in the TSC this morning, the core proposal from the WG task force is that we replace working groups with technology focused SIGs (where discussions happen) and task forces focused on a short term deliverable (where the deliverable must be completed in less than 6 months, for example). 

the list of proposals is here:

please comment (and, while we have withdrawn proposals 1 and 2, please read the discussion on them for context). 

specifically... here's where we're at:

  • Proposal 3: Working groups should be dropped.
  • Proposal 4: Formalize "task force" as a task-specific group with limited scope and fixed time to complete.
  • Proposal 5: A task-force will be required to create a "proposal" and the TSC must approve the proposal.
  • Proposal 6: The task-force leader will be required to report on completion of deliverables.
  • Proposal 7: A task-force that requires additional time, must request an extension from the TSC.
  • Proposal 8: Existing working groups will be converted into a technology focused SIG.
--mic


Upcoming Event: DCIWG Quarterly Report reminder - Thu, 09/12/2019 9:00am-10:00am #cal-reminder

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Reminder: DCIWG Quarterly Report reminder

When: Thursday, 12 September 2019, 9:00am to 10:00am, (GMT-07:00) America/Los Angeles

View Event

Description: Reminder: Hyperledger DCIWG Quarterly Update Due #tsc-project-update

When: At the end of the month

View Event

Organizer: community-architects@hyperledger.org

Description: The Hyperledger DCIWG update to the TSC is due at the end of the month.  Please schedule a time to add a review on an upcoming TSC call and please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


Upcoming Event: Hyperledger Quilt Quarterly Update Due #tsc-project-update - Thu, 09/19/2019 #cal-reminder #tsc-project-update

tsc@lists.hyperledger.org Calendar <tsc@...>
 

Reminder: Hyperledger Quilt Quarterly Update Due #tsc-project-update

When: Thursday, 19 September 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Quilt update to the TSC was due 16 September, 2019, and it will be presented to the TSC on 19 September, 2019. Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


Re: Results of TSC election

Arnaud Le Hors
 

Thank you all. I'm really honored to serve as chair.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Dan O'Prey via Lists.Hyperledger.Org" <dan=digitalasset.com@...>
To:        "Middleton, Dan" <dan.middleton@...>
Cc:        tsc@...
Date:        09/11/2019 06:18 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] Results of TSC election
Sent by:        tsc@...




Congratulations again to Arnaud!

And thank you to Dan for the awesome work representing the TSC on the board over the past year. Exemplary job.

Dan O'Prey

CMO & Head of Community / +1 646 647 5957
Digital Asset, creators of DAML


On Wed, Sep 11, 2019 at 12:07 PM Middleton, Dan <dan.middleton@...> wrote:
Congratulations, Arnaud. I’m happy to have the chair role in good hands.
 
Best,
 
Dan Middleton
Principal Engineer
Intel
 
 
From: <tsc@...> on behalf of Ry Jones <rjones@...>
Date:
Wednesday, September 11, 2019 at 6:01 PM
To:
TSC <
tsc@...>
Subject:
[Hyperledger TSC] Results of TSC election

 
Hi,
Please welcome the new TSC chair - Arnaud J Le Hors
Ry

--

Ry Jones
Community Architect, Hyperledger
Chat@rjones

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at 
http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.




Re: Results of TSC election

Christopher Ferris <chris.ferris@...>
 

Congrats, Arnaud!

Dan, thanks for your leadership over the past year. Hyperledger has grown and prospered during your tenure. Let’s work to continue that trend even as we look to ways to increase cross project collaboration and integration.

Cheers

Chris

On Sep 11, 2019, at 11:08 AM, Dan O'Prey via Lists.Hyperledger.Org <dan=digitalasset.com@...> wrote:

Congratulations again to Arnaud!

And thank you to Dan for the awesome work representing the TSC on the board over the past year. Exemplary job.

Dan O'Prey

CMO & Head of Community / +1 646 647 5957
Digital Asset, creators of DAML


On Wed, Sep 11, 2019 at 12:07 PM Middleton, Dan <dan.middleton@...> wrote:

Congratulations, Arnaud. I’m happy to have the chair role in good hands.

 

Best,

 

Dan Middleton

Principal Engineer

Intel

 

 

From: <tsc@...> on behalf of Ry Jones <rjones@...>
Date: Wednesday, September 11, 2019 at 6:01 PM
To: TSC <tsc@...>
Subject: [Hyperledger TSC] Results of TSC election

 

Hi,

Please welcome the new TSC chair - Arnaud J Le Hors

Ry


--

Ry Jones

Community Architect, Hyperledger


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.


Re: Results of TSC election

Dan O'Prey <dan@...>
 

Congratulations again to Arnaud!

And thank you to Dan for the awesome work representing the TSC on the board over the past year. Exemplary job.

Dan O'Prey

CMO & Head of Community / +1 646 647 5957
Digital Asset, creators of DAML


On Wed, Sep 11, 2019 at 12:07 PM Middleton, Dan <dan.middleton@...> wrote:

Congratulations, Arnaud. I’m happy to have the chair role in good hands.

 

Best,

 

Dan Middleton

Principal Engineer

Intel

 

 

From: <tsc@...> on behalf of Ry Jones <rjones@...>
Date: Wednesday, September 11, 2019 at 6:01 PM
To: TSC <tsc@...>
Subject: [Hyperledger TSC] Results of TSC election

 

Hi,

Please welcome the new TSC chair - Arnaud J Le Hors

Ry


--

Ry Jones

Community Architect, Hyperledger


This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.


Re: Results of TSC election

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

Congratulations, Arnaud. I’m happy to have the chair role in good hands.

 

Best,

 

Dan Middleton

Principal Engineer

Intel

 

 

From: <tsc@...> on behalf of Ry Jones <rjones@...>
Date: Wednesday, September 11, 2019 at 6:01 PM
To: TSC <tsc@...>
Subject: [Hyperledger TSC] Results of TSC election

 

Hi,

Please welcome the new TSC chair - Arnaud J Le Hors

Ry


--

Ry Jones

Community Architect, Hyperledger


Results of TSC election

Ry Jones
 

Hi,
Please welcome the new TSC chair - Arnaud J Le Hors
Ry

--
Ry Jones
Community Architect, Hyperledger

1221 - 1240 of 3894