Is having a specific target release date needed? Yes, it is! We seem to be aligned on this based on the feedback in the Governance Committee call earlier this week
What core product use cases should we prioritize?
Wes - Include the 6 currently included in the catalog
Ramkumar - Definitely include the use cases from the HoA work. Focus on PPMIC and USCT
Ayush - EPR use case from Rwanda, Construction and e-Cabinet from Djibouti, overall likely to be less than 10
Steve - Include input from the G2P use cases
What building blocks can be included?
All of wave 1 and 2?
Ramkumar
Foundational - IM, registry, workflow, ID,
Functional - Registration, Payments
Sherman - The relationship between the foundational/infrastructure BBs and Functional is bi-directional and changes on either side may result in changes to both
When could we realistically create a v1.0 release?
Comments
Rachel - Have BB review the specs for other BBs
Nico - What is included in this “release”?
BB Specs for finished wave 1 and 2
Some set of Use Cases
Margus - Why not the playbook?
Steve - Include a list of products that are compliant (once that is defined) with the BB specs. As in a specific product version is compliant with this version of the BB spec
Ramkumar - Should be maintained separately from the BB
Nico - Why group BB versions into an overall release?
Wes - Outside perspective it’s helpful to have a single version number to identify (with multiple versioned components included in that overall release). From inside, it will help us focus getting our work to a publish-quality
Rachel - Having a release also will help products to achieve compliance to BBs. This is also true for the Implementation Playbook (with regards to training and supporting documents, etc). These don’t need to be released in sync, the targets are different
Sherman - BB are using a form of semver (Major.Minor.Internal):
Internal - Changes related to just the BB
Minor -
Major -
Ramkumar/Margus - Some changes (ie, in IM BB) may result in changes in many other BBs and might inform that a new global version is required
Meelis
The release should only include things that have been validated
We should concentrate on MVP-level, a lot will be learned (and required changes) once implementations are started
Reevaluate Required/Optional (dont be too strict), rename must/should or add if not existing
Why? To have the same clear wording for the importance of reqs in all specs
e.g. "Multiple instances of scheduler BB may be hosted with load balancing in high concurrency demand" In this case, is "may be" meant as "optional" or rather a suggestion?
Give requirements an abbreviations which can be referenced
Why1? To more easily state compliance
e.g. we can create an list based on these abbreviations to give suppliers for self-assessment
Why2? To make it easier to handle the optional requirements
e.g. "for use case X, you need the optional requirements Aw1,Eg1 and Fr3"
Check for errors and wrong formalities
e.g. Headings with no text underneath, headings wrong numbering, Version history in gitbook needed?...
Take up Architecture and Security BB again
Publish the compliance concept and process
Improvement Comments
Ramkumar - We have a template so let’s use and update that instead of creating anything new.