Agenda

Presenter

Duration

Discussion

• Review pending action items

• Risk register

@Esther Ogunjimi

 10 minutes

TECH-175: Technical Committee Action ItemsDone

TECH-278: All BB Leads to confirm if data model has been defined for respective BBs.In Progress

TECH-288: Review BB data core model in GithubIn Progress

TECH-324: Create GitBook instance for wave 3 BBsDone

Technical Risk Register

Wes - We may want to add a bit more detail in the description section so it is clear what is being requested/tasked.

Steve - To provide some context and the specific actions that is required. As best practice is to have description, a clear expected outcome and acceptance criteria.

Jake - as we are building momentum and we've done a lot of work, it's important that we can show this work; it's very hard to show and demonstrate progress to people who are not in the progress, if it's not visible

Specification release tasks

@Steve Conrad

15 minutes

TECH-206: Specifications Release v1.0In Review

• Driving towards spec release by the end of March and as part of the work, the product committee has done a thorough review of the different building block specifications. I did a run through of the specifications and created a confluence doc with the lists all of the proposed changes that need to be made to the building blocks in advance of that March release.

  • Jira backlog was created for these tasks and assigned to all wave 1& 2 BB Leads

  • all changes will be made in gitbook.

  • all BB Leads are requested to work on their specs over the next two weeks and hopefully we can close out.

  • the review process is that the product committee will have the final review over the specs

Wes - across most of the different sections that we have in the spec, it would be helpful, if the different building block leads could decide on what the structure of those sections should look like.

Because it will be confusing if one building block puts the requirements section using bulleted list, another has a table, another just has pros. It is helpful for us to agree on exactly how each one of those should look, and I don't think we should dictate that. The BB Leads are all in the best position to be able to decide that. But that's something that's a bit separate than the individual tickets because those are individual building block themselves. There are some cross cutting things that need to be decided.

• Welcome the tech writer @Valeria Tafoya

• Vijay - What is expected from the building block leads on the specifications? what is the technical writer going to do? Who is supposed to modify the document now with the comments?

• Ramkumar - there are two types of comments in the list of comments

  • comments which are about the content of the specifications.

  • there are comments regarding the format, layout of the specifications

The building block leads have to look into the content related questions regarding the formatting, layout and the presentation and make sure it is consistent and in uniform across the building blocks; that's where we need technical writer help to scan across the building blocks and We are putting things in the same look, feel, shape and quality.

Ramkumar - How do we qualify for publication?

Wes - The best place to ask questions and have specific discussions will be on the Jira Tasks themselves. Tag people so that they get notified

Satay - suggesting to harness the API specs as well as the Gherkin feature files to test the API specs so that it becomes a complete package.

Wes - once we do the publication of the specification, the links that are in that publication should remain consistent afterwards. Anything that is more like code, we should just link to it from the specification as long as we're linking to a specific non volatile repository.

Taylor - from the beginning the standard is actually open API specification 3.0 in the tag; the release for the building block, then gitbook can do something more presentable with that . There should be a checklist that shows open API specification 3.0 in the YAML rather than in JSON.

Rachel - The openapi specs are in the /api folder of the github repo and then gitbook can display that in a swagger-like UI automatically GitBook and editing of controlled documentation

Ramkumar - What do we do with the specs that are already in swagger?

Steve - we should be deprecating swagger and any API YAML files should be in our GitHub repositories.

Vijay - To what extent do payment BB WG have flexibility in terms of not having the same format as the overbuilding blocks.

Status update

BB Leads

@Ain Aaviksoo (Deactivated)

30 minutes

• scrum standup-style (what we did this week; plans for next week; blockers/pain points and open/unresolved questions?)

• Update on BB coordination

Consent BB

Last week

• Made progress with gherkin scenarios

• supporting with consent tender process

Next week

• Meeting with the representative from the Institute for Interoperability Studies

• Update on BB coordination BB Interaction Flow

It is important to consider that we are meeting not just the requirements of individual building blocks, but the overall principles.

Everyone is invited to be part of the practical output discussion Iabelled framework for workflow coordination.

• it was suggested to have a presentation by a government facing an architect, to describe what are the practical implementation principles - from INIS (Institute for Interoperability Studies)

Steve - is taking some of the technical recommendations and putting them into the nonfunctional requirements document. There is potentially a need for guidance at a higher level, which might not necessarily fit into the non functional requirements document, as part of the release we need to define a guidance document for government entities in selecting and using GovStack.

Jake - where we want to be as an initiative is to be able to link countries with the products. One of the main problems that many countries have is going through the product selection process and understanding what products are available for their use cases and their requirements.

it is important that we document and curate the catalog of these kind of generalised use cases and then correspond the specifications, the APIs that are being worked and the tests.

This framework would allow us to automate some comparisons of products that have APIs, and link it all the way back to the UCs.

Workflow BB

Last week

• Updated open API spec to match BPMN terminology

• Migrating to global test harness orb

• Waiting to finalise the new tests for five API that have real input and output formats

Next week

• Migrating to global test harness orb

• Re-writing tests harness for the API tests to be specific rather than generic

Who is taking on adapter development and when?

IM BB

Last week

• Participated in the BB interaction flow meeting

• Continuing with new functionality

• Working on testing second level testing

Next week

• Continuing with new functionality

• Working on testing second level testing

Payment BB

Last week

• No meeting this week

• Received the first draft of the G2P payment UC implementation with the API, currently being reviewed by Vijay, Satya and the MiFos team.

• The WG will continue discussion on some additional ICs on G2B and B2G.

Next week

• Two meetings next week

• Second draft of G2P payment UC will be circulated to the wider group

• Review Jira backlog and start working on spec release tickets

Sodevelo Team

Last week

• Working on the testing app, it will be presented at the testing meeting tomorrow.

• Finalized sequence configuration and work on information Mediator and identity APIs; awaiting review.

• Finalised gherkin file template, is to standardise the work to match the template

Next week

• Start working on USCT example implementation development

• Reviewing the test written to ensure it matches the gherkin file template

Taylor

• does BB Leads know any implementation of a mock server that takes an API spec as an input and returns a mock server as an output?

  • do all the building blocks have the mock server in place now?

GIS BB

Last week

• Working from finalising the scoping of the spec

• Identified two user journeys for two UCs;

  • how you know the response to incidents in case of emergency.

  • managing land information.

• Working on logical blueprint.

Pain point

• Having challenge with the nature of the geographic Information Services that can be provided through the GIS services. When it comes to understanding interaction with other building blocks is not really clear for us because what GIS service does is providing geographic information;

Next week

• Finalising the GIS services

UI/UX BB

Last week

• Developed a template for design system on Sigma

Next week

• Scoping mother and child UC and end to end user journey

Schedular BB

Last week

• Did gherkin for three APIs and one is tested

  • reducing the number of APIs as some redundancies was found

Next week

• Updating the spec with the recommended changes

• Translating APIs in swagger hub to yaml

Sandbox team

Last week

• Completed sprint 6

• Three work streams running concurrently;

  • working on front demo - UI work

  • infra tech building for sandbox - build up or deploy

  • requirement setting for integration project

• There billing book for candidates to integrate into sandbox - with potential to integrate into the sandbox UC

Next week

• Starting sprint 7

EPR (Extended Producer Responsibility) Use Case

@Steve Conrad @PSRAMKUMAR

15 minutes

https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/YLLEfCKTnmzAMDSDzJJH/product-use-case/env-1-extended-producer-responsibility-epr

• The country engagement teams have been working on a couple of specific use cases:

  • one in Rwanda EPR use case

  • from Djibouti, construction online construction permit use case.

These are tied to deliverables that we need to show, produce and deliver very quickly. We will prioritise the development of the example implementations and the APIs and spec definitions for these use cases.

Steve - what is the priority and what we should be focusing on first?

Wes - the priority right now is the unconditional social cash transfer use case, because it has gone through the review process in the product committee.

The ERP use case is still undergoing review. However, feedbacks are welcome but not doing much in terms of updating the specifications. Then, the construction permit UC will be next when the PC get context from the country teams.

The goal will be to get any specification updates that are required to support those use cases; those are the priority and ahead of the example implementation. PC will then hand the use case off to the sandbox team so that they can start to work on them.

Here is the Use Case roadmap - this will track the flow all the way from the country teams to the sandbox. The country teams will define the to-be user journeys and wireframes and identify building blocks that are needed; then they will hand it over to the product committee; then to TC to start to work on the example implementation step by step, and then to the sandbox team.

Tarek - The Construction Permit use case may be relevant to GIS BB given the facts that constructions are tight to locational sites, it would be interesting to learn more about this.

Meelis - Does BIM standards taken under review also in GIS WG?

Tarek - not for now.. we have been mainly focused on the "geographical" context, building on OGC standards.

USCT use case registration example definition

@PSRAMKUMAR

20 minutes

USCT https://app.gitbook.com/o/pxmRWOPoaU8fUAbbcrus/s/YLLEfCKTnmzAMDSDzJJH/product-use-case/inst-1-unconditional-social-cash-transfer

what is the input to this step and what are the outputs of this step to break this UC down?

Gap analysis will be conducted and documented where the gaps are and then we create JIRA tickets for the building block groups to address the required definitions.