GovStack Release | Wes Brown | 30 min | Questions 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 Nico - Why group BB versions into an overall release? 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): 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
Suggestion for v1.0 improvements by Nico Lueck 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. This conversation is continuing on Friday at 14:00 UTC: https://teams.microsoft.com/l/meetup-join/19%3Ameeting_MWVlMTJmZmYtMGU1ZC00YmUzLWI3YTYtNjc1MzM2Mjk1ZTY4%40thread.v2/0?context={"Tid"%3A"23e464d7-04e6-4b87-913c-24bd89219fd3"%2C"Oid"%3A"4b55ace1-b300-4235-be65-0501afad7e10"} |