Page Comparison

Item

Presenter

Time

Notes

Review Action Items

Wes Brown

5 min

Sandbox Use Cases

Wes Brown

5 min

Feedback on Unconditional Social Cash Transfer

Looking for documentation about the Djibouti Construction/Online Building Plan use case

GovStack Release

Wes Brown

15 30 min

Questions

1. Is having a specific target release date needed?

   1. Yolanda: We are already “released” and being used

   2. Jaume: Releasing focuses us around specific goals

   3. Nico: Version 1.0 could be APIs “complete”, consistent, well formatted. Would vote for having a specific release target

   4. Yolanda: Wave 3 BB are expected to be complete by March/April 2023. Version 2 of wave 1 and 2 should be completed in 2023 as well. We also need to provide concrete feedback to the BB leads.

   5. Rachel: Historical context - previous BB spec versions were tagged as version 1.0 but when this was reviewed back in Spring/Summer 2022 it was decided that the specs were not at a 1.0 level and so a version 0.9 was used instead

2. What core product use cases should we prioritize?

3. What building blocks can be included?

4. When could we realistically create a v1.0 release?

Comments

1. Yes, it is! We seem to be aligned on this based on the feedback in the Governance Committee call earlier this week

2. What core product use cases should we prioritize?

   1. Wes - Include the 6 currently included in the catalog

   2. Ramkumar - Definitely include the use cases from the HoA work. Focus on PPMIC and USCT

   3. Ayush - EPR use case from Rwanda, Construction and e-Cabinet from Djibouti, overall likely to be less than 10

   4. Steve - Include input from the G2P use cases

3. What building blocks can be included?

   1. All of wave 1 and 2?

   2. Ramkumar

      1. Foundational - IM, registry, workflow, ID,

      2. Functional - Registration, Payments

   3. Sherman - The relationship between the foundational/infrastructure BBs and Functional is bi-directional and changes on either side may result in changes to both

4. 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?

    • Wes - This seems like a separate discussion that is related to the relationship of the Implementation Playbook to the Framework, let’s just focus on the framework-related topic for now

    • Margus - Would like it noted that he disagrees with the separation of the playbook at framework

  • 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

Suggestion for v1.0 improvements by Nico Lueck

1. Reevaluate Required/Optional (dont be too strict), rename must/should or add if not existing

   1. Why? To have the same clear wording for the importance of reqs in all specs

   2. 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?

2. Give requirements an abbreviations which can be referenced

   1. Why1? To more easily state compliance

   2. e.g. we can create an list based on these abbreviations to give suppliers for self-assessment

   3. Why2? To make it easier to handle the optional requirements

   4. e.g. "for use case X, you need the optional requirements Aw1,Eg1 and Fr3"

3. Check for errors and wrong formalities

   1. e.g. Headings with no text underneath, headings wrong numbering, Version history in gitbook needed?...

4. Take up Architecture and Security BB again

5. 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"}

Conclusions

1. Scope: Use Cases, BB specifications, potentially “compliant” Applications

2. Use Cases: 6 Use Cases from Product Catalog, Rwanda EPR, and HoA Use Cases. Expected to be less than 15 in total

3. Building Blocks: All Wave 1 & 2. Some concern about BBs that are not functionally complete (Identity, Payments, Others?)

EPR Use Case Design

Martinez, Yolanda (Deactivated)

5 min

Org Chart

Nico Lueck

5 min

Discuss Compliance Process

Wes Brown

15 min

•  Wes Brown Create initial draft of GovStack compliance process, incorporating previous work and current feedback