Date   

Re: [External] [Hyperledger TSC] Agenda for TSC call on Feb 11, 2021

Baohua Yang
 

Hi, Arnaud and team
Sorry I cannot make it this week.

On Wed, Feb 10, 2021 at 6:09 PM Kuhrt, Tracy A. via lists.hyperledger.org <tracy.a.kuhrt=accenture.com@...> wrote:
I will not be able to attend the call tomorrow. 

Tracy


From: tsc@... <tsc@...> on behalf of Arnaud Le Hors <lehors@...>
Sent: Wednesday, February 10, 2021 11:04:12 AM
To: Hyperledger List <tsc@...>
Subject: [External] [Hyperledger TSC] Agenda for TSC call on Feb 11, 2021
 
This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments.

Hi all,

There are a lot of items we could discuss tomorrow. I selected a few for which I hope we can make some progress.

https://wiki.hyperledger.org/display/TSC/2021+02+11+TSC+Meeting+Record

Talk to you then.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




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

www.accenture.com



--
Best wishes!

Baohua Yang


Re: [External] [Hyperledger TSC] Agenda for TSC call on Feb 11, 2021

Kuhrt, Tracy A.
 

I will not be able to attend the call tomorrow. 

Tracy


From: tsc@... <tsc@...> on behalf of Arnaud Le Hors <lehors@...>
Sent: Wednesday, February 10, 2021 11:04:12 AM
To: Hyperledger List <tsc@...>
Subject: [External] [Hyperledger TSC] Agenda for TSC call on Feb 11, 2021
 
This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links and attachments.

Hi all,

There are a lot of items we could discuss tomorrow. I selected a few for which I hope we can make some progress.

https://wiki.hyperledger.org/display/TSC/2021+02+11+TSC+Meeting+Record

Talk to you then.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




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

www.accenture.com


Agenda for TSC call on Feb 11, 2021

Arnaud Le Hors
 

Hi all,

There are a lot of items we could discuss tomorrow. I selected a few for which I hope we can make some progress.

https://wiki.hyperledger.org/display/TSC/2021+02+11+TSC+Meeting+Record

Talk to you then.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM


Re: Question about license and a way to identify exceptions

Arnaud Le Hors
 

Hi,

Thank you for bringing this up. I'm not aware of any exception being requested and/or granted. I'll put this on the agenda for discussion.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "Arun S M" <arun.s.m.cse@...>
To:        "Technical Steering Committee (TSC)" <tsc@...>
Date:        02/09/2021 07:39 PM
Subject:        [EXTERNAL] [Hyperledger TSC] Question about license and a way to identify exceptions
Sent by:        tsc@...



Hi,

I was going through Hyperledger labs repositories for some other purpose when I found this project submitted by one of the active volunteers at Hyperledger India Chapter. It has been put under MIT license. When I searched for the charter and information on licensing, it is mentioned that there will be an exception process if it is not Apache 2.0. However, I am not sure if this project went through that process.

GitHub: https://github.com/hyperledger-labs/HL-StarterKit
Wiki: https://wiki.hyperledger.org/display/HYP/FAQ#FAQ-CanIuseHyperledgerwithinmyproduct?Whatarethelicenserequirements?
Section 12 of charter document: https://www.hyperledger.org/about/charter

In the next Hyperledger India Chapter community meeting on Thursday, I will talk to the creator of the project about this.
But these questions exist
1. Was there an exception process? If so, where do we document it and how can we reference the exception process from this repository in future?
2. Shall we define a way to identify exceptions directly from the repository?
3. Should this be the responsibility of the lab steward or the sponsor?

Going back to another discussion/email on the need for a sponsor, if lab stewards can handle these then good enough.
I agree to Brian's point that the more volunteers the better will be participation and engagement.

Regards,
Arun




Re: SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects

VIPIN BHARATHAN
 

Arun SM,

I guess you are referring to Vipin Rathi in your email- 

Labs may become top-level projects like Ursa and Cactus did.
Not all labs want to be top-level projects.

I (Vipin Bharathan) was the sponsor of
inter-carrier-settlements  from telecom-sig for which Vipin Rathi was a maintainer; I had been following the discussion about inter-carrier settlements from the telecom SIG. and I thought it was a worthy project. Inter-carrier settlement was a use-case that was quite active in the UK (independent of the telecom SIG).

nter-carrier-settlements is now archived. 
There was nothing created except for the readme file. Mainly due to the main maintainer being busy with other activity and another one dropping out.

About the licensing issue, I see two projects with no license file, 3 with CC-By-4.0 and of course the one with MIT.
All others (37) have Apache 2.0

Again, to reiterate, the sponsors do not usually engage with the project other than the initial sponsorship.

VipinB 

dlt.nyc
Vipin Bharathan
Digital Transformation Consultant
Financial Services (Blockchain, ML, Design Thinking)
vip@...


From: tsc@... <tsc@...> on behalf of Arun S M via lists.hyperledger.org <arun.s.m.cse=gmail.com@...>
Sent: Tuesday, February 9, 2021 2:00 PM
To: Arnaud Le Hors <lehors@...>
Cc: tsc@... <tsc@...>
Subject: Re: [Hyperledger TSC] SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects
 
This sounds to me like "I know somebody who the Hyperledger community already knows, that person likes my project so I am proposing it".
I guess the problem Vipin brought up is to make it sound like "I have an idea, let me propose it to Hyperledger labs, if the community likes it then it has potential to become a top level project".
Correct me if I am wrong. This is what I could infer from the SIG members meeting notes.

To simplify the process, we could follow the PR process. The reviewers (stewards or active volunteers) can have direct feedback on necessary parameters.
Brian brought up good points in the earlier thread. The reasons why we cannot simply ignore the concept of a sponsor.

On the point that Vipin brought up - developer pain points, standard process followed etc.
Randomly thinking about these problems, shall we make short videos on explaining them?
Ex: Tell that DCO sign-off is mandatory, show how it looks like and what it means.

Regards,
Arun

On Tue, Feb 9, 2021 at 2:26 AM Arnaud Le Hors <lehors@...> wrote:
As things stand, the role of sponsors is defined with:

"The role of the sponsor is to officially endorse the proposed lab, indicating in doing so that they believe the proposal is worthy of being given a space among the hyperledger labs. Sponsors may also serve as mentors to the project but how much sponsors are involved in the lab beyond its launch is up to them."

See https://wiki.hyperledger.org/display/TSC/2019+02+14+TSC+Minutes
"Informal decision: no objections so we accept the definition as is."
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "VIPIN BHARATHAN" <vip@...>
To:        "tsc@..." <tsc@...>, "bbehlendorf@..." <bbehlendorf@...>
Date:        02/08/2021 09:34 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects
Sent by:        tsc@...



Brian,

I agree that governance should be imposed. DCOs are enforced by the rules setup inside the labs for example.

Sponsors do not do any of the other tasks than "sponsor" the projects, basically a review of the proposal, Lab Stewards do that as well.

In fact we have been having discussions about "processes that encourage contribution; using Git correctly" etc. for all projects, not just the labs. These efforts can be extended to labs as well.
Let us be very clear about what the Sponsors actually do (or don't do) before we say we require them.

Thanks

dlt.nyc
Vipin Bharathan
Digital Transformation Consultant
Financial Services (Blockchain, ML, Design Thinking)
vip@...



From: tsc@... <tsc@...> on behalf of Brian Behlendorf via lists.hyperledger.org <bbehlendorf=linuxfoundation.org@...>
Sent:
Monday, February 8, 2021 3:05 PM
To:
tsc@... <tsc@...>
Subject:
Re: [Hyperledger TSC] SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects

 
There are some basic things we need the developers involved with each effort within Labs to do (for example, using DCOs), and some things they should be doing (using processes that encourage contribution; using Git correctly; etc). Labs that don't do them create operational, reputational, and potentially legal liability for Hyperledger. That liability is on the shoulders of the TSC and Governing Board, who delegate it down to the Labs stewards.

If the Labs stewards are happy policing for and enforcing the things that must be done, and working with communities on the things that should be done, then great. But the point of Sponsors has always been to fan out those responsibilities and efforts to a larger group who could be trusted to perform those roles. Attaching that limit to other maintainers helped ensure it was people who understood those needs and shoulds (though we could always do a better job documenting them). If there aren't enough volunteers for that work, that quite reasonably sets a limit to the number of projects we should have in Labs. It had very little to do with evaluating the quality of a Labs proposal, except to infer that poor quality proposals might not attract a qualified Sponsor.

The TSC can choose to do away with the Sponsor requirement, but not with the responsibilities for governance. If that's preferred, let's just create a page linking to github repositories (hosted by other organizations) of projects we think are doing good things but are otherwise not overseeing.

Brian

On 2/8/21 6:34 AM, VIPIN BHARATHAN wrote:
Currently, there are no asks for the sponsor except to stand behind the process of application, they are not expected to engage beyond that point.

dlt.nyc
Vipin Bharathan
Digital Transformation Consultant
Financial Services (Blockchain, ML, Design Thinking)
vip@...



From: Arun .S.M. <arun.s.m.cse@...>
Sent:
Monday, February 8, 2021 9:05 AM
To:
VIPIN BHARATHAN
<vip@...>
Cc:
tracy.a.kuhrt@...<tracy.a.kuhrt@...>; lehors@...<lehors@...>; SIG-Chairs@...<SIG-Chairs@...>; tsc@...<tsc@...>
Subject:
Re: [Hyperledger TSC] SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects

 
It could be because I don't know about it much further.
Is the sponsor of the project held accountable with additional responsibility?

For example, does it become the sponsor's responsibility to ensure the project follows Hyperledger's guidelines, guide through for a couple of months for best practices etc?
If this is the case then let's discuss how these can be delegated off from the sponsor's shoulder to anybody else in the community.

Regards,
Arun


--
Brian Behlendorf
Managing Director for Blockchain, Healthcare and Identity
bbehlendorf@...
Twitter: @brianbehlendorf



Re: SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects

Arun S M
 

This sounds to me like "I know somebody who the Hyperledger community already knows, that person likes my project so I am proposing it".
I guess the problem Vipin brought up is to make it sound like "I have an idea, let me propose it to Hyperledger labs, if the community likes it then it has potential to become a top level project".
Correct me if I am wrong. This is what I could infer from the SIG members meeting notes.

To simplify the process, we could follow the PR process. The reviewers (stewards or active volunteers) can have direct feedback on necessary parameters.
Brian brought up good points in the earlier thread. The reasons why we cannot simply ignore the concept of a sponsor.

On the point that Vipin brought up - developer pain points, standard process followed etc.
Randomly thinking about these problems, shall we make short videos on explaining them?
Ex: Tell that DCO sign-off is mandatory, show how it looks like and what it means.

Regards,
Arun


On Tue, Feb 9, 2021 at 2:26 AM Arnaud Le Hors <lehors@...> wrote:
As things stand, the role of sponsors is defined with:

"The role of the sponsor is to officially endorse the proposed lab, indicating in doing so that they believe the proposal is worthy of being given a space among the hyperledger labs. Sponsors may also serve as mentors to the project but how much sponsors are involved in the lab beyond its launch is up to them."

See https://wiki.hyperledger.org/display/TSC/2019+02+14+TSC+Minutes
"Informal decision: no objections so we accept the definition as is."
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "VIPIN BHARATHAN" <vip@...>
To:        "tsc@..." <tsc@...>, "bbehlendorf@..." <bbehlendorf@...>
Date:        02/08/2021 09:34 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects
Sent by:        tsc@...



Brian,

I agree that governance should be imposed. DCOs are enforced by the rules setup inside the labs for example.

Sponsors do not do any of the other tasks than "sponsor" the projects, basically a review of the proposal, Lab Stewards do that as well.

In fact we have been having discussions about "processes that encourage contribution; using Git correctly" etc. for all projects, not just the labs. These efforts can be extended to labs as well.
Let us be very clear about what the Sponsors actually do (or don't do) before we say we require them.

Thanks

dlt.nyc
Vipin Bharathan
Digital Transformation Consultant
Financial Services (Blockchain, ML, Design Thinking)
vip@...



From: tsc@... <tsc@...> on behalf of Brian Behlendorf via lists.hyperledger.org <bbehlendorf=linuxfoundation.org@...>
Sent:
Monday, February 8, 2021 3:05 PM
To:
tsc@... <tsc@...>
Subject:
Re: [Hyperledger TSC] SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects

 
There are some basic things we need the developers involved with each effort within Labs to do (for example, using DCOs), and some things they should be doing (using processes that encourage contribution; using Git correctly; etc). Labs that don't do them create operational, reputational, and potentially legal liability for Hyperledger. That liability is on the shoulders of the TSC and Governing Board, who delegate it down to the Labs stewards.

If the Labs stewards are happy policing for and enforcing the things that must be done, and working with communities on the things that should be done, then great. But the point of Sponsors has always been to fan out those responsibilities and efforts to a larger group who could be trusted to perform those roles. Attaching that limit to other maintainers helped ensure it was people who understood those needs and shoulds (though we could always do a better job documenting them). If there aren't enough volunteers for that work, that quite reasonably sets a limit to the number of projects we should have in Labs. It had very little to do with evaluating the quality of a Labs proposal, except to infer that poor quality proposals might not attract a qualified Sponsor.

The TSC can choose to do away with the Sponsor requirement, but not with the responsibilities for governance. If that's preferred, let's just create a page linking to github repositories (hosted by other organizations) of projects we think are doing good things but are otherwise not overseeing.

Brian

On 2/8/21 6:34 AM, VIPIN BHARATHAN wrote:
Currently, there are no asks for the sponsor except to stand behind the process of application, they are not expected to engage beyond that point.

dlt.nyc
Vipin Bharathan
Digital Transformation Consultant
Financial Services (Blockchain, ML, Design Thinking)
vip@...



From: Arun .S.M. <arun.s.m.cse@...>
Sent:
Monday, February 8, 2021 9:05 AM
To:
VIPIN BHARATHAN
<vip@...>
Cc:
tracy.a.kuhrt@...<tracy.a.kuhrt@...>; lehors@...<lehors@...>; SIG-Chairs@...<SIG-Chairs@...>; tsc@...<tsc@...>
Subject:
Re: [Hyperledger TSC] SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects

 
It could be because I don't know about it much further.
Is the sponsor of the project held accountable with additional responsibility?

For example, does it become the sponsor's responsibility to ensure the project follows Hyperledger's guidelines, guide through for a couple of months for best practices etc?
If this is the case then let's discuss how these can be delegated off from the sponsor's shoulder to anybody else in the community.

Regards,
Arun


--
Brian Behlendorf
Managing Director for Blockchain, Healthcare and Identity
bbehlendorf@...
Twitter: @brianbehlendorf



Question about license and a way to identify exceptions

Arun S M
 

Hi,

I was going through Hyperledger labs repositories for some other purpose when I found this project submitted by one of the active volunteers at Hyperledger India Chapter. It has been put under MIT license. When I searched for the charter and information on licensing, it is mentioned that there will be an exception process if it is not Apache 2.0. However, I am not sure if this project went through that process.

Section 12 of charter document: https://www.hyperledger.org/about/charter

In the next Hyperledger India Chapter community meeting on Thursday, I will talk to the creator of the project about this.
But these questions exist
1. Was there an exception process? If so, where do we document it and how can we reference the exception process from this repository in future?
2. Shall we define a way to identify exceptions directly from the repository?
3. Should this be the responsibility of the lab steward or the sponsor?

Going back to another discussion/email on the need for a sponsor, if lab stewards can handle these then good enough.
I agree to Brian's point that the more volunteers the better will be participation and engagement.

Regards,
Arun


Tomorrow's CMSIG call at 10 am EST-

VIPIN BHARATHAN
 

Hi all,

Presenting an overview of today's clearing solutions as well as an alternative. 
Volatility and settlement delay contribute to friction and inefficiencies in the market, disadvantaging retail investors. 
The Robinhood GME saga is used to illustrate the weaknesses.

dFMI (decentralized Financial Market Infrastructure) can solve the problem. 
Towards a 24/7 market and the case for ad-hoc settlement. 
otc.Digital has a decentralized clearing solution as part of their post-trade framework buildout on the blockchain. 
The presentation will give a glimpse into an actual solution, not a pie in the sky future.

Where: https://zoom.us/my/hyperledger.community.backup?pwd=dkJKdHRlc3dNZEdKR1JYdW40R2pDUT09
When: February 10th, 10:00 am EST(15:00 UTC)
Discuss: https://wiki.hyperledger.org/display/CMSIG/2021-02-10




dlt.nyc
Vipin Bharathan
Digital Transformation Consultant
Financial Services (Blockchain, ML, Design Thinking)
vip@...


Re: SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects

Arnaud Le Hors
 

As things stand, the role of sponsors is defined with:

"The role of the sponsor is to officially endorse the proposed lab, indicating in doing so that they believe the proposal is worthy of being given a space among the hyperledger labs. Sponsors may also serve as mentors to the project but how much sponsors are involved in the lab beyond its launch is up to them."

See https://wiki.hyperledger.org/display/TSC/2019+02+14+TSC+Minutes
"Informal decision: no objections so we accept the definition as is."
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "VIPIN BHARATHAN" <vip@...>
To:        "tsc@..." <tsc@...>, "bbehlendorf@..." <bbehlendorf@...>
Date:        02/08/2021 09:34 PM
Subject:        [EXTERNAL] Re: [Hyperledger TSC] SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects
Sent by:        tsc@...



Brian,

I agree that governance should be imposed. DCOs are enforced by the rules setup inside the labs for example.

Sponsors do not do any of the other tasks than "sponsor" the projects, basically a review of the proposal, Lab Stewards do that as well.

In fact we have been having discussions about "processes that encourage contribution; using Git correctly" etc. for all projects, not just the labs. These efforts can be extended to labs as well.
Let us be very clear about what the Sponsors actually do (or don't do) before we say we require them.

Thanks

dlt.nyc
Vipin Bharathan
Digital Transformation Consultant
Financial Services (Blockchain, ML, Design Thinking)
vip@...



From: tsc@... <tsc@...> on behalf of Brian Behlendorf via lists.hyperledger.org <bbehlendorf=linuxfoundation.org@...>
Sent:
Monday, February 8, 2021 3:05 PM
To:
tsc@... <tsc@...>
Subject:
Re: [Hyperledger TSC] SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects

 
There are some basic things we need the developers involved with each effort within Labs to do (for example, using DCOs), and some things they should be doing (using processes that encourage contribution; using Git correctly; etc). Labs that don't do them create operational, reputational, and potentially legal liability for Hyperledger. That liability is on the shoulders of the TSC and Governing Board, who delegate it down to the Labs stewards.

If the Labs stewards are happy policing for and enforcing the things that must be done, and working with communities on the things that should be done, then great. But the point of Sponsors has always been to fan out those responsibilities and efforts to a larger group who could be trusted to perform those roles. Attaching that limit to other maintainers helped ensure it was people who understood those needs and shoulds (though we could always do a better job documenting them). If there aren't enough volunteers for that work, that quite reasonably sets a limit to the number of projects we should have in Labs. It had very little to do with evaluating the quality of a Labs proposal, except to infer that poor quality proposals might not attract a qualified Sponsor.

The TSC can choose to do away with the Sponsor requirement, but not with the responsibilities for governance. If that's preferred, let's just create a page linking to github repositories (hosted by other organizations) of projects we think are doing good things but are otherwise not overseeing.

Brian

On 2/8/21 6:34 AM, VIPIN BHARATHAN wrote:
Currently, there are no asks for the sponsor except to stand behind the process of application, they are not expected to engage beyond that point.

dlt.nyc
Vipin Bharathan
Digital Transformation Consultant
Financial Services (Blockchain, ML, Design Thinking)
vip@...



From: Arun .S.M. <arun.s.m.cse@...>
Sent:
Monday, February 8, 2021 9:05 AM
To:
VIPIN BHARATHAN
<vip@...>
Cc:
tracy.a.kuhrt@...<tracy.a.kuhrt@...>; lehors@...<lehors@...>; SIG-Chairs@...<SIG-Chairs@...>; tsc@...<tsc@...>
Subject:
Re: [Hyperledger TSC] SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects

 
It could be because I don't know about it much further.
Is the sponsor of the project held accountable with additional responsibility?

For example, does it become the sponsor's responsibility to ensure the project follows Hyperledger's guidelines, guide through for a couple of months for best practices etc?
If this is the case then let's discuss how these can be delegated off from the sponsor's shoulder to anybody else in the community.

Regards,
Arun


--
Brian Behlendorf
Managing Director for Blockchain, Healthcare and Identity
bbehlendorf@...
Twitter: @brianbehlendorf



Re: SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects

VIPIN BHARATHAN
 

Brian,

I agree that governance should be imposed. DCOs are enforced by the rules setup inside the labs for example.

Sponsors do not do any of the other tasks than "sponsor" the projects, basically a review of the proposal, Lab Stewards do that as well.

In fact we have been having discussions about "processes that encourage contribution; using Git correctly" etc. for all projects, not just the labs. These efforts can be extended to labs as well.
Let us be very clear about what the Sponsors actually do (or don't do) before we say we require them.

Thanks

dlt.nyc
Vipin Bharathan
Digital Transformation Consultant
Financial Services (Blockchain, ML, Design Thinking)
vip@...


From: tsc@... <tsc@...> on behalf of Brian Behlendorf via lists.hyperledger.org <bbehlendorf=linuxfoundation.org@...>
Sent: Monday, February 8, 2021 3:05 PM
To: tsc@... <tsc@...>
Subject: Re: [Hyperledger TSC] SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects
 
There are some basic things we need the developers involved with each effort within Labs to do (for example, using DCOs), and some things they should be doing (using processes that encourage contribution; using Git correctly; etc). Labs that don't do them create operational, reputational, and potentially legal liability for Hyperledger. That liability is on the shoulders of the TSC and Governing Board, who delegate it down to the Labs stewards.

If the Labs stewards are happy policing for and enforcing the things that must be done, and working with communities on the things that should be done, then great. But the point of Sponsors has always been to fan out those responsibilities and efforts to a larger group who could be trusted to perform those roles. Attaching that limit to other maintainers helped ensure it was people who understood those needs and shoulds (though we could always do a better job documenting them). If there aren't enough volunteers for that work, that quite reasonably sets a limit to the number of projects we should have in Labs. It had very little to do with evaluating the quality of a Labs proposal, except to infer that poor quality proposals might not attract a qualified Sponsor.

The TSC can choose to do away with the Sponsor requirement, but not with the responsibilities for governance. If that's preferred, let's just create a page linking to github repositories (hosted by other organizations) of projects we think are doing good things but are otherwise not overseeing.

Brian

On 2/8/21 6:34 AM, VIPIN BHARATHAN wrote:
Currently, there are no asks for the sponsor except to stand behind the process of application, they are not expected to engage beyond that point.

dlt.nyc
Vipin Bharathan
Digital Transformation Consultant
Financial Services (Blockchain, ML, Design Thinking)


From: Arun .S.M. <arun.s.m.cse@...>
Sent: Monday, February 8, 2021 9:05 AM
To: VIPIN BHARATHAN <vip@...>
Cc: tracy.a.kuhrt@... <tracy.a.kuhrt@...>; lehors@... <lehors@...>; SIG-Chairs@... <SIG-Chairs@...>; tsc@... <tsc@...>
Subject: Re: [Hyperledger TSC] SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects
 
It could be because I don't know about it much further.
Is the sponsor of the project held accountable with additional responsibility?

For example, does it become the sponsor's responsibility to ensure the project follows Hyperledger's guidelines, guide through for a couple of months for best practices etc?
If this is the case then let's discuss how these can be delegated off from the sponsor's shoulder to anybody else in the community.

Regards,
Arun


-- 
Brian Behlendorf
Managing Director for Blockchain, Healthcare and Identity
bbehlendorf@...
Twitter: @brianbehlendorf


Re: SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects

Brian Behlendorf
 

There are some basic things we need the developers involved with each effort within Labs to do (for example, using DCOs), and some things they should be doing (using processes that encourage contribution; using Git correctly; etc). Labs that don't do them create operational, reputational, and potentially legal liability for Hyperledger. That liability is on the shoulders of the TSC and Governing Board, who delegate it down to the Labs stewards.

If the Labs stewards are happy policing for and enforcing the things that must be done, and working with communities on the things that should be done, then great. But the point of Sponsors has always been to fan out those responsibilities and efforts to a larger group who could be trusted to perform those roles. Attaching that limit to other maintainers helped ensure it was people who understood those needs and shoulds (though we could always do a better job documenting them). If there aren't enough volunteers for that work, that quite reasonably sets a limit to the number of projects we should have in Labs. It had very little to do with evaluating the quality of a Labs proposal, except to infer that poor quality proposals might not attract a qualified Sponsor.

The TSC can choose to do away with the Sponsor requirement, but not with the responsibilities for governance. If that's preferred, let's just create a page linking to github repositories (hosted by other organizations) of projects we think are doing good things but are otherwise not overseeing.

Brian

On 2/8/21 6:34 AM, VIPIN BHARATHAN wrote:
Currently, there are no asks for the sponsor except to stand behind the process of application, they are not expected to engage beyond that point.

dlt.nyc
Vipin Bharathan
Digital Transformation Consultant
Financial Services (Blockchain, ML, Design Thinking)


From: Arun .S.M. <arun.s.m.cse@...>
Sent: Monday, February 8, 2021 9:05 AM
To: VIPIN BHARATHAN <vip@...>
Cc: tracy.a.kuhrt@... <tracy.a.kuhrt@...>; lehors@... <lehors@...>; SIG-Chairs@... <SIG-Chairs@...>; tsc@... <tsc@...>
Subject: Re: [Hyperledger TSC] SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects
 
It could be because I don't know about it much further.
Is the sponsor of the project held accountable with additional responsibility?

For example, does it become the sponsor's responsibility to ensure the project follows Hyperledger's guidelines, guide through for a couple of months for best practices etc?
If this is the case then let's discuss how these can be delegated off from the sponsor's shoulder to anybody else in the community.

Regards,
Arun


-- 
Brian Behlendorf
Managing Director for Blockchain, Healthcare and Identity
bbehlendorf@...
Twitter: @brianbehlendorf


Re: [Hyperledger SIG Chairs] SIG Request for Support from Technical Community: Technical contributors

Christopher Ferris
 

This thread contains lots of good advice, but no practical actionable recommendations.
 
The reality is that some of the projects offer more comprehensive guidance for contributors than others. Those are more
likely to attract contributors. Retaining them is another issue entirely.
 
Without getting into specific criticisms, I would note that some of the projects do indeed make it difficult to find
(or impossible) how to contribute and that every project could use some introspection/reflection.
 
Someone observed that each project handles things differently, which is very true. We couldn't impose a specific
process on all for any number of reasons. However, assembling the advice in this thread, and which many of us have
internalized over time to be easily shared for new or foundering projects would be a useful exercise.
 
FWIW, I think Fabric and Besu seem to have the most comprehensive guidance and are worthy of emulation. One last thought,
projects with multiple repositories should ideally link their collective repos to a single canonical and authoritative CONTRIBUTING.md.
 
Cheers,

Christopher Ferris IBM Fellow, CTO Open Technology
twitter: @christo4ferris | phone: +1 508 667 0402 | blog: 
https://developer.ibm.com/profiles/chrisfer/
 
 

----- Original message -----
From: "Sean Young" <sean@...>
Sent by: tsc@...
To: Ry Jones <rjones@...>
Cc: Arun S M <arun.s.m.cse@...>, David Boswell <dboswell@...>, Tracy Kuhrt <tracy.a.kuhrt@...>, "tsc@..." <tsc@...>, "SIG-Chairs@..." <SIG-Chairs@...>
Subject: [EXTERNAL] Re: [Hyperledger TSC] [Hyperledger SIG Chairs] SIG Request for Support from Technical Community: Technical contributors
Date: Mon, Feb 8, 2021 1:14 PM
 
Hi Ry,

On Mon, Feb 08, 2021 at 10:06:27AM -0800, Ry Jones wrote:
> We do have some of this information in the Hyperledger overview
> <https://tinyurl.com/yyenka9n >; that data is available per-project (and
> per-repo) as well.
>
> There is also timing data <https://tinyurl.com/yy87mzhr >.

That is good; better is if this is documented for potential contributers.
This gives a warm fuzzy feeling of "my contribution is welcome here".

Much more so than reading the tealeaves of how a project behaves.


Thanks

Sean

> Ry
>
> On Mon, Feb 8, 2021 at 9:49 AM Sean Young <sean@...> wrote:
>
> > 1. Time to review a PR
> >    Users should know that their PR will get a full review within e.g.
> >    14 days. Escalation routes should be documented, e.g. post in this
> >    rocketchat channel "my PR has not been reviewed, it has been 14 days".
> >
> >    This includes every re-review after rework.
> >
> --
> Ry Jones
> Community Architect, Hyperledger
> Chat <https://www.youtube.com/watch?v=EEc4JRyaAoA >: @rjones
> <https://chat.hyperledger.org/direct/rjones > Calendar
> <https://calendly.com/ryjones >




 
 


Re: [Hyperledger SIG Chairs] SIG Request for Support from Technical Community: Technical contributors

Sean Young
 

Hi Ry,

On Mon, Feb 08, 2021 at 10:06:27AM -0800, Ry Jones wrote:
We do have some of this information in the Hyperledger overview
<https://tinyurl.com/yyenka9n>; that data is available per-project (and
per-repo) as well.

There is also timing data <https://tinyurl.com/yy87mzhr>.
That is good; better is if this is documented for potential contributers.
This gives a warm fuzzy feeling of "my contribution is welcome here".

Much more so than reading the tealeaves of how a project behaves.


Thanks

Sean

Ry

On Mon, Feb 8, 2021 at 9:49 AM Sean Young <sean@mess.org> wrote:

1. Time to review a PR
Users should know that their PR will get a full review within e.g.
14 days. Escalation routes should be documented, e.g. post in this
rocketchat channel "my PR has not been reviewed, it has been 14 days".

This includes every re-review after rework.
--
Ry Jones
Community Architect, Hyperledger
Chat <https://www.youtube.com/watch?v=EEc4JRyaAoA>: @rjones
<https://chat.hyperledger.org/direct/rjones> Calendar
<https://calendly.com/ryjones>


Re: SIG Request for Support from Technical Community: Defining Standards

Brian Behlendorf
 

(I've moved SIG-chairs to Bcc so that they're not caught in follow-up replies as a courtesy, but feel free to follow along on the TSC list)

Recently, the Linux Foundation has done more with open specifications as they relate to software work, and specifically in ways to enable "umbrella" projects like ours to have a separately chartered project that can focus on specifications. See here:

We could launch a Hyperledger specifications project (or series of projects), operating based on this CommunitySpecification process.

It would require:

1) Use of a Contributor License Agreement for anyone participating in that project (this is separate from / above our standard DCO)

2) The drafting of a scope for specifications within that project - so we should discuss level of granularity, do we have a project focused on Aries-ish specifications, anything identity, or anything DLT-related? We can have more than one such spec project, but they'll each require Governing Board approval.

3) Committed volunteers from the TSC or community to help us keep the process on track - the scope of which isn't yet clear to me. It is clear that we need a champion or two for this idea to come from the community - it's not something I'll push top-down.

4) It would be a best practice for the name of these specs to be different from the name of HL software packages, so that independent implementations aren't discouraged.

There are likely other ramifications; maybe those who've been involved with TOIP or other such CommunitySpecification-based efforts can share what they've experienced.

I'm not convinced that the Aries specification work wouldn't be better handled at TOIP than at HL, or that we have other useful standards work to that couldn't be better handled elsewhere. But I will say if a neutral zone like this has been a barrier to collaboration even just between our own projects, that's a great reason to do something along these lines at HL.

Any takers?

Brian

On 2/8/21 6:28 AM, VIPIN BHARATHAN wrote:
Hi all,

I have heard from Brian several times that Hyperledger is not a standards organization, which stands to reason.  
There is a survey of Blockchain standards in GSMI. This illustrates the dictum that standards are so great because there are so many of them.
One of the points that GSMI brought up is the need for the SDOs (Standards Development Organizations) to co-ordinate, plus the fact that orgs like ISO are closed to regular folks and that they charge a lot for their standards.

I chair the Interoperability workstream in Digital Currency Global Initiative (DCGI) - a collaboration between ITU-T (an SDO) and Stanford. This is open for participation and one of their methods is to study use cases for extracting common elements and the state of the art of implementations which are far in advance of standards settings. I invite the HL cactus folks to present on this topic.  The DCGI will publish a roadmap towards standards for Digital Currencies, the ur-use case for Blockchain. The working groups in DCGI include Policy & Governance, Architecture, & Security. 

Best

dlt.nyc
Vipin Bharathan
Digital Transformation Consultant
Financial Services (Blockchain, ML, Design Thinking)


From: tsc@... <tsc@...> on behalf of Arnaud Le Hors via lists.hyperledger.org <lehors=us.ibm.com@...>
Sent: Monday, February 8, 2021 7:43 AM
To: tracy.a.kuhrt@... <tracy.a.kuhrt@...>
Cc: SIG-Chairs@... <SIG-Chairs@...>; tsc@... <tsc@...>
Subject: Re: [Hyperledger TSC] SIG Request for Support from Technical Community: Defining Standards
 
Hi,
I think this actually raises a couple of issues.

The first one is the framework to develop standards within Hyperledger. Hyperledger wasn't set up to develop standards. The belief was that this would be done in other organizations and we would merely focus on implementation. That question was recently raised in the context of the Aries project which has been in fact developing a specification. I will let Brian speak up about what we can do here.

The second one is a question of socialization of the work happening in different parts of Hyperledger. This is a need we have across Hyperledger. The TSC has had several discussions about what we could do to help projects know more about each other so that opportunities for collaboration could be seized - projects often work on similar topics in isolation due to a lack of awareness. We clearly haven't figured this one out yet and ought to give this another look.

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




From:        "Kuhrt, Tracy A. via lists.hyperledger.org" <tracy.a.kuhrt=accenture.com@...>
To:        "tsc@..." <tsc@...>
Cc:        "SIG-Chairs@..." <SIG-Chairs@...>
Date:        02/04/2021 11:01 PM
Subject:        [EXTERNAL] [Hyperledger TSC] SIG Request for Support from Technical Community: Defining Standards
Sent by:        tsc@...


On January 11th, I provided a report back on the SIG chair meetingthat I attended. On our TSC call on January 14th, we had some initial discussions about each of the items that I reported back on. It was suggested that I break out the individual items so that if there were any additional thoughts on the topic that we could discuss in a single thread instead of mixing topics.

 

This is the email to discuss item #1 Defining standards -- data standards, process standards.  How to get standards to interoperate.  How to break things out of silos since different SIGs are working on standards in separate groups.  Can presenting these standards efforts to the TSC help break these out of standards?  Can the technical community help with implementation of the standards?

 

Here is what has been mentioned on the previous thread so far regarding this topic:

 

From Arun:

Do we need to streamline the outcomes of these standardization activities? TSC can help here by reviewing current modes of collaboration. Another way TSC can be involved is to review the content as you suggested. TSC could guide SIGs on what is possible, already available, what alternatives are available, be able to bridge to other similar outcomes. This will help TSC in a way to respond to project needs and requests.

 

Tracy

 





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

www.accenture.com




-- 
Brian Behlendorf
Managing Director for Blockchain, Healthcare and Identity
bbehlendorf@...
Twitter: @brianbehlendorf


Re: [Hyperledger SIG Chairs] SIG Request for Support from Technical Community: Technical contributors

Ry Jones
 

We do have some of this information in the Hyperledger overview; that data is available per-project (and per-repo) as well.

There is also timing data.
Ry


On Mon, Feb 8, 2021 at 9:49 AM Sean Young <sean@...> wrote:
1. Time to review a PR
   Users should know that their PR will get a full review within e.g.
   14 days. Escalation routes should be documented, e.g. post in this
   rocketchat channel "my PR has not been reviewed, it has been 14 days".

   This includes every re-review after rework.
--
Ry Jones
Community Architect, Hyperledger


Re: [Hyperledger SIG Chairs] SIG Request for Support from Technical Community: Technical contributors

Sean Young
 

On Sat, Feb 06, 2021 at 06:50:36PM +0530, Arun S M wrote:
Adding onto this discussion,

The entry barriers that I have found while asking the developer community
to get involved are
1. First time contributors think that they need to spend a significant
amount of time before making attempts to contribute. They are unsure of
their code acceptance by a project.
I think this is part of a larger problem. When contributing to any project,
you don't know what the response is going to be to PR. I think many of
us have invested time into a pull request and it just is ignored or you
just a get snotty response.

I think projects need to have clearly defined rules for maintainers:

1. Time to review a PR
Users should know that their PR will get a full review within e.g.
14 days. Escalation routes should be documented, e.g. post in this
rocketchat channel "my PR has not been reviewed, it has been 14 days".

This includes every re-review after rework.

2. A pull request should be taken seriously (or "listened to")
A pull request might not be useful, but the user is experiencing a
problem they would like to solve. This should be discussed, and handled
appropriately. Explore the root issue.

There is a wonderful blog series on this issue:

http://aturon.github.io/tech/2018/05/25/listening-part-1/

3. Expectations of code style, testing etc. should be documented.
All known requirements should be documented, so that whoever writes
a PR knows what to expect.

There can be exceptions for "RFC" PRs.

4. Expectations for merged PR to present in a release
Once a PR is merged, the next question is always, when is it in a
release. A documented release cycle really helps here.

There are probably more things but I can't think of them now.

2. Lack of awareness on available opportunities to get involved.
I think most users want to contribute specific issues that are bothering
them. A few would like to contribute but do not know where to start; usually
these are very new users.

3. Number of reworks on a PR. due to lack of information on better
practices followed at Hyperledger.
Absolutely, if there was standard practise for a project, it should be
clearly documentated.


Sean


Re: [Hyperledger SIG Chairs] SIG Request for Support from Technical Community: Technical contributors

Hart Montgomery
 

Hi Arun,

Thanks for bringing this up to everyone.  I think #1, in particular, is a big issue.  Most projects have their own specific PR requirements that can be difficult to get right on the first time.  Maintainers also tend to respond to and deal with PRs from people that they know more quickly, and PRs from unknown contributors that are useful but maybe do a couple of things wrong because the contributors are new can get "black holed."  I guess this plays into #3 as well.

Two things that I've recommended for these problems in some of the projects I've worked on are as follows:
  1. Require that maintainers address PRs in order (except for some critical fixes).  This means that people cannot just skip PRs for people that they don't know, and must respond to all PRs in a timely manner.  
  2. Never close someone's PR without explaining why.  Even if it's a totally foolish PR, at least a sentence or two is required.
I think these rules help reduce discouragement for new people trying PRs.  I don't think we want to regulate things at a Hyperledger level, but I did want to share things that seem to work for projects that I work on/follow closely.

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

Hart


From: tsc@... <tsc@...> on behalf of Arun S M <arun.s.m.cse@...>
Sent: Saturday, February 6, 2021 5:20 AM
To: David Boswell <dboswell@...>
Cc: Tracy Kuhrt <tracy.a.kuhrt@...>; tsc@... <tsc@...>; SIG-Chairs@... <SIG-Chairs@...>
Subject: Re: [Hyperledger TSC] [Hyperledger SIG Chairs] SIG Request for Support from Technical Community: Technical contributors
 
Adding onto this discussion,

The entry barriers that I have found while asking the developer community to get involved are
1. First time contributors think that they need to spend a significant amount of time before making attempts to contribute. They are unsure of their code acceptance by a project.
2. Lack of awareness on available opportunities to get involved.
3. Number of reworks on a PR. due to lack of information on better practices followed at Hyperledger.

Building upon the idea of aggregating contribution opportunities at one place, and similar discussions I have had with another project in Hyperledger.
How about also categorizing those opportunities into different verticals?
- Documentation efforts for those who wish to help out there.
- Porting efforts, if somebody is new to a programming language or doesn't know about a project. Here are low hanging fruits/easy picks.
- Adding to the test coverage, implementing fully designed modules. For a slightly mature developer.
- A section for specific requirements. For example, call out need for help on expertise from verifiable credentials use cases, call out need to work on a setting up a test network, call out need to work on a backend. This way specific people interested in a domain can even subscribe to available opportunities.
- Influencing the roadmap of a project. This is where the passionate developers/organizations join by themselves.

Weekly dev letters can be used to publish a link to this page. Also, highlight new opportunities added upon here.

Regards,
Arun

On Sat, Feb 6, 2021 at 4:19 AM David Boswell <dboswell@...> wrote:
Out of all of the ideas that came out of that discussion, I think this one about rolling up contribution opportunities could bring the most benefit to the entire community.

Right now a potential contributor needs to look at 72 different places (16 projects, 42 labs repositories, 5 Working Groups, 9 Special Interest Groups) to get a full picture of what they can contribute to.  Having one place that aggregates everything that they could contribute to would be a much lower barrier to entry.

And bringing all contribution opportunities together in one place could promote collaboration among different parts of the community.  It seems entirely possible that different groups are working separately on similar tasks without realizing it because there isn't a lot of visibility across the whole of the community.  Could we get a better sense of where to combine efforts if we did roll opportunities up?

It seems like it should be possible to have one page on the wiki that aggregates all 'help wanted' and/or all 'good first issues'.  Last year Ry installed a Confluence plug-in that let us embed Github issues onto a wiki page (see example at link below) and that could be the basis of something that pulled from a wider collection of sources.


Thanks,
David

On Thu, Feb 4, 2021 at 2:02 PM Kuhrt, Tracy A. via lists.hyperledger.org <tracy.a.kuhrt=accenture.com@...> wrote:

On January 11th, I provided a report back on the SIG chair meeting that I attended. On our TSC call on January 14th, we had some initial discussions about each of the items that I reported back on. It was suggested that I break out the individual items so that if there were any additional thoughts on the topic that we could discuss in a single thread instead of mixing topics.

 

This is the email to discuss item #5 Technical contributors -- can the TSC help recruit people to work on things that the SIGs are doing, such as a Labs project.  Can we roll up contribution opportunities across SIGs into one place?

 

Here is what has been mentioned on the previous thread so far regarding this topic:

 

From Arun:

Streamlining the process would help. For example, in few of the labs projects asking for a new feature or raising a defect is as simple as adding a new issue on GitHub. TSC can review the current process followed by the SIGs, check if they all are using similar ways of communication, requesting for comments, how are the community call times are allotted to different topics. TSC can play the role of being a steward to help SIGs with technical contributions if TSC is aware of what's going on.

 

Tracy




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

www.accenture.com


Re: SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects

VIPIN BHARATHAN
 

Currently, there are no asks for the sponsor except to stand behind the process of application, they are not expected to engage beyond that point.

dlt.nyc
Vipin Bharathan
Digital Transformation Consultant
Financial Services (Blockchain, ML, Design Thinking)
vip@...


From: Arun .S.M. <arun.s.m.cse@...>
Sent: Monday, February 8, 2021 9:05 AM
To: VIPIN BHARATHAN <vip@...>
Cc: tracy.a.kuhrt@... <tracy.a.kuhrt@...>; lehors@... <lehors@...>; SIG-Chairs@... <SIG-Chairs@...>; tsc@... <tsc@...>
Subject: Re: [Hyperledger TSC] SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects
 
It could be because I don't know about it much further.
Is the sponsor of the project held accountable with additional responsibility?

For example, does it become the sponsor's responsibility to ensure the project follows Hyperledger's guidelines, guide through for a couple of months for best practices etc?
If this is the case then let's discuss how these can be delegated off from the sponsor's shoulder to anybody else in the community.

Regards,
Arun


Re: SIG Request for Support from Technical Community: Defining Standards

VIPIN BHARATHAN
 

Hi all,

I have heard from Brian several times that Hyperledger is not a standards organization, which stands to reason.  
There is a survey of Blockchain standards in GSMI. This illustrates the dictum that standards are so great because there are so many of them.
One of the points that GSMI brought up is the need for the SDOs (Standards Development Organizations) to co-ordinate, plus the fact that orgs like ISO are closed to regular folks and that they charge a lot for their standards.

I chair the Interoperability workstream in Digital Currency Global Initiative (DCGI) - a collaboration between ITU-T (an SDO) and Stanford. This is open for participation and one of their methods is to study use cases for extracting common elements and the state of the art of implementations which are far in advance of standards settings. I invite the HL cactus folks to present on this topic.  The DCGI will publish a roadmap towards standards for Digital Currencies, the ur-use case for Blockchain. The working groups in DCGI include Policy & Governance, Architecture, & Security. 

Best

dlt.nyc
Vipin Bharathan
Digital Transformation Consultant
Financial Services (Blockchain, ML, Design Thinking)
vip@...


From: tsc@... <tsc@...> on behalf of Arnaud Le Hors via lists.hyperledger.org <lehors=us.ibm.com@...>
Sent: Monday, February 8, 2021 7:43 AM
To: tracy.a.kuhrt@... <tracy.a.kuhrt@...>
Cc: SIG-Chairs@... <SIG-Chairs@...>; tsc@... <tsc@...>
Subject: Re: [Hyperledger TSC] SIG Request for Support from Technical Community: Defining Standards
 
Hi,
I think this actually raises a couple of issues.

The first one is the framework to develop standards within Hyperledger. Hyperledger wasn't set up to develop standards. The belief was that this would be done in other organizations and we would merely focus on implementation. That question was recently raised in the context of the Aries project which has been in fact developing a specification. I will let Brian speak up about what we can do here.

The second one is a question of socialization of the work happening in different parts of Hyperledger. This is a need we have across Hyperledger. The TSC has had several discussions about what we could do to help projects know more about each other so that opportunities for collaboration could be seized - projects often work on similar topics in isolation due to a lack of awareness. We clearly haven't figured this one out yet and ought to give this another look.

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




From:        "Kuhrt, Tracy A. via lists.hyperledger.org" <tracy.a.kuhrt=accenture.com@...>
To:        "tsc@..." <tsc@...>
Cc:        "SIG-Chairs@..." <SIG-Chairs@...>
Date:        02/04/2021 11:01 PM
Subject:        [EXTERNAL] [Hyperledger TSC] SIG Request for Support from Technical Community: Defining Standards
Sent by:        tsc@...


On January 11th, I provided a report back on the SIG chair meetingthat I attended. On our TSC call on January 14th, we had some initial discussions about each of the items that I reported back on. It was suggested that I break out the individual items so that if there were any additional thoughts on the topic that we could discuss in a single thread instead of mixing topics.

 

This is the email to discuss item #1 Defining standards -- data standards, process standards.  How to get standards to interoperate.  How to break things out of silos since different SIGs are working on standards in separate groups.  Can presenting these standards efforts to the TSC help break these out of standards?  Can the technical community help with implementation of the standards?

 

Here is what has been mentioned on the previous thread so far regarding this topic:

 

From Arun:

Do we need to streamline the outcomes of these standardization activities? TSC can help here by reviewing current modes of collaboration. Another way TSC can be involved is to review the content as you suggested. TSC could guide SIGs on what is possible, already available, what alternatives are available, be able to bridge to other similar outcomes. This will help TSC in a way to respond to project needs and requests.

 

Tracy

 





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

www.accenture.com




Re: SIG Request for Support from Technical Community: Labs and technical documents have been created in isolation so far and don’t tend to connect with projects

Arun S M
 

It could be because I don't know about it much further.
Is the sponsor of the project held accountable with additional responsibility?

For example, does it become the sponsor's responsibility to ensure the project follows Hyperledger's guidelines, guide through for a couple of months for best practices etc?
If this is the case then let's discuss how these can be delegated off from the sponsor's shoulder to anybody else in the community.

Regards,
Arun

241 - 260 of 3549