Hyperledger Project

Technical Steering Committee (TSC) Meeting

No recording. 

December 14, 2017 (7:00am - 8:00am PT) via GoToMeeting

TSC Members

Arnaud Le Hors


Baohua Yang


Binh Nguyen


Christopher Ferris


Dan Middleton


Greg Haskins


Hart Montgomery


Jonathan Levi


Kelly Olson


Mic Bowman


Nathan George




FYI:  canceling 12/28 TSC meeting since many on holiday

2018 Hackfest planning [reminder thread]

  • February - US [TBD]
  • April - Tel Aviv, Dubai, Japan? [TBD]
  • If you have potential venue space, please reach out to tbenzies@linuxfoundation.org or indicate interest here.
  • Looking to have a database of venues that will allow us to schedule hackfests further out.
  • Dan has found space in Minneapolis
  • Baohua asked about Hackathon schedule - Don't have a regular heartbeat for Hackathons, but are interested in hearing about any that we should be participating in

Project Reporting

  • Hyperledger Burrow update
    • No representation. Move to next week's meeting.
  • Hyperledger Cello update
    • Releasing 0.8 at the end of December
    • Three maintainers. Contributors from 7 companies + individual contributors
    • Concern - what platforms should be supported?
      • no blanket policy within Hyperledger
      • each project decides

Hyperledger Labs

  • Proposal
  • Who are the maintainers? Prefer if proposal outlined who the TSC might want as a maintainer
    • Two levels of maintainers. 
      • Each lab would have its own set of maintainers.
      • The organization would need a set of maintainers that will define what gets into labs.
    • How much control do we want to exercise over the labs? Trying to find a spot between the extremes of completely free for anyone to add a project and total control.
    • We want volunteers for the maintainers, possibly even some of the TSC members (Arnaud volunteers)
  • What are the criteria for entering the lab? More clarity on what we want as a lab project.
    • Out of scope of Hyperledger or Blockchain technologies
  • Is there an expectation or constraint that a project will become a project?
    • Code/projects being built of two classes
      • Too early, but could become a project
      • Demos/sample code
    • Labs shouldn't be a precursor to incubation. Could be used for experimentation. Could be something that comes out of Hackfest.
  • Caliper as an example - could be a good candidate for a labs project
  • Does this need to be brought to the marketing committee for brand concerns?
  • W3C community groups provide a good model
  • Want more specificity in the document
  • Project for incubation - is there a natural inclination to put that in labs. We don't want that to be a place of rejected projects (see Apache Labs)
  • Maintainers have a responsibility for what is in the labs. Maintainers will need to recruit or potentially roll up a project into the attic if there is a project that has gone dormant
  • Who will be evaluating lab projects for security issues?
  • Ultimately the maintainers should err on the side of allowing disruptive ideas rather than waiting for it to be beautiful
  • A/I: Arnaud to update the text for more specificity

Releasing the Fabric 1.0 Security Audit report

  • Thread
  • Have the maintainers of the Fabric signed off on the release - Leave it up to them to approve
  • Want to be sure all items have been addressed before releasing the report
  • A/I Dave will go to the maintainers of Fabric to get approval and then send an email notification to the TSC to get final sign off
  • No labels