Date   

Upcoming Event: Hyperledger Explorer Quarterly Update Due #tsc-project-update - Thu, 12/05/2019 #tsc-project-update #cal-reminder

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

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

When: Thursday, 5 December 2019

View Event

Organizer: community-architects@...

Description: Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


Re: Incubation/Active Status

Somogyvari, Peter
 

Hi Hart,

 

 

Made it to the end, thank you for the blessing! 😊

 

I agree with the general direction and would like to emphasize how important it is that the community size metrics be objective ones and also trustworthy. I separate those two because a Github repo could have a thousand stars, but no production users, if it was featured in the right place or somehow received enough attention (or maybe people just like the idea and give it a thumbs up even if they are not intending on using it).

In this sense GitHub is just like any other social media platform where seemingly objective metrics must be interpreted with a grain of salt => I heard the same rumor a number of times now that the average Silicon Valley venture capitalist will consider one github star worthy of 1500 dollars of investment money.

What gets measured gets managed. What gets managed gets distorted, almost by definition (not saying that anybody here or elsewhere had/have/will have any bad intentions at all, just that incentivization is a double edged sword).

 

One idea that I have (that I’ve seen done elsewhere a lot) is to for projects to open a survey asking “Who uses/planning on using the project and for what?”. People who are genuinely planning on or already are using the project usually pile in there with use-cases from money-backed/profitable companies and often times it results in a new “Who uses X” section of the project readme showing off company logos.

So, maybe we could consider this an item on the active checklist. It does have a chicken-egg problem with 1.0 releases being dependent on the active status itself since I couldn’t advise anyone with good conscience to adapt a project while it hasn’t had it’s first official stable release yet. Which brings me to my next idea:

Maybe labs should be free to issue major/stable releases before they reach active status and we could find some other way to label the releases as active/incubation.

 

What I’m saying in a longwinded way I guess is that changes may be necessary, but we should take extra care not to “lower the bar” while fixing/optimizing the process.

I’m deeply involved in one of the labs projects so it would be convenient for me to support anything that gets our project faster to active status, but when we get there I want that active status to still mean the same thing, a certain level of guarantee to would be users that the project can be integrated into their stack with confidence.

In other words, I don’t (and nobody should) mind working hard for the active status, but a predictable, transparent, easy to understand process/metrics is very much appreciated (not saying the current process is not all of these things, just that more of it is welcome).

 

Another random idea: Could also help to add more statuses to avoid the binary good/not good, in/out feel and the human emotions that come with them.

I’ve seen in real estate investment that projects can have phases like ramping up, stabilizing, operating which immediately tells you what can you expect if you get on board at any one of those stages. Not saying we need exactly those, just something to consider as well.

 

 

Peter

 

Peter Somogyvari

OOO: Dec 18 - 31

Workshop: -

Technology Architect

Accenture Products & Platforms | Technology & Engineering CoE

Office: - | Mobile: 650.488.1741

  

           

Become an LGBT Ally. Demonstrate your support for an inclusive workplace for Lesbian, Gay, Bisexual, Transgender (LGBT) employees.

 

 




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

www.accenture.com


Incubation/Active Status

Hart Montgomery
 

Hi Everyone,

 

Sorry for the incoming long wall of text.  I wanted to comment on the incubation/active status debates so that hopefully we could clarify things, frustrate people less, and spend less time on what is essentially a rubber stamp in the future.  With that being said, here goes:

 

In light of all of the discussion we’ve had on the Besu proposal for active status, I wanted to dig down into the details of why people care so much about active status versus incubation.  We discussed this a little bit in the project lifecycle task force (https://wiki.hyperledger.org/display/HYP/Project+Incubation+Exit+Criteria), but in light of all of the discussion at the last TSC meeting, I thought it might be a good idea to bring it up again.

 

My fundamental question is the following:  why do we care so much (or at all) about active/incubation status, and do we even need a distinction? 

 

The two documents that are relevant to the discussion are:

https://wiki.hyperledger.org/display/HYP/Project+Lifecycle

https://wiki.hyperledger.org/display/HYP/Project+Incubation+Exit+Criteria

 

Let’s ignore for a moment that the exit criteria in these two documents are not exactly consistent (for instance, the project lifecycle document requires a “history of releases” like that of an active project, while the actual exit criteria document only would require a “developer preview”).  This is something that definitely needs to be cleaned up, but I’ll mostly go by the exit criteria document, since it is more recent.

 

The core overriding requirement for active status, as put by Chris first (I think), is that “the community and infrastructure necessary for a project to succeed are in place.”  This means that all people and things that a project will need to generate good quality, useful code are there.  With this in mind, let’s take a look at the core requirements from the exit criteria document:

 

1.       Legal (Apache 2.0, etc.)

2.       Community—the seemingly most discussed metric

3.       Sufficient test coverage

4.       Sufficient user documentation

5.       Alignment (i.e., the project still fits within Hyperledger)

6.       Infrastructure is set up

7.       CII Badge

 

We also require TSC approval for a project’s 1.0 release.  This hasn’t been migrated over to the official TSC documentation list (so, there’s even more inconsistency here in terms of what is written in the official TSC documentation).  But here (https://wiki.hyperledger.org/pages/viewpage.action?pageId=16321784 ) is the document and here is a summary:

 

1.       Project has reached active status

2.       Release features meet the project’s charter

3.       Satisfies “internal project requirements”—mostly things like appropriate test coverage, bug handling, and documentation

4.       Satisfies “technical criteria”—CII badge, security audit, crypto code auditing, license scan, etc.

 

Obviously there is a lot of overlap between these two. 

 

In particular, of the active status criteria, #3 (test coverage), #4 (sufficient user documentation), and #7 (CII badge) are explicitly covered in the 1.0 release criteria.  In addition, #6 (infrastructure) and #1 (legal) are mentioned in both, although the requirements for 1.0 release seem a little bit more stringent (i.e. more infrastructure is required).

 

Let’s go back to the beginning of the project lifecycle and look at what is required for incubation status:

 

1.       Have a clear description

2.       Have a well-defined scope

3.       Identify committed development resources

4.       Identify initial maintainers

5.       Be vendor neutral

 

We have been implicitly requiring incoming code to be correctly licensed by incubation (rather than active status), so one easy move I think we could do is to formalize this requirement.  It’s not mentioned in either the project lifecycle document or the project proposal document.

 

“Well-defined scope” corresponds roughly to “Alignment” in the incubation exit criteria, and we ask the “context” question in the project lifecycle document, so I’d assume that any project that fails the #2 requirement “Alignment” for active status will probably not have made it to incubation in the first place, barring some sort of pivot (but this would, of course, fail the #2 requirement for 1.0 release (release meet’s the project’s charter).

 

So if we assume metrics #1 (legal) and #5 (alignment) are already a given due to the project getting into incubation in the first place, then the only thing active/incubation is really giving us that is unique from both the project proposal requirements and the 1.0 release criteria is the community metric. 

 

Perhaps not coincidentally, we have talked about the community metric the most for active status discussion, and it seems to be the bottleneck in most past, current, and planned proposals (i.e., people are waiting on proposing due to the community metric).  This metric is also perhaps the most subjective.  On the most recent TSC call, it seemed like everyone had a different interpretation of the community metric. 

 

The exact community metric requirements are:

·         The project must have an active and diverse set of contributing members representing various constituencies

·         The project is not highly dependent on any single contributor (there are at least 3 legally independent committers and there is no single company or entity that is vital to the success of the project)

·         Release plans are developed and executed in public by the community.

 

Out of these, the first two are very open to interpretation.  If one is so inclined, it’s easy to make the case that many (or, if you want to be argumentative, all) of the Hyperledger projects are highly dependent on a “single entity.”  Regardless of whether you agree with what I’m about to propose, I think it’s a relatively universal good idea that if we do keep the incubation exit criteria in its current form, we should provide more quantification here so that projects that want to apply for active status have a better idea of what they need to attain.

 

I’ve mostly stuck with established facts so far.  Now I’m going to veer off into what might be a controversial opinion.  I’m of the opinion that the only real criterion (and purpose) of the active status/incubation exit criteria checkpoint is the community status evaluation—everything else either follows from the project being approved for incubation in the first place or is present in the 1.0 release criteria. 

 

What does the general community get from incubation/active status?  A binary value that says whether the TSC thought the community support of a certain project was “good” or “not good” on some particular day.  In the grand scheme of things, this is not particularly useful information, since even the TSC can’t exactly agree on what “good” community support is.

 

On the other hand, there are several notable tools that would provide community metrics that could be very useful for outsiders.  Bitergia (https://blog.bitergia.com/) is an example that comes to mind.  If we had strong public metrics on code contributions and community support (distributions on contribution by company, contributor, geography, etc.) this active/incubation bit wouldn’t really be needed:  rather than have the TSC assess the status of a community, why not give people all of the appropriate information and let them judge for themselves?

 

We can argue that something like security or cryptography requires expert review:  it’s very hard for someone who isn’t an expert in these areas to decide whether or not something is secure, even given time to examine it.  But community support is not exactly something that requires an expert review—any average person with some knowledge of software development can make a pretty reasonable determination of community support if they are given enough facts.  Since this is something that is very subjective but also doesn’t require expert knowledge to analyze, it might be best to leave the TSC out of this.

 

So, while I don’t think this is feasible now since we don’t have the software in place to property handle contributor analytics, I think it might be worth considering in the long run to do the following:

 

1.       Move all of the requirements of the incubation exit criteria to either the 1.0 release or the project proposal.

2.       Get rid of the active/incubation status altogether.

3.       Collect and publish a large and useful amount of contributor statistics so outsiders can determine the level of community support for a project themselves.

 

What do people think about this?  Does this make sense?

 

I’d also like to point out that we currently require projects to achieve active status before releasing a 1.0 version.  If we keep active status as a milestone, I’d like to push back on this requirement.  At least in my opinion, we approved this assuming the bar for active status was much lower than it currently is today.  The bar for active status seems to be very high.  Something like Explorer may never get enough contributors to have active status under the current metrics—and this is OK, because it may not need a lot of contributors to build successful software--but that doesn’t mean it shouldn’t be able to release a 1.0 if the software is excellent.

 

Finally, regardless of what you think about this idea, we do need to clean up our documentation on this.  It’s not clear at all and is in some cases contradictory.  Putting all of the useful documentation in one place and adding some examples of when (and when not) projects are ready for milestones would be quite useful for projects and hopefully end a lot of the frustration involved in the project lifecycle process for both the projects and the TSC.

 

Please let me know what you all think about this (positive and negative).  If this gets a lot of responses, I’ll move it to a wiki so it can be further taken apart.

 

If you’ve made it this far, bless your heart and thanks for reading.

 

Thanks,

Hart

 


TSC Agenda for Dec 5, 2019

Arnaud Le Hors
 

[I've been fighting system issues all day and just realized this email never found its way out. Apologies for the late arrival.]
 
Hi,
 
The agenda for this week's call is up. There are a lot of quarterly reports up for review, please, make sure to do so prior to the call. We will NOT go through them on the call. We will merely focus on any pertinent aspects/issues as appropriate.
 
Thanks
--
Arnaud Le Hors - Senior Technical Staff Member, Blockchain & Web Open Technologies - IBM


moderated Accepted: Technical Steering Committee (TSC)

Angelo De Caro
 


Upcoming Event: Hyperledger Besu Quarterly Update Due #tsc-project-update - Thu, 12/05/2019 #cal-reminder #tsc-project-update

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

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

When: Thursday, 5 December 2019

View Event

Organizer: community-architects@...

Description: Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


Re: [Hyperledger Architecture WG] This weeks WG meeting topic: Blockchain Integration Framework

Ram Jagadeesan (rjagadee)
 

Thanks Brian,
The more the merrier!

Ram


On Dec 2, 2019, at 2:31 PM, Brian Behlendorf <bbehlendorf@...> wrote:

Hi all. I felt this might be of interest to others on the TSC mailing list (sorry Ram for jumping the gun if you wanted it to be a small quiet call :-D )   It's also great to see the Arch WG used for this kind of thing.

Brian



-------- Forwarded Message --------
Subject: [Hyperledger Architecture WG] This weeks WG meeting topic: Blockchain Integration Framework
Date: Mon, 2 Dec 2019 11:03:35 -0800
From: Ram Jagadeesan (rjagadee) <ram.jagadeesan@...>
To: hyperledger-arch-wg@..., Hamilton, Jonathan M. <jonathan.m.hamilton@...>, Fujimoto, Shingo <shingo_fujimoto@...>


Folks,

Jonathan Hamilton from Accenture and Shingo Fujimoto from Fujitsu will be presenting on their work on Blockchain interoperability leading up to the Hyperledger lab project on the same topic.

Agenda:
  • 1. Fujitsu ConnectionChain context & history
  • 2. Accenture Federation for Interoperability context & history
  • 3. Design principles for Blockchain Integration Framework (both merging these two into one software and shaping roadmap priorities)
  • 4. Q&A / open discussion

  • [Hyperledger Architecture WG] Architecture WG Biweekly Meeting
    When: Wed, December 4,  9 AM - 10 AM PST (5pm – 6pm GMT)
    Description: Bi-weekly Architecture WG meeting


    [Hyperledger Architecture WG] This weeks WG meeting topic: Blockchain Integration Framework

    Brian Behlendorf
     

    Hi all. I felt this might be of interest to others on the TSC mailing list (sorry Ram for jumping the gun if you wanted it to be a small quiet call :-D )   It's also great to see the Arch WG used for this kind of thing.

    Brian



    -------- Forwarded Message --------
    Subject: [Hyperledger Architecture WG] This weeks WG meeting topic: Blockchain Integration Framework
    Date: Mon, 2 Dec 2019 11:03:35 -0800
    From: Ram Jagadeesan (rjagadee) <ram.jagadeesan@...>
    To: hyperledger-arch-wg@..., Hamilton, Jonathan M. <jonathan.m.hamilton@...>, Fujimoto, Shingo <shingo_fujimoto@...>


    Folks,

    Jonathan Hamilton from Accenture and Shingo Fujimoto from Fujitsu will be presenting on their work on Blockchain interoperability leading up to the Hyperledger lab project on the same topic.

    Agenda:
  • 1. Fujitsu ConnectionChain context & history
  • 2. Accenture Federation for Interoperability context & history
  • 3. Design principles for Blockchain Integration Framework (both merging these two into one software and shaping roadmap priorities)
  • 4. Q&A / open discussion

  • [Hyperledger Architecture WG] Architecture WG Biweekly Meeting
    When: Wed, December 4,  9 AM - 10 AM PST (5pm – 6pm GMT)
    Description: Bi-weekly Architecture WG meeting


    Upcoming Event: Hyperledger Explorer Quarterly Update Due #tsc-project-update - Thu, 12/05/2019 #tsc-project-update #cal-reminder

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

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

    When: Thursday, 5 December 2019

    View Event

    Organizer: community-architects@...

    Description: Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


    Upcoming Event: Hyperledger Besu Quarterly Update Due #tsc-project-update - Thu, 12/05/2019 #tsc-project-update #cal-reminder

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

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

    When: Thursday, 5 December 2019

    View Event

    Organizer: community-architects@...

    Description: Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


    Upcoming Event: Hyperledger Ursa Quarterly Update Due #tsc-project-update - Thu, 12/05/2019 #tsc-project-update #cal-reminder

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

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

    When: Thursday, 5 December 2019

    View Event

    Organizer: community-architects@...

    Description: Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


    Upcoming Event: Hyperledger Smart Contracts WG Quarterly Update Due #tsc-wg-update - Thu, 12/05/2019 #tsc-wg-update #cal-reminder

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

    Reminder: Hyperledger Smart Contracts WG Quarterly Update Due #tsc-wg-update

    When: Thursday, 5 December 2019

    View Event

    Organizer: community-architects@...

    Description: Please review the update at TSC Working Group Updates prior to the meeting and add your questions to the update.


    Cancelled Event: Technical Steering Committee (TSC) - Thursday, 28 November 2019 #cal-cancelled

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

    Cancelled: Technical Steering Committee (TSC)

    This event has been cancelled.

    When:
    Thursday, 28 November 2019
    7:00am to 8:00am
    (UTC-08:00) America/Los Angeles

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

    Organizer: Technical Steering Committee (TSC)

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

    Or iPhone one-tap :
    US: +16699006833,,6223336701# or +16465588656,,6223336701#
    Or Telephone:
    Dial(for higher quality, dial a number based on your current location):
    US: +1 669 900 6833 or +1 646 558 8656 or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)
    Meeting ID: 622-333-6701
    International numbers available: https://zoom.us/zoomconference?m=BYDz1WGXJTTJ_s4_zumD9hqKjJv-Whgs


    TSC Agenda for Nov 21, 2019

    Arnaud Le Hors
     


    moderated Event: Technical Steering Committee (TSC) #cal-invite

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

    Technical Steering Committee (TSC)

    When:
    Thursday, 14 November 2019
    7:00am to 8:00am
    (UTC-08:00) America/Los Angeles
    Repeats: Weekly on Thursday

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

    Organizer: Technical Steering Committee (TSC)

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

    Or iPhone one-tap :
    US: +16699006833,,6223336701# or +16465588656,,6223336701#
    Or Telephone:
    Dial(for higher quality, dial a number based on your current location):
    US: +1 669 900 6833 or +1 646 558 8656 or +1 877 369 0926 (Toll Free) or +1 855 880 1246 (Toll Free)
    Meeting ID: 622-333-6701
    International numbers available: https://zoom.us/zoomconference?m=BYDz1WGXJTTJ_s4_zumD9hqKjJv-Whgs


    Re: Hyperledger Besu Active Status Proposal

    Grace Hartley
     

    Hi TSC,

    Thanks for the discussion today about the Besu Active Status Proposal.

    Following up from my note in the TSC chat, I put together a breakdown of contributors to Besu since joining Hyperledger. I looked at September 1st to present.

    PegaSys contributors: 21
    Non-PegaSys contributors: 8

    Looking forward to continuing the discussion at next week's TSC meeting. 

    Thanks,
    Grace

    On Mon, Oct 14, 2019 at 11:25 AM Grace Hartley via Lists.Hyperledger.Org <grace.hartley=consensys.net@...> wrote:
    Hi TSC,
     
    The Hyperledger Besu team would like to propose the project be moved from Incubation status to Active status. 
     
    We have drafted this proposal on how we believe we meet the requirements on this page on the Wiki: Hyperledger Besu Active Status Proposal.
     
    We look forward to your thoughtful engagement around this matter.
     
    Thank you,
    Grace and the Hyperledger Besu team


    Upcoming Event: Hyperledger Aries Quarterly Update Due #tsc-project-update - Thu, 11/21/2019 #tsc-project-update #cal-reminder

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

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

    When: Thursday, 21 November 2019

    View Event

    Organizer: community-architects@...

    Description: Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


    Upcoming Event: Hyperledger Grid Quarterly Update Due #tsc-project-update - Thu, 11/21/2019 #cal-reminder #tsc-project-update

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

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

    When: Thursday, 21 November 2019

    View Event

    Organizer: community-architects@...

    Description: Please review the update at TSC Project Updates prior to the meeting and add your questions to the update.


    Upcoming Event: Hyperledger Technical WG China Quarterly Update Due #tsc-wg-update - Thu, 11/21/2019 #tsc-wg-update #cal-reminder

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

    Reminder: Hyperledger Technical WG China Quarterly Update Due #tsc-wg-update

    When: Thursday, 21 November 2019

    View Event

    Organizer: community-architects@...

    Description: Please review the update at TSC Working Group Updates prior to the meeting and add your questions to the update.


    Re: CMSIG Announcing a talk by Marley Gray

    Jonathan Levi
     

    Sure thing. Yes, the full date was further down in the original one too, but much clearer on the following one.

    Thanks Vipin! 

    Jonathan



    On Wed, Nov 13, 2019 at 17:06, VIPIN BHARATHAN
    <vip@...> wrote:
    Thanks Jonathan,
    I sent it out again with the right dates prominently.
    V

    dlt.nyc
    Vipin Bharathan
    Digital Transformation Consultant
    Financial Services 
    vip@...


    From: Jonathan Levi <jonathan@...>
    Sent: Wednesday, November 13, 2019 10:05 AM
    To: VIPIN BHARATHAN <vip@...>; capital-markets-sig@... <capital-markets-sig@...>
    Cc: Hyperledger List <tsc@...>
    Subject: Re: [Hyperledger TSC] CMSIG Announcing a talk by Marley Gray on
     
    Wednesday, Nov 20th
    at 10:00 am EST (15:00 UTC) 

    Jonathan 



    On Wed, Nov 13, 2019 at 17:00, VIPIN BHARATHAN
    <vip@...> wrote:
    Hi Everyone,

    The CMSIG is pleased to announce the following presentation:

    When:
    Wednesday 10 am EST 15:00 UTC

    Where:
    On the CMSIG zoom call
    What:
    The Capital Markets Special interest Group (SIG) represents industry professionals working together to study how Hyperledger DLTs interact with Capital Markets use cases. The community is working on a series of projects under the SIG umbrella. They deal with regulation, standards, structure and life cycle of instruments like equities and bonds. One of the most important areas of investigation are the tokenisation of assets. We meet regularly on a zoom conference call every two weeks, Wednesday at 10 am. Eastern Standard Time which is 15:00 UTC.

    The Token Taxonomy Initiative (TTI) has been working to develop a set of common terms and a framework around tokens. They have just released a version 1.0 of their Token Taxonomy Framework Marley Gray, Principal Architect, Azure Blockchain Engineering, Microsoft; who is also the chair of the TTI working group will make a presentation of TTI's work to the SIG on Wednesday the 20th at 10 am. Eastern Time. If you are interested in this topic, please join and get your questions answered. As with all SIG and Working Group calls in Hyperledger, it is open to all; not just the members of Hyperledger.

    dlt.nyc
    Vipin Bharathan
    Digital Transformation Consultant
    Blockchain in Financial Services 
    vip@...

    1061 - 1080 of 3824