Todd Benzies <tbenzies@...>
Technical Steering Committee (TSC) Meeting
May 19, 2016 (7:00am - 8:30am PT)
Deutsche Boerse Group
Richard G. Brown
Welcoming Brian Behlendorf, Executive Director, Hyperledger Project
Action item review
Exit criteria discussion
Action Item Review
TSC representation policy draft (Chris Ferris)
Whitepaper draft by 5/18 then on 5/19 TSC agenda (Dave Voell)
Bishop to work with Binh, Sheehan, and Greg to get HIP busywork Exerciser integrated into fabric
Doodle poll for June (virtual) Hackathon (Todd Benzies)
Doodle poll for July Hackathon (west coast) (Todd Benzies)
Exit criteria doodle pool (Todd Benzies) -- can start discussion during TSC call
Requirements WG (Oleg Abdrashitov)
Architecture WG (Ram Jagadeesan)
Whitepaper WG (Dave Voell)
Whitepaper Draft v0.1 (published May 19, 2016)
Please provide feedback to the Whitepaper working group through our Feedback Form
Request for everyone, especially TSC members, to read through and add edits prior to this draft going to the Governing Board
Identity WG (Christopher Allen)
Minutes from May 18th meeting
Need more work in requirements and use cases around lifecycles of identities, will be working on some docs to share with those WGs
Variety of discussions around possible technologies being deployed elsewhere with real relevance
Selective disclosure and different approaches was a hot topic for the group
May need different identity services and determine what APIs would be needed
Tomorrow is big UN conference on digiital identity http://www.weboftrust.info/
Jeremy S: we came up with list of potential use cases and will be reaching out to Oleg to see how it maps in. As we getting a better sense of dimensions of layers of system -- helps to have a common language to separate out some of these things.
CI WG (Chris Ferris)
Gerrit has been stood up; need some more config and training and then a planned migration from Github to Gerrit
Jenkins is up; but still needs a small amount of confg, should be done early next week
If people want to help with CI, plenty of opportunity to volunteer
Exit Criteria Discussion [thank you to Alice Ma and Bill for the notes below!]
Project must have cultivated a diverse set of contributing members
One of the most important factors
Ensure that membership is > 1
Diversity includes diversity of usage, e.g.: companies that use the technology and servicing the technology. We shouldn't just measure the contributions, we need to take into account the types sizes of companies that can deploy solutions
Must demonstrate some threshold of test coverage.
Some sections of the codebase are more important to cover than others (crypto, security)
We need a yardstick to measure this beyond "we always need more (tests)"
What's a reasonable % of test coverage?
Appropriateness of requirements met by MVP
Project must have real world use
Use by a small supply chain/something that is "real "in some fashion is a criteria for being mature
Real problems: does the code fit into the regulatory requirement?
Refinement period is necessary for all OS projects:
Ledgers cannot be treated like a service package. Needs to be cross-autonomizationservice?
Can incubate DNS bind and understand how it works as a package
Other projects had continually running test pads to verify cross-organization consistency: not a full-blown production systems
May need to know whether or not it's "transaction-ready"
Has it been audited/blessed by security/crypto community
Has it been used by a regulator
Ensure that there's enough disclaimers so that there's no misunderstandings/legal trouble
What does "maturity" and "incubation" mean from a community perspective?
Should discuss this further outside of the call.
Definition of "mature": is there a separate interpretation of maturity within the Hyperledger organization (vs the interpretation within other OS communities)
Just because something is out of incubation doesn't mean it's not incubating anymore. It means that it's at its beginning, and that more tests and functionality can be added
Should there be a level in between "mature" and "incubating"? Or should this be handled by levels of release? (1.0, 2.0, 3.0, etc)
Does "mature" really mean "mature enough to rely on it in some fashion"?
Proposed definition of "incubation" and "maturity" – "maturity" means that we have agreed that this thing is something we're going to continue to support and develop
Input from someone (name?):
The "incubation" label is like "beta"
Considerations: Has this project/module proven capable of releases? People maintaining, debugging as necessary, security patches
Look to Apache incubator for how other OSF's do this (they don't require proof of production use)
Input from Christopher Allen:
Slack channel: archived messages can't be seen
Modes of communication/collaboration: slack, email, conference calls
If we want to use slack, then maybe we should consider getting an enterprise version
Todd and Brian to have a conversation about what we can do to fix
TSC representation policy draft by 5/26 (Chris Ferris)
Doodle poll for June (virtual) Hackathon
Doodle poll for July Hackathon (west coast)
Whitepaper Review on 5/26 call
Slack channel (Todd Benzies and Brian Behlendorf)
Exit Criteria Summary (Chris Ferris)
Senior Program Manager
The Linux Foundation
+1 (415) 412-0310 (m)