All,

In the event formatting is lost in email, please email me for a Word version if you would like to have it.

Disclaimer:  This paper is meant for discussion within the Exit Criteria Group on a use, do not use or partial use basis.  The letters A-D and numbers 1-4 can be further defined and expanded or contracted as deemed appropriate by the group. This simplified idea is not meant to impugn any work thus far completed.     

A challenge of HLP life cycle graduation criteria from incubation to mature (stable) to deprecated is assigning symmetric or common standards in codebase development across applications written to serve diverse sectors and functions.  This paper is a simplified attempt to utilize a Use Case vs. Function matrix to arrive at a more asymmetric requirement rating for application specific exit/graduation criteria.

 No one knows or will know an application better than its maintainers.  That said, the TSC must have a scheme of metrics by which it reviews projects submitted for incubation and graduation to mature phase and beyond. 

 Application initial maintainers can assign an alphanumeric designator to use case and performance information based on their initial intended use case function of the application and the level of performance complexity required of a “stable” codebase for that particular application deployment.  Applications under such a scheme would progress from 0.5-developer preview to 1.0-production deployment (and subsequent releases beyond 1.0) until innovation/disruption has ceased.

 A number from 1 to 4 is assigned reflecting the level of required reliability/complexity of code for graduation from a cycle stage.  The number 1 would represent the highest degree of required reliability as it pertains to any of the following as an example:

o    Initial stated scope and intent of maintainers (projects may naturally change direction as they develop)

o    Level of regulation scrutinizing real world deployment of the application

o    Scalability and speed requirement

o    Ability to access and troubleshoot (ex: IoT manufacture, transport, troubleshoot remotely, etc.)

o    Specified least number of critical errors per ‘x’ lines of code (Business Logic maybe 5 lines per 1,000 result in critical error?)

o    What level of security is required?

o    Will the application function handle personal identifiable or corporate confidential information?

The initial maintainer assigned number designation of 1 to 4 is then coupled with a letter from A to D.      

RATING SCHEME EXPLAINED

Complexity/Reliability ratings range from "complex and reliable" (1) to "stable" (4) as shown in the table below. 

The scale of A-D indicates the initial maintainer assigned use case such as supply chain, health records, counterfeit drugs, IoT, Music Publishing, etc.  see; https://github.com/hyperledger/hyperledger/wiki/Use-Cases     The highest degree of expected performance of an application is entered as a "1".  The lowest rating of "4" means that the expected application performance is considered adequate for the function for which it is used or deployed.   

Application rating scheme examples:

1A            an application written to function in healthcare records where a database of patient information, insurance claims, etc. is pulled from external sources.

4D        an application written to function in supply chain where non-sensitive items are entered and tracked from warehouse to final destination.  To further explain the supply chain example; tracking a shipment of plywood from East Texas to Florida should require far less complexity and function than shipping blood from Europe to Africa or Zika drugs to South America.

Cheers,

Bill