2019 03 21 TSC minutes

Owned by Ry Jones
Oct 01, 2019
7 min read

 (7:00am - 8:00am PT)

via Zoom

Hyperledger is committed to creating a safe and welcoming community for all. For more information please visit our Code of Conduct: Hyperledger Code of Conduct

TSC Members

Present?

  • Arnaud Le Hors
  • Baohua Yang
  • Binh Nguyen
  • Christopher Ferris
  • Dan Middleton
  • Hart Montgomery
  • Kelly Olson
  • Mark Wagner
  • Mic Bowman
  • Nathan George
  • Silas Davis

Resources:

Announcements

  • Contributors summit.
    • Still trying to find a location, hopefully free.
    • Dates are August 1st and 2nd.
    • Questions:
      • Arnaud: where will it happen?
      • It is happening in conjunction with the Members Summit in Japan.
  • Global Forum
    • Approved by governing board.
    • Looking for locations for Q1 2020.
  • CfP for Members Summit goes out this week.
  • Quilt reboot next week.

Items of discussion

  • Internship proposal selection process is nearly complete.
  • Continued Iroha Discussion about lifecycle.
    • Topics
      • Should Iroha move to a 1.0 production release.
      • What are the formalized 1.0 release criteria.
      • What are the details of the project lifecycles and can a project move backwards as forward.
        • Is the lifecycle status a criteria for the 1.0 release?
    • The following is a rough summary of the conversation:
      • Dan: when we think about what it means for HL to announce a release it isn't just technical, it should also include the community readiness.
      • Arnaud: not sure what we want to focus on, we should separate the parts. There are several issues.
      • Dave: it boils down to the question: would the TSC prevent a 1.0 release if there were community related issues (e.g. not diversified contributors, no meetups, etc) given that the project has met all technical hurdles (e.g. security audit, feature complete, CII badge complete).
      • Arnaud: that's already defined in the lifecycle document. The first major release expectation is that it comes after the project is "active" with some exceptions. Maybe we shouldn't reopen the discussion.
      • Aleš: the diversity won't increase if the Iroha first major release is not approve. It's a chicken and egg problem.
      • Mark: that's not the right question to ask. I don't agree that 1.0 is required to increase diversity.
      • Aleš: some companies working with Soramitsu have expressed concern about getting involved before Iroha's first major release is approved.
      • Mark: do we expect our first major releases to mean "this is enterprise software" not just "it's open source do with it what you like"?
      • Dave: official recommendation is that Iroha is ready for 1.0 technically. CII badge, all pieces in place, security audit is complete and they have met the bar that all other projects met to go 1.0. The software is ready for use.
      • Mark: are they ready to support issues that come with 1.0.
      • Dan: maybe reaching out to potential partners asking them to contribute to the project now so that they can be part of the big announcement of the first major release.
      • Vipin:  A couple of issues.
        • How do we measure the diversity and stability of a project? That measure is made up of knowledge and contributions of core components by multiple vendors.
        • We should go back and look at what the real contribution diversity was for Sawtooth and Fabric when they went 1.0.
        • We really want a project to have a life beyond the involvement of specific companies.
        • We need to look at the total investment of the vendor including outside companies paid by the vendor to judge whether there is real diversity in contributions.
        • If we look at the actual contributions to the core components of all of our projects we will likely find that the diversity is very limited.
        • Are we chasing after something that is impossible to measure at this time?
      • Silas: linking community diversity to software maturity is probably not good.
        • SQLite is mature but developed by one person.
        • It is entirely possible for a project to have very immature community but a robust and mature project.
        • The two are not completely independent, but it is problematic to link the two for 1.0 purposes.
      • Hart:
        • What are the specific benefits of going from incubation to active status. It seems like the benefit is only marketing related.
        • Interested in the formulation for going from incubation to active as well as the exact criteria for going to 1.0.
        • It would be nice to have some consistent documentation and guidelines for these because Ursa is about to run through them.
        • Measuring diversity is probably very difficult because there's no requirement that a developer maintain a single identity for all of their contributions.
      • Binh:
        • Contributors to an open source project is very dynamic and diversity may come and go on short time scales.
        • From a technical point of view, Iroha is a good candidate for 1.0.
        • We have to consider the dynamic nature of the diversity.
        • We need to consider the reasons that would make Soramitsu abandon a project and it is very unlikely.
        • Look at Fabric, nearly all contributions come from IBM. Will IBM go away? Probably not because they have built an entire business unit on it.
        • When Iroha went from incubation to active status there were more contributors but today there are not.
      • Dan: it is likely that we won't be able to get to a completely objective measurement but we should be able to make an intelligent judgement.
      • Baohua: we need to separate the technical quality from the community quality.
        • It is always more difficult to build out a mature community.
        • Suggests we focus on the technical quality for 1.0 and focus more on the community when a project becomes "active".
      • Nikolai:
        • Diversity is a very dynamic thing and there are positive trends in chat participation and docker image pulls and documentation contributions.
        • Their diversity plan is in effect and that is driving the positive trends in their community diversity.
        • It would be nice to separate the technical health from the community health. The community health should be a dynamic measure that is measured over a pretty narrow "recent time" window.
        • They have a diverse set of contributors for everything but code. 
        • There is an expressed intent to join the project to contribute code but they are waiting for the first major release approval.
        • Recommend that we focus on technical quality when approving first major release.
        • Consider the potential harm to the community that moving from active back to incubation. Incubation implies that the project is not technically mature even if the 1.0 is approved.
        • The lifecycles status confuse the perception of whether the project is ready or not.
      • Mark:
        • Let's just vote on Iroha based on the standards that were in effect when they applied.
        • Let's continue the discussion outside of the context of the Iroha first major release approval.
      • Dave: +1
      • Mic: What's the take on the DCO situation?
      • Dave:
        • Ran a DCO audit last week.
        • Grabbed the unique list of contributors and moved the Soramitsu employees out of the list because they can be covered by a single sign-off from Soramitsu.
        • About 27 contributors that make contributions without signing off on their contributions.
        • We should try to find those contributors and get them to sign off.
      • Mic: In favor of the 1.0 subject to resolution of the DCO issues.
      • Nikolai:
        • In 2017 there was a CLAHub tool process for LF/HL contributions.
        • In 2018 our CI pipeline changed to using DCO bot and requiring the signed-off-by.
        • According to the rules, CLAHub and DCO bot rules were met.
      • Dave: I think the contributions may have come in before the code came to HL.
      • Nikolai: Please investigate the situation more to figure out whether the not-signed-off contributions were covered by the HLABot when they were made.
      • Vipin: if the rule was put into place after the commits it is fine.
      • Nikolai: the Iroha team will not make a squash commit.
      • Silas: unsure how a squash commit solves the underlying IP issues.
      • Arnaud: whomever does the squash takes liability for everything in the squash.
      • Ry: 
        • prior to HL, all code bases were required to come in as a squash commit.
        • when CLAHub was being used, it was using a modified version of the DCO.
        • The reason we left CLAHub was because it had different DCO text from what the LF was using and we can't go back and change the DCO text for CLAHub.
      • Baohua: is it possible to go back and find the developers and ask them to sign off on the commits.
      • Arnaud: getting emails from the developers would make it fine.
      • Ry: we could even check the emails into the codebase.
      • Baohua: we should try to get the emails.
      • Mark: does the DCO apply across projects?
        • Ry: the DCO is per-commit?
      • Dave: it is impossible to make a commit now without the signoff.
      • Silas: so we'll have to rewrite history?
        • Dave: not if we get emails from developers.
      • Dan: we need an owner to figure out if the DCO sign-off status is good.
        • Dave: I'll take it.
      • Ry: can we have a vote on the 1.0 approval provided that the DCO sign-off gets resolved?
      • Dan: that is in order as long as everybody is ok with that.
      • Mark: proposal that Iroha goes to 1.0 provided DCO gets resolved.
      • Silas: are we going to fix incubation issues later?
      • Dan: willing to give some freedom with Iroha because of their long history with Hyperledger but new projects must meet the bar for diversity.
      • Silona: we are working to hammer out the clear, defined metrics and criteria so that we can do the enforcement better because it becomes mechanical.
      • Silas: good with the compromise.
      • Arnaud: the door is open for projects moving forward and backward on the maturity spectrum. most interested in defining the 1.0 criteria precisely that we can hold projects to and force them to address when asking for 1.0 release.
      • Dan: call for a roll vote for approval of Iroha's first major release.
        • Mic: second
        • None abstaining and none apposed.
        • Motion passes unanimously.

Quarterly updates

  • Hyperledger Explorer report
    • Questions:
    • None

Upcoming items

  • Focus exclusively on the 1.0 release criteria discussion. (Dan)
  • Testnets and CI/CD proposal. (Dave)
  • Ambassador reboot maybe. (Silona)

Recordings

dummyfile.txt

dummyfile.txt

Backlog