Date   

Agenda for November 29, 2018

Tracy Kuhrt <tkuhrt@...>
 

Location: https://zoom.us/my/hyperledger.community.backup


Reminders

Quarterly project updates

Quarterly WG updates
  • None until next quarter
Open Discussion Items

----
Tracy Kuhrt
Community Architect, Hyperledger
The Linux Foundation
tkuhrt@...
Hyperledger Chat: @tkuhrt


Re: What is the exact role of a lab sponsor?

Vipin Bharathan
 

Hello Arnaud,
The proposals I made were (taken from your list)
- To believe in the project. Questioning and guiding the project so that the aims are concrete. Ensure this before the proposal hits the labs, the sponsor has to be convinced before s/he signs on.
- Help the project participants write its proposal, guiding them.
- Keep tabs on the ongoing work, helping spread the word in the wider community to encourage participation as well as look for adoption in various venues
- Generally function as a mentor.  

All the bold items- are what I would fully support as requirements which corresponds to your proposal:

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.  

As far as HL staff being able to propose new labs; I believe that it is a completely different animal.
It is inimical to the concept of Hyperledger as an open source community. This is what I heard during the discussion on the TSC.

Best,
Vipin


On Wed, Nov 28, 2018 at 1:10 PM Arnaud Le Hors <lehors@...> wrote:
Hi all,

In an offline discussion the lab stewards were asked what the exact responsibility of a lab sponsor is. The current documentation doesn't really say anything, it just says that a lab proposal must have a sponsor.

The question triggered a discussion among the stewards which led to various tasks being proposed including:

- Determining when/if a lab should attempt to progress to a full-blown project within Hyperledger
- Determining when/if a lab has reached the end of life and would be something that should be archived (in conjunction with the lab stewards)
- Reporting to the TSC about the status of the lab
- To believe in the project. Questioning and guiding the project so that the aims are concrete. Ensure this before the proposal hits the labs, the sponsor has to be convinced before s/he signs on.
- Help the project participants write its proposal, guiding them.
- Keep tabs on the ongoing work, helping spread the word in the wider community to encourage participation as well as look for adoption in various venues
- Generally function as a mentor.

However, I fear that putting so much responsibility on the sponsors which only a few people qualify for risks to seriously limit the number of labs we can manage, which is contrary to the whole idea.

My understanding was that the primary responsibility of the sponsor was to endorse the proposal because the idea was brought up when we were discussing ways to avoid the labs becoming a dumping ground for everything and anything people might want to propose. So, I take the sponsorship role to be primarily about making a first assessment of a proposal and backing it up by putting their name behind it.

I have no problem with sponsors doing more if they choose to of course, I just don't want that to become a requirement. So I would be happy to define the role of sponsors as something like:


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.


Tracy suggested I put that up for the TSC to consider. So, here we go.
I would appreciate if this could be put on the TSC agenda along with my previous proposal to extend the list of possible sponsors to include the staff which is somewhat related and which has fallen off the radar.

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


What is the exact role of a lab sponsor?

Arnaud Le Hors
 

Hi all,

In an offline discussion the lab stewards were asked what the exact responsibility of a lab sponsor is. The current documentation doesn't really say anything, it just says that a lab proposal must have a sponsor.

The question triggered a discussion among the stewards which led to various tasks being proposed including:

- Determining when/if a lab should attempt to progress to a full-blown project within Hyperledger
- Determining when/if a lab has reached the end of life and would be something that should be archived (in conjunction with the lab stewards)
- Reporting to the TSC about the status of the lab
- To believe in the project. Questioning and guiding the project so that the aims are concrete. Ensure this before the proposal hits the labs, the sponsor has to be convinced before s/he signs on.
- Help the project participants write its proposal, guiding them.
- Keep tabs on the ongoing work, helping spread the word in the wider community to encourage participation as well as look for adoption in various venues
- Generally function as a mentor.

However, I fear that putting so much responsibility on the sponsors which only a few people qualify for risks to seriously limit the number of labs we can manage, which is contrary to the whole idea.

My understanding was that the primary responsibility of the sponsor was to endorse the proposal because the idea was brought up when we were discussing ways to avoid the labs becoming a dumping ground for everything and anything people might want to propose. So, I take the sponsorship role to be primarily about making a first assessment of a proposal and backing it up by putting their name behind it.

I have no problem with sponsors doing more if they choose to of course, I just don't want that to become a requirement. So I would be happy to define the role of sponsors as something like:


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.


Tracy suggested I put that up for the TSC to consider. So, here we go.
I would appreciate if this could be put on the TSC agenda along with my previous proposal to extend the list of possible sponsors to include the staff which is somewhat related and which has fallen off the radar.

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


Re: New Project Proposal: Fabric Desktop

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

Hi Yi Deng,

 

Building on my initial reply: https://lists.hyperledger.org/g/tsc/message/1845

 

The TSC had some previous discussion which Hart has linked to.

In reviewing that discussion we decided that the best approach for proposals like yours is for you to first
“seek and document support from the maintainers of a project it depends on”.

 

Can I ask you to please post this proposal to the fabric mailing list?

Solicit feedback from the maintainers and then include that with your proposal.

The maintainers may ask you to include your code in the existing Fabric project or may decline your proposal. If they decline the proposal you are still free to raise it again to the TSC along with that context and we can help decide what the right path is.

 

Thanks,

Dan

 

 

From: <tsc@...> on behalf of Yi DENG <michaelyideng@...>
Date: Sunday, November 25, 2018 at 8:30 PM
To: "Olson, Kelly M" <kelly.m.olson@...>
Cc: "hmontgomery@..." <hmontgomery@...>, "mwagner@..." <mwagner@...>, "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] New Project Proposal: Fabric Desktop

 

Hi TSC and all,

 

I think Olson gave a great explanation. Firstly, as the project devoloper, I personally don't care about if it is a top-level or sub-level project, but I do care about the autonomy. 

 

Secondly, this app is general-purpose. You can also call it a tool, not an app. 

 

Thirdly, supporting multiple blockchain projects is promising. But so far, I don't see a great standard to abstract workflow models. It leads to some projects which claim it will support multiple framworks, but hard to implement. Or may it be better to support different blockchain frameworks by different projects? In the case of desktop tools, maybe it is. If we do want tools that are cross-framework, a standard is needed. 

 

 

On Thu, Nov 15, 2018 at 8:29 AM Olson, Kelly M <kelly.m.olson@...> wrote:

Hey Mark,

 

Thanks for sending this e-mail. I agree with Hart that a lot has changed in the past couple of years. I am generally in favor of applications being ‘projects’. The main reason is that I believe allowing applications will bring in new developers and increase deployments of Hyperledger projects. I think getting new contributors into Hyperledger is one of our biggest challenges and an inability to do that poses a risk to the long-term health of Hyperledger as a community.

 

The question of what exactly an ‘app’ is, is a bit fuzzy, but I haven’t yet seen a compelling reason for them to be out of scope. Ethereum has arguably the largest developer ecosystem, and many of its applications run on standardized smart contract logic (e.g. ERC20 and ERC721 contracts). By creating high-quality community-owned business logic, application development speed and security can be increased. The biggest issue I see is that the bar for developing an application is significantly lower than developing an entire blockchain stack, and so I think there are some governance questions around what are the criteria for accepting an application. This decision would also mean an expansion of the number of projects under the ‘umbrella’, which should cause us to re-think how we market and fund the projects (though that is probably better left to the board and marketing committee). I’d be interested in hearing other’s opinions on the potential downsides that they see by allowing applications.

 

On the second topic, I’m in favor of consolidating single-ledger tools into their top-level projects. It’s confusing that ‘Sawtooth Explorer’ supports Sawtooth, but ‘Hyperledger Explorer’ supports Fabric. These sorts of things continue to cause people to conflate Hyperledger the community with the Fabric project. However, if these projects were to move under their respective ledger, I think it raises some governance questions that need to be worked out. For example, ‘Hyperledger Explorer’ is predominately managed by DTTC maintainers last I checked, and I think it’s important that tool maintainers are able to keep their ‘sovereignty’ from the larger top-level projects. Similarly, top-level projects may want to protect their brand by not allowing tools under their project without first approving. In the event of a top-level project rejecting a tool, there should be a process to resolve that conflict at the TSC. I would support tools graduating to top-level projects as they support more than one ledger.

 

Finally, I think this leads to a question about whether apps should be top level projects or be under their respective ledgers. I would suggest following the same model as tools, where if the app is specifically designed around one ledger, then it should likely target being a subproject. If an app can be run across multiple ledgers (say an EVM-based smart contract) then it would be a good candidate for a top-level project as it could run across Burrow/Sawtooth/Fabric.

 

Kelly

 

From: <tsc@...> on behalf of "hmontgomery@..." <hmontgomery@...>
Date: Wednesday, November 14, 2018 at 3:33 PM
To: mark wagner <mwagner@...>, Yi DENG <michaelyideng@...>
Cc: Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] New Project Proposal: Fabric Desktop

 

Hi Mark,

 

I’ll defer #1 for now, but I have a number of comments about #2.

 

If you do want to take the angle that proposals that are specific to a DLT (or other existing project) should be under the same umbrella as the project, then you’d probably want to start with the Fabric Go SDK, the Fabric Python SDK, and the Java Chaincode support for Hyperledger Fabric projects.  These were all passed as fully independent projects (before you were on the TSC) but are clearly Fabric-specific to a degree that even Composer is not.  Correct me if I am wrong here, but I believe they are still wholly independent, although the maintainers are heavily involved in Fabric directly as well.

 

However, we did discuss this quite a bit almost a year and a half ago.  I have a bunch of emails from March and April 2017 where we discussed essentially this exact issue.  Some examples:

 

There are a bunch of other relevant emails around that time on the TSC list that you can find if you’re interested and search a little bit (I’m still waiting for someone to comb all of these for an all-time “dumb things said in TSC emails” list, on which I will surely be prominently featured).  In the end, we decided around that time that independent projects and a flat structure were the best way to maximize contributions.  I’m not sure if this group wants to have that discussion again, but, to be fair, Hyperledger has changed a lot in the last year and a half.

 

Anyways, I hope this helps you (and others) who weren’t around when we had to walk uphill both ways to the TSC meetings navigate this issue.

 

Thanks,

Hart

 

 

 

From: tsc@... [mailto:tsc@...] On Behalf Of mark wagner
Sent: Wednesday, November 14, 2018 11:16 AM
To: Yi DENG <michaelyideng@...>
Cc: Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] New Project Proposal: Fabric Desktop

 

I would like the TSC to discuss two things that this proposal raises.

 

1) if its an app, can it be a project ?

iirc some previous discussions, our charter does not allow that.

 

2) If a new proposal is specific to an existing project, should it be under the umbrella of the existing project or standalone ?

I know that things like Composer are standalone but I have heard multiple folks voice that in reality Composer should have been a subproject of Fabric.

 

What do other members think ?

 

-mark

 

On Fri, Nov 9, 2018 at 2:51 AM, Yi DENG <michaelyideng@...> wrote:

Dear TSC and all, 

It is Yi. Recently, we developed a desktop app for Fabric. It is general-purpose, in other words, an API tool with GUI. We would like to contribute it to Hyperledger. Looking forward to discussion at TSC meeting. I can make a 5-minutes demonstration about what it is and how to use it.

 

Proposal:

https://docs.google.com/document/d/1XX-I1uud0DV2TVRj6H5w8r5OaX0W0VCZqveeLqMBqBU/edit

 

Code repository:

https://github.com/blockchain-desktop/hyperledger-fabric-desktop

 

----

Yi DENG

Senior Software Engineer - Yonyou




--

Mark Wagner

Senior Principal Software Engineer

Performance and Scalability

Red Hat, Inc


 

--

_________________________

羿

Yi DENG


Hyperledger Community Survey

Tracy Kuhrt <tkuhrt@...>
 

As you may remember, last year we developed a community surveyThe original goals for this survey were to:
  • Find out who are developers are
  • Find out what developers want from the different Hyperledger projects
  • Find out what tools are developers use

We are interested in repeating this survey. We have made a few minor modifications to the survey, and we would like to get your feedback on any questions that the TSC would like added to the survey. Please review the following and provide your comments and suggestions: Developer Survey Questions 2018. We would ideally like to kick this survey off around the time frame of the Hyperledger Global Forum and running it through February 2019. 

----
Tracy Kuhrt
Community Architect, Hyperledger
The Linux Foundation
tkuhrt@...
Hyperledger Chat: @tkuhrt


Re: [Hyperledger Architecture WG] [Hyperledger Performance and Scale WG] [Hyperledger Identity WG] [Hyperledger TSC] How can we improve diversity in the Hyperledger technical community?

David Boswell
 

Marissa,

I'm glad to hear that you think that formalizing the organic mentoring that is happening now sounds like it would be beneficial for the community.

If you, or anyone else here interested in mentoring, diversity and community health, would be interested in joining a conversation about this topic, a group is meeting tomorrow at 10 am pacific to discuss how to move forward with these topics.

Feel free to join us -- agenda and dial-in information are in this working doc at:


Thanks,
David

On Sun, Nov 18, 2018 at 1:34 PM Marissa Iannarone <mari.iannarone@...> wrote:
Hi David,

Thank you for looking into this. As I enter into 2019 planning for the patient subgroup of the healthcare working group, it is a great time to reflect on what can be done differently to encourage participation and also how to welcome folks that definitely have something to contribute, but might not know exactly what yet.

I see mentorship happening organically with people reaching out to me directly via email, LinkedIn, and with me reaching out to Rich and others that have been engaged in the community longer. I think formalizing this would help increase retention and also help us think about how we bring different skill sets into projects. As a first step, as I'm holding the planning meeting next Friday, I can ask who might be interested in this sort of structure and get some thoughts. Anything else I can do to start us off?

Best,
Marissa

Marissa Iannarone
Associate with Forum Solutions LLC
phone number: +01 (360) 525 4961
email: mari.iannarone@...



On Wed, Oct 31, 2018 at 12:51 PM David Boswell <dboswell@...> wrote:
I've been looking into the topic of diversity in open source communities and wanted to share some interesting articles and a specific proposal for something our community can do.

To start, here are some important points made by three different articles:

* The basic structure of open, meritocratic and welcoming communities puts more hurdles in place for some people than others.  There's a great article that looks at how the essay 'The Tyranny of Structurelessness', an article about power structures in the feminist movement, applies to open source communities.  I think the most important line in that article is: “First, we need to recognize that while we all strive to be meritocratic when engaging and involving people we are often predisposed to those who act, talk and think like us.”


* Building on that point, open source projects are biased in favor of contributors who show up with an itch to scratch (they already have a thing in mind they want to do).  Sumana Harihareswara has a great article that points out that not everyone has an itch to scratch when they come to a community and we are sending the message that those people aren't real contributors.  But just like people have different learning styles, if we want to have a more diverse group of contributors we need to recognize that there are different contribution styles as well -- otherwise we keep limiting our contributions to the subset of people who participate in the one way we've promoted as 'the right way to contribute'.


* So we need to put new structures in place for new contributors that don't have an itch to scratch the moment they show up in the community.  Many people are interested in Hyperledger and want to get involved but don't know what to do.  We can match those new people with contribution opportunities and with existing contributors to help them.  And data shows that matching people with mentors does increase diversity -- see this recent Economist article that compares effectiveness of different diversity policies.

https://www.economist.com/united-states/2018/09/29/anti-discrimination-statements-by-employers

The proposal then is to create a formal mentoring program in the community where existing contributors share their knowledge with new contributors and connect them with tasks that the projects need help with that fit their interests and skills.  And there are models out there for how to do this in an open source community.  Mozilla had a mentoring effort that scaled to a large size by having a small group of mentors level up a group of people who then mentored others who then leveled up more people.  The attached image of their mentoring structure shows how this scales up quickly.

Thoughts?

Thanks,
David


Hyperledger Cello Quarterly Update Due #tsc-project-update - Thu, 11/29/2018 #cal-reminder #tsc-project-update

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

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

When:
Thursday, 29 November 2018

Organizer:
tkuhrt@...

Description:
The Hyperledger Cello project update to the TSC was due November 26, 2018, and it will be presented to the TSC on November 29, 2018. Please review prior to the meeting and bring your questions.

View Event


Re: New Project Proposal: Fabric Desktop

Yi DENG
 

Hi TSC and all,

I think Olson gave a great explanation. Firstly, as the project devoloper, I personally don't care about if it is a top-level or sub-level project, but I do care about the autonomy. 

Secondly, this app is general-purpose. You can also call it a tool, not an app. 

Thirdly, supporting multiple blockchain projects is promising. But so far, I don't see a great standard to abstract workflow models. It leads to some projects which claim it will support multiple framworks, but hard to implement. Or may it be better to support different blockchain frameworks by different projects? In the case of desktop tools, maybe it is. If we do want tools that are cross-framework, a standard is needed. 


On Thu, Nov 15, 2018 at 8:29 AM Olson, Kelly M <kelly.m.olson@...> wrote:

Hey Mark,

 

Thanks for sending this e-mail. I agree with Hart that a lot has changed in the past couple of years. I am generally in favor of applications being ‘projects’. The main reason is that I believe allowing applications will bring in new developers and increase deployments of Hyperledger projects. I think getting new contributors into Hyperledger is one of our biggest challenges and an inability to do that poses a risk to the long-term health of Hyperledger as a community.

 

The question of what exactly an ‘app’ is, is a bit fuzzy, but I haven’t yet seen a compelling reason for them to be out of scope. Ethereum has arguably the largest developer ecosystem, and many of its applications run on standardized smart contract logic (e.g. ERC20 and ERC721 contracts). By creating high-quality community-owned business logic, application development speed and security can be increased. The biggest issue I see is that the bar for developing an application is significantly lower than developing an entire blockchain stack, and so I think there are some governance questions around what are the criteria for accepting an application. This decision would also mean an expansion of the number of projects under the ‘umbrella’, which should cause us to re-think how we market and fund the projects (though that is probably better left to the board and marketing committee). I’d be interested in hearing other’s opinions on the potential downsides that they see by allowing applications.

 

On the second topic, I’m in favor of consolidating single-ledger tools into their top-level projects. It’s confusing that ‘Sawtooth Explorer’ supports Sawtooth, but ‘Hyperledger Explorer’ supports Fabric. These sorts of things continue to cause people to conflate Hyperledger the community with the Fabric project. However, if these projects were to move under their respective ledger, I think it raises some governance questions that need to be worked out. For example, ‘Hyperledger Explorer’ is predominately managed by DTTC maintainers last I checked, and I think it’s important that tool maintainers are able to keep their ‘sovereignty’ from the larger top-level projects. Similarly, top-level projects may want to protect their brand by not allowing tools under their project without first approving. In the event of a top-level project rejecting a tool, there should be a process to resolve that conflict at the TSC. I would support tools graduating to top-level projects as they support more than one ledger.

 

Finally, I think this leads to a question about whether apps should be top level projects or be under their respective ledgers. I would suggest following the same model as tools, where if the app is specifically designed around one ledger, then it should likely target being a subproject. If an app can be run across multiple ledgers (say an EVM-based smart contract) then it would be a good candidate for a top-level project as it could run across Burrow/Sawtooth/Fabric.

 

Kelly

 

From: <tsc@...> on behalf of "hmontgomery@..." <hmontgomery@...>
Date: Wednesday, November 14, 2018 at 3:33 PM
To: mark wagner <mwagner@...>, Yi DENG <michaelyideng@...>
Cc: Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] New Project Proposal: Fabric Desktop

 

Hi Mark,

 

I’ll defer #1 for now, but I have a number of comments about #2.

 

If you do want to take the angle that proposals that are specific to a DLT (or other existing project) should be under the same umbrella as the project, then you’d probably want to start with the Fabric Go SDK, the Fabric Python SDK, and the Java Chaincode support for Hyperledger Fabric projects.  These were all passed as fully independent projects (before you were on the TSC) but are clearly Fabric-specific to a degree that even Composer is not.  Correct me if I am wrong here, but I believe they are still wholly independent, although the maintainers are heavily involved in Fabric directly as well.

 

However, we did discuss this quite a bit almost a year and a half ago.  I have a bunch of emails from March and April 2017 where we discussed essentially this exact issue.  Some examples:

 

There are a bunch of other relevant emails around that time on the TSC list that you can find if you’re interested and search a little bit (I’m still waiting for someone to comb all of these for an all-time “dumb things said in TSC emails” list, on which I will surely be prominently featured).  In the end, we decided around that time that independent projects and a flat structure were the best way to maximize contributions.  I’m not sure if this group wants to have that discussion again, but, to be fair, Hyperledger has changed a lot in the last year and a half.

 

Anyways, I hope this helps you (and others) who weren’t around when we had to walk uphill both ways to the TSC meetings navigate this issue.

 

Thanks,

Hart

 

 

 

From: tsc@... [mailto:tsc@...] On Behalf Of mark wagner
Sent: Wednesday, November 14, 2018 11:16 AM
To: Yi DENG <michaelyideng@...>
Cc: Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] New Project Proposal: Fabric Desktop

 

I would like the TSC to discuss two things that this proposal raises.

 

1) if its an app, can it be a project ?

iirc some previous discussions, our charter does not allow that.

 

2) If a new proposal is specific to an existing project, should it be under the umbrella of the existing project or standalone ?

I know that things like Composer are standalone but I have heard multiple folks voice that in reality Composer should have been a subproject of Fabric.

 

What do other members think ?

 

-mark

 

On Fri, Nov 9, 2018 at 2:51 AM, Yi DENG <michaelyideng@...> wrote:

Dear TSC and all, 

It is Yi. Recently, we developed a desktop app for Fabric. It is general-purpose, in other words, an API tool with GUI. We would like to contribute it to Hyperledger. Looking forward to discussion at TSC meeting. I can make a 5-minutes demonstration about what it is and how to use it.

 

Proposal:

https://docs.google.com/document/d/1XX-I1uud0DV2TVRj6H5w8r5OaX0W0VCZqveeLqMBqBU/edit

 

Code repository:

https://github.com/blockchain-desktop/hyperledger-fabric-desktop

 

----

Yi DENG

Senior Software Engineer - Yonyou




--

Mark Wagner

Senior Principal Software Engineer

Performance and Scalability

Red Hat, Inc



--
_________________________
邓羿
Yi DENG


[Call for contributors][NodeSDK] Nodejs 10 compatibility

? ?? <david-khala@...>
 

Dear community members,

 

Per discussion in latest TWGC meeting in 21 Nov, we would like to invite interested nodejs SDK source contributors to collaborate on nodejs 10 compatibility feature.

 

This is the created Epic to trace:

https://jira.hyperledger.org/browse/FABN-1031

 

Best Regards,

David Liu

+852 5982 3942 (HongKong)

 


No TSC Meeting November 22, 2018

Tracy Kuhrt <tkuhrt@...>
 

As a reminder, there is no TSC call tomorrow due to the Thanksgiving holiday in the US.

Reminders
  • APAC Hackfest -- week of March 4th (details coming soon)
  • Schedule announced for Hyperledger Global Forum, December 12-15 (Basel, Switzerland). Next registration deadline before price increases is November 25th
Quarterly Project Updates for November 29th meeting:

----
Tracy Kuhrt
Community Architect, Hyperledger
The Linux Foundation
tkuhrt@...
Hyperledger Chat: @tkuhrt


LFIT RE limited support 17-DEC-2018 to 02-JAN-2019 inclusive

Ry Jones
 

The Linux Foundation will be reducing daily operations from December 17, 2018 to January 2, 2019.  During this time the LF IT Release Engineering team will have limited support available and projects should plan accordingly.

We recommend that major releases or other work, if they have not already been planned and the responsible Release Engineer(s) made aware, be postponed until after Jan. 2.

Please note that CI change code review will not occur with LF Release Engineering staff during this window, unless it is related to an environment stopping issue.

--
Ry Jones
Community Architect, Hyperledger
Chat: @ry


Reminder: Join us Hyperledger Global Forum, Basel Switzerland - 5 Days Left before tickets rates go up + discounts

Daniela Barbosa
 

Apologies for the cross-posting, want to make sure everyone is aware of the deadlines coming up for Hyperledger Global Forum.
 
As we head into the end of the month, a quick reminder: You have only five days left to save on your ticket to Hyperledger Global Forum happening in Basel Switzerland, Dec 12-15th before rates go up on November 25th.

I am sure you are starting to hear the buzz out there in the community, we are certainly feeling it. For the first time, the global Hyperledger community from 350+ organizations will converge to collaborate and hack together in person. With over 75 sessions and activities for business and technical audiences including 1/2 and full day training and workshops, there will certainly be a plethora of learning and networking opportunities for everyone.

Don’t miss this unique opportunity to join your peers from around the globe that will include developers, enterprise end-users, and blockchain enthusiasts learning about the latest production deployments and advancing their blockchain skills. 

You can register here, before rates go up on November 25th. 

If your company is a Hyperledger member company, please send me an email (dbarbosa@...) and I can provide you with your member discount code. 

If you are a member of our active community, but currently not a member company we would like to offer you an additional 20% discount, please select corporate non-member as the registrant type and enter code: HGF18COMM

Need more information on why you should attend? Here is a two-page overview of the event and a sample letter to convince your boss, if they still need convincing! 

Can you also please do me a favor and forward this to others at your company and or in your community that you think shouldn’t miss this event? We would be happy to extend the discount codes to them as well.

Thanks and hopefully we will see you in Basel!

~daniela

Daniela Barbosa
VP of World Wide Alliances, Hyperledger
Mobile/Text: 650.296.6969

The Linux Foundation
http://hyperledger.org


Re: [Hyperledger Architecture WG] [Hyperledger Performance and Scale WG] [Hyperledger Identity WG] [Hyperledger TSC] How can we improve diversity in the Hyperledger technical community?

Marissa Iannarone
 

Hi David,

Thank you for looking into this. As I enter into 2019 planning for the patient subgroup of the healthcare working group, it is a great time to reflect on what can be done differently to encourage participation and also how to welcome folks that definitely have something to contribute, but might not know exactly what yet.

I see mentorship happening organically with people reaching out to me directly via email, LinkedIn, and with me reaching out to Rich and others that have been engaged in the community longer. I think formalizing this would help increase retention and also help us think about how we bring different skill sets into projects. As a first step, as I'm holding the planning meeting next Friday, I can ask who might be interested in this sort of structure and get some thoughts. Anything else I can do to start us off?

Best,
Marissa

Marissa Iannarone
Associate with Forum Solutions LLC
phone number: +01 (360) 525 4961
email: mari.iannarone@...



On Wed, Oct 31, 2018 at 12:51 PM David Boswell <dboswell@...> wrote:
I've been looking into the topic of diversity in open source communities and wanted to share some interesting articles and a specific proposal for something our community can do.

To start, here are some important points made by three different articles:

* The basic structure of open, meritocratic and welcoming communities puts more hurdles in place for some people than others.  There's a great article that looks at how the essay 'The Tyranny of Structurelessness', an article about power structures in the feminist movement, applies to open source communities.  I think the most important line in that article is: “First, we need to recognize that while we all strive to be meritocratic when engaging and involving people we are often predisposed to those who act, talk and think like us.”


* Building on that point, open source projects are biased in favor of contributors who show up with an itch to scratch (they already have a thing in mind they want to do).  Sumana Harihareswara has a great article that points out that not everyone has an itch to scratch when they come to a community and we are sending the message that those people aren't real contributors.  But just like people have different learning styles, if we want to have a more diverse group of contributors we need to recognize that there are different contribution styles as well -- otherwise we keep limiting our contributions to the subset of people who participate in the one way we've promoted as 'the right way to contribute'.


* So we need to put new structures in place for new contributors that don't have an itch to scratch the moment they show up in the community.  Many people are interested in Hyperledger and want to get involved but don't know what to do.  We can match those new people with contribution opportunities and with existing contributors to help them.  And data shows that matching people with mentors does increase diversity -- see this recent Economist article that compares effectiveness of different diversity policies.

https://www.economist.com/united-states/2018/09/29/anti-discrimination-statements-by-employers

The proposal then is to create a formal mentoring program in the community where existing contributors share their knowledge with new contributors and connect them with tasks that the projects need help with that fit their interests and skills.  And there are models out there for how to do this in an open source community.  Mozilla had a mentoring effort that scaled to a large size by having a small group of mentors level up a group of people who then mentored others who then leveled up more people.  The attached image of their mentoring structure shows how this scales up quickly.

Thoughts?

Thanks,
David


Re: New Project Proposal: Fabric Desktop

Olson, Kelly M <kelly.m.olson@...>
 

Hey Mark,

 

Thanks for sending this e-mail. I agree with Hart that a lot has changed in the past couple of years. I am generally in favor of applications being ‘projects’. The main reason is that I believe allowing applications will bring in new developers and increase deployments of Hyperledger projects. I think getting new contributors into Hyperledger is one of our biggest challenges and an inability to do that poses a risk to the long-term health of Hyperledger as a community.

 

The question of what exactly an ‘app’ is, is a bit fuzzy, but I haven’t yet seen a compelling reason for them to be out of scope. Ethereum has arguably the largest developer ecosystem, and many of its applications run on standardized smart contract logic (e.g. ERC20 and ERC721 contracts). By creating high-quality community-owned business logic, application development speed and security can be increased. The biggest issue I see is that the bar for developing an application is significantly lower than developing an entire blockchain stack, and so I think there are some governance questions around what are the criteria for accepting an application. This decision would also mean an expansion of the number of projects under the ‘umbrella’, which should cause us to re-think how we market and fund the projects (though that is probably better left to the board and marketing committee). I’d be interested in hearing other’s opinions on the potential downsides that they see by allowing applications.

 

On the second topic, I’m in favor of consolidating single-ledger tools into their top-level projects. It’s confusing that ‘Sawtooth Explorer’ supports Sawtooth, but ‘Hyperledger Explorer’ supports Fabric. These sorts of things continue to cause people to conflate Hyperledger the community with the Fabric project. However, if these projects were to move under their respective ledger, I think it raises some governance questions that need to be worked out. For example, ‘Hyperledger Explorer’ is predominately managed by DTTC maintainers last I checked, and I think it’s important that tool maintainers are able to keep their ‘sovereignty’ from the larger top-level projects. Similarly, top-level projects may want to protect their brand by not allowing tools under their project without first approving. In the event of a top-level project rejecting a tool, there should be a process to resolve that conflict at the TSC. I would support tools graduating to top-level projects as they support more than one ledger.

 

Finally, I think this leads to a question about whether apps should be top level projects or be under their respective ledgers. I would suggest following the same model as tools, where if the app is specifically designed around one ledger, then it should likely target being a subproject. If an app can be run across multiple ledgers (say an EVM-based smart contract) then it would be a good candidate for a top-level project as it could run across Burrow/Sawtooth/Fabric.

 

Kelly

 

From: <tsc@...> on behalf of "hmontgomery@..." <hmontgomery@...>
Date: Wednesday, November 14, 2018 at 3:33 PM
To: mark wagner <mwagner@...>, Yi DENG <michaelyideng@...>
Cc: Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] New Project Proposal: Fabric Desktop

 

Hi Mark,

 

I’ll defer #1 for now, but I have a number of comments about #2.

 

If you do want to take the angle that proposals that are specific to a DLT (or other existing project) should be under the same umbrella as the project, then you’d probably want to start with the Fabric Go SDK, the Fabric Python SDK, and the Java Chaincode support for Hyperledger Fabric projects.  These were all passed as fully independent projects (before you were on the TSC) but are clearly Fabric-specific to a degree that even Composer is not.  Correct me if I am wrong here, but I believe they are still wholly independent, although the maintainers are heavily involved in Fabric directly as well.

 

However, we did discuss this quite a bit almost a year and a half ago.  I have a bunch of emails from March and April 2017 where we discussed essentially this exact issue.  Some examples:

 

There are a bunch of other relevant emails around that time on the TSC list that you can find if you’re interested and search a little bit (I’m still waiting for someone to comb all of these for an all-time “dumb things said in TSC emails” list, on which I will surely be prominently featured).  In the end, we decided around that time that independent projects and a flat structure were the best way to maximize contributions.  I’m not sure if this group wants to have that discussion again, but, to be fair, Hyperledger has changed a lot in the last year and a half.

 

Anyways, I hope this helps you (and others) who weren’t around when we had to walk uphill both ways to the TSC meetings navigate this issue.

 

Thanks,

Hart

 

 

 

From: tsc@... [mailto:tsc@...] On Behalf Of mark wagner
Sent: Wednesday, November 14, 2018 11:16 AM
To: Yi DENG <michaelyideng@...>
Cc: Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] New Project Proposal: Fabric Desktop

 

I would like the TSC to discuss two things that this proposal raises.

 

1) if its an app, can it be a project ?

iirc some previous discussions, our charter does not allow that.

 

2) If a new proposal is specific to an existing project, should it be under the umbrella of the existing project or standalone ?

I know that things like Composer are standalone but I have heard multiple folks voice that in reality Composer should have been a subproject of Fabric.

 

What do other members think ?

 

-mark

 

On Fri, Nov 9, 2018 at 2:51 AM, Yi DENG <michaelyideng@...> wrote:

Dear TSC and all, 

It is Yi. Recently, we developed a desktop app for Fabric. It is general-purpose, in other words, an API tool with GUI. We would like to contribute it to Hyperledger. Looking forward to discussion at TSC meeting. I can make a 5-minutes demonstration about what it is and how to use it.

 

Proposal:

https://docs.google.com/document/d/1XX-I1uud0DV2TVRj6H5w8r5OaX0W0VCZqveeLqMBqBU/edit

 

Code repository:

https://github.com/blockchain-desktop/hyperledger-fabric-desktop

 

----

Yi DENG

Senior Software Engineer - Yonyou




--

Mark Wagner

Senior Principal Software Engineer

Performance and Scalability

Red Hat, Inc


Re: New Project Proposal: Fabric Desktop

Hart Montgomery
 

Hi Mark,

 

I’ll defer #1 for now, but I have a number of comments about #2.

 

If you do want to take the angle that proposals that are specific to a DLT (or other existing project) should be under the same umbrella as the project, then you’d probably want to start with the Fabric Go SDK, the Fabric Python SDK, and the Java Chaincode support for Hyperledger Fabric projects.  These were all passed as fully independent projects (before you were on the TSC) but are clearly Fabric-specific to a degree that even Composer is not.  Correct me if I am wrong here, but I believe they are still wholly independent, although the maintainers are heavily involved in Fabric directly as well.

 

However, we did discuss this quite a bit almost a year and a half ago.  I have a bunch of emails from March and April 2017 where we discussed essentially this exact issue.  Some examples:

·         A thread on the Fabric Go SDK proposal:  https://lists.hyperledger.org/g/tsc/message/672?p=,,,20,0,0,0::relevance,,I+think+SDK+projects+as+top+level+projects+would+be+a+bit+of+a+departure+from+what+we%E2%80%99ve+done+for+the+last+year.,20,2,0,17551967

·         A discussion about whether or not we should have a tiered or flat project structure, with a lot of rambling by me:  https://lists.hyperledger.org/g/tsc/message/745?p=,,,20,0,0,0::relevance,,All%2C+just+a+reminder+that+we+should+try+to+wrap+this+discussion+up+before+next+week%27s+TSC.+,20,2,0,17551990

 

There are a bunch of other relevant emails around that time on the TSC list that you can find if you’re interested and search a little bit (I’m still waiting for someone to comb all of these for an all-time “dumb things said in TSC emails” list, on which I will surely be prominently featured).  In the end, we decided around that time that independent projects and a flat structure were the best way to maximize contributions.  I’m not sure if this group wants to have that discussion again, but, to be fair, Hyperledger has changed a lot in the last year and a half.

 

Anyways, I hope this helps you (and others) who weren’t around when we had to walk uphill both ways to the TSC meetings navigate this issue.

 

Thanks,

Hart

 

 

 

From: tsc@... [mailto:tsc@...] On Behalf Of mark wagner
Sent: Wednesday, November 14, 2018 11:16 AM
To: Yi DENG <michaelyideng@...>
Cc: Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] New Project Proposal: Fabric Desktop

 

I would like the TSC to discuss two things that this proposal raises.

 

1) if its an app, can it be a project ?

iirc some previous discussions, our charter does not allow that.

 

2) If a new proposal is specific to an existing project, should it be under the umbrella of the existing project or standalone ?

I know that things like Composer are standalone but I have heard multiple folks voice that in reality Composer should have been a subproject of Fabric.

 

What do other members think ?

 

-mark

 

On Fri, Nov 9, 2018 at 2:51 AM, Yi DENG <michaelyideng@...> wrote:

Dear TSC and all, 

It is Yi. Recently, we developed a desktop app for Fabric. It is general-purpose, in other words, an API tool with GUI. We would like to contribute it to Hyperledger. Looking forward to discussion at TSC meeting. I can make a 5-minutes demonstration about what it is and how to use it.

 

Proposal:

https://docs.google.com/document/d/1XX-I1uud0DV2TVRj6H5w8r5OaX0W0VCZqveeLqMBqBU/edit

 

Code repository:

https://github.com/blockchain-desktop/hyperledger-fabric-desktop

 

----

Yi DENG

Senior Software Engineer - Yonyou




--

Mark Wagner

Senior Principal Software Engineer

Performance and Scalability

Red Hat, Inc


No TSC meeting Nov 15

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

Hi,

No meeting tomorrow. There are no open agenda items ready for discussion.

 

The next round of project and working group updates are due the week after next.

Please see below for those and the event reminders:

 

·  Reminders

o    APAC Hackfest -- week of March 4th (details coming soon)

o    Schedule announced for Hyperledger Global Forum, December 12-15 (Basel, Switzerland) Next registration deadline before price increases is November 25th

o    November 22nd meeting canceled due to Thanksgiving holiday in the US

·  Quarterly project updates

o    November 29: Hyperledger Burrow deferred due to lack of update (original due date November 12th)

o    November 29: Hyperledger Composer deferred due to lack of update (original due date October 29th)

o    November 29: Hyperledger Cello

Thanks,

Dan Middleton

TSC Chair


Re: New Project Proposal: Fabric Desktop

mark wagner <mwagner@...>
 

I would like the TSC to discuss two things that this proposal raises.

1) if its an app, can it be a project ?
iirc some previous discussions, our charter does not allow that.

2) If a new proposal is specific to an existing project, should it be under the umbrella of the existing project or standalone ?
I know that things like Composer are standalone but I have heard multiple folks voice that in reality Composer should have been a subproject of Fabric.

What do other members think ?

-mark

On Fri, Nov 9, 2018 at 2:51 AM, Yi DENG <michaelyideng@...> wrote:

Dear TSC and all, 

It is Yi. Recently, we developed a desktop app for Fabric. It is general-purpose, in other words, an API tool with GUI.
We would like to contribute it to Hyperledger. Looking forward to discussion at TSC meeting. I can make a 5-minutes demonstration about what it is and how to use it.

 

Proposal:

https://docs.google.com/document/d/1XX-I1uud0DV2TVRj6H5w8r5OaX0W0VCZqveeLqMBqBU/edit

 

Code repository:

https://github.com/blockchain-desktop/hyperledger-fabric-desktop

 

----

Yi DENG

Senior Software Engineer - Yonyou




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


Re: Hyperledger Burrow Quarterly Update Due #tsc-project-update - Thu, 11/15/18 #tsc-project-update #cal-reminder

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

No problem, Silas.

No meeting next week, so you will be up Nov 29.

 

Get well,

Dan

 

From: <tsc@...> on behalf of "Silas Davis via Lists.Hyperledger.Org" <silas=monax.io@...>
Reply-To: "silas@..." <silas@...>
Date: Wednesday, November 14, 2018 at 4:33 AM
To: "tsc@..." <tsc@...>
Cc: "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] Hyperledger Burrow Quarterly Update Due #tsc-project-update - Thu, 11/15/18 #cal-reminder

 

Hello all,

 

I'm suffering from a throat infection that makes it painful to speak for a prolonged period. Can I request that the Burrow quarterly update is postponed until next week?

 

Thanks,

Silas

 

On Tue, Nov 13, 2018 at 7:00 AM tsc@... Calendar <tsc@...> wrote:

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

When:
Thursday, 15 November 2018

Organizer:
tkuhrt@...

Description:
The Hyperledger Burrow project update to the TSC was due November 12, 2018, and it will be presented to the TSC on November 15, 2018. Please review prior to the meeting and bring your questions.

View Event


Re: Hyperledger Burrow Quarterly Update Due #tsc-project-update - Thu, 11/15/18 #tsc-project-update #cal-reminder

Silas Davis
 

Hello all,

I'm suffering from a throat infection that makes it painful to speak for a prolonged period. Can I request that the Burrow quarterly update is postponed until next week?

Thanks,
Silas


On Tue, Nov 13, 2018 at 7:00 AM tsc@... Calendar <tsc@...> wrote:

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

When:
Thursday, 15 November 2018

Organizer:
tkuhrt@...

Description:
The Hyperledger Burrow project update to the TSC was due November 12, 2018, and it will be presented to the TSC on November 15, 2018. Please review prior to the meeting and bring your questions.

View Event


Re: New Project Proposal: Fabric Desktop

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

Hi Yi Deng,

Thank you for the proposal. You may see a comment in the proposal document that Hyperledger requires apache 2.0 licenses for all projects. I hope that won’t be difficult for you to relicense from GPL.

 

Before discussing the proposal in the Technical Steering Committee I would appreciate hearing some feedback on the mail list from any Fabric maintainers.

 

I would also find a comparison with Composer edifying.

 

Thanks,

Dan Middleton

Hyperledger TSC Chair

 

From: <tsc@...> on behalf of Yi DENG <michaelyideng@...>
Date: Friday, November 9, 2018 at 3:32 AM
To: "araticsu@..." <araticsu@...>
Cc: "tsc@..." <tsc@...>
Subject: Re: [Hyperledger TSC] New Project Proposal: Fabric Desktop

 

Hi Sijie Wu, 

 

In your dichotomy, this desktop is more on  “contract/chaincode side” side. It works with existed fabric networks, and doesn't deploys a network. It is just a thin wrapper of SDKs, which interact with fabric networks but not deploy those.  

 

 

On Fri, Nov 9, 2018 at 4:48 PM sijie wu <araticsu@...> wrote:

not sure whether this is more focused on “deploy / orchestration” side, or “contract / chaincode side” side, put this tradeoff / focus aside,  js / electron is good


2018119日,下午3:51Yi DENG <michaelyideng@...> 写道:

Dear TSC and all, 

It is Yi. Recently, we developed a desktop app for Fabric. It is general-purpose, in other words, an API tool with GUI. We would like to contribute it to Hyperledger. Looking forward to discussion at TSC meeting. I can make a 5-minutes demonstration about what it is and how to use it.

 

Proposal:

https://docs.google.com/document/d/1XX-I1uud0DV2TVRj6H5w8r5OaX0W0VCZqveeLqMBqBU/edit

 

Code repository:

https://github.com/blockchain-desktop/hyperledger-fabric-desktop

 

----

Yi DENG

Senior Software Engineer - Yonyou


 

--

_________________________

羿

Yi DENG

1981 - 2000 of 3844