Date   

Iroha Release Request: Discussion related to DCO and sign-off setbacks

Sara Garifullina <garifullina@...>
 

Dear TSC Members,

Is there any issue with DCO at all right now? We are not yet sure if this is actually an issue in our codebase. We made this assumption based solely on Hyperledger Chapter, section 13: "All contributions shall be accompanied by a Developer Certificate of Origin sign-off (http://developercertificate.org) that is submitted through a Governing Board and LF-approved contribution process". 

Nikolai is going to check with Silona Bonewald if there is a document or reference in LF or Hyperledger that clearly states that git sign-off (-s) option is the only approved option to submit a contribution with DCO. A quick review of this whole story: before 2018 our project used CLA hub tool: https://www.clahub.com, which requested any new member to submit their agreement explicitly for their first pull request. This was a required check, but something suddenly changed in 2018 (if I remember correctly) and Linux Foundation IT team requested us to use -s option instead of introduction of DCO bot in CI pipeline. DCO bot, an example of one of the bot's checks: https://github.com/hyperledger/iroha/pull/2175/checks?check_run_id=78892886; so that each contribution in GitHub is checked by this bot now. 

Nikolai cannot find any discussion related to this decision and would be happy to find out how this happened. As you can see from meeting agenda during the TSC call when Iroha progressed from Incubation to Active state, Makoto told that the project is going to use CLA hub tool, so TSC members should've been informed about that: https://lists.hyperledger.org/g/tsc/message/811

If there is an issue with DCO — should we modify Git commit history? Nikolai's personal opinion is not exactly — we must not modify who did what (commit authors should remain unchanged) and thus squash of all old commits is not an option; but if the correction is required for 1.0 codebase one of our maintainers will go over each of 7k commits and add a sign-off message (which results in change of committer — authors will remain unchanged).


Identity Working Group Calls tomorrow (March 20) at noon and 8 pm EDT

Vipin Bharathan
 

FYI

---------- Forwarded message ---------
From: vipin bharathan <vipinsun@...>
Date: Tue, Mar 19, 2019 at 1:12 PM
Subject: Identity Working Group Calls tomorrow (March 20) at noon and 8 pm EDT
To: <Identity-WG@...>


That would be 4 pm UTC and 12 midnight UTC
Hello all,

Trying an experiment tomorrow by running multiple calls at different times with the same Agenda. This is an attempt to escape the time zone limitations of our calls.

4 pm UTC is good for The whole of North and South America as well as Europe and possibly parts of the near East.

12 midnight UTC the whole of East Asia, Australia etc.

We might fiddle with these dates and times. What is unknown at this point is the level of interest we might get

Two calls tomorrow:
4 pm UTC and 12 midnight UTC

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/my/hyperledger.community

All are welcome.-


Meeting minutes:
We are taking the minutes on the wiki now. Please edit collaboratively or send updates by email. This is the location
You need a LF ID to login to edit.
To read passively you do not need a LFID
 

All are welcome. You do not have to be a member of Hyperledger to be on the call!

zoom details 
iPhone one-tap :

US: +16465588656,,4034983298# or +16699006833,,4034983298#

Or Telephone:
Dial(for higher quality, dial a number based on your current location):

US: +1 646 558 8656 or +1 669 900 6833 or +1 855 880 1246 (Toll Free) or +1 877 369 0926 (Toll Free)

Meeting ID: 403 498 3298

International numbers available: https://zoom.us/u/bAaJoyznpThis is an open call. 


Re: [Hyperledger Performance and Scale WG] [Hyperledger TSC] some thoughts on the future of the PSWG

Vipin Bharathan
 

Hello Mark and others,

We have been having similar issues with the Architecture and Identity Working Groups.

You do not join a WG to mature into a developer for a particular solution. The work in a WG is complementary to the work in a project. You could do both. The WGs are not just about "documentation".

I have been thinking about the function of Working Groups. In my view it is the following.

The Working Groups were meant to be technical and focused on cross-cutting or primary concerns; like Architecture, Identity, Performance & Scale and now Smart Contracts.

Building stuff does require thinking about what to build. The WGs were meant to be a place where technical concerns from the various projects are aired out and where the collective wisdom of the WG participants could inform us all and prevent the isolation of frameworks from each other. In other words what makes Hyperledger, Hyperledger (beyond a single ledger); to connect projects together. This is evident in the papers published by the Architecture and PSWG groups.  

The Identity WG for example had people from Legal, Technical, Business as well as practitioners from  Identity specific areas all coming together to discuss topics like GDPR, Aadhar etc. and its relevance to the DLTs we are building. We brought Indy into the mix and are now working on L2 protocols in the Identity space. There is no comparable venue in HL for this. Somehow this message has been diluted and projects do not take this seriously enough nor is it effectively communicated.

The WGs were never highlighted in the wiki, and their benefits and contributions were seen as less than "landing patches".  

I see similarities in the way SIGs are forming now. In contrast, to the WGs the SIGs focus on verticals. WGs focus on horizontals. Both are needed. There should be collaboration between the SIGs and the WGs. 

Technical Working Group China and now one for India were formed because of differences in time zones and languages; and they are like all the WGs and SIGs rolled into one for the region. 

So now for some suggestions and ideas to make Working Groups more effective and encourage participation. This is based on conversations I have had with many people:

- It is important to do cross SIG/cross Regional/cross WG presentations
-Promotion in wiki, during bootcamps, messaging and Community Architect Support
-Experimentation with meeting times to encourage worldwide participation
-For PSWG, engagement with TPC, STAC, actual functional use case(Provenance) to look for numbers to measure, Look at ExactPro methodology etc.
-Engagement with Architecture for improvements in Performance like the waterloo project and implications on DLT architecture. What are the implications for other DLTs (other than Fabric)

Hope this long email may be of some use in rebooting the WGs and also rethinking of a more collaborative future. 

Best,
Vipin

On Tue, Mar 19, 2019 at 1:22 AM Kulkarni, Amol <amol.kulkarni@...> wrote:

One of the issues with the WGs as they’re currently set up is that interested folks from Asia cannot call into them.

 

The PSWG, for example, currently meets from 6:30 – 7:30 pm India time. While I’m working on performance and benchmarking specifically, my colleagues and I cannot call into any of these meetings. Perhaps rescheduling meetings to encourage participants from different geos might be one way to increase participation in WGs.

 

Amol

 

From: tsc@... [mailto:tsc@...] On Behalf Of Silona Bonewald
Sent: Tuesday, March 19, 2019 7:49 AM
To: Christopher Ferris <chris.ferris@...>
Cc: Todd Little <todd.little@...>; Montgomery, Hart <hmontgomery@...>; mark wagner <mwagner@...>; perf-and-scale-wg@...; Hyperledger List <tsc@...>
Subject: Re: [Hyperledger Performance and Scale WG] [Hyperledger TSC] some thoughts on the future of the PSWG

 

The Technical Working Group China participated in the HKBootcamp and was highly visible.  I think it is a good idea for other working groups to think about how to recruit and engage more with the community thru events like Bootcamps etc. 

 

For example, my team has been discussing with the Learning Materials Working Group about how they will recruit.  First from the projects themselves, and then how do we help them market themselves to get more volunteers?  Of course, having a good landing page on the wiki helps!

 

Also, Hyperledger has been starting up a bunch of SIGs.  I believe some people are moving to those SIGs.  And Ecosystem team is actively recruiting new members to participate there first.  Should we look at how we cross "advertise" internally?  Or look at how we "advertise" to new members and externally.

 

What other paths to recruitment should we explore? 

 

Silona

 

On Mon, Mar 18, 2019 at 4:15 PM Christopher Ferris <chris.ferris@...> wrote:

Todd, the Fabric maintainers would welcome additional help in documenting Fabric or providing and curating samples. They don’t write themselves.

 

I tend to agree with Hart’s analysis, and while I have a regular call that conflicts, I join occasionally and am definitely interested in the subject matter.

 

I’d agree with Todd that working with a traditional benchmarking org would be good, as would input into Caliper and other performance testing efforts.

 

We aren’t yet at a point where we can effectively provide guidance on comparative performance characteristics, which is ultimately what people will be seeking.

Chris


On Mar 18, 2019, at 6:49 PM, Todd Little <todd.little@...> wrote:

Hi Hart,

I tend to agree, but I also think another factor is that as we've moved from initial versions of the various platforms to production ready platforms, people are probably getting tied up working on those production deployments.  I know for me it's mostly a matter of I participate when I don't have conflicts or not traveling.

Personally I'd like to see us move in the direction of helping some standards organizations define blockchain benchmarks that can be used to evaluate blockchain platforms, as I'm not sure we're in the business of setting those kinds of standards.  Someone please correct me if I'm wrong.  I may have asked this before, but has anyone reached out to TPC to see if they're interested in creating some blockchain benchmarks?

With respect to the documentation, agreed it's fairly weak, and in particular design documentation is sorely lacking, at least for Fabric.  I can't speak to the other platforms.  Samples/examples is another area that is pretty weak.  Our platforms are so feature rich that it's hard to pick them up without a set of rich samples/examples.

-tl

PS FWIW I'll be on the call tomorrow.

On 3/18/2019 5:28 PM, Montgomery, Hart wrote:

Hi Mark,

 

I think this is probably true for most working groups.  At least from what I’ve seen and heard (and to be fair, this is not a huge sample size), fewer people are participating in the working groups, and those who are generally are participating less.

 

I’m not sure this is a bad thing, in many cases.  I think some people have replaced spending time on working groups with time spent on regular projects.  Personally, I’ve spent less time on working group stuff since Ursa has begun (and, obviously, more time on Ursa), which is probably a kind of progression we want to encourage in Hyperledger.  Having people that come into the working groups looking to learn become regular contributors surely is a positive thing. 

 

On the other hand, as the working groups seem to focus more and more on work products—which is typically documentation--fewer people seem to be interested since there is often substantial outside work involved, and not necessarily of the fun kind.  In particular, I think every SWOT analysis we have done on Hyperledger involves documentation being listed as a weakness.   While documentation has gotten better, it’s still something that I think most people would agree needs a lot of work on most aspects of Hyperledger.

 

So, for a TL;DR:  from my viewpoint, people are leaving working groups to contribute (great!)  or avoid documentation work (not so great). 

 

Do these experiences jibe with yours (or others’)?

 

Sorry for another long email.

 

Thanks,

Hart

 

 

 

From: tsc@... [mailto:tsc@...] On Behalf Of mark wagner
Sent: Monday, March 18, 2019 12:33 PM
To: perf-and-scale-wg@...
Cc: Hyperledger List <tsc@...>
Subject: [Hyperledger TSC] some thoughts on the future of the PSWG

 

Hi

 

I would like to carry this discussion mostly in the mailing lists in order to be as inclusive as possible.

 

Over the last few months attendance and participation on the Performance and Scale WG (PSWG) calls has been declining. I am wondering if we need to shift focus a bit to get more people involved and make progress.

 

There are many possible directions we can head in and I have included some thoughts here, but if others have additional ideas please feel encouraged to add them.

 

First is stay the course. We are currently struggling to get our thoughts on describing metrics for provenance captured to paper.

 

Do we want to focus more on actual performance work vs just defining metrics / use case papers. This does not need to be "just running tests".

 

We can do things like examine trade offs between different design decisions, examine different crypto solutions / technologies from a perf and scale perspective, help understand cost performance tradeoffs.

 

Perhaps we help spin up testnets and drive testing of different DLT frameworks ?

 

Do we provide a performance analysis service to the different projects that is based on architecture decisions. Perhaps something similar to what several research students have done (Harish and his team, FastFabric, etc).

 

I am trying to cut a wide swath here to avoid limiting peoples thoughts, so any and all comments are encouraged. If you have not been involved in the PSWG and would be interested in participating if we did "X" then speak up!

 

thanks

 

-mark

--

Mark Wagner

Chair, Performance and Scale Working Group

 



--

Silona Bonewald

VP of Community Architecture, Hyperledger

Mobile/Text: 512.750.9220
https://calendly.com/silona

The Linux Foundation
http://hyperledger.org


Re: Some thoughts on the future of the PSWG

Michael Schloh von Bennewitz <hyperledger@...>
 

Hello Silona,

On lun., mars 18, 2019, Silona Bonewald wrote:
The Technical Working Group China participated in the HKBootcamp and was
highly visible. I think it is a good idea for other working groups to
think about how to recruit and engage more with the community thru events
like Bootcamps etc.
This probably deserves an official announcement, but any
Hyperledger activity in or near China should please consider:

Defcon China 1.0
Beijing 31 May - 2 June
Bits and Blocks Village
Blockchain learning and hacking
Partnered with Baidu Security!

We are forming the staff to plan the village right now, and I hope
very much that Hyperledger plays an important role in outreach.

We may have a blockchain challenge or hackathon, or
t may be a bootcamp. It's too early to know for sure.

[...]

What other paths to recruitment should we explore?
The path going through the door of our Bits and Blocks village!

Anyone interested in a management role with benefits or a more
simple one like speaking or workshop instruction should please
contact me at michael@....

https://www.defcon.org/

Cheers,
Michael


Hyperledger Caliper Quarterly Update Due #tsc-project-update - Thu, 03/21/2019 #tsc-project-update #cal-reminder

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

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

When:
Thursday, 21 March 2019

Organizer:
tkuhrt@...

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

View Event


Re: [Hyperledger Performance and Scale WG] [Hyperledger TSC] some thoughts on the future of the PSWG

Kulkarni, Amol <amol.kulkarni@...>
 

One of the issues with the WGs as they’re currently set up is that interested folks from Asia cannot call into them.

 

The PSWG, for example, currently meets from 6:30 – 7:30 pm India time. While I’m working on performance and benchmarking specifically, my colleagues and I cannot call into any of these meetings. Perhaps rescheduling meetings to encourage participants from different geos might be one way to increase participation in WGs.

 

Amol

 

From: tsc@... [mailto:tsc@...] On Behalf Of Silona Bonewald
Sent: Tuesday, March 19, 2019 7:49 AM
To: Christopher Ferris <chris.ferris@...>
Cc: Todd Little <todd.little@...>; Montgomery, Hart <hmontgomery@...>; mark wagner <mwagner@...>; perf-and-scale-wg@...; Hyperledger List <tsc@...>
Subject: Re: [Hyperledger Performance and Scale WG] [Hyperledger TSC] some thoughts on the future of the PSWG

 

The Technical Working Group China participated in the HKBootcamp and was highly visible.  I think it is a good idea for other working groups to think about how to recruit and engage more with the community thru events like Bootcamps etc. 

 

For example, my team has been discussing with the Learning Materials Working Group about how they will recruit.  First from the projects themselves, and then how do we help them market themselves to get more volunteers?  Of course, having a good landing page on the wiki helps!

 

Also, Hyperledger has been starting up a bunch of SIGs.  I believe some people are moving to those SIGs.  And Ecosystem team is actively recruiting new members to participate there first.  Should we look at how we cross "advertise" internally?  Or look at how we "advertise" to new members and externally.

 

What other paths to recruitment should we explore? 

 

Silona

 

On Mon, Mar 18, 2019 at 4:15 PM Christopher Ferris <chris.ferris@...> wrote:

Todd, the Fabric maintainers would welcome additional help in documenting Fabric or providing and curating samples. They don’t write themselves.

 

I tend to agree with Hart’s analysis, and while I have a regular call that conflicts, I join occasionally and am definitely interested in the subject matter.

 

I’d agree with Todd that working with a traditional benchmarking org would be good, as would input into Caliper and other performance testing efforts.

 

We aren’t yet at a point where we can effectively provide guidance on comparative performance characteristics, which is ultimately what people will be seeking.

Chris


On Mar 18, 2019, at 6:49 PM, Todd Little <todd.little@...> wrote:

Hi Hart,

I tend to agree, but I also think another factor is that as we've moved from initial versions of the various platforms to production ready platforms, people are probably getting tied up working on those production deployments.  I know for me it's mostly a matter of I participate when I don't have conflicts or not traveling.

Personally I'd like to see us move in the direction of helping some standards organizations define blockchain benchmarks that can be used to evaluate blockchain platforms, as I'm not sure we're in the business of setting those kinds of standards.  Someone please correct me if I'm wrong.  I may have asked this before, but has anyone reached out to TPC to see if they're interested in creating some blockchain benchmarks?

With respect to the documentation, agreed it's fairly weak, and in particular design documentation is sorely lacking, at least for Fabric.  I can't speak to the other platforms.  Samples/examples is another area that is pretty weak.  Our platforms are so feature rich that it's hard to pick them up without a set of rich samples/examples.

-tl

PS FWIW I'll be on the call tomorrow.

On 3/18/2019 5:28 PM, Montgomery, Hart wrote:

Hi Mark,

 

I think this is probably true for most working groups.  At least from what I’ve seen and heard (and to be fair, this is not a huge sample size), fewer people are participating in the working groups, and those who are generally are participating less.

 

I’m not sure this is a bad thing, in many cases.  I think some people have replaced spending time on working groups with time spent on regular projects.  Personally, I’ve spent less time on working group stuff since Ursa has begun (and, obviously, more time on Ursa), which is probably a kind of progression we want to encourage in Hyperledger.  Having people that come into the working groups looking to learn become regular contributors surely is a positive thing. 

 

On the other hand, as the working groups seem to focus more and more on work products—which is typically documentation--fewer people seem to be interested since there is often substantial outside work involved, and not necessarily of the fun kind.  In particular, I think every SWOT analysis we have done on Hyperledger involves documentation being listed as a weakness.   While documentation has gotten better, it’s still something that I think most people would agree needs a lot of work on most aspects of Hyperledger.

 

So, for a TL;DR:  from my viewpoint, people are leaving working groups to contribute (great!)  or avoid documentation work (not so great). 

 

Do these experiences jibe with yours (or others’)?

 

Sorry for another long email.

 

Thanks,

Hart

 

 

 

From: tsc@... [mailto:tsc@...] On Behalf Of mark wagner
Sent: Monday, March 18, 2019 12:33 PM
To: perf-and-scale-wg@...
Cc: Hyperledger List <tsc@...>
Subject: [Hyperledger TSC] some thoughts on the future of the PSWG

 

Hi

 

I would like to carry this discussion mostly in the mailing lists in order to be as inclusive as possible.

 

Over the last few months attendance and participation on the Performance and Scale WG (PSWG) calls has been declining. I am wondering if we need to shift focus a bit to get more people involved and make progress.

 

There are many possible directions we can head in and I have included some thoughts here, but if others have additional ideas please feel encouraged to add them.

 

First is stay the course. We are currently struggling to get our thoughts on describing metrics for provenance captured to paper.

 

Do we want to focus more on actual performance work vs just defining metrics / use case papers. This does not need to be "just running tests".

 

We can do things like examine trade offs between different design decisions, examine different crypto solutions / technologies from a perf and scale perspective, help understand cost performance tradeoffs.

 

Perhaps we help spin up testnets and drive testing of different DLT frameworks ?

 

Do we provide a performance analysis service to the different projects that is based on architecture decisions. Perhaps something similar to what several research students have done (Harish and his team, FastFabric, etc).

 

I am trying to cut a wide swath here to avoid limiting peoples thoughts, so any and all comments are encouraged. If you have not been involved in the PSWG and would be interested in participating if we did "X" then speak up!

 

thanks

 

-mark

--

Mark Wagner

Chair, Performance and Scale Working Group

 



--

Silona Bonewald

VP of Community Architecture, Hyperledger

Mobile/Text: 512.750.9220
https://calendly.com/silona

The Linux Foundation
http://hyperledger.org


Re: [Hyperledger Performance and Scale WG] [Hyperledger TSC] some thoughts on the future of the PSWG

Silona Bonewald <sbonewald@...>
 

The Technical Working Group China participated in the HKBootcamp and was highly visible.  I think it is a good idea for other working groups to think about how to recruit and engage more with the community thru events like Bootcamps etc. 

For example, my team has been discussing with the Learning Materials Working Group about how they will recruit.  First from the projects themselves, and then how do we help them market themselves to get more volunteers?  Of course, having a good landing page on the wiki helps!

Also, Hyperledger has been starting up a bunch of SIGs.  I believe some people are moving to those SIGs.  And Ecosystem team is actively recruiting new members to participate there first.  Should we look at how we cross "advertise" internally?  Or look at how we "advertise" to new members and externally.

What other paths to recruitment should we explore? 

Silona

On Mon, Mar 18, 2019 at 4:15 PM Christopher Ferris <chris.ferris@...> wrote:
Todd, the Fabric maintainers would welcome additional help in documenting Fabric or providing and curating samples. They don’t write themselves.

I tend to agree with Hart’s analysis, and while I have a regular call that conflicts, I join occasionally and am definitely interested in the subject matter.

I’d agree with Todd that working with a traditional benchmarking org would be good, as would input into Caliper and other performance testing efforts.

We aren’t yet at a point where we can effectively provide guidance on comparative performance characteristics, which is ultimately what people will be seeking.

Chris

On Mar 18, 2019, at 6:49 PM, Todd Little <todd.little@...> wrote:

Hi Hart,

I tend to agree, but I also think another factor is that as we've moved from initial versions of the various platforms to production ready platforms, people are probably getting tied up working on those production deployments.  I know for me it's mostly a matter of I participate when I don't have conflicts or not traveling.

Personally I'd like to see us move in the direction of helping some standards organizations define blockchain benchmarks that can be used to evaluate blockchain platforms, as I'm not sure we're in the business of setting those kinds of standards.  Someone please correct me if I'm wrong.  I may have asked this before, but has anyone reached out to TPC to see if they're interested in creating some blockchain benchmarks?

With respect to the documentation, agreed it's fairly weak, and in particular design documentation is sorely lacking, at least for Fabric.  I can't speak to the other platforms.  Samples/examples is another area that is pretty weak.  Our platforms are so feature rich that it's hard to pick them up without a set of rich samples/examples.

-tl

PS FWIW I'll be on the call tomorrow.

On 3/18/2019 5:28 PM, Montgomery, Hart wrote:

Hi Mark,

 

I think this is probably true for most working groups.  At least from what I’ve seen and heard (and to be fair, this is not a huge sample size), fewer people are participating in the working groups, and those who are generally are participating less.

 

I’m not sure this is a bad thing, in many cases.  I think some people have replaced spending time on working groups with time spent on regular projects.  Personally, I’ve spent less time on working group stuff since Ursa has begun (and, obviously, more time on Ursa), which is probably a kind of progression we want to encourage in Hyperledger.  Having people that come into the working groups looking to learn become regular contributors surely is a positive thing. 

 

On the other hand, as the working groups seem to focus more and more on work products—which is typically documentation--fewer people seem to be interested since there is often substantial outside work involved, and not necessarily of the fun kind.  In particular, I think every SWOT analysis we have done on Hyperledger involves documentation being listed as a weakness.   While documentation has gotten better, it’s still something that I think most people would agree needs a lot of work on most aspects of Hyperledger.

 

So, for a TL;DR:  from my viewpoint, people are leaving working groups to contribute (great!)  or avoid documentation work (not so great). 

 

Do these experiences jibe with yours (or others’)?

 

Sorry for another long email.

 

Thanks,

Hart

 

 

 

From: tsc@... [mailto:tsc@...] On Behalf Of mark wagner
Sent: Monday, March 18, 2019 12:33 PM
To: perf-and-scale-wg@...
Cc: Hyperledger List <tsc@...>
Subject: [Hyperledger TSC] some thoughts on the future of the PSWG

 

Hi

 

I would like to carry this discussion mostly in the mailing lists in order to be as inclusive as possible.

 

Over the last few months attendance and participation on the Performance and Scale WG (PSWG) calls has been declining. I am wondering if we need to shift focus a bit to get more people involved and make progress.

 

There are many possible directions we can head in and I have included some thoughts here, but if others have additional ideas please feel encouraged to add them.

 

First is stay the course. We are currently struggling to get our thoughts on describing metrics for provenance captured to paper.

 

Do we want to focus more on actual performance work vs just defining metrics / use case papers. This does not need to be "just running tests".

 

We can do things like examine trade offs between different design decisions, examine different crypto solutions / technologies from a perf and scale perspective, help understand cost performance tradeoffs.

 

Perhaps we help spin up testnets and drive testing of different DLT frameworks ?

 

Do we provide a performance analysis service to the different projects that is based on architecture decisions. Perhaps something similar to what several research students have done (Harish and his team, FastFabric, etc).

 

I am trying to cut a wide swath here to avoid limiting peoples thoughts, so any and all comments are encouraged. If you have not been involved in the PSWG and would be interested in participating if we did "X" then speak up!

 

thanks

 

-mark

--

Mark Wagner

Chair, Performance and Scale Working Group




--
Silona Bonewald
VP of Community Architecture, Hyperledger
Mobile/Text: 512.750.9220
https://calendly.com/silona
The Linux Foundation
http://hyperledger.org


Re: [Hyperledger Performance and Scale WG] [Hyperledger TSC] some thoughts on the future of the PSWG

Christopher Ferris <chris.ferris@...>
 

Todd, the Fabric maintainers would welcome additional help in documenting Fabric or providing and curating samples. They don’t write themselves.

I tend to agree with Hart’s analysis, and while I have a regular call that conflicts, I join occasionally and am definitely interested in the subject matter.

I’d agree with Todd that working with a traditional benchmarking org would be good, as would input into Caliper and other performance testing efforts.

We aren’t yet at a point where we can effectively provide guidance on comparative performance characteristics, which is ultimately what people will be seeking.

Chris

On Mar 18, 2019, at 6:49 PM, Todd Little <todd.little@...> wrote:

Hi Hart,

I tend to agree, but I also think another factor is that as we've moved from initial versions of the various platforms to production ready platforms, people are probably getting tied up working on those production deployments.  I know for me it's mostly a matter of I participate when I don't have conflicts or not traveling.

Personally I'd like to see us move in the direction of helping some standards organizations define blockchain benchmarks that can be used to evaluate blockchain platforms, as I'm not sure we're in the business of setting those kinds of standards.  Someone please correct me if I'm wrong.  I may have asked this before, but has anyone reached out to TPC to see if they're interested in creating some blockchain benchmarks?

With respect to the documentation, agreed it's fairly weak, and in particular design documentation is sorely lacking, at least for Fabric.  I can't speak to the other platforms.  Samples/examples is another area that is pretty weak.  Our platforms are so feature rich that it's hard to pick them up without a set of rich samples/examples.

-tl

PS FWIW I'll be on the call tomorrow.

On 3/18/2019 5:28 PM, Montgomery, Hart wrote:

Hi Mark,

 

I think this is probably true for most working groups.  At least from what I’ve seen and heard (and to be fair, this is not a huge sample size), fewer people are participating in the working groups, and those who are generally are participating less.

 

I’m not sure this is a bad thing, in many cases.  I think some people have replaced spending time on working groups with time spent on regular projects.  Personally, I’ve spent less time on working group stuff since Ursa has begun (and, obviously, more time on Ursa), which is probably a kind of progression we want to encourage in Hyperledger.  Having people that come into the working groups looking to learn become regular contributors surely is a positive thing. 

 

On the other hand, as the working groups seem to focus more and more on work products—which is typically documentation--fewer people seem to be interested since there is often substantial outside work involved, and not necessarily of the fun kind.  In particular, I think every SWOT analysis we have done on Hyperledger involves documentation being listed as a weakness.   While documentation has gotten better, it’s still something that I think most people would agree needs a lot of work on most aspects of Hyperledger.

 

So, for a TL;DR:  from my viewpoint, people are leaving working groups to contribute (great!)  or avoid documentation work (not so great). 

 

Do these experiences jibe with yours (or others’)?

 

Sorry for another long email.

 

Thanks,

Hart

 

 

 

From: tsc@... [mailto:tsc@...] On Behalf Of mark wagner
Sent: Monday, March 18, 2019 12:33 PM
To: perf-and-scale-wg@...
Cc: Hyperledger List <tsc@...>
Subject: [Hyperledger TSC] some thoughts on the future of the PSWG

 

Hi

 

I would like to carry this discussion mostly in the mailing lists in order to be as inclusive as possible.

 

Over the last few months attendance and participation on the Performance and Scale WG (PSWG) calls has been declining. I am wondering if we need to shift focus a bit to get more people involved and make progress.

 

There are many possible directions we can head in and I have included some thoughts here, but if others have additional ideas please feel encouraged to add them.

 

First is stay the course. We are currently struggling to get our thoughts on describing metrics for provenance captured to paper.

 

Do we want to focus more on actual performance work vs just defining metrics / use case papers. This does not need to be "just running tests".

 

We can do things like examine trade offs between different design decisions, examine different crypto solutions / technologies from a perf and scale perspective, help understand cost performance tradeoffs.

 

Perhaps we help spin up testnets and drive testing of different DLT frameworks ?

 

Do we provide a performance analysis service to the different projects that is based on architecture decisions. Perhaps something similar to what several research students have done (Harish and his team, FastFabric, etc).

 

I am trying to cut a wide swath here to avoid limiting peoples thoughts, so any and all comments are encouraged. If you have not been involved in the PSWG and would be interested in participating if we did "X" then speak up!

 

thanks

 

-mark

--

Mark Wagner

Chair, Performance and Scale Working Group



Re: [Hyperledger Performance and Scale WG] [Hyperledger TSC] some thoughts on the future of the PSWG

Todd Little
 

Hi Hart,

I tend to agree, but I also think another factor is that as we've moved from initial versions of the various platforms to production ready platforms, people are probably getting tied up working on those production deployments.  I know for me it's mostly a matter of I participate when I don't have conflicts or not traveling.

Personally I'd like to see us move in the direction of helping some standards organizations define blockchain benchmarks that can be used to evaluate blockchain platforms, as I'm not sure we're in the business of setting those kinds of standards.  Someone please correct me if I'm wrong.  I may have asked this before, but has anyone reached out to TPC to see if they're interested in creating some blockchain benchmarks?

With respect to the documentation, agreed it's fairly weak, and in particular design documentation is sorely lacking, at least for Fabric.  I can't speak to the other platforms.  Samples/examples is another area that is pretty weak.  Our platforms are so feature rich that it's hard to pick them up without a set of rich samples/examples.

-tl

PS FWIW I'll be on the call tomorrow.

On 3/18/2019 5:28 PM, Montgomery, Hart wrote:

Hi Mark,

 

I think this is probably true for most working groups.  At least from what I’ve seen and heard (and to be fair, this is not a huge sample size), fewer people are participating in the working groups, and those who are generally are participating less.

 

I’m not sure this is a bad thing, in many cases.  I think some people have replaced spending time on working groups with time spent on regular projects.  Personally, I’ve spent less time on working group stuff since Ursa has begun (and, obviously, more time on Ursa), which is probably a kind of progression we want to encourage in Hyperledger.  Having people that come into the working groups looking to learn become regular contributors surely is a positive thing. 

 

On the other hand, as the working groups seem to focus more and more on work products—which is typically documentation--fewer people seem to be interested since there is often substantial outside work involved, and not necessarily of the fun kind.  In particular, I think every SWOT analysis we have done on Hyperledger involves documentation being listed as a weakness.   While documentation has gotten better, it’s still something that I think most people would agree needs a lot of work on most aspects of Hyperledger.

 

So, for a TL;DR:  from my viewpoint, people are leaving working groups to contribute (great!)  or avoid documentation work (not so great). 

 

Do these experiences jibe with yours (or others’)?

 

Sorry for another long email.

 

Thanks,

Hart

 

 

 

From: tsc@... [mailto:tsc@...] On Behalf Of mark wagner
Sent: Monday, March 18, 2019 12:33 PM
To: perf-and-scale-wg@...
Cc: Hyperledger List <tsc@...>
Subject: [Hyperledger TSC] some thoughts on the future of the PSWG

 

Hi

 

I would like to carry this discussion mostly in the mailing lists in order to be as inclusive as possible.

 

Over the last few months attendance and participation on the Performance and Scale WG (PSWG) calls has been declining. I am wondering if we need to shift focus a bit to get more people involved and make progress.

 

There are many possible directions we can head in and I have included some thoughts here, but if others have additional ideas please feel encouraged to add them.

 

First is stay the course. We are currently struggling to get our thoughts on describing metrics for provenance captured to paper.

 

Do we want to focus more on actual performance work vs just defining metrics / use case papers. This does not need to be "just running tests".

 

We can do things like examine trade offs between different design decisions, examine different crypto solutions / technologies from a perf and scale perspective, help understand cost performance tradeoffs.

 

Perhaps we help spin up testnets and drive testing of different DLT frameworks ?

 

Do we provide a performance analysis service to the different projects that is based on architecture decisions. Perhaps something similar to what several research students have done (Harish and his team, FastFabric, etc).

 

I am trying to cut a wide swath here to avoid limiting peoples thoughts, so any and all comments are encouraged. If you have not been involved in the PSWG and would be interested in participating if we did "X" then speak up!

 

thanks

 

-mark

--

Mark Wagner

Chair, Performance and Scale Working Group



Re: some thoughts on the future of the PSWG

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

Hi Mark,

 

I think this is probably true for most working groups.  At least from what I’ve seen and heard (and to be fair, this is not a huge sample size), fewer people are participating in the working groups, and those who are generally are participating less.

 

I’m not sure this is a bad thing, in many cases.  I think some people have replaced spending time on working groups with time spent on regular projects.  Personally, I’ve spent less time on working group stuff since Ursa has begun (and, obviously, more time on Ursa), which is probably a kind of progression we want to encourage in Hyperledger.  Having people that come into the working groups looking to learn become regular contributors surely is a positive thing. 

 

On the other hand, as the working groups seem to focus more and more on work products—which is typically documentation--fewer people seem to be interested since there is often substantial outside work involved, and not necessarily of the fun kind.  In particular, I think every SWOT analysis we have done on Hyperledger involves documentation being listed as a weakness.   While documentation has gotten better, it’s still something that I think most people would agree needs a lot of work on most aspects of Hyperledger.

 

So, for a TL;DR:  from my viewpoint, people are leaving working groups to contribute (great!)  or avoid documentation work (not so great). 

 

Do these experiences jibe with yours (or others’)?

 

Sorry for another long email.

 

Thanks,

Hart

 

 

 

From: tsc@... [mailto:tsc@...] On Behalf Of mark wagner
Sent: Monday, March 18, 2019 12:33 PM
To: perf-and-scale-wg@...
Cc: Hyperledger List <tsc@...>
Subject: [Hyperledger TSC] some thoughts on the future of the PSWG

 

Hi

 

I would like to carry this discussion mostly in the mailing lists in order to be as inclusive as possible.

 

Over the last few months attendance and participation on the Performance and Scale WG (PSWG) calls has been declining. I am wondering if we need to shift focus a bit to get more people involved and make progress.

 

There are many possible directions we can head in and I have included some thoughts here, but if others have additional ideas please feel encouraged to add them.

 

First is stay the course. We are currently struggling to get our thoughts on describing metrics for provenance captured to paper.

 

Do we want to focus more on actual performance work vs just defining metrics / use case papers. This does not need to be "just running tests".

 

We can do things like examine trade offs between different design decisions, examine different crypto solutions / technologies from a perf and scale perspective, help understand cost performance tradeoffs.

 

Perhaps we help spin up testnets and drive testing of different DLT frameworks ?

 

Do we provide a performance analysis service to the different projects that is based on architecture decisions. Perhaps something similar to what several research students have done (Harish and his team, FastFabric, etc).

 

I am trying to cut a wide swath here to avoid limiting peoples thoughts, so any and all comments are encouraged. If you have not been involved in the PSWG and would be interested in participating if we did "X" then speak up!

 

thanks

 

-mark

--

Mark Wagner

Chair, Performance and Scale Working Group


some thoughts on the future of the PSWG

mark wagner <mwagner@...>
 

Hi

I would like to carry this discussion mostly in the mailing lists in order to be as inclusive as possible.

Over the last few months attendance and participation on the Performance and Scale WG (PSWG) calls has been declining. I am wondering if we need to shift focus a bit to get more people involved and make progress.

There are many possible directions we can head in and I have included some thoughts here, but if others have additional ideas please feel encouraged to add them.

First is stay the course. We are currently struggling to get our thoughts on describing metrics for provenance captured to paper.

Do we want to focus more on actual performance work vs just defining metrics / use case papers. This does not need to be "just running tests".

We can do things like examine trade offs between different design decisions, examine different crypto solutions / technologies from a perf and scale perspective, help understand cost performance tradeoffs.

Perhaps we help spin up testnets and drive testing of different DLT frameworks ?

Do we provide a performance analysis service to the different projects that is based on architecture decisions. Perhaps something similar to what several research students have done (Harish and his team, FastFabric, etc).

I am trying to cut a wide swath here to avoid limiting peoples thoughts, so any and all comments are encouraged. If you have not been involved in the PSWG and would be interested in participating if we did "X" then speak up!

thanks

-mark
--
Mark Wagner
Chair, Performance and Scale Working Group


Re: Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

takakir@jp.ibm.com
 

My apologies.
Pls disregard my previous email as it was sent by error.


iPhoneから送信

2019/03/18 21:20、"takakir@..." <takakir@...>のメール:

B1の鳥料理 藤よしにいます。

iPhoneから送信

2019/03/18 20:56、Vipin Bharathan <vipinsun@...>のメール:

In short Exactpro has not done any tests. But they already know the results. Exactly the pros I would want to do my testing.
Vipin


On Mar 18, 2019, at 6:21 AM, Ian Allison <ian@...> wrote:

Attachments10:14 AM (0 minutes ago)
Hi guys,

Post-trade DLT systems such as those provided using R3’s Corda, Hyperledger Fabric and Digital Asset are still a couple of years shy of the tough benchmark software tests implemented by post-trade tech assurance specialists Exactpro.


In particular, the most likely points of failure will be where these DLT systems connect to legacy architecture, noted Exactpro which exclusively shared a white paper outlining its methodology, to be presented at the ICST 2019 conference in China next month.


Exactpro has a venerable history in post-trade technology testing, having been acquired by the London Stock Exchange back in 2015, the firm completed a buyout from LSEG at the beginning of 2018. Exactpro now employs over 550 specialists.


Stepping back, Iosif Itkin, co-CEO and co-founder of Exactpro said,


  • I think there are still gaps in technology so we can’t assume that the fabrics already support everything. I think it is still a question of a couple of years before there will be a radical shift from prototyping to software testing. Prototyping focuses on the parts that work. Testing focuses on the parts that do not work. This shift is required before large scale mission critical systems will go into live service.

  • In my view when we look at implementing prototypes we constantly encounter particular parts are not implemented yet. E.g. domain models are absent in most of the areas and software developers need to build them from scratch for every new use-case. In the code there are still some trade-offs between what is already available and the security/reliability requirements. These [missing parts] are well known to developers and expected to be released in the next versions. It is just there is still lots of work to do.


On Thu, Mar 14, 2019 at 4:03 PM Vipin Bharathan <vipinsun@...> wrote:
Hi all,

As suggested in today's tsc meeting I am raising the question Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?
Are numbers like the number of lines of code (or equivalent measures) from companies available at time of 1.0 (in active) available for other frameworks that already passed this milestone?

Another interesting statistic would be increase in contributor diversity SINCE 1.0.
Just to ensure that criteria are applied fairly for all projects in 1.0. And to see whether adoption is linked to 1.0 announcement.

Please put this on next week's agenda.

Regards,
Vipin
 
Also added as comment on the Agenda.



--
Ian Allison 
Reporter | CoinDesk
Direct:  +44 203 894 5977
Mobile: +44 742 768 6132

CoinDesk: News -- Events -- Research

<ICST 2019 - 4pages_bib_upd.pdf>



Re: Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

takakir@jp.ibm.com
 

B1の鳥料理 藤よしにいます。

iPhoneから送信

2019/03/18 20:56、Vipin Bharathan <vipinsun@...>のメール:

In short Exactpro has not done any tests. But they already know the results. Exactly the pros I would want to do my testing.
Vipin


On Mar 18, 2019, at 6:21 AM, Ian Allison <ian@...> wrote:

Attachments10:14 AM (0 minutes ago)
Hi guys,

Post-trade DLT systems such as those provided using R3’s Corda, Hyperledger Fabric and Digital Asset are still a couple of years shy of the tough benchmark software tests implemented by post-trade tech assurance specialists Exactpro.


In particular, the most likely points of failure will be where these DLT systems connect to legacy architecture, noted Exactpro which exclusively shared a white paper outlining its methodology, to be presented at the ICST 2019 conference in China next month.


Exactpro has a venerable history in post-trade technology testing, having been acquired by the London Stock Exchange back in 2015, the firm completed a buyout from LSEG at the beginning of 2018. Exactpro now employs over 550 specialists.


Stepping back, Iosif Itkin, co-CEO and co-founder of Exactpro said,


  • I think there are still gaps in technology so we can’t assume that the fabrics already support everything. I think it is still a question of a couple of years before there will be a radical shift from prototyping to software testing. Prototyping focuses on the parts that work. Testing focuses on the parts that do not work. This shift is required before large scale mission critical systems will go into live service.

  • In my view when we look at implementing prototypes we constantly encounter particular parts are not implemented yet. E.g. domain models are absent in most of the areas and software developers need to build them from scratch for every new use-case. In the code there are still some trade-offs between what is already available and the security/reliability requirements. These [missing parts] are well known to developers and expected to be released in the next versions. It is just there is still lots of work to do.


On Thu, Mar 14, 2019 at 4:03 PM Vipin Bharathan <vipinsun@...> wrote:
Hi all,

As suggested in today's tsc meeting I am raising the question Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?
Are numbers like the number of lines of code (or equivalent measures) from companies available at time of 1.0 (in active) available for other frameworks that already passed this milestone?

Another interesting statistic would be increase in contributor diversity SINCE 1.0.
Just to ensure that criteria are applied fairly for all projects in 1.0. And to see whether adoption is linked to 1.0 announcement.

Please put this on next week's agenda.

Regards,
Vipin
 
Also added as comment on the Agenda.



--
Ian Allison 
Reporter | CoinDesk
Direct:  +44 203 894 5977
Mobile: +44 742 768 6132

CoinDesk: News -- Events -- Research

<ICST 2019 - 4pages_bib_upd.pdf>


Re: Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

Vipin Bharathan
 

In short Exactpro has not done any tests. But they already know the results. Exactly the pros I would want to do my testing.
Vipin


On Mar 18, 2019, at 6:21 AM, Ian Allison <ian@...> wrote:

Attachments10:14 AM (0 minutes ago)
Hi guys,

Post-trade DLT systems such as those provided using R3’s Corda, Hyperledger Fabric and Digital Asset are still a couple of years shy of the tough benchmark software tests implemented by post-trade tech assurance specialists Exactpro.


In particular, the most likely points of failure will be where these DLT systems connect to legacy architecture, noted Exactpro which exclusively shared a white paper outlining its methodology, to be presented at the ICST 2019 conference in China next month.


Exactpro has a venerable history in post-trade technology testing, having been acquired by the London Stock Exchange back in 2015, the firm completed a buyout from LSEG at the beginning of 2018. Exactpro now employs over 550 specialists.


Stepping back, Iosif Itkin, co-CEO and co-founder of Exactpro said,


  • I think there are still gaps in technology so we can’t assume that the fabrics already support everything. I think it is still a question of a couple of years before there will be a radical shift from prototyping to software testing. Prototyping focuses on the parts that work. Testing focuses on the parts that do not work. This shift is required before large scale mission critical systems will go into live service.

  • In my view when we look at implementing prototypes we constantly encounter particular parts are not implemented yet. E.g. domain models are absent in most of the areas and software developers need to build them from scratch for every new use-case. In the code there are still some trade-offs between what is already available and the security/reliability requirements. These [missing parts] are well known to developers and expected to be released in the next versions. It is just there is still lots of work to do.


On Thu, Mar 14, 2019 at 4:03 PM Vipin Bharathan <vipinsun@...> wrote:
Hi all,

As suggested in today's tsc meeting I am raising the question Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?
Are numbers like the number of lines of code (or equivalent measures) from companies available at time of 1.0 (in active) available for other frameworks that already passed this milestone?

Another interesting statistic would be increase in contributor diversity SINCE 1.0.
Just to ensure that criteria are applied fairly for all projects in 1.0. And to see whether adoption is linked to 1.0 announcement.

Please put this on next week's agenda.

Regards,
Vipin
 
Also added as comment on the Agenda.



--
Ian Allison 
Reporter | CoinDesk
Direct:  +44 203 894 5977
Mobile: +44 742 768 6132

CoinDesk: News -- Events -- Research

<ICST 2019 - 4pages_bib_upd.pdf>


Re: Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

Ian Allison
 

Attachments10:14 AM (0 minutes ago)
Hi guys,

Post-trade DLT systems such as those provided using R3’s Corda, Hyperledger Fabric and Digital Asset are still a couple of years shy of the tough benchmark software tests implemented by post-trade tech assurance specialists Exactpro.


In particular, the most likely points of failure will be where these DLT systems connect to legacy architecture, noted Exactpro which exclusively shared a white paper outlining its methodology, to be presented at the ICST 2019 conference in China next month.


Exactpro has a venerable history in post-trade technology testing, having been acquired by the London Stock Exchange back in 2015, the firm completed a buyout from LSEG at the beginning of 2018. Exactpro now employs over 550 specialists.


Stepping back, Iosif Itkin, co-CEO and co-founder of Exactpro said,


  • I think there are still gaps in technology so we can’t assume that the fabrics already support everything. I think it is still a question of a couple of years before there will be a radical shift from prototyping to software testing. Prototyping focuses on the parts that work. Testing focuses on the parts that do not work. This shift is required before large scale mission critical systems will go into live service.

  • In my view when we look at implementing prototypes we constantly encounter particular parts are not implemented yet. E.g. domain models are absent in most of the areas and software developers need to build them from scratch for every new use-case. In the code there are still some trade-offs between what is already available and the security/reliability requirements. These [missing parts] are well known to developers and expected to be released in the next versions. It is just there is still lots of work to do.


On Thu, Mar 14, 2019 at 4:03 PM Vipin Bharathan <vipinsun@...> wrote:
Hi all,

As suggested in today's tsc meeting I am raising the question Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?
Are numbers like the number of lines of code (or equivalent measures) from companies available at time of 1.0 (in active) available for other frameworks that already passed this milestone?

Another interesting statistic would be increase in contributor diversity SINCE 1.0.
Just to ensure that criteria are applied fairly for all projects in 1.0. And to see whether adoption is linked to 1.0 announcement.

Please put this on next week's agenda.

Regards,
Vipin
 
Also added as comment on the Agenda.



--
Ian Allison 
Reporter | CoinDesk
Direct:  +44 203 894 5977
Mobile: +44 742 768 6132

CoinDesk: News -- Events -- Research


Re: Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

mark wagner <mwagner@...>
 

Vipin and all

Note that my comments below are "generic" and do not specifically apply to Iroha.

I agree that a 1.0 release should mean "production ready". Part of that is quality of code, completeness of code / design, etc.
To me production ready also means that the project is ready to support the users who have issues, find bugs, etc. While this is open source, we need to take the mindset of a for profit company wrt to making sure the code is supportable, etc. If the code is poor and the resources are not adequate, a for profit company will go out of business with a bad 1.0 release.

I also feel that projects should be able to be move in either direction along the "status" line. For example, if a project loses a lot of participants and is on life support, perhaps it should go back to incubation for a reboot. This is a project health issue, not a version issue. Of course we could come up with another state to accomplish the same thing if that makes people more comfortable.

I also feel that in order to move forward, we need to have clear and articulated guidelines/rules/requirements for what constitutes the various project stages and release criteria. I disagree with the philosophy of "well we didn't apply that on project X three years ago so we cant use it here" This is about moving forward and building a stronger Hyperledger, if the rules need to get tweaked (or written down) then imho its the right direction to go in. A separate discussion is if we then be do we need to go back and "level set" all projects on the new guidelines or are older projects grandfathered in.

Finally, and more of a devils advocate question (and this is were people that know me get nervous), in addition to diversity of contributors, do we need to have a minimum number of active contributors ?   could a project with three highly over-caffeinated contributors, all from different companies, progress along our project life-cycle ?

-mark


On Sat, Mar 16, 2019 at 2:36 PM VIPIN BHARATHAN <vip@...> wrote:
Jonathan,

I started the thread; so that we can have objective criteria when visiting 1.0, to compare with other projects that were given the nod to 1.0; not about active vs. incubation. The vote that was up before the TSC on Thursday was 1.0 for Iroha. According to what I read in the emails everyone agrees that Iroha is ready for 1.0.  

If you are for changing the rules on the fly and pushing Iroha back into incubation; I certainly would not support it (I know it does not matter since I am not on the TSC). Dave's Grand Unified Theory of project readiness, which is still being worked on and which is not agreed on by the TSC yet, cannot be used as criteria post-facto.  I also hear Hart's POV that it does not matter as no-one outside HL really cares about this.

The DGUTPR is a good thing to have, for the future. Let us be very clear in our project lifecycle document. Governance is good when the rules are not arbitrary and consistent.

Best,
Vipin

dlt.nyc
Vipin Bharathan
Enterprise Blockchain Consultant


From: tsc@... <tsc@...> on behalf of Jonathan Levi (HACERA) via Lists.Hyperledger.Org <jonathan=hacera.com@...>
Sent: Saturday, March 16, 2019 1:09 PM
To: vipin bharathan
Cc: tsc@...
Subject: Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?
 
One moment pls. I thought that the whole argument/discussion was/is regarding whether the "active" status was justified... or whether the project should get back to "incubation".

That's what Dave, Chris, Arnaud have brought up (Mic commented on, etc.), having taken a second look at the diversity criteria.

If you guys recall, back in the day Dan Middleton and I (Jonathan) have been extremely lenient last year when most people on the TSC felt that there isn't enough community engagement using the tools that HL provides/provided. Please don't ask me to find the link to the recording. But I felt the same as Vipin, that we should not be that hard on Iroha...

It is very difficult to compare the level of attention a project gets when people have Intel Corp  or IBM Corp. behind it. But ultimately, it is up to the TSC to decide/vote based on the criteria that we all "shook on". If people deem that things need revisiting, then all the power to the changers.

----

Not taking sides, just trying to make sure that I can follow. Am I correct in understanding that Makoto suggests that companies don't want to (or are less happy to) contribute to a project that is in Beta (or, pre-1.0), while Chris, Arnaud and others are concerned that declaring a "1.0" before a project - including its community, developers, users, commerical and non-commercial supporters - make the Technical Steering Committee feel that it's ready?

If that's the case, then the steps that Arnaud and Dave are taking in terms of better clarifying and documenting what (measures) the TSC will use to evaluate such "1.0" readiness, in case people feel that these are not well defined... so that we don't spend weekends on such a long email threads, every so often (as thankfully Hart pointed out).

Unless, Vipin, your argument/suggestion is that they should not re-visit the "active" status at all?

My 2 (or 3) cents:

1. It is very difficult to build a community around a  layer 1 blockhain. We know all about it, that we even worked to create the free and open Unbounded Network, to help small projects as much as big ones to get more people around them, etc. (https://unbounded.network).

2. From my familiarity with the people
Involved and having worked with them now for several years: I don't believe that the people mentioned have an "inner" agenda to harm Iroha.

3. Going 1.0 too early doesn't always help. Hyperledger Fabric 1.0 is an exception. And even then, it wasn't pain-free. As the release manager, there were many things that didn't get into the release, weren't at the right maturity level, I couldn't get others to confirm why they are needed, or didn't fit the overall flow of Fabric 1.0 architecture. Remember, a lot of.code was contributed from research labs across the globe.

I made many friends and a few "enemies" (who I helped later on to get some of these missing feature into Fabric 1.2, 1.3 and 1.4). Other than Arnaud (who was always a pain when it comes to running Fabric on Windows ;-)) - I believe that everybody else forgave me or at least understood why we couldn't get everything in. I hope.

But we see several (too many, to be precise) ICOs who have finally released a "1.0" in the form of a "mainnet", and they have no users, no token utility and no traction. Some are even paying others to publish fake trades on their systems (the founders will probably end up sitting in jail as they are paying others to to post wash trades, manipulate prices, etc.). But we aren't there. Just saying, that going 1.0 is not everything or the final thing - it is just the beginning.

----

Since this is not the case and we are far from such cases, not only because we know Makoto, who is a fine gentleman by all means, a hard working team, highly ambitious  and the Iroha team has been allocating people to address some of the issues (since Amsterdam's Hackathon at ABN Amro and Consensus 2018) and on several other occasions - they keep asking around to see how and what they can improve... so instead of "buying fake trades" Makoto spells it out very clearly without sugar-coating: they can't get (more/enough) external contributions while in beta, etc.

While it isn't easy to favor "inclusion" and remember that not all of us work for huge companies, at the same time, let's keep the discussion technical and evaluate based on the the set criteria. Reminding you that I was "vehemently" against letting Composer reach 1.0, due to the radical changes that they made in 0.16, such days before the vote. I didn't feel it was "1.0", and that project came straight from IBM itself. To me, it didn't feel ready, and only months later other agreed with my vote (not without giving me a lot of grief until they changed their minds). BTW, I still think that Composer is a nice development tool and it helped us to explain visually what's a distributed system or a ledger to hundreds if not thousands of newcomers, but it wasn't ready at the time.

------

To summarize, while putting down my request for clarification in writing, I have semi-formed an opinion:

Sounds like having a clear criteria from the TSC and evaluating whether Iroha meets it, will be the most simple, fair and straight-forward way to go. "Active" or back to "Incubation", please all keep in mind that not too far down the line, the TSC will need to use the same criteria for Grid and other projects. 

Comments, questions, poisoned arrows welcome ;-)

Thanks,

----

Jonathan Levi

HACERA
     To Blockchain with Confidence






On Sat, Mar 16, 2019, 5:50 PM Vipin Bharathan <vipinsun@...> wrote:
Iroha is already active. So the only question before the TSC is whether they can go to 1.0 at this point. Seems like the answer is yes based on the exchanges that I have seen.
Vipin


On Mar 16, 2019, at 5:42 AM, Baohua Yang <yangbaohua@...> wrote:

I tend to feel that we may use version number only to measure code maturity, while using status to measure project itself, which certainly includes code maturity and more metrics.

Hence how about we give the active criteria as:

* released v1.0;
* have active commit activities;
* have good diversity in contributors.
* And more.

On Sat, Mar 16, 2019 at 11:16 AM Vipin Bharathan <vipinsun@...> wrote:
Hi all,

Ursa/Grid or any other project that becomes active or goes into 1.0 will have similar issues, if the rules are not clear/arbitrary. It behooves us to have more active full dlt projects in 1.0 status. Especially if the project is sound and has passed most of the criteria for maturity/security etc. If you listened to the Iroha peoples experience in the bootcamp; most participants in HK were not even aware of the existence of Iroha.

Many people when referring to Hyperledger actually mean Hyperledger Fabric; an impression that I have had to correct many times over. Not to take away from Fabric's popularity and adoption rates; I am a fan; but we all will (including Fabric) benefit if Iroha achieves 1.0 status. This means that the Hyperledger ecosystem is a level playing field and even small companies can make a difference.

Vipin 



On Fri, Mar 15, 2019 at 6:13 PM hmontgomery@... <hmontgomery@...> wrote:

Hi Everyone,

 

Sorry for causing controversy here.  I’ll attempt to clarify my points.

 

I understand Fabric-Java-SDK doesn’t function as a top-level project, and it is not being marketed as such.  But we approved it for incubation as its own (completely independent) project two and a half years ago.  If you go through the old TSC email archives, you can find where we did this (Ex.  https://lists.hyperledger.org/g/tsc/message/321?p=,,,20,0,0,0::relevance,,Fabric+java+sdk,20,2,0,17551816 is the first email when I search for Fabric-Java-SDK).

 

We had a discussion on tiers of projects (Ex. https://lists.hyperledger.org/g/tsc/message/681?p=,,,20,0,0,0::relevance,,RFC+1149,20,2,0,17551967) but this eventually got shot down and we went with a flat project hierarchy.  So, formally speaking, we don’t have project tiers, and every project under incubation technically is a top-level project under our governance structure.  To my knowledge (please correct me if I’m wrong), we haven’t formally folded projects like the Fabric-Java-SDK into their “parent” projects, so I believe these are de jure top-level projects, even if they are not top-level in practice.

 

As Arnaud points out, this may be something we want to discuss going forward as the number of projects continues to proliferate. 

 

I hope this has explained the thought process from my previous email.  Sorry for the confusion, and I’d be happy to clarify further if necessary.

 

Thanks,

Hart

 

From: Arnaud Le Hors [mailto:lehors@...]
Sent: Friday, March 15, 2019 1:26 PM
To: Montgomery, Hart <hmontgomery@...>
Cc: Dave Huseby <dhuseby@...>; Mic Bowman <mic.bowman@...>; Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

 

Wait, what?? The Fabric-Java-SDK is a top level project?? Where is this being said? It's not on https://www.hyperledger.org/projectsnor https://wiki.hyperledger.org/display/HYP/Projects

For what it's worth, the answer to your question is a big NO for me. Although I got slammed for saying it in the context of the proposal to what's now called Grid project I think we should have fewer top level projects and let platform specific projects live within the platform project they are tied to.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "hmontgomery@..." <hmontgomery@...>
To:        Dave Huseby <dhuseby@...>, Mic Bowman <mic.bowman@...>
Cc:        Hyperledger List <tsc@...>
Date:        03/15/2019 09:08 PM
Subject:        Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?
Sent by:        tsc@...





Hi Everyone,
 
A question:  do people outside of Hyperledger notice or care about the “active” vs “incubation” status?  I haven’t seen much press about this, and the writing I have seen typically gets it wrong and views active status as “production ready.”
 
Do we have more (non-marketing) resources for active projects (as compared to projects with incubation status)?  I’m not aware of any.
 
If we are going to measure project diversity, are we going to require (major) contributors to use their real names?  For instance, if we wanted to fast-track Ursa’s move to active status, we could have some of the core contributors make every Ursa commit with a new LF ID under a pseudonymous email.  Our contribution statistics would look fantastic, and we would have the added bonus of being able to completely derail the TSC elections (maybe we could run 6 winning candidates entirely on dunking booth platforms).  I realize this isn’t currently a problem, but it is probably something we should consider as we move forward.
 
In addition, if we are going to revise (and potentially roll back) the status of projects, then there are probably a bunch of things to look at.  For instance, at this point in time, do we think that the Fabric-Java-SDK should be its own incubated project?  This is obviously a useful and worthwhile coding effort, but by our “modern” standards, we never would have approved this as a top level project, and I suspect the new documentation will reflect this.
 
Thanks,
Hart
 
 
From: tsc@... [mailto:tsc@...] On Behalf Of Dave Huseby
Sent:
Friday, March 15, 2019 12:37 PM
To:
Mic Bowman <mic.bowman@...>
Cc:
Hyperledger List <tsc@...>
Subject:
Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

 
So to answer everybody's question about where the 1.0 criteria come from. It is a list that I have put together for the Grand Unified Theory of Project Readiness that I am putting together for the April 11th TSC call (see "future items"--formerly the "backlog"--in the TSC agenda doc).
 
I see 1.0 as purely a technical maturity measure. I see the "status" of a project as orthogonal to that. The reason I included documentation as a 1.0 criteria is because I don't see software as "ready for real work" if it isn't documented. From a purely technical standpoint, I have a rule: "all bugs live in the gap between the documentation and the implementation." It is impossible to know correct behavior from incorrect behavior if the correct behavior is undocumented. Shawn is right that the documentation also serves Hyperledger events as well. Documentation is dual purpose in this case and I'd still like to see it as a 1.0 criteria.
 
Cheers!
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation

+1-206-234-2392
dhuseby@...
 
 
On Fri, Mar 15, 2019 at 11:26 AM Mic Bowman <mic.bowman@...> wrote:
Comments embedded below…
 
From:tsc@...[mailto:tsc@...] On Behalf Of Dave Huseby
Sent:
Thursday, March 14, 2019 9:17 PM
To:
hmontgomery@...
Cc:
Vipin Bharathan <vipinsun@...>; Hyperledger List <tsc@...>
Subject:
Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

 
Here's my 2p on this:
 
I think the "status" of a project (e.g. "inactive", "incubation", "active", etc) is about the status of the community. A project in the incubation phase is one that has a small core of developers working on a minimum viable product. Typically this is a group of students at the same university or a group of employees at the same company. Moving from incubation to active happens when the project's community outgrows that initial core group and has enough critical mass that the original creators could leave the project and it would keep going.
 
The authorization to release a 1.0 major release is based on all of the technical aspects of the project. Off the top of my head, that list includes the CII badge, public code repo, public mailing list, some form of CI/CD, public bug tracker, public roadmap, an outside security audit, and some form of change management system (e.g. 2+2 reviews) full DCO compliance, training/educational materials for bootcamps and webinars as well as online documentation.
 
[Mic:] I like this list. Given that we don’t seem to have (or at least I cannot find it) a list of criteria for 1.0 release, would it make sense to start a “release criteria” doc we could use to focus the discussion? I’m happy to contribute/comment. We should also pull in some of our previous discussions on the topic.  Question: why is the 1.0 designation is important to Hyperledger TSC? My assumption is that we care because it reflects a commitment of resources for security analysis, marketing, etc and because it reflects on the “credibility” of the organization?
 
By applying these standards, I think the appropriate position for the Iroha project is to be in "incubation" but to approve a 1.0. I think Chris demonstrated that the contributions are still 99.9% Soramitsu. I would push back a little and also look for the stats over the last quarter and last two quarters as a more accurate measure of their community diversification. I agree with Chris that a plan is good but actually diversification should be demonstrated.
 
[Mic:] As Vipin suggested… it would be good to run the same queries over the other projects to get a baseline for what constitutes “normal” diversity in a community. Specifically… it would be interesting to compare overall contributor diversity, change in diversity post-1.0 release, and diversity over the last quarter (or some short, recent time period).
 
I also believe that the Iroha team has met all of the technical standards for a 1.0. The code base is solid and real projects are being built.
 
If we flag Iroha as in "incubation" while releasing a 1.0, not only will it more closely reflect reality, but it also mirrors the status of other Hyperledger projects such as Indy. Indy has been diversifying their contributor and maintainers considerably over the last few quarters and is about to move out of incubation even though Indy node is nearing its 2.0 release.
 
I disagree that it will harm Iroha diversification efforts to move back to "incubation" status. What is more important is to put out a solid 1.0 release and building relationships with people and organizations that can now take an enterprise-ready Iroha and build things with it. In many ways, I would expect that most projects will reach 1.0 before they have enough critical mass to move out of incubation. In fact, I think that the critical mass actually happens as a result of putting out a solid 1.0.
 
Cheers!
Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation

+1-206-234-2392
dhuseby@...
 
 
On Thu, Mar 14, 2019 at 10:41 AM hmontgomery@...<hmontgomery@...> wrote:
Hi Everyone,
 
Thanks for the suggestion Vipin.  Could we define more rigorous metrics for this (or at least suggestions, with perhaps some gray area)?
 
Putting on my Ursa hat, at some point in the hopefully not too distant future we’ll want to push forward with these things.  Having the knowledge of specific requirements (and whether we’ve met them or not, or whether it is borderline) would be immensely useful.  Putting on my TSC hat, I really want to avoid having to repeat this discussion again and again (a la the “improving the hackfests” discussions over the years), so coming up with something solid and writing it down is really appealing.
 
Thanks,
Hart
 
From: tsc@...[mailto:tsc@...] On Behalf Of Vipin Bharathan
Sent:
Thursday, March 14, 2019 9:04 AM
Cc:
Hyperledger List <
tsc@...>
Subject:
[Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

 
Hi all,
 
As suggested in today's tsc meeting I am raising the question Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?
Are numbers like the number of lines of code (or equivalent measures) from companies available at time of 1.0 (in active) available for other frameworks that already passed this milestone?
 
Another interesting statistic would be increase in contributor diversity SINCE 1.0.
Just to ensure that criteria are applied fairly for all projects in 1.0. And to see whether adoption is linked to 1.0 announcement.
 
Please put this on next week's agenda.
 
Regards,
Vipin
 
Also added as comment on the Agenda.





--
Best wishes!

Baohua Yang



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


Re: Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

Jonathan Levi (HACERA)
 

Hi Vipin,

I tried to start and end the email without taking sides. See the ending paragraph below:

Sounds like having a clear criteria from the TSC and evaluating whether Iroha meets it, will be the most simple, fair and straight-forward way to go. "Active" or back to "Incubation", please all keep in mind that not too far down the line, the TSC will need to use the same criteria for Grid and other projects. 


No, I am not a believer of making rules on the fly, just as much as I didn't believe in the suggestion to erase the git commit history.

I believe that the TSC should be clear as possible, about the criteria and apply it across the board. The definition for what "active" is pretty well written IMHO. Seems like the "1.0" isn't as clear.

On the contrary, I, too, suggest(ed), just like Dave and Arnaud to clarify the requirements, so that we don't need to have such threads for each project "on the fly".

I don't believe we (Jonathan and you Vipin) are in disagreement... unless my email below wasn't clear. If the latter, then I'd be happy to clarify.

Thanks, Jonathan


On Sat, Mar 16, 2019, 8:35 PM VIPIN BHARATHAN <vip@...> wrote:
Jonathan,

I started the thread; so that we can have objective criteria when visiting 1.0, to compare with other projects that were given the nod to 1.0; not about active vs. incubation. The vote that was up before the TSC on Thursday was 1.0 for Iroha. According to what I read in the emails everyone agrees that Iroha is ready for 1.0.  

If you are for changing the rules on the fly and pushing Iroha back into incubation; I certainly would not support it (I know it does not matter since I am not on the TSC). Dave's Grand Unified Theory of project readiness, which is still being worked on and which is not agreed on by the TSC yet, cannot be used as criteria post-facto.  I also hear Hart's POV that it does not matter as no-one outside HL really cares about this.

The DGUTPR is a good thing to have, for the future. Let us be very clear in our project lifecycle document. Governance is good when the rules are not arbitrary and consistent.

Best,
Vipin


Vipin Bharathan
Enterprise Blockchain Consultant


From: tsc@... <tsc@...> on behalf of Jonathan Levi (HACERA) via Lists.Hyperledger.Org <jonathan=hacera.com@...>
Sent: Saturday, March 16, 2019 1:09 PM
To: vipin bharathan
Cc: tsc@...
Subject: Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?
 
One moment pls. I thought that the whole argument/discussion was/is regarding whether the "active" status was justified... or whether the project should get back to "incubation".

That's what Dave, Chris, Arnaud have brought up (Mic commented on, etc.), having taken a second look at the diversity criteria.

If you guys recall, back in the day Dan Middleton and I (Jonathan) have been extremely lenient last year when most people on the TSC felt that there isn't enough community engagement using the tools that HL provides/provided. Please don't ask me to find the link to the recording. But I felt the same as Vipin, that we should not be that hard on Iroha...

It is very difficult to compare the level of attention a project gets when people have Intel Corp  or IBM Corp. behind it. But ultimately, it is up to the TSC to decide/vote based on the criteria that we all "shook on". If people deem that things need revisiting, then all the power to the changers.

----

Not taking sides, just trying to make sure that I can follow. Am I correct in understanding that Makoto suggests that companies don't want to (or are less happy to) contribute to a project that is in Beta (or, pre-1.0), while Chris, Arnaud and others are concerned that declaring a "1.0" before a project - including its community, developers, users, commerical and non-commercial supporters - make the Technical Steering Committee feel that it's ready?

If that's the case, then the steps that Arnaud and Dave are taking in terms of better clarifying and documenting what (measures) the TSC will use to evaluate such "1.0" readiness, in case people feel that these are not well defined... so that we don't spend weekends on such a long email threads, every so often (as thankfully Hart pointed out).

Unless, Vipin, your argument/suggestion is that they should not re-visit the "active" status at all?

My 2 (or 3) cents:

1. It is very difficult to build a community around a  layer 1 blockhain. We know all about it, that we even worked to create the free and open Unbounded Network, to help small projects as much as big ones to get more people around them, etc. (https://unbounded.network).

2. From my familiarity with the people
Involved and having worked with them now for several years: I don't believe that the people mentioned have an "inner" agenda to harm Iroha.

3. Going 1.0 too early doesn't always help. Hyperledger Fabric 1.0 is an exception. And even then, it wasn't pain-free. As the release manager, there were many things that didn't get into the release, weren't at the right maturity level, I couldn't get others to confirm why they are needed, or didn't fit the overall flow of Fabric 1.0 architecture. Remember, a lot of.code was contributed from research labs across the globe.

I made many friends and a few "enemies" (who I helped later on to get some of these missing feature into Fabric 1.2, 1.3 and 1.4). Other than Arnaud (who was always a pain when it comes to running Fabric on Windows ;-)) - I believe that everybody else forgave me or at least understood why we couldn't get everything in. I hope.

But we see several (too many, to be precise) ICOs who have finally released a "1.0" in the form of a "mainnet", and they have no users, no token utility and no traction. Some are even paying others to publish fake trades on their systems (the founders will probably end up sitting in jail as they are paying others to to post wash trades, manipulate prices, etc.). But we aren't there. Just saying, that going 1.0 is not everything or the final thing - it is just the beginning.

----

Since this is not the case and we are far from such cases, not only because we know Makoto, who is a fine gentleman by all means, a hard working team, highly ambitious  and the Iroha team has been allocating people to address some of the issues (since Amsterdam's Hackathon at ABN Amro and Consensus 2018) and on several other occasions - they keep asking around to see how and what they can improve... so instead of "buying fake trades" Makoto spells it out very clearly without sugar-coating: they can't get (more/enough) external contributions while in beta, etc.

While it isn't easy to favor "inclusion" and remember that not all of us work for huge companies, at the same time, let's keep the discussion technical and evaluate based on the the set criteria. Reminding you that I was "vehemently" against letting Composer reach 1.0, due to the radical changes that they made in 0.16, such days before the vote. I didn't feel it was "1.0", and that project came straight from IBM itself. To me, it didn't feel ready, and only months later other agreed with my vote (not without giving me a lot of grief until they changed their minds). BTW, I still think that Composer is a nice development tool and it helped us to explain visually what's a distributed system or a ledger to hundreds if not thousands of newcomers, but it wasn't ready at the time.

------

To summarize, while putting down my request for clarification in writing, I have semi-formed an opinion:

Sounds like having a clear criteria from the TSC and evaluating whether Iroha meets it, will be the most simple, fair and straight-forward way to go. "Active" or back to "Incubation", please all keep in mind that not too far down the line, the TSC will need to use the same criteria for Grid and other projects. 

Comments, questions, poisoned arrows welcome ;-)

Thanks,

----

Jonathan Levi

HACERA
     To Blockchain with Confidence






On Sat, Mar 16, 2019, 5:50 PM Vipin Bharathan <vipinsun@...> wrote:
Iroha is already active. So the only question before the TSC is whether they can go to 1.0 at this point. Seems like the answer is yes based on the exchanges that I have seen.
Vipin


On Mar 16, 2019, at 5:42 AM, Baohua Yang <yangbaohua@...> wrote:

I tend to feel that we may use version number only to measure code maturity, while using status to measure project itself, which certainly includes code maturity and more metrics.

Hence how about we give the active criteria as:

* released v1.0;
* have active commit activities;
* have good diversity in contributors.
* And more.

On Sat, Mar 16, 2019 at 11:16 AM Vipin Bharathan <vipinsun@...> wrote:
Hi all,

Ursa/Grid or any other project that becomes active or goes into 1.0 will have similar issues, if the rules are not clear/arbitrary. It behooves us to have more active full dlt projects in 1.0 status. Especially if the project is sound and has passed most of the criteria for maturity/security etc. If you listened to the Iroha peoples experience in the bootcamp; most participants in HK were not even aware of the existence of Iroha.

Many people when referring to Hyperledger actually mean Hyperledger Fabric; an impression that I have had to correct many times over. Not to take away from Fabric's popularity and adoption rates; I am a fan; but we all will (including Fabric) benefit if Iroha achieves 1.0 status. This means that the Hyperledger ecosystem is a level playing field and even small companies can make a difference.

Vipin 



On Fri, Mar 15, 2019 at 6:13 PM hmontgomery@... <hmontgomery@...> wrote:

Hi Everyone,

 

Sorry for causing controversy here.  I’ll attempt to clarify my points.

 

I understand Fabric-Java-SDK doesn’t function as a top-level project, and it is not being marketed as such.  But we approved it for incubation as its own (completely independent) project two and a half years ago.  If you go through the old TSC email archives, you can find where we did this (Ex.  https://lists.hyperledger.org/g/tsc/message/321?p=,,,20,0,0,0::relevance,,Fabric+java+sdk,20,2,0,17551816 is the first email when I search for Fabric-Java-SDK).

 

We had a discussion on tiers of projects (Ex. https://lists.hyperledger.org/g/tsc/message/681?p=,,,20,0,0,0::relevance,,RFC+1149,20,2,0,17551967) but this eventually got shot down and we went with a flat project hierarchy.  So, formally speaking, we don’t have project tiers, and every project under incubation technically is a top-level project under our governance structure.  To my knowledge (please correct me if I’m wrong), we haven’t formally folded projects like the Fabric-Java-SDK into their “parent” projects, so I believe these are de jure top-level projects, even if they are not top-level in practice.

 

As Arnaud points out, this may be something we want to discuss going forward as the number of projects continues to proliferate. 

 

I hope this has explained the thought process from my previous email.  Sorry for the confusion, and I’d be happy to clarify further if necessary.

 

Thanks,

Hart

 

From: Arnaud Le Hors [mailto:lehors@...]
Sent: Friday, March 15, 2019 1:26 PM
To: Montgomery, Hart <hmontgomery@...>
Cc: Dave Huseby <dhuseby@...>; Mic Bowman <mic.bowman@...>; Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

 

Wait, what?? The Fabric-Java-SDK is a top level project?? Where is this being said? It's not on https://www.hyperledger.org/projectsnor https://wiki.hyperledger.org/display/HYP/Projects

For what it's worth, the answer to your question is a big NO for me. Although I got slammed for saying it in the context of the proposal to what's now called Grid project I think we should have fewer top level projects and let platform specific projects live within the platform project they are tied to.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "hmontgomery@..." <hmontgomery@...>
To:        Dave Huseby <dhuseby@...>, Mic Bowman <mic.bowman@...>
Cc:        Hyperledger List <tsc@...>
Date:        03/15/2019 09:08 PM
Subject:        Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?
Sent by:        tsc@...





Hi Everyone,
 
A question:  do people outside of Hyperledger notice or care about the “active” vs “incubation” status?  I haven’t seen much press about this, and the writing I have seen typically gets it wrong and views active status as “production ready.”
 
Do we have more (non-marketing) resources for active projects (as compared to projects with incubation status)?  I’m not aware of any.
 
If we are going to measure project diversity, are we going to require (major) contributors to use their real names?  For instance, if we wanted to fast-track Ursa’s move to active status, we could have some of the core contributors make every Ursa commit with a new LF ID under a pseudonymous email.  Our contribution statistics would look fantastic, and we would have the added bonus of being able to completely derail the TSC elections (maybe we could run 6 winning candidates entirely on dunking booth platforms).  I realize this isn’t currently a problem, but it is probably something we should consider as we move forward.
 
In addition, if we are going to revise (and potentially roll back) the status of projects, then there are probably a bunch of things to look at.  For instance, at this point in time, do we think that the Fabric-Java-SDK should be its own incubated project?  This is obviously a useful and worthwhile coding effort, but by our “modern” standards, we never would have approved this as a top level project, and I suspect the new documentation will reflect this.
 
Thanks,
Hart
 
 
From: tsc@... [mailto:tsc@...] On Behalf Of Dave Huseby
Sent:
Friday, March 15, 2019 12:37 PM
To:
Mic Bowman <mic.bowman@...>
Cc:
Hyperledger List <tsc@...>
Subject:
Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

 
So to answer everybody's question about where the 1.0 criteria come from. It is a list that I have put together for the Grand Unified Theory of Project Readiness that I am putting together for the April 11th TSC call (see "future items"--formerly the "backlog"--in the TSC agenda doc).
 
I see 1.0 as purely a technical maturity measure. I see the "status" of a project as orthogonal to that. The reason I included documentation as a 1.0 criteria is because I don't see software as "ready for real work" if it isn't documented. From a purely technical standpoint, I have a rule: "all bugs live in the gap between the documentation and the implementation." It is impossible to know correct behavior from incorrect behavior if the correct behavior is undocumented. Shawn is right that the documentation also serves Hyperledger events as well. Documentation is dual purpose in this case and I'd still like to see it as a 1.0 criteria.
 
Cheers!
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation

+1-206-234-2392
dhuseby@...
 
 
On Fri, Mar 15, 2019 at 11:26 AM Mic Bowman <mic.bowman@...> wrote:
Comments embedded below…
 
From:tsc@...[mailto:tsc@...] On Behalf Of Dave Huseby
Sent:
Thursday, March 14, 2019 9:17 PM
To:
hmontgomery@...
Cc:
Vipin Bharathan <vipinsun@...>; Hyperledger List <tsc@...>
Subject:
Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

 
Here's my 2p on this:
 
I think the "status" of a project (e.g. "inactive", "incubation", "active", etc) is about the status of the community. A project in the incubation phase is one that has a small core of developers working on a minimum viable product. Typically this is a group of students at the same university or a group of employees at the same company. Moving from incubation to active happens when the project's community outgrows that initial core group and has enough critical mass that the original creators could leave the project and it would keep going.
 
The authorization to release a 1.0 major release is based on all of the technical aspects of the project. Off the top of my head, that list includes the CII badge, public code repo, public mailing list, some form of CI/CD, public bug tracker, public roadmap, an outside security audit, and some form of change management system (e.g. 2+2 reviews) full DCO compliance, training/educational materials for bootcamps and webinars as well as online documentation.
 
[Mic:] I like this list. Given that we don’t seem to have (or at least I cannot find it) a list of criteria for 1.0 release, would it make sense to start a “release criteria” doc we could use to focus the discussion? I’m happy to contribute/comment. We should also pull in some of our previous discussions on the topic.  Question: why is the 1.0 designation is important to Hyperledger TSC? My assumption is that we care because it reflects a commitment of resources for security analysis, marketing, etc and because it reflects on the “credibility” of the organization?
 
By applying these standards, I think the appropriate position for the Iroha project is to be in "incubation" but to approve a 1.0. I think Chris demonstrated that the contributions are still 99.9% Soramitsu. I would push back a little and also look for the stats over the last quarter and last two quarters as a more accurate measure of their community diversification. I agree with Chris that a plan is good but actually diversification should be demonstrated.
 
[Mic:] As Vipin suggested… it would be good to run the same queries over the other projects to get a baseline for what constitutes “normal” diversity in a community. Specifically… it would be interesting to compare overall contributor diversity, change in diversity post-1.0 release, and diversity over the last quarter (or some short, recent time period).
 
I also believe that the Iroha team has met all of the technical standards for a 1.0. The code base is solid and real projects are being built.
 
If we flag Iroha as in "incubation" while releasing a 1.0, not only will it more closely reflect reality, but it also mirrors the status of other Hyperledger projects such as Indy. Indy has been diversifying their contributor and maintainers considerably over the last few quarters and is about to move out of incubation even though Indy node is nearing its 2.0 release.
 
I disagree that it will harm Iroha diversification efforts to move back to "incubation" status. What is more important is to put out a solid 1.0 release and building relationships with people and organizations that can now take an enterprise-ready Iroha and build things with it. In many ways, I would expect that most projects will reach 1.0 before they have enough critical mass to move out of incubation. In fact, I think that the critical mass actually happens as a result of putting out a solid 1.0.
 
Cheers!
Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation

+1-206-234-2392
dhuseby@...
 
 
On Thu, Mar 14, 2019 at 10:41 AM hmontgomery@...<hmontgomery@...> wrote:
Hi Everyone,
 
Thanks for the suggestion Vipin.  Could we define more rigorous metrics for this (or at least suggestions, with perhaps some gray area)?
 
Putting on my Ursa hat, at some point in the hopefully not too distant future we’ll want to push forward with these things.  Having the knowledge of specific requirements (and whether we’ve met them or not, or whether it is borderline) would be immensely useful.  Putting on my TSC hat, I really want to avoid having to repeat this discussion again and again (a la the “improving the hackfests” discussions over the years), so coming up with something solid and writing it down is really appealing.
 
Thanks,
Hart
 
From: tsc@...[mailto:tsc@...] On Behalf Of Vipin Bharathan
Sent:
Thursday, March 14, 2019 9:04 AM
Cc:
Hyperledger List <
tsc@...>
Subject:
[Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

 
Hi all,
 
As suggested in today's tsc meeting I am raising the question Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?
Are numbers like the number of lines of code (or equivalent measures) from companies available at time of 1.0 (in active) available for other frameworks that already passed this milestone?
 
Another interesting statistic would be increase in contributor diversity SINCE 1.0.
Just to ensure that criteria are applied fairly for all projects in 1.0. And to see whether adoption is linked to 1.0 announcement.
 
Please put this on next week's agenda.
 
Regards,
Vipin
 
Also added as comment on the Agenda.





--
Best wishes!

Baohua Yang

_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#2094) | Reply To Sender | Reply To Group | Mute This Topic | New Topic

Your Subscription | Contact Group Owner | Unsubscribe [vip@...]

_._,_._,


Re: Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

VIPIN BHARATHAN
 

Jonathan,

I started the thread; so that we can have objective criteria when visiting 1.0, to compare with other projects that were given the nod to 1.0; not about active vs. incubation. The vote that was up before the TSC on Thursday was 1.0 for Iroha. According to what I read in the emails everyone agrees that Iroha is ready for 1.0.  

If you are for changing the rules on the fly and pushing Iroha back into incubation; I certainly would not support it (I know it does not matter since I am not on the TSC). Dave's Grand Unified Theory of project readiness, which is still being worked on and which is not agreed on by the TSC yet, cannot be used as criteria post-facto.  I also hear Hart's POV that it does not matter as no-one outside HL really cares about this.

The DGUTPR is a good thing to have, for the future. Let us be very clear in our project lifecycle document. Governance is good when the rules are not arbitrary and consistent.

Best,
Vipin

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


From: tsc@... <tsc@...> on behalf of Jonathan Levi (HACERA) via Lists.Hyperledger.Org <jonathan=hacera.com@...>
Sent: Saturday, March 16, 2019 1:09 PM
To: vipin bharathan
Cc: tsc@...
Subject: Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?
 
One moment pls. I thought that the whole argument/discussion was/is regarding whether the "active" status was justified... or whether the project should get back to "incubation".

That's what Dave, Chris, Arnaud have brought up (Mic commented on, etc.), having taken a second look at the diversity criteria.

If you guys recall, back in the day Dan Middleton and I (Jonathan) have been extremely lenient last year when most people on the TSC felt that there isn't enough community engagement using the tools that HL provides/provided. Please don't ask me to find the link to the recording. But I felt the same as Vipin, that we should not be that hard on Iroha...

It is very difficult to compare the level of attention a project gets when people have Intel Corp  or IBM Corp. behind it. But ultimately, it is up to the TSC to decide/vote based on the criteria that we all "shook on". If people deem that things need revisiting, then all the power to the changers.

----

Not taking sides, just trying to make sure that I can follow. Am I correct in understanding that Makoto suggests that companies don't want to (or are less happy to) contribute to a project that is in Beta (or, pre-1.0), while Chris, Arnaud and others are concerned that declaring a "1.0" before a project - including its community, developers, users, commerical and non-commercial supporters - make the Technical Steering Committee feel that it's ready?

If that's the case, then the steps that Arnaud and Dave are taking in terms of better clarifying and documenting what (measures) the TSC will use to evaluate such "1.0" readiness, in case people feel that these are not well defined... so that we don't spend weekends on such a long email threads, every so often (as thankfully Hart pointed out).

Unless, Vipin, your argument/suggestion is that they should not re-visit the "active" status at all?

My 2 (or 3) cents:

1. It is very difficult to build a community around a  layer 1 blockhain. We know all about it, that we even worked to create the free and open Unbounded Network, to help small projects as much as big ones to get more people around them, etc. (https://unbounded.network).

2. From my familiarity with the people
Involved and having worked with them now for several years: I don't believe that the people mentioned have an "inner" agenda to harm Iroha.

3. Going 1.0 too early doesn't always help. Hyperledger Fabric 1.0 is an exception. And even then, it wasn't pain-free. As the release manager, there were many things that didn't get into the release, weren't at the right maturity level, I couldn't get others to confirm why they are needed, or didn't fit the overall flow of Fabric 1.0 architecture. Remember, a lot of.code was contributed from research labs across the globe.

I made many friends and a few "enemies" (who I helped later on to get some of these missing feature into Fabric 1.2, 1.3 and 1.4). Other than Arnaud (who was always a pain when it comes to running Fabric on Windows ;-)) - I believe that everybody else forgave me or at least understood why we couldn't get everything in. I hope.

But we see several (too many, to be precise) ICOs who have finally released a "1.0" in the form of a "mainnet", and they have no users, no token utility and no traction. Some are even paying others to publish fake trades on their systems (the founders will probably end up sitting in jail as they are paying others to to post wash trades, manipulate prices, etc.). But we aren't there. Just saying, that going 1.0 is not everything or the final thing - it is just the beginning.

----

Since this is not the case and we are far from such cases, not only because we know Makoto, who is a fine gentleman by all means, a hard working team, highly ambitious  and the Iroha team has been allocating people to address some of the issues (since Amsterdam's Hackathon at ABN Amro and Consensus 2018) and on several other occasions - they keep asking around to see how and what they can improve... so instead of "buying fake trades" Makoto spells it out very clearly without sugar-coating: they can't get (more/enough) external contributions while in beta, etc.

While it isn't easy to favor "inclusion" and remember that not all of us work for huge companies, at the same time, let's keep the discussion technical and evaluate based on the the set criteria. Reminding you that I was "vehemently" against letting Composer reach 1.0, due to the radical changes that they made in 0.16, such days before the vote. I didn't feel it was "1.0", and that project came straight from IBM itself. To me, it didn't feel ready, and only months later other agreed with my vote (not without giving me a lot of grief until they changed their minds). BTW, I still think that Composer is a nice development tool and it helped us to explain visually what's a distributed system or a ledger to hundreds if not thousands of newcomers, but it wasn't ready at the time.

------

To summarize, while putting down my request for clarification in writing, I have semi-formed an opinion:

Sounds like having a clear criteria from the TSC and evaluating whether Iroha meets it, will be the most simple, fair and straight-forward way to go. "Active" or back to "Incubation", please all keep in mind that not too far down the line, the TSC will need to use the same criteria for Grid and other projects. 

Comments, questions, poisoned arrows welcome ;-)

Thanks,

----

Jonathan Levi

HACERA
     To Blockchain with Confidence






On Sat, Mar 16, 2019, 5:50 PM Vipin Bharathan <vipinsun@...> wrote:

Iroha is already active. So the only question before the TSC is whether they can go to 1.0 at this point. Seems like the answer is yes based on the exchanges that I have seen.
Vipin


On Mar 16, 2019, at 5:42 AM, Baohua Yang <yangbaohua@...> wrote:

I tend to feel that we may use version number only to measure code maturity, while using status to measure project itself, which certainly includes code maturity and more metrics.

Hence how about we give the active criteria as:

* released v1.0;
* have active commit activities;
* have good diversity in contributors.
* And more.

On Sat, Mar 16, 2019 at 11:16 AM Vipin Bharathan <vipinsun@...> wrote:
Hi all,

Ursa/Grid or any other project that becomes active or goes into 1.0 will have similar issues, if the rules are not clear/arbitrary. It behooves us to have more active full dlt projects in 1.0 status. Especially if the project is sound and has passed most of the criteria for maturity/security etc. If you listened to the Iroha peoples experience in the bootcamp; most participants in HK were not even aware of the existence of Iroha.

Many people when referring to Hyperledger actually mean Hyperledger Fabric; an impression that I have had to correct many times over. Not to take away from Fabric's popularity and adoption rates; I am a fan; but we all will (including Fabric) benefit if Iroha achieves 1.0 status. This means that the Hyperledger ecosystem is a level playing field and even small companies can make a difference.

Vipin 



On Fri, Mar 15, 2019 at 6:13 PM hmontgomery@... <hmontgomery@...> wrote:

Hi Everyone,

 

Sorry for causing controversy here.  I’ll attempt to clarify my points.

 

I understand Fabric-Java-SDK doesn’t function as a top-level project, and it is not being marketed as such.  But we approved it for incubation as its own (completely independent) project two and a half years ago.  If you go through the old TSC email archives, you can find where we did this (Ex.  https://lists.hyperledger.org/g/tsc/message/321?p=,,,20,0,0,0::relevance,,Fabric+java+sdk,20,2,0,17551816 is the first email when I search for Fabric-Java-SDK).

 

We had a discussion on tiers of projects (Ex. https://lists.hyperledger.org/g/tsc/message/681?p=,,,20,0,0,0::relevance,,RFC+1149,20,2,0,17551967) but this eventually got shot down and we went with a flat project hierarchy.  So, formally speaking, we don’t have project tiers, and every project under incubation technically is a top-level project under our governance structure.  To my knowledge (please correct me if I’m wrong), we haven’t formally folded projects like the Fabric-Java-SDK into their “parent” projects, so I believe these are de jure top-level projects, even if they are not top-level in practice.

 

As Arnaud points out, this may be something we want to discuss going forward as the number of projects continues to proliferate. 

 

I hope this has explained the thought process from my previous email.  Sorry for the confusion, and I’d be happy to clarify further if necessary.

 

Thanks,

Hart

 

From: Arnaud Le Hors [mailto:lehors@...]
Sent: Friday, March 15, 2019 1:26 PM
To: Montgomery, Hart <hmontgomery@...>
Cc: Dave Huseby <dhuseby@...>; Mic Bowman <mic.bowman@...>; Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

 

Wait, what?? The Fabric-Java-SDK is a top level project?? Where is this being said? It's not on https://www.hyperledger.org/projectsnor https://wiki.hyperledger.org/display/HYP/Projects

For what it's worth, the answer to your question is a big NO for me. Although I got slammed for saying it in the context of the proposal to what's now called Grid project I think we should have fewer top level projects and let platform specific projects live within the platform project they are tied to.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "hmontgomery@..." <hmontgomery@...>
To:        Dave Huseby <dhuseby@...>, Mic Bowman <mic.bowman@...>
Cc:        Hyperledger List <tsc@...>
Date:        03/15/2019 09:08 PM
Subject:        Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?
Sent by:        tsc@...





Hi Everyone,
 
A question:  do people outside of Hyperledger notice or care about the “active” vs “incubation” status?  I haven’t seen much press about this, and the writing I have seen typically gets it wrong and views active status as “production ready.”
 
Do we have more (non-marketing) resources for active projects (as compared to projects with incubation status)?  I’m not aware of any.
 
If we are going to measure project diversity, are we going to require (major) contributors to use their real names?  For instance, if we wanted to fast-track Ursa’s move to active status, we could have some of the core contributors make every Ursa commit with a new LF ID under a pseudonymous email.  Our contribution statistics would look fantastic, and we would have the added bonus of being able to completely derail the TSC elections (maybe we could run 6 winning candidates entirely on dunking booth platforms).  I realize this isn’t currently a problem, but it is probably something we should consider as we move forward.
 
In addition, if we are going to revise (and potentially roll back) the status of projects, then there are probably a bunch of things to look at.  For instance, at this point in time, do we think that the Fabric-Java-SDK should be its own incubated project?  This is obviously a useful and worthwhile coding effort, but by our “modern” standards, we never would have approved this as a top level project, and I suspect the new documentation will reflect this.
 
Thanks,
Hart
 
 
From: tsc@... [mailto:tsc@...] On Behalf Of Dave Huseby
Sent:
Friday, March 15, 2019 12:37 PM
To:
Mic Bowman <mic.bowman@...>
Cc:
Hyperledger List <tsc@...>
Subject:
Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

 
So to answer everybody's question about where the 1.0 criteria come from. It is a list that I have put together for the Grand Unified Theory of Project Readiness that I am putting together for the April 11th TSC call (see "future items"--formerly the "backlog"--in the TSC agenda doc).
 
I see 1.0 as purely a technical maturity measure. I see the "status" of a project as orthogonal to that. The reason I included documentation as a 1.0 criteria is because I don't see software as "ready for real work" if it isn't documented. From a purely technical standpoint, I have a rule: "all bugs live in the gap between the documentation and the implementation." It is impossible to know correct behavior from incorrect behavior if the correct behavior is undocumented. Shawn is right that the documentation also serves Hyperledger events as well. Documentation is dual purpose in this case and I'd still like to see it as a 1.0 criteria.
 
Cheers!
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation

+1-206-234-2392
dhuseby@...
 
 
On Fri, Mar 15, 2019 at 11:26 AM Mic Bowman <mic.bowman@...> wrote:
Comments embedded below…
 
From:tsc@...[mailto:tsc@...] On Behalf Of Dave Huseby
Sent:
Thursday, March 14, 2019 9:17 PM
To:
hmontgomery@...
Cc:
Vipin Bharathan <vipinsun@...>; Hyperledger List <tsc@...>
Subject:
Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

 
Here's my 2p on this:
 
I think the "status" of a project (e.g. "inactive", "incubation", "active", etc) is about the status of the community. A project in the incubation phase is one that has a small core of developers working on a minimum viable product. Typically this is a group of students at the same university or a group of employees at the same company. Moving from incubation to active happens when the project's community outgrows that initial core group and has enough critical mass that the original creators could leave the project and it would keep going.
 
The authorization to release a 1.0 major release is based on all of the technical aspects of the project. Off the top of my head, that list includes the CII badge, public code repo, public mailing list, some form of CI/CD, public bug tracker, public roadmap, an outside security audit, and some form of change management system (e.g. 2+2 reviews) full DCO compliance, training/educational materials for bootcamps and webinars as well as online documentation.
 
[Mic:] I like this list. Given that we don’t seem to have (or at least I cannot find it) a list of criteria for 1.0 release, would it make sense to start a “release criteria” doc we could use to focus the discussion? I’m happy to contribute/comment. We should also pull in some of our previous discussions on the topic.  Question: why is the 1.0 designation is important to Hyperledger TSC? My assumption is that we care because it reflects a commitment of resources for security analysis, marketing, etc and because it reflects on the “credibility” of the organization?
 
By applying these standards, I think the appropriate position for the Iroha project is to be in "incubation" but to approve a 1.0. I think Chris demonstrated that the contributions are still 99.9% Soramitsu. I would push back a little and also look for the stats over the last quarter and last two quarters as a more accurate measure of their community diversification. I agree with Chris that a plan is good but actually diversification should be demonstrated.
 
[Mic:] As Vipin suggested… it would be good to run the same queries over the other projects to get a baseline for what constitutes “normal” diversity in a community. Specifically… it would be interesting to compare overall contributor diversity, change in diversity post-1.0 release, and diversity over the last quarter (or some short, recent time period).
 
I also believe that the Iroha team has met all of the technical standards for a 1.0. The code base is solid and real projects are being built.
 
If we flag Iroha as in "incubation" while releasing a 1.0, not only will it more closely reflect reality, but it also mirrors the status of other Hyperledger projects such as Indy. Indy has been diversifying their contributor and maintainers considerably over the last few quarters and is about to move out of incubation even though Indy node is nearing its 2.0 release.
 
I disagree that it will harm Iroha diversification efforts to move back to "incubation" status. What is more important is to put out a solid 1.0 release and building relationships with people and organizations that can now take an enterprise-ready Iroha and build things with it. In many ways, I would expect that most projects will reach 1.0 before they have enough critical mass to move out of incubation. In fact, I think that the critical mass actually happens as a result of putting out a solid 1.0.
 
Cheers!
Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation

+1-206-234-2392
dhuseby@...
 
 
On Thu, Mar 14, 2019 at 10:41 AM hmontgomery@...<hmontgomery@...> wrote:
Hi Everyone,
 
Thanks for the suggestion Vipin.  Could we define more rigorous metrics for this (or at least suggestions, with perhaps some gray area)?
 
Putting on my Ursa hat, at some point in the hopefully not too distant future we’ll want to push forward with these things.  Having the knowledge of specific requirements (and whether we’ve met them or not, or whether it is borderline) would be immensely useful.  Putting on my TSC hat, I really want to avoid having to repeat this discussion again and again (a la the “improving the hackfests” discussions over the years), so coming up with something solid and writing it down is really appealing.
 
Thanks,
Hart
 
From: tsc@...[mailto:tsc@...] On Behalf Of Vipin Bharathan
Sent:
Thursday, March 14, 2019 9:04 AM
Cc:
Hyperledger List <
tsc@...>
Subject:
[Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

 
Hi all,
 
As suggested in today's tsc meeting I am raising the question Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?
Are numbers like the number of lines of code (or equivalent measures) from companies available at time of 1.0 (in active) available for other frameworks that already passed this milestone?
 
Another interesting statistic would be increase in contributor diversity SINCE 1.0.
Just to ensure that criteria are applied fairly for all projects in 1.0. And to see whether adoption is linked to 1.0 announcement.
 
Please put this on next week's agenda.
 
Regards,
Vipin
 
Also added as comment on the Agenda.





--
Best wishes!

Baohua Yang


Re: Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

Jonathan Levi (HACERA)
 

One moment pls. I thought that the whole argument/discussion was/is regarding whether the "active" status was justified... or whether the project should get back to "incubation".

That's what Dave, Chris, Arnaud have brought up (Mic commented on, etc.), having taken a second look at the diversity criteria.

If you guys recall, back in the day Dan Middleton and I (Jonathan) have been extremely lenient last year when most people on the TSC felt that there isn't enough community engagement using the tools that HL provides/provided. Please don't ask me to find the link to the recording. But I felt the same as Vipin, that we should not be that hard on Iroha...

It is very difficult to compare the level of attention a project gets when people have Intel Corp  or IBM Corp. behind it. But ultimately, it is up to the TSC to decide/vote based on the criteria that we all "shook on". If people deem that things need revisiting, then all the power to the changers.

----

Not taking sides, just trying to make sure that I can follow. Am I correct in understanding that Makoto suggests that companies don't want to (or are less happy to) contribute to a project that is in Beta (or, pre-1.0), while Chris, Arnaud and others are concerned that declaring a "1.0" before a project - including its community, developers, users, commerical and non-commercial supporters - make the Technical Steering Committee feel that it's ready?

If that's the case, then the steps that Arnaud and Dave are taking in terms of better clarifying and documenting what (measures) the TSC will use to evaluate such "1.0" readiness, in case people feel that these are not well defined... so that we don't spend weekends on such a long email threads, every so often (as thankfully Hart pointed out).

Unless, Vipin, your argument/suggestion is that they should not re-visit the "active" status at all?

My 2 (or 3) cents:

1. It is very difficult to build a community around a  layer 1 blockhain. We know all about it, that we even worked to create the free and open Unbounded Network, to help small projects as much as big ones to get more people around them, etc. (https://unbounded.network).

2. From my familiarity with the people
Involved and having worked with them now for several years: I don't believe that the people mentioned have an "inner" agenda to harm Iroha.

3. Going 1.0 too early doesn't always help. Hyperledger Fabric 1.0 is an exception. And even then, it wasn't pain-free. As the release manager, there were many things that didn't get into the release, weren't at the right maturity level, I couldn't get others to confirm why they are needed, or didn't fit the overall flow of Fabric 1.0 architecture. Remember, a lot of.code was contributed from research labs across the globe.

I made many friends and a few "enemies" (who I helped later on to get some of these missing feature into Fabric 1.2, 1.3 and 1.4). Other than Arnaud (who was always a pain when it comes to running Fabric on Windows ;-)) - I believe that everybody else forgave me or at least understood why we couldn't get everything in. I hope.

But we see several (too many, to be precise) ICOs who have finally released a "1.0" in the form of a "mainnet", and they have no users, no token utility and no traction. Some are even paying others to publish fake trades on their systems (the founders will probably end up sitting in jail as they are paying others to to post wash trades, manipulate prices, etc.). But we aren't there. Just saying, that going 1.0 is not everything or the final thing - it is just the beginning.

----

Since this is not the case and we are far from such cases, not only because we know Makoto, who is a fine gentleman by all means, a hard working team, highly ambitious  and the Iroha team has been allocating people to address some of the issues (since Amsterdam's Hackathon at ABN Amro and Consensus 2018) and on several other occasions - they keep asking around to see how and what they can improve... so instead of "buying fake trades" Makoto spells it out very clearly without sugar-coating: they can't get (more/enough) external contributions while in beta, etc.

While it isn't easy to favor "inclusion" and remember that not all of us work for huge companies, at the same time, let's keep the discussion technical and evaluate based on the the set criteria. Reminding you that I was "vehemently" against letting Composer reach 1.0, due to the radical changes that they made in 0.16, such days before the vote. I didn't feel it was "1.0", and that project came straight from IBM itself. To me, it didn't feel ready, and only months later other agreed with my vote (not without giving me a lot of grief until they changed their minds). BTW, I still think that Composer is a nice development tool and it helped us to explain visually what's a distributed system or a ledger to hundreds if not thousands of newcomers, but it wasn't ready at the time.

------

To summarize, while putting down my request for clarification in writing, I have semi-formed an opinion:

Sounds like having a clear criteria from the TSC and evaluating whether Iroha meets it, will be the most simple, fair and straight-forward way to go. "Active" or back to "Incubation", please all keep in mind that not too far down the line, the TSC will need to use the same criteria for Grid and other projects. 

Comments, questions, poisoned arrows welcome ;-)

Thanks,

----

Jonathan Levi

HACERA
     To Blockchain with Confidence






On Sat, Mar 16, 2019, 5:50 PM Vipin Bharathan <vipinsun@...> wrote:
Iroha is already active. So the only question before the TSC is whether they can go to 1.0 at this point. Seems like the answer is yes based on the exchanges that I have seen.
Vipin


On Mar 16, 2019, at 5:42 AM, Baohua Yang <yangbaohua@...> wrote:

I tend to feel that we may use version number only to measure code maturity, while using status to measure project itself, which certainly includes code maturity and more metrics.

Hence how about we give the active criteria as:

* released v1.0;
* have active commit activities;
* have good diversity in contributors.
* And more.

On Sat, Mar 16, 2019 at 11:16 AM Vipin Bharathan <vipinsun@...> wrote:
Hi all,

Ursa/Grid or any other project that becomes active or goes into 1.0 will have similar issues, if the rules are not clear/arbitrary. It behooves us to have more active full dlt projects in 1.0 status. Especially if the project is sound and has passed most of the criteria for maturity/security etc. If you listened to the Iroha peoples experience in the bootcamp; most participants in HK were not even aware of the existence of Iroha.

Many people when referring to Hyperledger actually mean Hyperledger Fabric; an impression that I have had to correct many times over. Not to take away from Fabric's popularity and adoption rates; I am a fan; but we all will (including Fabric) benefit if Iroha achieves 1.0 status. This means that the Hyperledger ecosystem is a level playing field and even small companies can make a difference.

Vipin 



On Fri, Mar 15, 2019 at 6:13 PM hmontgomery@... <hmontgomery@...> wrote:

Hi Everyone,

 

Sorry for causing controversy here.  I’ll attempt to clarify my points.

 

I understand Fabric-Java-SDK doesn’t function as a top-level project, and it is not being marketed as such.  But we approved it for incubation as its own (completely independent) project two and a half years ago.  If you go through the old TSC email archives, you can find where we did this (Ex.  https://lists.hyperledger.org/g/tsc/message/321?p=,,,20,0,0,0::relevance,,Fabric+java+sdk,20,2,0,17551816 is the first email when I search for Fabric-Java-SDK).

 

We had a discussion on tiers of projects (Ex. https://lists.hyperledger.org/g/tsc/message/681?p=,,,20,0,0,0::relevance,,RFC+1149,20,2,0,17551967) but this eventually got shot down and we went with a flat project hierarchy.  So, formally speaking, we don’t have project tiers, and every project under incubation technically is a top-level project under our governance structure.  To my knowledge (please correct me if I’m wrong), we haven’t formally folded projects like the Fabric-Java-SDK into their “parent” projects, so I believe these are de jure top-level projects, even if they are not top-level in practice.

 

As Arnaud points out, this may be something we want to discuss going forward as the number of projects continues to proliferate. 

 

I hope this has explained the thought process from my previous email.  Sorry for the confusion, and I’d be happy to clarify further if necessary.

 

Thanks,

Hart

 

From: Arnaud Le Hors [mailto:lehors@...]
Sent: Friday, March 15, 2019 1:26 PM
To: Montgomery, Hart <hmontgomery@...>
Cc: Dave Huseby <dhuseby@...>; Mic Bowman <mic.bowman@...>; Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

 

Wait, what?? The Fabric-Java-SDK is a top level project?? Where is this being said? It's not on https://www.hyperledger.org/projectsnor https://wiki.hyperledger.org/display/HYP/Projects

For what it's worth, the answer to your question is a big NO for me. Although I got slammed for saying it in the context of the proposal to what's now called Grid project I think we should have fewer top level projects and let platform specific projects live within the platform project they are tied to.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "hmontgomery@..." <hmontgomery@...>
To:        Dave Huseby <dhuseby@...>, Mic Bowman <mic.bowman@...>
Cc:        Hyperledger List <tsc@...>
Date:        03/15/2019 09:08 PM
Subject:        Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?
Sent by:        tsc@...





Hi Everyone,
 
A question:  do people outside of Hyperledger notice or care about the “active” vs “incubation” status?  I haven’t seen much press about this, and the writing I have seen typically gets it wrong and views active status as “production ready.”
 
Do we have more (non-marketing) resources for active projects (as compared to projects with incubation status)?  I’m not aware of any.
 
If we are going to measure project diversity, are we going to require (major) contributors to use their real names?  For instance, if we wanted to fast-track Ursa’s move to active status, we could have some of the core contributors make every Ursa commit with a new LF ID under a pseudonymous email.  Our contribution statistics would look fantastic, and we would have the added bonus of being able to completely derail the TSC elections (maybe we could run 6 winning candidates entirely on dunking booth platforms).  I realize this isn’t currently a problem, but it is probably something we should consider as we move forward.
 
In addition, if we are going to revise (and potentially roll back) the status of projects, then there are probably a bunch of things to look at.  For instance, at this point in time, do we think that the Fabric-Java-SDK should be its own incubated project?  This is obviously a useful and worthwhile coding effort, but by our “modern” standards, we never would have approved this as a top level project, and I suspect the new documentation will reflect this.
 
Thanks,
Hart
 
 
From: tsc@... [mailto:tsc@...] On Behalf Of Dave Huseby
Sent:
Friday, March 15, 2019 12:37 PM
To:
Mic Bowman <mic.bowman@...>
Cc:
Hyperledger List <tsc@...>
Subject:
Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

 
So to answer everybody's question about where the 1.0 criteria come from. It is a list that I have put together for the Grand Unified Theory of Project Readiness that I am putting together for the April 11th TSC call (see "future items"--formerly the "backlog"--in the TSC agenda doc).
 
I see 1.0 as purely a technical maturity measure. I see the "status" of a project as orthogonal to that. The reason I included documentation as a 1.0 criteria is because I don't see software as "ready for real work" if it isn't documented. From a purely technical standpoint, I have a rule: "all bugs live in the gap between the documentation and the implementation." It is impossible to know correct behavior from incorrect behavior if the correct behavior is undocumented. Shawn is right that the documentation also serves Hyperledger events as well. Documentation is dual purpose in this case and I'd still like to see it as a 1.0 criteria.
 
Cheers!
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation

+1-206-234-2392
dhuseby@...
 
 
On Fri, Mar 15, 2019 at 11:26 AM Mic Bowman <mic.bowman@...> wrote:
Comments embedded below…
 
From:tsc@...[mailto:tsc@...] On Behalf Of Dave Huseby
Sent:
Thursday, March 14, 2019 9:17 PM
To:
hmontgomery@...
Cc:
Vipin Bharathan <vipinsun@...>; Hyperledger List <tsc@...>
Subject:
Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

 
Here's my 2p on this:
 
I think the "status" of a project (e.g. "inactive", "incubation", "active", etc) is about the status of the community. A project in the incubation phase is one that has a small core of developers working on a minimum viable product. Typically this is a group of students at the same university or a group of employees at the same company. Moving from incubation to active happens when the project's community outgrows that initial core group and has enough critical mass that the original creators could leave the project and it would keep going.
 
The authorization to release a 1.0 major release is based on all of the technical aspects of the project. Off the top of my head, that list includes the CII badge, public code repo, public mailing list, some form of CI/CD, public bug tracker, public roadmap, an outside security audit, and some form of change management system (e.g. 2+2 reviews) full DCO compliance, training/educational materials for bootcamps and webinars as well as online documentation.
 
[Mic:] I like this list. Given that we don’t seem to have (or at least I cannot find it) a list of criteria for 1.0 release, would it make sense to start a “release criteria” doc we could use to focus the discussion? I’m happy to contribute/comment. We should also pull in some of our previous discussions on the topic.  Question: why is the 1.0 designation is important to Hyperledger TSC? My assumption is that we care because it reflects a commitment of resources for security analysis, marketing, etc and because it reflects on the “credibility” of the organization?
 
By applying these standards, I think the appropriate position for the Iroha project is to be in "incubation" but to approve a 1.0. I think Chris demonstrated that the contributions are still 99.9% Soramitsu. I would push back a little and also look for the stats over the last quarter and last two quarters as a more accurate measure of their community diversification. I agree with Chris that a plan is good but actually diversification should be demonstrated.
 
[Mic:] As Vipin suggested… it would be good to run the same queries over the other projects to get a baseline for what constitutes “normal” diversity in a community. Specifically… it would be interesting to compare overall contributor diversity, change in diversity post-1.0 release, and diversity over the last quarter (or some short, recent time period).
 
I also believe that the Iroha team has met all of the technical standards for a 1.0. The code base is solid and real projects are being built.
 
If we flag Iroha as in "incubation" while releasing a 1.0, not only will it more closely reflect reality, but it also mirrors the status of other Hyperledger projects such as Indy. Indy has been diversifying their contributor and maintainers considerably over the last few quarters and is about to move out of incubation even though Indy node is nearing its 2.0 release.
 
I disagree that it will harm Iroha diversification efforts to move back to "incubation" status. What is more important is to put out a solid 1.0 release and building relationships with people and organizations that can now take an enterprise-ready Iroha and build things with it. In many ways, I would expect that most projects will reach 1.0 before they have enough critical mass to move out of incubation. In fact, I think that the critical mass actually happens as a result of putting out a solid 1.0.
 
Cheers!
Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation

+1-206-234-2392
dhuseby@...
 
 
On Thu, Mar 14, 2019 at 10:41 AM hmontgomery@...<hmontgomery@...> wrote:
Hi Everyone,
 
Thanks for the suggestion Vipin.  Could we define more rigorous metrics for this (or at least suggestions, with perhaps some gray area)?
 
Putting on my Ursa hat, at some point in the hopefully not too distant future we’ll want to push forward with these things.  Having the knowledge of specific requirements (and whether we’ve met them or not, or whether it is borderline) would be immensely useful.  Putting on my TSC hat, I really want to avoid having to repeat this discussion again and again (a la the “improving the hackfests” discussions over the years), so coming up with something solid and writing it down is really appealing.
 
Thanks,
Hart
 
From: tsc@...[mailto:tsc@...] On Behalf Of Vipin Bharathan
Sent:
Thursday, March 14, 2019 9:04 AM
Cc:
Hyperledger List <
tsc@...>
Subject:
[Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

 
Hi all,
 
As suggested in today's tsc meeting I am raising the question Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?
Are numbers like the number of lines of code (or equivalent measures) from companies available at time of 1.0 (in active) available for other frameworks that already passed this milestone?
 
Another interesting statistic would be increase in contributor diversity SINCE 1.0.
Just to ensure that criteria are applied fairly for all projects in 1.0. And to see whether adoption is linked to 1.0 announcement.
 
Please put this on next week's agenda.
 
Regards,
Vipin
 
Also added as comment on the Agenda.





--
Best wishes!

Baohua Yang


Re: Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

Vipin Bharathan
 

Iroha is already active. So the only question before the TSC is whether they can go to 1.0 at this point. Seems like the answer is yes based on the exchanges that I have seen.
Vipin


On Mar 16, 2019, at 5:42 AM, Baohua Yang <yangbaohua@...> wrote:

I tend to feel that we may use version number only to measure code maturity, while using status to measure project itself, which certainly includes code maturity and more metrics.

Hence how about we give the active criteria as:

* released v1.0;
* have active commit activities;
* have good diversity in contributors.
* And more.

On Sat, Mar 16, 2019 at 11:16 AM Vipin Bharathan <vipinsun@...> wrote:
Hi all,

Ursa/Grid or any other project that becomes active or goes into 1.0 will have similar issues, if the rules are not clear/arbitrary. It behooves us to have more active full dlt projects in 1.0 status. Especially if the project is sound and has passed most of the criteria for maturity/security etc. If you listened to the Iroha peoples experience in the bootcamp; most participants in HK were not even aware of the existence of Iroha.

Many people when referring to Hyperledger actually mean Hyperledger Fabric; an impression that I have had to correct many times over. Not to take away from Fabric's popularity and adoption rates; I am a fan; but we all will (including Fabric) benefit if Iroha achieves 1.0 status. This means that the Hyperledger ecosystem is a level playing field and even small companies can make a difference.

Vipin 



On Fri, Mar 15, 2019 at 6:13 PM hmontgomery@... <hmontgomery@...> wrote:

Hi Everyone,

 

Sorry for causing controversy here.  I’ll attempt to clarify my points.

 

I understand Fabric-Java-SDK doesn’t function as a top-level project, and it is not being marketed as such.  But we approved it for incubation as its own (completely independent) project two and a half years ago.  If you go through the old TSC email archives, you can find where we did this (Ex.  https://lists.hyperledger.org/g/tsc/message/321?p=,,,20,0,0,0::relevance,,Fabric+java+sdk,20,2,0,17551816 is the first email when I search for Fabric-Java-SDK).

 

We had a discussion on tiers of projects (Ex. https://lists.hyperledger.org/g/tsc/message/681?p=,,,20,0,0,0::relevance,,RFC+1149,20,2,0,17551967) but this eventually got shot down and we went with a flat project hierarchy.  So, formally speaking, we don’t have project tiers, and every project under incubation technically is a top-level project under our governance structure.  To my knowledge (please correct me if I’m wrong), we haven’t formally folded projects like the Fabric-Java-SDK into their “parent” projects, so I believe these are de jure top-level projects, even if they are not top-level in practice.

 

As Arnaud points out, this may be something we want to discuss going forward as the number of projects continues to proliferate. 

 

I hope this has explained the thought process from my previous email.  Sorry for the confusion, and I’d be happy to clarify further if necessary.

 

Thanks,

Hart

 

From: Arnaud Le Hors [mailto:lehors@...]
Sent: Friday, March 15, 2019 1:26 PM
To: Montgomery, Hart <hmontgomery@...>
Cc: Dave Huseby <dhuseby@...>; Mic Bowman <mic.bowman@...>; Hyperledger List <tsc@...>
Subject: Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

 

Wait, what?? The Fabric-Java-SDK is a top level project?? Where is this being said? It's not on https://www.hyperledger.org/projectsnor https://wiki.hyperledger.org/display/HYP/Projects

For what it's worth, the answer to your question is a big NO for me. Although I got slammed for saying it in the context of the proposal to what's now called Grid project I think we should have fewer top level projects and let platform specific projects live within the platform project they are tied to.
--
Arnaud  Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM




From:        "hmontgomery@..." <hmontgomery@...>
To:        Dave Huseby <dhuseby@...>, Mic Bowman <mic.bowman@...>
Cc:        Hyperledger List <tsc@...>
Date:        03/15/2019 09:08 PM
Subject:        Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?
Sent by:        tsc@...





Hi Everyone,
 
A question:  do people outside of Hyperledger notice or care about the “active” vs “incubation” status?  I haven’t seen much press about this, and the writing I have seen typically gets it wrong and views active status as “production ready.”
 
Do we have more (non-marketing) resources for active projects (as compared to projects with incubation status)?  I’m not aware of any.
 
If we are going to measure project diversity, are we going to require (major) contributors to use their real names?  For instance, if we wanted to fast-track Ursa’s move to active status, we could have some of the core contributors make every Ursa commit with a new LF ID under a pseudonymous email.  Our contribution statistics would look fantastic, and we would have the added bonus of being able to completely derail the TSC elections (maybe we could run 6 winning candidates entirely on dunking booth platforms).  I realize this isn’t currently a problem, but it is probably something we should consider as we move forward.
 
In addition, if we are going to revise (and potentially roll back) the status of projects, then there are probably a bunch of things to look at.  For instance, at this point in time, do we think that the Fabric-Java-SDK should be its own incubated project?  This is obviously a useful and worthwhile coding effort, but by our “modern” standards, we never would have approved this as a top level project, and I suspect the new documentation will reflect this.
 
Thanks,
Hart
 
 
From: tsc@... [mailto:tsc@...] On Behalf Of Dave Huseby
Sent:
Friday, March 15, 2019 12:37 PM
To:
Mic Bowman <mic.bowman@...>
Cc:
Hyperledger List <tsc@...>
Subject:
Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

 
So to answer everybody's question about where the 1.0 criteria come from. It is a list that I have put together for the Grand Unified Theory of Project Readiness that I am putting together for the April 11th TSC call (see "future items"--formerly the "backlog"--in the TSC agenda doc).
 
I see 1.0 as purely a technical maturity measure. I see the "status" of a project as orthogonal to that. The reason I included documentation as a 1.0 criteria is because I don't see software as "ready for real work" if it isn't documented. From a purely technical standpoint, I have a rule: "all bugs live in the gap between the documentation and the implementation." It is impossible to know correct behavior from incorrect behavior if the correct behavior is undocumented. Shawn is right that the documentation also serves Hyperledger events as well. Documentation is dual purpose in this case and I'd still like to see it as a 1.0 criteria.
 
Cheers!
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation

+1-206-234-2392
dhuseby@...
 
 
On Fri, Mar 15, 2019 at 11:26 AM Mic Bowman <mic.bowman@...> wrote:
Comments embedded below…
 
From:tsc@...[mailto:tsc@...] On Behalf Of Dave Huseby
Sent:
Thursday, March 14, 2019 9:17 PM
To:
hmontgomery@...
Cc:
Vipin Bharathan <vipinsun@...>; Hyperledger List <tsc@...>
Subject:
Re: [Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

 
Here's my 2p on this:
 
I think the "status" of a project (e.g. "inactive", "incubation", "active", etc) is about the status of the community. A project in the incubation phase is one that has a small core of developers working on a minimum viable product. Typically this is a group of students at the same university or a group of employees at the same company. Moving from incubation to active happens when the project's community outgrows that initial core group and has enough critical mass that the original creators could leave the project and it would keep going.
 
The authorization to release a 1.0 major release is based on all of the technical aspects of the project. Off the top of my head, that list includes the CII badge, public code repo, public mailing list, some form of CI/CD, public bug tracker, public roadmap, an outside security audit, and some form of change management system (e.g. 2+2 reviews) full DCO compliance, training/educational materials for bootcamps and webinars as well as online documentation.
 
[Mic:] I like this list. Given that we don’t seem to have (or at least I cannot find it) a list of criteria for 1.0 release, would it make sense to start a “release criteria” doc we could use to focus the discussion? I’m happy to contribute/comment. We should also pull in some of our previous discussions on the topic.  Question: why is the 1.0 designation is important to Hyperledger TSC? My assumption is that we care because it reflects a commitment of resources for security analysis, marketing, etc and because it reflects on the “credibility” of the organization?
 
By applying these standards, I think the appropriate position for the Iroha project is to be in "incubation" but to approve a 1.0. I think Chris demonstrated that the contributions are still 99.9% Soramitsu. I would push back a little and also look for the stats over the last quarter and last two quarters as a more accurate measure of their community diversification. I agree with Chris that a plan is good but actually diversification should be demonstrated.
 
[Mic:] As Vipin suggested… it would be good to run the same queries over the other projects to get a baseline for what constitutes “normal” diversity in a community. Specifically… it would be interesting to compare overall contributor diversity, change in diversity post-1.0 release, and diversity over the last quarter (or some short, recent time period).
 
I also believe that the Iroha team has met all of the technical standards for a 1.0. The code base is solid and real projects are being built.
 
If we flag Iroha as in "incubation" while releasing a 1.0, not only will it more closely reflect reality, but it also mirrors the status of other Hyperledger projects such as Indy. Indy has been diversifying their contributor and maintainers considerably over the last few quarters and is about to move out of incubation even though Indy node is nearing its 2.0 release.
 
I disagree that it will harm Iroha diversification efforts to move back to "incubation" status. What is more important is to put out a solid 1.0 release and building relationships with people and organizations that can now take an enterprise-ready Iroha and build things with it. In many ways, I would expect that most projects will reach 1.0 before they have enough critical mass to move out of incubation. In fact, I think that the critical mass actually happens as a result of putting out a solid 1.0.
 
Cheers!
Dave
---
David Huseby
Security Maven, Hyperledger
The Linux Foundation

+1-206-234-2392
dhuseby@...
 
 
On Thu, Mar 14, 2019 at 10:41 AM hmontgomery@...<hmontgomery@...> wrote:
Hi Everyone,
 
Thanks for the suggestion Vipin.  Could we define more rigorous metrics for this (or at least suggestions, with perhaps some gray area)?
 
Putting on my Ursa hat, at some point in the hopefully not too distant future we’ll want to push forward with these things.  Having the knowledge of specific requirements (and whether we’ve met them or not, or whether it is borderline) would be immensely useful.  Putting on my TSC hat, I really want to avoid having to repeat this discussion again and again (a la the “improving the hackfests” discussions over the years), so coming up with something solid and writing it down is really appealing.
 
Thanks,
Hart
 
From: tsc@...[mailto:tsc@...] On Behalf Of Vipin Bharathan
Sent:
Thursday, March 14, 2019 9:04 AM
Cc:
Hyperledger List <
tsc@...>
Subject:
[Hyperledger TSC] Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?

 
Hi all,
 
As suggested in today's tsc meeting I am raising the question Which comes first 1.0 or contributor diversity or does diversity follow from 1.0?
Are numbers like the number of lines of code (or equivalent measures) from companies available at time of 1.0 (in active) available for other frameworks that already passed this milestone?
 
Another interesting statistic would be increase in contributor diversity SINCE 1.0.
Just to ensure that criteria are applied fairly for all projects in 1.0. And to see whether adoption is linked to 1.0 announcement.
 
Please put this on next week's agenda.
 
Regards,
Vipin
 
Also added as comment on the Agenda.





--
Best wishes!

Baohua Yang

1781 - 1800 of 3892