Date   

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

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

Hi Arnaud,

 

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

 

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

 

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

 

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

 

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

 

Thanks,

Hart

 

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

 

Hi Vipin,

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

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

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




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





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



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

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





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





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

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

Thanks,
Vipin


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





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





Hi all,

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

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

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

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

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

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

Best,
Vipin










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

Arnaud Le Hors
 

Hi Vipin,

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

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

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




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




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


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

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





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




Arnaud,
I had already addressed this question in my proposal: I quote
  • There has been a case made that SIGs are not under the TSC, and hence are not eligible. WGs and even the projects are only nominally under the control of the TSC, procedures are being worked out to make this involvement even lighter touch as projects, WGs and general technical output proliferates.  
Thanks,
Vipin


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





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




Hi all,

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

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

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

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

Best,
Vipin











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

VIPIN BHARATHAN
 

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

From: tsc@... <tsc@...> on behalf of Arnaud Le Hors via Lists.Hyperledger.Org <lehors=us.ibm.com@...>
Sent: Wednesday, August 14, 2019 4:38 PM
To: Vipin Bharathan
Cc: tsc@...
Subject: Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.
 
Vipin,
I'm sorry if my email made you feel I had ignored that part of your email. I hadn't but, I don't share your point of view and my point remains.
Regards.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




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




Arnaud,
I had already addressed this question in my proposal: I quote
  • There has been a case made that SIGs are not under the TSC, and hence are not eligible. WGs and even the projects are only nominally under the control of the TSC, procedures are being worked out to make this involvement even lighter touch as projects, WGs and general technical output proliferates.   
Thanks,
Vipin


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





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




Hi all,

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

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

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

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

Best,
Vipin








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

Arnaud Le Hors
 

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




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




Arnaud,
I had already addressed this question in my proposal: I quote
  • There has been a case made that SIGs are not under the TSC, and hence are not eligible. WGs and even the projects are only nominally under the control of the TSC, procedures are being worked out to make this involvement even lighter touch as projects, WGs and general technical output proliferates.   
Thanks,
Vipin


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





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




Hi all,

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

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

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

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

Best,
Vipin








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

Vipin Bharathan
 

Arnaud,
I had already addressed this question in my proposal: I quote
  • There has been a case made that SIGs are not under the TSC, and hence are not eligible. WGs and even the projects are only nominally under the control of the TSC, procedures are being worked out to make this involvement even lighter touch as projects, WGs and general technical output proliferates.   
Thanks,
Vipin


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




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




Hi all,

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

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

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

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

Best,
Vipin





Re: on expanding the TSC

Shawn Amundson
 

Another solution, which would scale better with   a larger TSC, is to do voting async on the mailing list.

-Shawn


On Wed, Aug 14, 2019 at 9:49 AM Arnaud Le Hors <lehors@...> wrote:
I actually meant to say something about the fact that the whole point wasn't about penalizing people who have been absent as much as it was to make sure that their absence doesn't prevent the TSC from continuing to function (i.e. reach quorum). So, I think such a rule would work well and is all we need. +1 from me.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Christopher Ferris" <chrisfer@...>
To:        cmickeyb@...
Cc:        tsc@...
Date:        08/12/2019 04:28 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] on expanding the TSC
Sent by:        tsc@...




Yeah, I forgot about this, but the Board modified ITS quorum rules for voting because we had a bit of an issue attaining quorum in the first year.
 
"Any Governing Board representative who fails to attend two consecutive Governing Board meetings will not be counted for purposes of determining quorum requirements as of the third consecutive meeting and until they next attend a Governing Board meeting."
 
Note that the language does not penalize voting privileges, directly but simply modifies the quorum rules. We could add the similar language to the charter to cover the TSC.
 
e.g.
 
Any TSC member who fails to attend two consecutive TSC meetings will not be counted for purposes of determining quorum requirements as of the third consecutive meeting and until they next attend a TSC meeting.
 
Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
email: chrisfer@...
twitter: @christo4ferris

blog: https://developer.ibm.com/code/author/chrisfer/
IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
phone: +1 508 667 0402

 
 
----- Original message -----
From: "Mic Bowman" <cmickeyb@...>
Sent by: tsc@...
To: Hyperledger List <tsc@...>
Cc:
Subject: [EXTERNAL] Re: [Hyperledger TSC] on expanding the TSC
Date: Sat, Aug 10, 2019 11:49 PM
 

+1 on increasing the TSC membership. the diversity of projects and complexity of projects would benefit tremendously from a more diverse TSC. we are more than "platforms" and the representation should reflect that.
 
i am concerned with "unexcused" absences (or at least absences that were not previously reported to the TSC chair) and the effect on quorum. several of the ideas presented seem to have merit. it does seem likely that many of these would work well and none would be perfect. lets not reinvent the wheel. seems like this might be a great time to adopt arnaud's approach and write up a could of these as concrete proposals we could consider.
 
--mic
 
 
On Sat, Aug 10, 2019 at 1:52 PM mark wagner <mwagner@...> wrote:
Chris and all who have spoken or read the thread.
 
This a great suggestion. I think that we need to request multiple changes to the charter in regards to the TSC. Plus I am not sure which of these require a charter change (Governing Board vote) vs a TSC vote.
 
1) Increasing the board size to 17 or 19.
I think that tying the size to the max number of Premium members sends an unintentional message that your money buys a vote (even though that is *not* the case or intent  here). Also, keeping the size "smaller" should make the meetings easier to manage.  we do have a lot of participation in TSC discussions from non TSC members so their voice is heard.
 
2) I am in favor of the proposal to require attendance.
I think missing two consecutive meetings is a good number to lose your voting rights until you attend your second consecutive meeting. So your first meeting back you can not vote. If you attend the following meeting you can vote. But you miss the second meeting you start prohibition all over.
 
 
3) Create the position of a TSC Vice Chair
Note that my thoughts here are about the process and are not intended as a reflection of the people.
 
It felt wrong to me that we allowed the Chair position to be passed around this year without input / official consent, when the elected, and then Chair appointed person, were both unable to fulfill their obligations / responsibilities. Also please keep in mind that the TSC Chair gets a seat and a vote on the Governing Board, so if the Chair is unable to attend the Board meeting, then the Vice Chair would automatically step up for that meeting.  The Chair is an elected position and TSC should be able to vote on who the position falls to when the Chair is unavailable to fulfill the duties.
 
So, my thoughts were that the newly elected TSC would vote on both a Chair and a Vice Chair. We should decide if the Vice Chair is the second highest vote tally for the Chair position or if it is a distinct, and concurrent, election at the time we vote for the Chair position.
 
4) Replacing a TSC member.
There should documented methods to replace a TSC member who is unable or unwilling to fill their term. This can be a single election by the community or an appointment by TSC vote (majority or super majority)?
 
 
5) Removing a TSC member (vote of no confidence / impeachment)
There should also be a mechanism to strip someone of their TSC seat / privileges if it is determined that they are no longer willing or able to fulfill their role in good faith or in accordance with the Hyperledger Charter and or bylaws.  This is a big deal so it should be "difficult" to do. So if it is a TSC elected position (Chair, Vice Chair) then a super majority of the TSC is required. If it is a TSC seat then a majority of the community, OR we can leave it to the Governing Board.
 
Also, if after five consecutive meetings missed you should lose your seat.
 
5) Delegation of privileges.
There has been some private chatter of allowing a TSC member to appoint someone to fill in for them when the TSC member can not attend a meeting, etc.  Again, TSC membership is a privilege voted upon by the community. It is not transferable. Just say no.
 
6) Remove the start up clause of the charter 4.a.i
This was only valid for the first six months of HYperledger. Not sure we need it any longer.
 
7) Reconcile modify the definition of Contributor between 4.a.ii and 4.b.i (see below)
Proposal to change 4.a.ii from:
"An Active Contributor is defined as any Contributor who has had a contribution accepted into the codebase during the prior twelve (12) months."
to:
"An Active Contributor is defined as any Contributor or Maintainer who has had made a technical contribution during the prior twelve (12) months. This can include code accepted into the codebase, actively participating in Working Groups,Committees, etc "
 
Also modify 4.b.i to replace the word "codebase" with something more expansive to also reflect WG contributions, etc.
 
 
Respectfully
 
-mark
 
4. Technical Steering Committee (“TSC”)
a. Composition
i. Startup Period: During the first six (6) months after project launch, the TSC voting members shall consist of one (1) appointed representative from each Premier Member and each Top Level Project Maintainer, provided that no company (including related companies or affiliates under common control) shall have more than three (3) votes on the TSC.
ii. Steady State: After the Startup Period, there shall be a nomination and election period for electing Contributors or Maintainers to the TSC. The TSC voting members shall consist of eleven (11) elected Contributors or Maintainers chosen by the Active Contributors. An Active Contributor is defined as any Contributor who has had a contribution accepted into the codebase during the prior twelve (12) months. The TSC shall approve the process and timing for nominations and elections held on an annual basis.
b. TSC projects generally will involve Maintainers and Contributors:
i. Contributors: anyone in the technical community that contributes code, documentation or other technical artifacts to the HLP codebase.
ii. Maintainers: Contributors who have the ability to commit code and contributions to a project’s main branch on an HLP project. A Contributor may become a Maintainer by a majority approval of the existing Maintainers.
 
 
On Fri, Aug 9, 2019 at 8:27 PM Baohua Yang <yangbaohua@...> wrote:
I like this idea.
 
Besides, we may consider an automatic opt-out for 3 continuous unexcused absences.
 
And for the number, consider the growing size of the community and more new projects, 17, 19 or 21 are good candidates.
 
Thanks!

 


On Thu, Aug 8, 2019 at 4:18 PM Arnaud Le Hors <lehors@...> wrote:
I support this idea. My only concern with growing the TSC would be the risk of not reaching quorum but if we mitigate this risk with an appropriate measure I think we can only gain from the expansion.
For what it's worth, OASIS has to that end a notion of Voting Rights that you lose after missing 2 meetings and gain back after attending 2 meetings that is easy to implement and works well in my experience:

https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26#gainVotingRights
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





From:        
"Christopher Ferris" <chrisfer@...>
To:        
tsc@...
Date:        
08/08/2019 02:53 PM
Subject:        
[EXTERNAL] [Hyperledger TSC] on expanding the TSC
Sent by:        
tsc@...



On today’s TSC call, I noted that when we established Hyperledger, we had 11 Premier members and chose the number of TSC members as a derivative of that. We now have 18 Premier members and a board that has 21 members. We have grown from one to now twelve projects and we have 3 proposed projects in the pipeline. We also have a growing number of WGs that may also be underrepresented. Yet, we have not grown the TSC beyond the original 11. This means that the TSC may not adequately represent the full breadth of our community.


We talked about the prospect of expanding the TSC to enable greater diversity of projects and WGs, as well as of expertise, etc.


Brian noted that CNCF TOB has an elected tier and a provision in their charter that the elected members may also choose a number of individuals from within the community  to serve as well. This might be a good model to emulate.


Any change in the number of TSC members will, of necessity, require a Hyperledger charter revision requiring a 2/3 vote of the board.


I’d like this email to serve as a continuation of today’s discussion hopefully leading to a formal proposal to a charter revision.


I’ll start by suggesting that we find a way of growing the TSC beginning this year, but after the scheduled TSC election, by at least six members. As was also expressed by Mic, we probably also should keep the size manageable, so maybe no more than 21 total.


Ry and Arnaud also suggested maybe adopting a quorum rule that penalized absentee members by removing them from quorum calculation and suspending voting privs following repeated unexcused absences as a device to encourage participation and diminish potential that we not achieve quorum (this seems not to have been a problem excepting in the summer months, but we might consider something as a prophylactic measure.


Thoughts?


Cheers,

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



 

 
 

 


 

--


Best wishes!

Baohua Yang

 
 


--

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





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

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

That is correct, Arnaud.

The board is also looking into how to better guide the SIG process so that it is supporting the projects. I expect we’ll have an update on that next quarter.

 

Regards,

 

Dan Middleton

Principal Engineer

Intel

 

 

From: <tsc@...> on behalf of Arnaud Le Hors <lehors@...>
Date: Wednesday, August 14, 2019 at 9:54 AM
To: Vipin Bharathan <vipinsun@...>
Cc: Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] TSC elections: electorate should include SIGs and some other suggestions.

 

The problem is that SIGs have been placed outside the governance of the TSC so it seems odd to have them sit on a board they have no direct relationship with.
Am I the only one to feel that way?
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




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





Hi all,

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

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

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

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

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

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

Best,
Vipin




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

Arnaud Le Hors
 

The problem is that SIGs have been placed outside the governance of the TSC so it seems odd to have them sit on a board they have no direct relationship with.
Am I the only one to feel that way?
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




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




Hi all,

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

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

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

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

Best,
Vipin





Re: on expanding the TSC

Arnaud Le Hors
 

I actually meant to say something about the fact that the whole point wasn't about penalizing people who have been absent as much as it was to make sure that their absence doesn't prevent the TSC from continuing to function (i.e. reach quorum). So, I think such a rule would work well and is all we need. +1 from me.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Christopher Ferris" <chrisfer@...>
To:        cmickeyb@...
Cc:        tsc@...
Date:        08/12/2019 04:28 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] on expanding the TSC
Sent by:        tsc@...




Yeah, I forgot about this, but the Board modified ITS quorum rules for voting because we had a bit of an issue attaining quorum in the first year.
 
"Any Governing Board representative who fails to attend two consecutive Governing Board meetings will not be counted for purposes of determining quorum requirements as of the third consecutive meeting and until they next attend a Governing Board meeting."
 
Note that the language does not penalize voting privileges, directly but simply modifies the quorum rules. We could add the similar language to the charter to cover the TSC.
 
e.g.
 
Any TSC member who fails to attend two consecutive TSC meetings will not be counted for purposes of determining quorum requirements as of the third consecutive meeting and until they next attend a TSC meeting.
 
Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
email: chrisfer@...
twitter: @christo4ferris

blog: https://developer.ibm.com/code/author/chrisfer/
IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
phone: +1 508 667 0402

 
 

----- Original message -----
From: "Mic Bowman" <cmickeyb@...>
Sent by: tsc@...
To: Hyperledger List <tsc@...>
Cc:
Subject: [EXTERNAL] Re: [Hyperledger TSC] on expanding the TSC
Date: Sat, Aug 10, 2019 11:49 PM
 

+1 on increasing the TSC membership. the diversity of projects and complexity of projects would benefit tremendously from a more diverse TSC. we are more than "platforms" and the representation should reflect that.
 
i am concerned with "unexcused" absences (or at least absences that were not previously reported to the TSC chair) and the effect on quorum. several of the ideas presented seem to have merit. it does seem likely that many of these would work well and none would be perfect. lets not reinvent the wheel. seems like this might be a great time to adopt arnaud's approach and write up a could of these as concrete proposals we could consider.
 
--mic
 
 
On Sat, Aug 10, 2019 at 1:52 PM mark wagner <mwagner@...> wrote:
Chris and all who have spoken or read the thread.
 
This a great suggestion. I think that we need to request multiple changes to the charter in regards to the TSC. Plus I am not sure which of these require a charter change (Governing Board vote) vs a TSC vote.
 
1) Increasing the board size to 17 or 19.
I think that tying the size to the max number of Premium members sends an unintentional message that your money buys a vote (even though that is *not* the case or intent  here). Also, keeping the size "smaller" should make the meetings easier to manage.  we do have a lot of participation in TSC discussions from non TSC members so their voice is heard.
 
2) I am in favor of the proposal to require attendance.
I think missing two consecutive meetings is a good number to lose your voting rights until you attend your second consecutive meeting. So your first meeting back you can not vote. If you attend the following meeting you can vote. But you miss the second meeting you start prohibition all over.
 
 
3) Create the position of a TSC Vice Chair
Note that my thoughts here are about the process and are not intended as a reflection of the people.
 
It felt wrong to me that we allowed the Chair position to be passed around this year without input / official consent, when the elected, and then Chair appointed person, were both unable to fulfill their obligations / responsibilities. Also please keep in mind that the TSC Chair gets a seat and a vote on the Governing Board, so if the Chair is unable to attend the Board meeting, then the Vice Chair would automatically step up for that meeting.  The Chair is an elected position and TSC should be able to vote on who the position falls to when the Chair is unavailable to fulfill the duties.
 
So, my thoughts were that the newly elected TSC would vote on both a Chair and a Vice Chair. We should decide if the Vice Chair is the second highest vote tally for the Chair position or if it is a distinct, and concurrent, election at the time we vote for the Chair position.
 
4) Replacing a TSC member.
There should documented methods to replace a TSC member who is unable or unwilling to fill their term. This can be a single election by the community or an appointment by TSC vote (majority or super majority)?
 
 
5) Removing a TSC member (vote of no confidence / impeachment)
There should also be a mechanism to strip someone of their TSC seat / privileges if it is determined that they are no longer willing or able to fulfill their role in good faith or in accordance with the Hyperledger Charter and or bylaws.  This is a big deal so it should be "difficult" to do. So if it is a TSC elected position (Chair, Vice Chair) then a super majority of the TSC is required. If it is a TSC seat then a majority of the community, OR we can leave it to the Governing Board.
 
Also, if after five consecutive meetings missed you should lose your seat.
 
5) Delegation of privileges.
There has been some private chatter of allowing a TSC member to appoint someone to fill in for them when the TSC member can not attend a meeting, etc.  Again, TSC membership is a privilege voted upon by the community. It is not transferable. Just say no.
 
6) Remove the start up clause of the charter 4.a.i
This was only valid for the first six months of HYperledger. Not sure we need it any longer.
 
7) Reconcile modify the definition of Contributor between 4.a.ii and 4.b.i (see below)
Proposal to change 4.a.ii from:
"An Active Contributor is defined as any Contributor who has had a contribution accepted into the codebase during the prior twelve (12) months."
to:
"An Active Contributor is defined as any Contributor or Maintainer who has had made a technical contribution during the prior twelve (12) months. This can include code accepted into the codebase, actively participating in Working Groups,Committees, etc "
 
Also modify 4.b.i to replace the word "codebase" with something more expansive to also reflect WG contributions, etc.
 
 
Respectfully
 
-mark
 
4. Technical Steering Committee (“TSC”)
a. Composition
i. Startup Period: During the first six (6) months after project launch, the TSC voting members shall consist of one (1) appointed representative from each Premier Member and each Top Level Project Maintainer, provided that no company (including related companies or affiliates under common control) shall have more than three (3) votes on the TSC.
ii. Steady State: After the Startup Period, there shall be a nomination and election period for electing Contributors or Maintainers to the TSC. The TSC voting members shall consist of eleven (11) elected Contributors or Maintainers chosen by the Active Contributors. An Active Contributor is defined as any Contributor who has had a contribution accepted into the codebase during the prior twelve (12) months. The TSC shall approve the process and timing for nominations and elections held on an annual basis.
b. TSC projects generally will involve Maintainers and Contributors:
i. Contributors: anyone in the technical community that contributes code, documentation or other technical artifacts to the HLP codebase.
ii. Maintainers: Contributors who have the ability to commit code and contributions to a project’s main branch on an HLP project. A Contributor may become a Maintainer by a majority approval of the existing Maintainers.
 
 
On Fri, Aug 9, 2019 at 8:27 PM Baohua Yang <yangbaohua@...> wrote:
I like this idea.
 
Besides, we may consider an automatic opt-out for 3 continuous unexcused absences.
 
And for the number, consider the growing size of the community and more new projects, 17, 19 or 21 are good candidates.
 
Thanks!

 


On Thu, Aug 8, 2019 at 4:18 PM Arnaud Le Hors <lehors@...> wrote:
I support this idea. My only concern with growing the TSC would be the risk of not reaching quorum but if we mitigate this risk with an appropriate measure I think we can only gain from the expansion.
For what it's worth, OASIS has to that end a notion of Voting Rights that you lose after missing 2 meetings and gain back after attending 2 meetings that is easy to implement and works well in my experience:

https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26#gainVotingRights
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





From:        
"Christopher Ferris" <chrisfer@...>
To:        
tsc@...
Date:        
08/08/2019 02:53 PM
Subject:        
[EXTERNAL] [Hyperledger TSC] on expanding the TSC
Sent by:        
tsc@...



On today’s TSC call, I noted that when we established Hyperledger, we had 11 Premier members and chose the number of TSC members as a derivative of that. We now have 18 Premier members and a board that has 21 members. We have grown from one to now twelve projects and we have 3 proposed projects in the pipeline. We also have a growing number of WGs that may also be underrepresented. Yet, we have not grown the TSC beyond the original 11. This means that the TSC may not adequately represent the full breadth of our community.


We talked about the prospect of expanding the TSC to enable greater diversity of projects and WGs, as well as of expertise, etc.


Brian noted that CNCF TOB has an elected tier and a provision in their charter that the elected members may also choose a number of individuals from within the community  to serve as well. This might be a good model to emulate.


Any change in the number of TSC members will, of necessity, require a Hyperledger charter revision requiring a 2/3 vote of the board.


I’d like this email to serve as a continuation of today’s discussion hopefully leading to a formal proposal to a charter revision.


I’ll start by suggesting that we find a way of growing the TSC beginning this year, but after the scheduled TSC election, by at least six members. As was also expressed by Mic, we probably also should keep the size manageable, so maybe no more than 21 total.


Ry and Arnaud also suggested maybe adopting a quorum rule that penalized absentee members by removing them from quorum calculation and suspending voting privs following repeated unexcused absences as a device to encourage participation and diminish potential that we not achieve quorum (this seems not to have been a problem excepting in the summer months, but we might consider something as a prophylactic measure.


Thoughts?


Cheers,

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



 

 
 

 


 

--


Best wishes!

Baohua Yang

 
 


--

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





Re: RocketChat Downtime (Aug 13, 17:00 PST)

Anton Baranov
 

This work is complete

On Tue, Aug 13, 2019 at 5:01 PM Anton Baranov via Lists.Hyperledger.Org <abaranov=linuxfoundation.org@...> wrote:

The maintenance begins shortly

On Mon, Aug 12, 2019 at 7:05 PM Tim Johnson <tijohnson@...> wrote:
What: Maintenance for chat.hyperledger.org to perform OS update and
instance resize

When: Tuesday Aug 13 17-18:00 EST

Length: Expected ~15-20min

I will repeat this Email before the downtime starts.

Tim


Re: RocketChat Downtime (Aug 13, 17:00 PST)

Anton Baranov
 

The maintenance begins shortly


On Mon, Aug 12, 2019 at 7:05 PM Tim Johnson <tijohnson@...> wrote:
What: Maintenance for chat.hyperledger.org to perform OS update and
instance resize

When: Tuesday Aug 13 17-18:00 EST

Length: Expected ~15-20min

I will repeat this Email before the downtime starts.

Tim


Upcoming Event: Hyperledger Cello Quarterly Update Due #tsc-project-update - Thu, 08/15/2019 #tsc-project-update #cal-reminder

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

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

When: Thursday, 15 August 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Cello update to the TSC was due 12 August, 2019, and it will be presented to the TSC on 15 August, 2019. Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


Upcoming Event: Hyperledger Transact Quarterly Update Due #tsc-project-update - Thu, 08/15/2019 #tsc-project-update #cal-reminder

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

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

When: Thursday, 15 August 2019

View Event

Organizer: community-architects@...

Description: The Hyperledger Transact update to the TSC is due. Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


RocketChat Downtime (Aug 13, 17:00 PST)

Tim Johnson <tijohnson@...>
 

What: Maintenance for chat.hyperledger.org to perform OS update and
instance resize

When: Tuesday Aug 13 17-18:00 EST

Length: Expected ~15-20min

I will repeat this Email before the downtime starts.

Tim


Re: on expanding the TSC

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

There are a number of good things in this thread that I hope the next TSC can consider.

 

This TSC has about 3 weeks left. During that time I hope we can conclude a number of the items we have opened.

I’ll post the agenda later, but we have backlog items including a few project proposals, committee processes, and the notion of a decision log / RFC process. Please prioritize updating yourselves on these items so we can make as much progress as possible in our remaining meetings.

 

Thanks,

Dan Middleton

Principal Engineer

Intel

 

 

From: <tsc@...> on behalf of binh nguyen <binh1010010110@...>
Date: Monday, August 12, 2019 at 4:31 PM
To: Christopher Ferris <chrisfer@...>
Cc: Mic Bowman <cmickeyb@...>, Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] on expanding the TSC

 

Hi all,

 

+1 to all and especially the details in Mark's and Chris' response emails. We might need a rules book,  but let's be careful not to do this Visitor arrested for eating chicken with fork :- ) 

 

I do have 1 concern though: most of us agreed to increase the members of TSC to adequately represent the community, but the way we organize our election today can't really achieve that IMHO. Taking top N with the highest number of votes doesn't represent the diversity of our community. I think we should organize our election based on projects and working groups, depending on the size, each project/working group many have different number of representatives (similar to US Congress even though they are famous for doing nothing :- ) 

 

For example, we could go with a logarithmic algorithm in allocating TSC members to a project or working group -- eg 0 < log10(x) < 4. This would guarantee a sizable project or working group would be represented, but no large group could dominate. This is just an idea off the top of my head. We can work out different techniques to ensure that TSC represents the breadth of our community.

 

Thanks,

Binh

 

On Mon, Aug 12, 2019 at 10:24 AM Christopher Ferris <chrisfer@...> wrote:

Yeah, I forgot about this, but the Board modified ITS quorum rules for voting because we had a bit of an issue attaining quorum in the first year.

 

"Any Governing Board representative who fails to attend two consecutive Governing Board meetings will not be counted for purposes of determining quorum requirements as of the third consecutive meeting and until they next attend a Governing Board meeting."

 

Note that the language does not penalize voting privileges, directly but simply modifies the quorum rules. We could add the similar language to the charter to cover the TSC.

 

e.g.

 

Any TSC member who fails to attend two consecutive TSC meetings will not be counted for purposes of determining quorum requirements as of the third consecutive meeting and until they next attend a TSC meeting.

 

Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
email: chrisfer@...
twitter: @christo4ferris

IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
phone: +1 508 667 0402

 

 

----- Original message -----
From: "Mic Bowman" <cmickeyb@...>
Sent by: tsc@...
To: Hyperledger List <tsc@...>
Cc:
Subject: [EXTERNAL] Re: [Hyperledger TSC] on expanding the TSC
Date: Sat, Aug 10, 2019 11:49 PM
 

+1 on increasing the TSC membership. the diversity of projects and complexity of projects would benefit tremendously from a more diverse TSC. we are more than "platforms" and the representation should reflect that.

 

i am concerned with "unexcused" absences (or at least absences that were not previously reported to the TSC chair) and the effect on quorum. several of the ideas presented seem to have merit. it does seem likely that many of these would work well and none would be perfect. lets not reinvent the wheel. seems like this might be a great time to adopt arnaud's approach and write up a could of these as concrete proposals we could consider.

 

--mic

 

 

On Sat, Aug 10, 2019 at 1:52 PM mark wagner <mwagner@...> wrote:

Chris and all who have spoken or read the thread.

 

This a great suggestion. I think that we need to request multiple changes to the charter in regards to the TSC. Plus I am not sure which of these require a charter change (Governing Board vote) vs a TSC vote.

 

1) Increasing the board size to 17 or 19.

I think that tying the size to the max number of Premium members sends an unintentional message that your money buys a vote (even though that is *not* the case or intent  here). Also, keeping the size "smaller" should make the meetings easier to manage.  we do have a lot of participation in TSC discussions from non TSC members so their voice is heard.

 

2) I am in favor of the proposal to require attendance.

I think missing two consecutive meetings is a good number to lose your voting rights until you attend your second consecutive meeting. So your first meeting back you can not vote. If you attend the following meeting you can vote. But you miss the second meeting you start prohibition all over.

 

 

3) Create the position of a TSC Vice Chair

Note that my thoughts here are about the process and are not intended as a reflection of the people.

 

It felt wrong to me that we allowed the Chair position to be passed around this year without input / official consent, when the elected, and then Chair appointed person, were both unable to fulfill their obligations / responsibilities. Also please keep in mind that the TSC Chair gets a seat and a vote on the Governing Board, so if the Chair is unable to attend the Board meeting, then the Vice Chair would automatically step up for that meeting.  The Chair is an elected position and TSC should be able to vote on who the position falls to when the Chair is unavailable to fulfill the duties.

 

So, my thoughts were that the newly elected TSC would vote on both a Chair and a Vice Chair. We should decide if the Vice Chair is the second highest vote tally for the Chair position or if it is a distinct, and concurrent, election at the time we vote for the Chair position.

 

4) Replacing a TSC member.

There should documented methods to replace a TSC member who is unable or unwilling to fill their term. This can be a single election by the community or an appointment by TSC vote (majority or super majority)?

 

 

5) Removing a TSC member (vote of no confidence / impeachment)

There should also be a mechanism to strip someone of their TSC seat / privileges if it is determined that they are no longer willing or able to fulfill their role in good faith or in accordance with the Hyperledger Charter and or bylaws.  This is a big deal so it should be "difficult" to do. So if it is a TSC elected position (Chair, Vice Chair) then a super majority of the TSC is required. If it is a TSC seat then a majority of the community, OR we can leave it to the Governing Board.

 

Also, if after five consecutive meetings missed you should lose your seat.

 

5) Delegation of privileges.

There has been some private chatter of allowing a TSC member to appoint someone to fill in for them when the TSC member can not attend a meeting, etc.  Again, TSC membership is a privilege voted upon by the community. It is not transferable. Just say no.

 

6) Remove the start up clause of the charter 4.a.i

This was only valid for the first six months of HYperledger. Not sure we need it any longer.

 

7) Reconcile modify the definition of Contributor between 4.a.ii and 4.b.i (see below)

Proposal to change 4.a.ii from:

"An Active Contributor is defined as any Contributor who has had a contribution accepted into the codebase during the prior twelve (12) months."

to:

"An Active Contributor is defined as any Contributor or Maintainer who has had made a technical contribution during the prior twelve (12) months. This can include code accepted into the codebase, actively participating in Working Groups,Committees, etc "

 

Also modify 4.b.i to replace the word "codebase" with something more expansive to also reflect WG contributions, etc.

 

 

Respectfully

 

-mark

 

4. Technical Steering Committee (“TSC”)

a. Composition

i. Startup Period: During the first six (6) months after project launch, the TSC voting members shall consist of one (1) appointed representative from each Premier Member and each Top Level Project Maintainer, provided that no company (including related companies or affiliates under common control) shall have more than three (3) votes on the TSC.

ii. Steady State: After the Startup Period, there shall be a nomination and election period for electing Contributors or Maintainers to the TSC. The TSC voting members shall consist of eleven (11) elected Contributors or Maintainers chosen by the Active Contributors. An Active Contributor is defined as any Contributor who has had a contribution accepted into the codebase during the prior twelve (12) months. The TSC shall approve the process and timing for nominations and elections held on an annual basis.

b. TSC projects generally will involve Maintainers and Contributors:

i. Contributors: anyone in the technical community that contributes code, documentation or other technical artifacts to the HLP codebase.

ii. Maintainers: Contributors who have the ability to commit code and contributions to a project’s main branch on an HLP project. A Contributor may become a Maintainer by a majority approval of the existing Maintainers.

 

 

On Fri, Aug 9, 2019 at 8:27 PM Baohua Yang <yangbaohua@...> wrote:

I like this idea.

 

Besides, we may consider an automatic opt-out for 3 continuous unexcused absences.

 

And for the number, consider the growing size of the community and more new projects, 17, 19 or 21 are good candidates.

 

Thanks!

 

On Thu, Aug 8, 2019 at 4:18 PM Arnaud Le Hors <lehors@...> wrote:

I support this idea. My only concern with growing the TSC would be the risk of not reaching quorum but if we mitigate this risk with an appropriate measure I think we can only gain from the expansion.
For what it's worth, OASIS has to that end a notion of Voting Rights that you lose after missing 2 meetings and gain back after attending 2 meetings that is easy to implement and works well in my experience:
https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26#gainVotingRights
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





From:        "Christopher Ferris" <chrisfer@...>
To:        tsc@...
Date:        08/08/2019 02:53 PM
Subject:        [EXTERNAL] [Hyperledger TSC] on expanding the TSC
Sent by:        tsc@...





On today’s TSC call, I noted that when we established Hyperledger, we had 11 Premier members and chose the number of TSC members as a derivative of that. We now have 18 Premier members and a board that has 21 members. We have grown from one to now twelve projects and we have 3 proposed projects in the pipeline. We also have a growing number of WGs that may also be underrepresented. Yet, we have not grown the TSC beyond the original 11. This means that the TSC may not adequately represent the full breadth of our community.

We talked about the prospect of expanding the TSC to enable greater diversity of projects and WGs, as well as of expertise, etc.

Brian noted that CNCF TOB has an elected tier and a provision in their charter that the elected members may also choose a number of individuals from within the community  to serve as well. This might be a good model to emulate.

Any change in the number of TSC members will, of necessity, require a Hyperledger charter revision requiring a 2/3 vote of the board.

I’d like this email to serve as a continuation of today’s discussion hopefully leading to a formal proposal to a charter revision.

I’ll start by suggesting that we find a way of growing the TSC beginning this year, but after the scheduled TSC election, by at least six members. As was also expressed by Mic, we probably also should keep the size manageable, so maybe no more than 21 total.

Ry and Arnaud also suggested maybe adopting a quorum rule that penalized absentee members by removing them from quorum calculation and suspending voting privs following repeated unexcused absences as a device to encourage participation and diminish potential that we not achieve quorum (this seems not to have been a problem excepting in the summer months, but we might consider something as a prophylactic measure.

Thoughts?

Cheers,

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



 

 

 

 

 

--

Best wishes!


Baohua Yang

 

 



--

Mark Wagner

Senior Principal Software Engineer

Performance and Scalability

Red Hat, Inc

 

 

 

 


Re: on expanding the TSC

binh nguyen
 

Hi all,

+1 to all and especially the details in Mark's and Chris' response emails. We might need a rules book,  but let's be careful not to do this Visitor arrested for eating chicken with fork :- ) 

I do have 1 concern though: most of us agreed to increase the members of TSC to adequately represent the community, but the way we organize our election today can't really achieve that IMHO. Taking top N with the highest number of votes doesn't represent the diversity of our community. I think we should organize our election based on projects and working groups, depending on the size, each project/working group many have different number of representatives (similar to US Congress even though they are famous for doing nothing :- ) 

For example, we could go with a logarithmic algorithm in allocating TSC members to a project or working group -- eg 0 < log10(x) < 4. This would guarantee a sizable project or working group would be represented, but no large group could dominate. This is just an idea off the top of my head. We can work out different techniques to ensure that TSC represents the breadth of our community.

Thanks,
Binh


On Mon, Aug 12, 2019 at 10:24 AM Christopher Ferris <chrisfer@...> wrote:
Yeah, I forgot about this, but the Board modified ITS quorum rules for voting because we had a bit of an issue attaining quorum in the first year.
 
"Any Governing Board representative who fails to attend two consecutive Governing Board meetings will not be counted for purposes of determining quorum requirements as of the third consecutive meeting and until they next attend a Governing Board meeting."
 
Note that the language does not penalize voting privileges, directly but simply modifies the quorum rules. We could add the similar language to the charter to cover the TSC.
 
e.g.
 
Any TSC member who fails to attend two consecutive TSC meetings will not be counted for purposes of determining quorum requirements as of the third consecutive meeting and until they next attend a TSC meeting.
 
Cheers,

Christopher Ferris
IBM Fellow, CTO Open Technology
email: chrisfer@...
twitter: @christo4ferris
IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
phone: +1 508 667 0402
 
 
----- Original message -----
From: "Mic Bowman" <cmickeyb@...>
Sent by: tsc@...
To: Hyperledger List <tsc@...>
Cc:
Subject: [EXTERNAL] Re: [Hyperledger TSC] on expanding the TSC
Date: Sat, Aug 10, 2019 11:49 PM
 
+1 on increasing the TSC membership. the diversity of projects and complexity of projects would benefit tremendously from a more diverse TSC. we are more than "platforms" and the representation should reflect that.
 
i am concerned with "unexcused" absences (or at least absences that were not previously reported to the TSC chair) and the effect on quorum. several of the ideas presented seem to have merit. it does seem likely that many of these would work well and none would be perfect. lets not reinvent the wheel. seems like this might be a great time to adopt arnaud's approach and write up a could of these as concrete proposals we could consider.
 
--mic
 
 
On Sat, Aug 10, 2019 at 1:52 PM mark wagner <mwagner@...> wrote:
Chris and all who have spoken or read the thread.
 
This a great suggestion. I think that we need to request multiple changes to the charter in regards to the TSC. Plus I am not sure which of these require a charter change (Governing Board vote) vs a TSC vote.
 
1) Increasing the board size to 17 or 19.
I think that tying the size to the max number of Premium members sends an unintentional message that your money buys a vote (even though that is *not* the case or intent  here). Also, keeping the size "smaller" should make the meetings easier to manage.  we do have a lot of participation in TSC discussions from non TSC members so their voice is heard.
 
2) I am in favor of the proposal to require attendance.
I think missing two consecutive meetings is a good number to lose your voting rights until you attend your second consecutive meeting. So your first meeting back you can not vote. If you attend the following meeting you can vote. But you miss the second meeting you start prohibition all over.
 
 
3) Create the position of a TSC Vice Chair
Note that my thoughts here are about the process and are not intended as a reflection of the people.
 
It felt wrong to me that we allowed the Chair position to be passed around this year without input / official consent, when the elected, and then Chair appointed person, were both unable to fulfill their obligations / responsibilities. Also please keep in mind that the TSC Chair gets a seat and a vote on the Governing Board, so if the Chair is unable to attend the Board meeting, then the Vice Chair would automatically step up for that meeting.  The Chair is an elected position and TSC should be able to vote on who the position falls to when the Chair is unavailable to fulfill the duties.
 
So, my thoughts were that the newly elected TSC would vote on both a Chair and a Vice Chair. We should decide if the Vice Chair is the second highest vote tally for the Chair position or if it is a distinct, and concurrent, election at the time we vote for the Chair position.
 
4) Replacing a TSC member.
There should documented methods to replace a TSC member who is unable or unwilling to fill their term. This can be a single election by the community or an appointment by TSC vote (majority or super majority)?
 
 
5) Removing a TSC member (vote of no confidence / impeachment)
There should also be a mechanism to strip someone of their TSC seat / privileges if it is determined that they are no longer willing or able to fulfill their role in good faith or in accordance with the Hyperledger Charter and or bylaws.  This is a big deal so it should be "difficult" to do. So if it is a TSC elected position (Chair, Vice Chair) then a super majority of the TSC is required. If it is a TSC seat then a majority of the community, OR we can leave it to the Governing Board.
 
Also, if after five consecutive meetings missed you should lose your seat.
 
5) Delegation of privileges.
There has been some private chatter of allowing a TSC member to appoint someone to fill in for them when the TSC member can not attend a meeting, etc.  Again, TSC membership is a privilege voted upon by the community. It is not transferable. Just say no.
 
6) Remove the start up clause of the charter 4.a.i
This was only valid for the first six months of HYperledger. Not sure we need it any longer.
 
7) Reconcile modify the definition of Contributor between 4.a.ii and 4.b.i (see below)
Proposal to change 4.a.ii from:
"An Active Contributor is defined as any Contributor who has had a contribution accepted into the codebase during the prior twelve (12) months."
to:
"An Active Contributor is defined as any Contributor or Maintainer who has had made a technical contribution during the prior twelve (12) months. This can include code accepted into the codebase, actively participating in Working Groups,Committees, etc "
 
Also modify 4.b.i to replace the word "codebase" with something more expansive to also reflect WG contributions, etc.
 
 
Respectfully
 
-mark
 

4. Technical Steering Committee (“TSC”)

a. Composition

i. Startup Period: During the first six (6) months after project launch, the TSC voting members shall consist of one (1) appointed representative from each Premier Member and each Top Level Project Maintainer, provided that no company (including related companies or affiliates under common control) shall have more than three (3) votes on the TSC.

ii. Steady State: After the Startup Period, there shall be a nomination and election period for electing Contributors or Maintainers to the TSC. The TSC voting members shall consist of eleven (11) elected Contributors or Maintainers chosen by the Active Contributors. An Active Contributor is defined as any Contributor who has had a contribution accepted into the codebase during the prior twelve (12) months. The TSC shall approve the process and timing for nominations and elections held on an annual basis.

b. TSC projects generally will involve Maintainers and Contributors:

i. Contributors: anyone in the technical community that contributes code, documentation or other technical artifacts to the HLP codebase.

ii. Maintainers: Contributors who have the ability to commit code and contributions to a project’s main branch on an HLP project. A Contributor may become a Maintainer by a majority approval of the existing Maintainers.

 
 
On Fri, Aug 9, 2019 at 8:27 PM Baohua Yang <yangbaohua@...> wrote:
I like this idea.
 
Besides, we may consider an automatic opt-out for 3 continuous unexcused absences.
 
And for the number, consider the growing size of the community and more new projects, 17, 19 or 21 are good candidates.
 
Thanks!
 
On Thu, Aug 8, 2019 at 4:18 PM Arnaud Le Hors <lehors@...> wrote:
I support this idea. My only concern with growing the TSC would be the risk of not reaching quorum but if we mitigate this risk with an appropriate measure I think we can only gain from the expansion.
For what it's worth, OASIS has to that end a notion of Voting Rights that you lose after missing 2 meetings and gain back after attending 2 meetings that is easy to implement and works well in my experience:
https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26#gainVotingRights
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





From:        "Christopher Ferris" <chrisfer@...>
To:        tsc@...
Date:        08/08/2019 02:53 PM
Subject:        [EXTERNAL] [Hyperledger TSC] on expanding the TSC
Sent by:        tsc@...



On today’s TSC call, I noted that when we established Hyperledger, we had 11 Premier members and chose the number of TSC members as a derivative of that. We now have 18 Premier members and a board that has 21 members. We have grown from one to now twelve projects and we have 3 proposed projects in the pipeline. We also have a growing number of WGs that may also be underrepresented. Yet, we have not grown the TSC beyond the original 11. This means that the TSC may not adequately represent the full breadth of our community.

We talked about the prospect of expanding the TSC to enable greater diversity of projects and WGs, as well as of expertise, etc.

Brian noted that CNCF TOB has an elected tier and a provision in their charter that the elected members may also choose a number of individuals from within the community  to serve as well. This might be a good model to emulate.

Any change in the number of TSC members will, of necessity, require a Hyperledger charter revision requiring a 2/3 vote of the board.

I’d like this email to serve as a continuation of today’s discussion hopefully leading to a formal proposal to a charter revision.

I’ll start by suggesting that we find a way of growing the TSC beginning this year, but after the scheduled TSC election, by at least six members. As was also expressed by Mic, we probably also should keep the size manageable, so maybe no more than 21 total.

Ry and Arnaud also suggested maybe adopting a quorum rule that penalized absentee members by removing them from quorum calculation and suspending voting privs following repeated unexcused absences as a device to encourage participation and diminish potential that we not achieve quorum (this seems not to have been a problem excepting in the summer months, but we might consider something as a prophylactic measure.

Thoughts?

Cheers,

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



 

 

 

 
 
--
Best wishes!

Baohua Yang

 

 



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

 

 

 


Maintainers summit finalized

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

We will be holding the summit in Minneapolis October 8-10th.


We’ve setup this page in the events space to track more details as we get going…

https://wiki.hyperledger.org/x/GA75

 

We had previously communicated a different date/location option but were able to update to accommodate many maintainers who would not have been able to make that original proposal. Thanks to Accenture for volunteering space to facilitate this improvement. We know there are also conflicts with this date/location but it is the best optimization for the October timeframe.

 

Regards,

 

Dan Middleton

Principal Engineer

Intel

 


Re: on expanding the TSC

Christopher Ferris <chrisfer@...>
 

Yeah, I forgot about this, but the Board modified ITS quorum rules for voting because we had a bit of an issue attaining quorum in the first year.
 
"Any Governing Board representative who fails to attend two consecutive Governing Board meetings will not be counted for purposes of determining quorum requirements as of the third consecutive meeting and until they next attend a Governing Board meeting."
 
Note that the language does not penalize voting privileges, directly but simply modifies the quorum rules. We could add the similar language to the charter to cover the TSC.
 
e.g.
 
Any TSC member who fails to attend two consecutive TSC meetings will not be counted for purposes of determining quorum requirements as of the third consecutive meeting and until they next attend a TSC meeting.
 
Cheers,

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

----- Original message -----
From: "Mic Bowman" <cmickeyb@...>
Sent by: tsc@...
To: Hyperledger List <tsc@...>
Cc:
Subject: [EXTERNAL] Re: [Hyperledger TSC] on expanding the TSC
Date: Sat, Aug 10, 2019 11:49 PM
 
+1 on increasing the TSC membership. the diversity of projects and complexity of projects would benefit tremendously from a more diverse TSC. we are more than "platforms" and the representation should reflect that.
 
i am concerned with "unexcused" absences (or at least absences that were not previously reported to the TSC chair) and the effect on quorum. several of the ideas presented seem to have merit. it does seem likely that many of these would work well and none would be perfect. lets not reinvent the wheel. seems like this might be a great time to adopt arnaud's approach and write up a could of these as concrete proposals we could consider.
 
--mic
 
 
On Sat, Aug 10, 2019 at 1:52 PM mark wagner <mwagner@...> wrote:
Chris and all who have spoken or read the thread.
 
This a great suggestion. I think that we need to request multiple changes to the charter in regards to the TSC. Plus I am not sure which of these require a charter change (Governing Board vote) vs a TSC vote.
 
1) Increasing the board size to 17 or 19.
I think that tying the size to the max number of Premium members sends an unintentional message that your money buys a vote (even though that is *not* the case or intent  here). Also, keeping the size "smaller" should make the meetings easier to manage.  we do have a lot of participation in TSC discussions from non TSC members so their voice is heard.
 
2) I am in favor of the proposal to require attendance.
I think missing two consecutive meetings is a good number to lose your voting rights until you attend your second consecutive meeting. So your first meeting back you can not vote. If you attend the following meeting you can vote. But you miss the second meeting you start prohibition all over.
 
 
3) Create the position of a TSC Vice Chair
Note that my thoughts here are about the process and are not intended as a reflection of the people.
 
It felt wrong to me that we allowed the Chair position to be passed around this year without input / official consent, when the elected, and then Chair appointed person, were both unable to fulfill their obligations / responsibilities. Also please keep in mind that the TSC Chair gets a seat and a vote on the Governing Board, so if the Chair is unable to attend the Board meeting, then the Vice Chair would automatically step up for that meeting.  The Chair is an elected position and TSC should be able to vote on who the position falls to when the Chair is unavailable to fulfill the duties.
 
So, my thoughts were that the newly elected TSC would vote on both a Chair and a Vice Chair. We should decide if the Vice Chair is the second highest vote tally for the Chair position or if it is a distinct, and concurrent, election at the time we vote for the Chair position.
 
4) Replacing a TSC member.
There should documented methods to replace a TSC member who is unable or unwilling to fill their term. This can be a single election by the community or an appointment by TSC vote (majority or super majority)?
 
 
5) Removing a TSC member (vote of no confidence / impeachment)
There should also be a mechanism to strip someone of their TSC seat / privileges if it is determined that they are no longer willing or able to fulfill their role in good faith or in accordance with the Hyperledger Charter and or bylaws.  This is a big deal so it should be "difficult" to do. So if it is a TSC elected position (Chair, Vice Chair) then a super majority of the TSC is required. If it is a TSC seat then a majority of the community, OR we can leave it to the Governing Board.
 
Also, if after five consecutive meetings missed you should lose your seat.
 
5) Delegation of privileges.
There has been some private chatter of allowing a TSC member to appoint someone to fill in for them when the TSC member can not attend a meeting, etc.  Again, TSC membership is a privilege voted upon by the community. It is not transferable. Just say no.
 
6) Remove the start up clause of the charter 4.a.i
This was only valid for the first six months of HYperledger. Not sure we need it any longer.
 
7) Reconcile modify the definition of Contributor between 4.a.ii and 4.b.i (see below)
Proposal to change 4.a.ii from:
"An Active Contributor is defined as any Contributor who has had a contribution accepted into the codebase during the prior twelve (12) months."
to:
"An Active Contributor is defined as any Contributor or Maintainer who has had made a technical contribution during the prior twelve (12) months. This can include code accepted into the codebase, actively participating in Working Groups,Committees, etc "
 
Also modify 4.b.i to replace the word "codebase" with something more expansive to also reflect WG contributions, etc.
 
 
Respectfully
 
-mark
 

4. Technical Steering Committee (“TSC”)

a. Composition

i. Startup Period: During the first six (6) months after project launch, the TSC voting members shall consist of one (1) appointed representative from each Premier Member and each Top Level Project Maintainer, provided that no company (including related companies or affiliates under common control) shall have more than three (3) votes on the TSC.

ii. Steady State: After the Startup Period, there shall be a nomination and election period for electing Contributors or Maintainers to the TSC. The TSC voting members shall consist of eleven (11) elected Contributors or Maintainers chosen by the Active Contributors. An Active Contributor is defined as any Contributor who has had a contribution accepted into the codebase during the prior twelve (12) months. The TSC shall approve the process and timing for nominations and elections held on an annual basis.

b. TSC projects generally will involve Maintainers and Contributors:

i. Contributors: anyone in the technical community that contributes code, documentation or other technical artifacts to the HLP codebase.

ii. Maintainers: Contributors who have the ability to commit code and contributions to a project’s main branch on an HLP project. A Contributor may become a Maintainer by a majority approval of the existing Maintainers.

 
 
On Fri, Aug 9, 2019 at 8:27 PM Baohua Yang <yangbaohua@...> wrote:
I like this idea.
 
Besides, we may consider an automatic opt-out for 3 continuous unexcused absences.
 
And for the number, consider the growing size of the community and more new projects, 17, 19 or 21 are good candidates.
 
Thanks!
 
On Thu, Aug 8, 2019 at 4:18 PM Arnaud Le Hors <lehors@...> wrote:
I support this idea. My only concern with growing the TSC would be the risk of not reaching quorum but if we mitigate this risk with an appropriate measure I think we can only gain from the expansion.
For what it's worth, OASIS has to that end a notion of Voting Rights that you lose after missing 2 meetings and gain back after attending 2 meetings that is easy to implement and works well in my experience:
https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26#gainVotingRights
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





From:        "Christopher Ferris" <chrisfer@...>
To:        tsc@...
Date:        08/08/2019 02:53 PM
Subject:        [EXTERNAL] [Hyperledger TSC] on expanding the TSC
Sent by:        tsc@...



On today’s TSC call, I noted that when we established Hyperledger, we had 11 Premier members and chose the number of TSC members as a derivative of that. We now have 18 Premier members and a board that has 21 members. We have grown from one to now twelve projects and we have 3 proposed projects in the pipeline. We also have a growing number of WGs that may also be underrepresented. Yet, we have not grown the TSC beyond the original 11. This means that the TSC may not adequately represent the full breadth of our community.

We talked about the prospect of expanding the TSC to enable greater diversity of projects and WGs, as well as of expertise, etc.

Brian noted that CNCF TOB has an elected tier and a provision in their charter that the elected members may also choose a number of individuals from within the community  to serve as well. This might be a good model to emulate.

Any change in the number of TSC members will, of necessity, require a Hyperledger charter revision requiring a 2/3 vote of the board.

I’d like this email to serve as a continuation of today’s discussion hopefully leading to a formal proposal to a charter revision.

I’ll start by suggesting that we find a way of growing the TSC beginning this year, but after the scheduled TSC election, by at least six members. As was also expressed by Mic, we probably also should keep the size manageable, so maybe no more than 21 total.

Ry and Arnaud also suggested maybe adopting a quorum rule that penalized absentee members by removing them from quorum calculation and suspending voting privs following repeated unexcused absences as a device to encourage participation and diminish potential that we not achieve quorum (this seems not to have been a problem excepting in the summer months, but we might consider something as a prophylactic measure.

Thoughts?

Cheers,

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



 

 

 

 
 
--
Best wishes!

Baohua Yang

 

 



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

 

 

 


Re: on expanding the TSC

Christopher Ferris <chrisfer@...>
 

My comments inlined below avec <cbf></cbf>
 
Cheers,

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

----- Original message -----
From: "mark wagner" <mwagner@...>
Sent by: tsc@...
To: Hyperledger List <tsc@...>
Cc:
Subject: [EXTERNAL] Re: [Hyperledger TSC] on expanding the TSC
Date: Sat, Aug 10, 2019 4:52 PM
 
Chris and all who have spoken or read the thread.
 
This a great suggestion. I think that we need to request multiple changes to the charter in regards to the TSC. Plus I am not sure which of these require a charter change (Governing Board vote) vs a TSC vote.
 
1) Increasing the board size to 17 or 19.
I think that tying the size to the max number of Premium members sends an unintentional message that your money buys a vote (even though that is *not* the case or intent  here). Also, keeping the size "smaller" should make the meetings easier to manage.  we do have a lot of participation in TSC discussions from non TSC members so their voice is heard.
 
2) I am in favor of the proposal to require attendance.
I think missing two consecutive meetings is a good number to lose your voting rights until you attend your second consecutive meeting. So your first meeting back you can not vote. If you attend the following meeting you can vote. But you miss the second meeting you start prohibition all over. <cbf>As I think I noted, every case where we instituted an attendance requirement, we have also given chair discretion to forgive an absence if regrets are sent in advance and the excuse is reasonable in the eyes of the chair (travel, illness, etc). Excused absence should also be made completely transparent and be recorded in the minutes.</cbf>
 
3) Create the position of a TSC Vice Chair
Note that my thoughts here are about the process and are not intended as a reflection of the people.
 
It felt wrong to me that we allowed the Chair position to be passed around this year without input / official consent, when the elected, and then Chair appointed person, were both unable to fulfill their obligations / responsibilities. Also please keep in mind that the TSC Chair gets a seat and a vote on the Governing Board, so if the Chair is unable to attend the Board meeting, then the Vice Chair would automatically step up for that meeting.  The Chair is an elected position and TSC should be able to vote on who the position falls to when the Chair is unavailable to fulfill the duties.
 
So, my thoughts were that the newly elected TSC would vote on both a Chair and a Vice Chair. We should decide if the Vice Chair is the second highest vote tally for the Chair position or if it is a distinct, and concurrent, election at the time we vote for the Chair position. <cbf>+1 - I agree it seemed odd to me, but I withheld comment. If we agree, then second highest vote total (for chair) would work from my perspective, unless of course someone ran unopposed. It is unclear to me whether we would need to have a charter change for this alone. Seems like we could decide on a vice-chair position that was exclusively for purposes of managing the TSC calls in the absence of the elected chair.</cbf>
 
4) Replacing a TSC member.
There should documented methods to replace a TSC member who is unable or unwilling to fill their term. This can be a single election by the community or an appointment by TSC vote (majority or super majority)?
<cbf>Depending on how we expand the TSC membership, if we had some number selected by the elected TSC members, then seems like a replacement could similarly be handled by the currently seated TSC membership.</cbf>
 
5) Removing a TSC member (vote of no confidence / impeachment)
There should also be a mechanism to strip someone of their TSC seat / privileges if it is determined that they are no longer willing or able to fulfill their role in good faith or in accordance with the Hyperledger Charter and or bylaws.  This is a big deal so it should be "difficult" to do. So if it is a TSC elected position (Chair, Vice Chair) then a super majority of the TSC is required. If it is a TSC seat then a majority of the community, OR we can leave it to the Governing Board. <cbf>I would hope that this could be handled, without a formal process, by the Exec Director and/or TSC chair and would be limited to CoC violations.</cbf>
 
Also, if after five consecutive meetings missed you should lose your seat.<cbf>I could get behind this so long as the chair discretion rule applied and the consecutive absences were unexcused. One should not lose their seat because of a vacation or illness.</cbf>
 
5) Delegation of privileges.
There has been some private chatter of allowing a TSC member to appoint someone to fill in for them when the TSC member can not attend a meeting, etc.  Again, TSC membership is a privilege voted upon by the community. It is not transferable. Just say no. <cbf>+1</cbf>
 
6) Remove the start up clause of the charter 4.a.i
This was only valid for the first six months of HYperledger. Not sure we need it any longer. <cbf>It no longer applies, but not sure that removing it is necessary as the caveat is clear.</cbf>
 
7) Reconcile modify the definition of Contributor between 4.a.ii and 4.b.i (see below)
Proposal to change 4.a.ii from:
"An Active Contributor is defined as any Contributor who has had a contribution accepted into the codebase during the prior twelve (12) months."
to:
"An Active Contributor is defined as any Contributor or Maintainer who has had made a technical contribution during the prior twelve (12) months. This can include code accepted into the codebase, actively participating in Working Groups,Committees, etc " <cbf>given multiple projects, there is no "the codebase" per se. I would also extend to the Hyperledger Labs which are growing nicely and part of our broader community. So, maybe:
 
"This can include code or documentation contributed and accepted into an incubating, active, or labs project; active WG participation (as determined by the WG chair)."
 
</cbf>
 
Also modify 4.b.i to replace the word "codebase" with something more expansive to also reflect WG contributions, etc.
 
 
Respectfully
 
-mark
 

4. Technical Steering Committee (“TSC”)

a. Composition

i. Startup Period: During the first six (6) months after project launch, the TSC voting members shall consist of one (1) appointed representative from each Premier Member and each Top Level Project Maintainer, provided that no company (including related companies or affiliates under common control) shall have more than three (3) votes on the TSC.

ii. Steady State: After the Startup Period, there shall be a nomination and election period for electing Contributors or Maintainers to the TSC. The TSC voting members shall consist of eleven (11) elected Contributors or Maintainers chosen by the Active Contributors. An Active Contributor is defined as any Contributor who has had a contribution accepted into the codebase during the prior twelve (12) months. The TSC shall approve the process and timing for nominations and elections held on an annual basis.

b. TSC projects generally will involve Maintainers and Contributors:

i. Contributors: anyone in the technical community that contributes code, documentation or other technical artifacts to the HLP codebase.

ii. Maintainers: Contributors who have the ability to commit code and contributions to a project’s main branch on an HLP project. A Contributor may become a Maintainer by a majority approval of the existing Maintainers.

 
 
On Fri, Aug 9, 2019 at 8:27 PM Baohua Yang <yangbaohua@...> wrote:
I like this idea.
 
Besides, we may consider an automatic opt-out for 3 continuous unexcused absences.
 
And for the number, consider the growing size of the community and more new projects, 17, 19 or 21 are good candidates.
 
Thanks!
 
On Thu, Aug 8, 2019 at 4:18 PM Arnaud Le Hors <lehors@...> wrote:
I support this idea. My only concern with growing the TSC would be the risk of not reaching quorum but if we mitigate this risk with an appropriate measure I think we can only gain from the expansion.
For what it's worth, OASIS has to that end a notion of Voting Rights that you lose after missing 2 meetings and gain back after attending 2 meetings that is easy to implement and works well in my experience:
https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26#gainVotingRights
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM





From:        "Christopher Ferris" <chrisfer@...>
To:        tsc@...
Date:        08/08/2019 02:53 PM
Subject:        [EXTERNAL] [Hyperledger TSC] on expanding the TSC
Sent by:        tsc@...



On today’s TSC call, I noted that when we established Hyperledger, we had 11 Premier members and chose the number of TSC members as a derivative of that. We now have 18 Premier members and a board that has 21 members. We have grown from one to now twelve projects and we have 3 proposed projects in the pipeline. We also have a growing number of WGs that may also be underrepresented. Yet, we have not grown the TSC beyond the original 11. This means that the TSC may not adequately represent the full breadth of our community.

We talked about the prospect of expanding the TSC to enable greater diversity of projects and WGs, as well as of expertise, etc.

Brian noted that CNCF TOB has an elected tier and a provision in their charter that the elected members may also choose a number of individuals from within the community  to serve as well. This might be a good model to emulate.

Any change in the number of TSC members will, of necessity, require a Hyperledger charter revision requiring a 2/3 vote of the board.

I’d like this email to serve as a continuation of today’s discussion hopefully leading to a formal proposal to a charter revision.

I’ll start by suggesting that we find a way of growing the TSC beginning this year, but after the scheduled TSC election, by at least six members. As was also expressed by Mic, we probably also should keep the size manageable, so maybe no more than 21 total.

Ry and Arnaud also suggested maybe adopting a quorum rule that penalized absentee members by removing them from quorum calculation and suspending voting privs following repeated unexcused absences as a device to encourage participation and diminish potential that we not achieve quorum (this seems not to have been a problem excepting in the summer months, but we might consider something as a prophylactic measure.

Thoughts?

Cheers,

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



 

 

 

 
 
--
Best wishes!

Baohua Yang

 

 



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


Re: on expanding the TSC

Mic Bowman
 

+1 on increasing the TSC membership. the diversity of projects and complexity of projects would benefit tremendously from a more diverse TSC. we are more than "platforms" and the representation should reflect that.

i am concerned with "unexcused" absences (or at least absences that were not previously reported to the TSC chair) and the effect on quorum. several of the ideas presented seem to have merit. it does seem likely that many of these would work well and none would be perfect. lets not reinvent the wheel. seems like this might be a great time to adopt arnaud's approach and write up a could of these as concrete proposals we could consider.

--mic


On Sat, Aug 10, 2019 at 1:52 PM mark wagner <mwagner@...> wrote:
Chris and all who have spoken or read the thread.

This a great suggestion. I think that we need to request multiple changes to the charter in regards to the TSC. Plus I am not sure which of these require a charter change (Governing Board vote) vs a TSC vote.

1) Increasing the board size to 17 or 19.
I think that tying the size to the max number of Premium members sends an unintentional message that your money buys a vote (even though that is *not* the case or intent  here). Also, keeping the size "smaller" should make the meetings easier to manage.  we do have a lot of participation in TSC discussions from non TSC members so their voice is heard.

2) I am in favor of the proposal to require attendance.
I think missing two consecutive meetings is a good number to lose your voting rights until you attend your second consecutive meeting. So your first meeting back you can not vote. If you attend the following meeting you can vote. But you miss the second meeting you start prohibition all over.


3) Create the position of a TSC Vice Chair
Note that my thoughts here are about the process and are not intended as a reflection of the people.

It felt wrong to me that we allowed the Chair position to be passed around this year without input / official consent, when the elected, and then Chair appointed person, were both unable to fulfill their obligations / responsibilities. Also please keep in mind that the TSC Chair gets a seat and a vote on the Governing Board, so if the Chair is unable to attend the Board meeting, then the Vice Chair would automatically step up for that meeting.  The Chair is an elected position and TSC should be able to vote on who the position falls to when the Chair is unavailable to fulfill the duties.

So, my thoughts were that the newly elected TSC would vote on both a Chair and a Vice Chair. We should decide if the Vice Chair is the second highest vote tally for the Chair position or if it is a distinct, and concurrent, election at the time we vote for the Chair position.

4) Replacing a TSC member.
There should documented methods to replace a TSC member who is unable or unwilling to fill their term. This can be a single election by the community or an appointment by TSC vote (majority or super majority)?


5) Removing a TSC member (vote of no confidence / impeachment)
There should also be a mechanism to strip someone of their TSC seat / privileges if it is determined that they are no longer willing or able to fulfill their role in good faith or in accordance with the Hyperledger Charter and or bylaws.  This is a big deal so it should be "difficult" to do. So if it is a TSC elected position (Chair, Vice Chair) then a super majority of the TSC is required. If it is a TSC seat then a majority of the community, OR we can leave it to the Governing Board.

Also, if after five consecutive meetings missed you should lose your seat.

5) Delegation of privileges.
There has been some private chatter of allowing a TSC member to appoint someone to fill in for them when the TSC member can not attend a meeting, etc.  Again, TSC membership is a privilege voted upon by the community. It is not transferable. Just say no.

6) Remove the start up clause of the charter 4.a.i
This was only valid for the first six months of HYperledger. Not sure we need it any longer.

7) Reconcile modify the definition of Contributor between 4.a.ii and 4.b.i (see below)
Proposal to change 4.a.ii from:
"An Active Contributor is defined as any Contributor who has had a contribution accepted into the codebase during the prior twelve (12) months."
to:
"An Active Contributor is defined as any Contributor or Maintainer who has had made a technical contribution during the prior twelve (12) months. This can include code accepted into the codebase, actively participating in Working Groups,Committees, etc "

Also modify 4.b.i to replace the word "codebase" with something more expansive to also reflect WG contributions, etc.


Respectfully

-mark

4. Technical Steering Committee (“TSC”)

a. Composition

i. Startup Period: During the first six (6) months after project launch, the TSC voting members shall consist of one (1) appointed representative from each Premier Member and each Top Level Project Maintainer, provided that no company (including related companies or affiliates under common control) shall have more than three (3) votes on the TSC.

ii. Steady State: After the Startup Period, there shall be a nomination and election period for electing Contributors or Maintainers to the TSC. The TSC voting members shall consist of eleven (11) elected Contributors or Maintainers chosen by the Active Contributors. An Active Contributor is defined as any Contributor who has had a contribution accepted into the codebase during the prior twelve (12) months. The TSC shall approve the process and timing for nominations and elections held on an annual basis.

b. TSC projects generally will involve Maintainers and Contributors:

i. Contributors: anyone in the technical community that contributes code, documentation or other technical artifacts to the HLP codebase.

ii. Maintainers: Contributors who have the ability to commit code and contributions to a project’s main branch on an HLP project. A Contributor may become a Maintainer by a majority approval of the existing Maintainers.



On Fri, Aug 9, 2019 at 8:27 PM Baohua Yang <yangbaohua@...> wrote:
I like this idea.

Besides, we may consider an automatic opt-out for 3 continuous unexcused absences.

And for the number, consider the growing size of the community and more new projects, 17, 19 or 21 are good candidates.

Thanks!

On Thu, Aug 8, 2019 at 4:18 PM Arnaud Le Hors <lehors@...> wrote:
I support this idea. My only concern with growing the TSC would be the risk of not reaching quorum but if we mitigate this risk with an appropriate measure I think we can only gain from the expansion.
For what it's worth, OASIS has to that end a notion of Voting Rights that you lose after missing 2 meetings and gain back after attending 2 meetings that is easy to implement and works well in my experience:
https://www.oasis-open.org/policies-guidelines/tc-process-2017-05-26#gainVotingRights
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Christopher Ferris" <chrisfer@...>
To:        tsc@...
Date:        08/08/2019 02:53 PM
Subject:        [EXTERNAL] [Hyperledger TSC] on expanding the TSC
Sent by:        tsc@...




On today’s TSC call, I noted that when we established Hyperledger, we had 11 Premier members and chose the number of TSC members as a derivative of that. We now have 18 Premier members and a board that has 21 members. We have grown from one to now twelve projects and we have 3 proposed projects in the pipeline. We also have a growing number of WGs that may also be underrepresented. Yet, we have not grown the TSC beyond the original 11. This means that the TSC may not adequately represent the full breadth of our community.

We talked about the prospect of expanding the TSC to enable greater diversity of projects and WGs, as well as of expertise, etc.

Brian noted that CNCF TOB has an elected tier and a provision in their charter that the elected members may also choose a number of individuals from within the community  to serve as well. This might be a good model to emulate.

Any change in the number of TSC members will, of necessity, require a Hyperledger charter revision requiring a 2/3 vote of the board.

I’d like this email to serve as a continuation of today’s discussion hopefully leading to a formal proposal to a charter revision.

I’ll start by suggesting that we find a way of growing the TSC beginning this year, but after the scheduled TSC election, by at least six members. As was also expressed by Mic, we probably also should keep the size manageable, so maybe no more than 21 total.

Ry and Arnaud also suggested maybe adopting a quorum rule that penalized absentee members by removing them from quorum calculation and suspending voting privs following repeated unexcused absences as a device to encourage participation and diminish potential that we not achieve quorum (this seems not to have been a problem excepting in the summer months, but we might consider something as a prophylactic measure.

Thoughts?

Cheers,

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

blog: https://developer.ibm.com/code/author/chrisfer/
IBM Open Source white paper: https://developer.ibm.com/articles/cl-open-architecture-update/
phone:
+1 508 667 0402






--
Best wishes!

Baohua Yang



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

1361 - 1380 of 3893