Thank you, Alice! Nice write-up.


Cheers,



Christopher Ferris

IBM Distinguished Engineer, CTO Open Technology

IBM Cloud, Open Technologies

email: chrisfer@...

twitter: @christo4ferris

blog: https://developer.ibm.com/opentech/author/chrisfer/

phone: +1 508 667 0402




-----hyperledger-tsc-bounces@... wrote: -----To: "hyperledger-tsc@..." <hyperledger-tsc@...>
From: Alice Ma via hyperledger-tsc
Sent by: hyperledger-tsc-bounces@...
Date: 05/19/2016 01:42PM
Subject: [Hyperledger Project TSC] Exit Criteria Discussion Notes from May 19 2016

Exit Criteria from Incubation Discussion – 19 May 2016

• Project must have cultivated a diverse set of contributing members
o One of the most important factors
o Ensure that membership is > 1
o 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.
o Some sections of the codebase are more important to cover than others (crypto, security)
o We need a yardstick to measure this beyond "we always need more (tests)"
o What's a reasonable % of test coverage?
- Hard to say because it's different at different levels:
• security stuff: upper 90's
• business logic: 5 lines of test per 10 000lines of code (?)
- Further discussion required
• Scalability
o Which dimensions?
o Is this idea related to scale of use in real world?
• Appropriateness of requirements met by MVP
o Concern: Given that running code wins, is there a risk in putting too many requirements?
- Programming practices of security world are difficult to do in an agile way BUT there's still value to the agile paradigm. When it comes to business logic, we could do better than Etherium (?) smart contracts (15 serious errors per 1000)
- HOWEVER: Contracts/chain code (except for samples) are not quite what we're doing
- STILL, some things need to be strong, so we do need a high bar (e.g. identity/IBM's new crypto system using keys in a new form)
• Project must have real world use
o Use by a small supply chain/something that is "real "in some fashion is a criteria for being mature
o Real problems: does the code fit into the regulatory requirement?
- Test ledgers perpetually running?
- Less rigorous definition
o 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 BUT ???
- Other projects had continually running test pads to verify cross-organization consistency: not a full-blown production systems
o 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?
o Should discuss this further outside of the call.
o Definition of "mature": is there a separate interpretation of maturity within the Hyperledger organization (vs the interpretation within other OS communities)
o 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
o 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)
o Does "mature" really mean "mature enough to rely on it in some fashion"?
o 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
- "Anchor points": both terms reference a project's participation in the final release of the code base, not in terms of maturity or use of the code IRL
o 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)
• Sufficient documentation
o Should be enough for anyone to test/deploy any of the modules. Documentation should illustrate test cases, demonstrate various test cases
• Input from Christopher Allen:
o We haven't had discussion on:
- Multiple identity system
- Pluggable architecture
- E.g.: Hyperledger would only have 1 "master" codebase, future iterations will have to reconcile with existing ones
o Does one version of a module need to be compatible with existing mature versions for it to be considered "mature"?

Other Concerns
• Slack channel: archived messages can't be seen
• Modes of communication/collaboration: slack, email, conference calls
o If we want to use slack, then maybe we should consider getting an enterprise version
o Todd and Brian to have a conversation about what we can do to fix
_______________________________________________
hyperledger-tsc mailing list
hyperledger-tsc@...
https://lists.hyperledger.org/mailman/listinfo/hyperledger-tsc