2017 12 14 TSC Meeting

Owned by Ry Jones
Oct 01, 2019
2 min read

Hyperledger Project

Technical Steering Committee (TSC) Meeting

No recording. 

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

TSC Members

Arnaud Le Hors

Yes

Baohua Yang

Yes

Binh Nguyen

No

Christopher Ferris

No

Dan Middleton

Yes

Greg Haskins

No

Hart Montgomery

Yes

Jonathan Levi

No

Kelly Olson

Yes

Mic Bowman

Yes

Nathan George

Yes

DID NOT REACH QUORUM

Resources:


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