• BB Leads to set up the examples with the demo application - if they do not have DPG identified. Demo application is required to expose the endpoint. (Demo mock example) Satyajit Suri and all BB Leads
• Backup the data in digital ocean - Aleksander Reitsakas and Taylor Downs to support in overseeing
• All BB leads yet to, should write their test plan and send to Taylor Downs and PSRAMKUMAR (architecture team) to review and sign off. Pending with Satyajit Suri
• Account mapper keeps the ID with payment discussion will be planned with Jaume (IDV BB) to better understand the API - Mauree, Venkatesen
• Have focus discussion on role based access control for consent BB and feedback to TC - Ain Aaviksoo (Deactivated)

Agenda

Presenter

Duration

Discussion

• Pending action items review

• Risk register

Esther Ogunjimi

5 minutes

Technical Risk Register

• There will be dedicated digital ocean account and access will be provided to anyone that wants to spin-up demo

• Steve will be consulted if anyone wants to make use of digital ocean account

Jake - Managing AWS is easier with the scrip

BB cook book

PSRAMKUMAR

20 minutes

Govstack Building Block Cookbook

• The cook book is the first draft with expanded scope of activities.

• Wave3 will be able to make reference to this document for some of their expectations, but it can be extended across other GS groups.

• BB groups will make use of the cookbook to build up their Jira backlog.

Taylor

• Develop BB prototype - need to be reworded and out in the right context - so people do not think they are building software that will be use by government.

• Position of open API might be late as shown in the document for the stage it suppose to happen. As part of the lesson learnt from working in previous wave; the actual API spec for the BB was part of the specification - it might be useful to encourage people to publish soft specification that do not have API associated with them? Then getting granular about what is API later and the functionality being defined might lead to issues later

Ramkumar

We can publish the specs later as suggested by Taylor but there could be two stages of review; first to review the rest of the spec (product related TAC review) and the second to focus solely on API (technical TAC review)

Taylor

When publishing a spec, there should be some very experienced business users who are familiar with the problems in the space - to determine if the spec solves the business problems and there should also be some very experienced technical people - who could review the spec to know if it is implementable

There must be very experienced business and technical people that need to look into the specs before publishing.

Jake

People might not be providing feedback on API might be because it is at the low level. There need to be varying degrees of explanation for what the BB does

At the product level, there is need to verify at the high level, we need to highlight the responsibilities of the BBs and in natural language, what they do - the domain need to be described better and not to over indexed on some of the API details

Ramkumar

There are two end goals; first, to leave it at the specification level

Secondly, manifestation of a demo - for this API is required

Jake

We have different consumers and we need to close the gaps. All BB need to look at the SDG Digital Investment Framework to verify if the use cases, identify if any UC is missing and can start with UC from their domain

Wes

PC help define the UCs

Jaume

Working more on prototyping the API to see how it works.

Steve

The specs should have what the higher level business need and the technical user. There should be a similar process developed for the PC to show what the development of the UC looks like and linking to the BB process.

• Jira structure

• post-partum demo

Steve Conrad

15 minutes

• Assessing where the BB are in the process that Ramkumar has outlined, mapping it into roadmap for various BB WG and identifying the next steps - timelines, etc

• Waves 1&2 are at the point of defining open API specification, the more detailed specifications and setting up the test harness.

• Set up project for different BB WGs and map out various epics to show the epics that require domain experts of the WG and developers.

• Suggested using story-point to size up task for estimation (S(1), M(3), L(5), XL(8)) and get the velocity - how much work we are able to get done for each sprint.

• TC meetings might be replaced with sprint planning meetings

Jake

The only way to secure more resources to support the BB WGs is when we can show metric through sizing the tickets to get some duration.

Each BB should set their own sprints.

Update

BB Leads

35 minutes

Workflow BB

• Sorting out some internal blocker.

Consent BB

• Have a grasp of the type of API required.

• Started delivering on mock test script

• Team have aligned better on the mother and child UC and the description of API matching specific steps in the UC ONGOING

ID BB

• Released the first draft of ID mapping - to describe what is expected from the feature and have sector identifier for payment. Will launch the ID mapping next week.

• ID integration test with Digital registries - Integration of MOSIP plus the gateway to translate into openID connect

• Research on G2P connect for GS - GS can provide DPI that will go to the government

API test & Integration update

Satyajit Suri

15 minutes

PC read out

Wes Brown

5 minutes

• Defined UCs to work with in the sandbox - the G2P UC and the UC from Djibouti country implementation

• UC template will be built from the two UC areas

Taylor

Important to have healthy overlap with the PC &TC and not a redundant overlap

AOB

• Terminology

• YouTube

PSRAMKUMAR