Agenda

Presenter

Duration

Discussion

Review pending action items

 @Esther Ogunjimi

 10 minutes

TECH-654: Updates based on technical reviewDone

TECH-670: Candidate ProductsDone

TECH-742: TC Action Items - From 08.06.2023In Progress

@Taylor Downs is happy to support any BB Lead struggling to find candidate products, reach out to him.

Status update

All Leads

35 minutes

Roadmap - https://govstack-global.atlassian.net/jira/plans/reports/6EFAz

V1.0 Feedback

Steve - Are we thinking about any review process or reaching out to people for feedback outside of Govstack? Or are we just waiting for the asynchronous feedback that comes through the feedback forms?

Ramkumar - there is no plan for TAC review for v1.0, just the asynchronous feedback.

USCT Use Case

• Working on data verification

The next priority Use Case will be Online Construction Permit Use Case

Testing

• Started integrating OpenIMIS

• Will be discussing mapping, adaptors, and application

• Improved ID BB testing and awaiting review for all the changes

• Will be meeting with Consent BB

• Working on gherkin file template

Sandbox

• Concluding the first real developing sprint - to improve technical setup

• Preparing the simulation to be handed over to the TC

Building Blocks

Wes - have some significant concerns about where we are with all of the wave 3 building blocks. Look through what we have in JIRA, there is not a single BB that has any task that is marked as finished. There is only one BB that has some level of actual progress which is the GIS BB. The idea that all the wave 3 are going to be ready with something to review by the end of the month seems very optimistic if these groups cannot go in and update Jira for us to get a clear perspective on where they are and what they are doing. We are not getting any kind of visibility into where the wave 3 BBs are.

• UI/UX BB

  • Met with registration building block for feedback and input

  • Presented the UI/UX working group's work at a Creative Bureaucracy Festival meetup in Berlin and there are people who are keen to get involved as well as raising awareness with organisations like Apolitical

  • Continue to work through patterns and restructuring the specs

  • Will be working with Tech Writer to review the spec

Satya - With respect to the BB providers that ITU has contracted, there is a requirement that when GS provides its UI related requirements, the BB provider should customise based on those UI guidelines and requirements. Currently, Technofort is almost 70% complete with their work. How soon can we start getting some UI guidelines for Technofort to adapt their UIs to GS guidelines? To create the alignment of the UI and avoid this piece of work being missed before the contract end date.

Ramkumar - UX team is working with specific building blocks to see their requirements as examples of patterns that should come out but they have no mandate to do UI requirements for a specific BB. That should be done between the BB and the vendor

Jaume - The contractor is to deliver the implementation of specification and not on a schedule. The contractor needs to implement at our pace taking into consideration most Leads are part time.

• Registrations and Digital Registries:

  • MOSIP+ UNCTAD's eRegistrations pilot ok. Some additional functionalities are needed in eRegistrations to make anonymous onboarding in MOSIP system.

• ID BB

Started discussion on ID API onboarding with the idea to build an ornament that is fully independent from the ID BB

Have intention to prototype the integration of onboarding.

The feedbacks received from the initial version from 2022 of the GS documentation for ID BB has been lost when the BB was moved including the defined overall scope. This will be resolved by reintroduction ID BB vision in the GitBook

Taylor - We want software that "does lots of things". But we want requirements that DON'T "require lots of things" but, at the same time, require "just enough" that people can build things that work together.

Steve - how do we acknowledge the complexity and the detail that is needed in an implementation? And, do we need, an overall intro to GS? For instance, here are some of the the core principles that we are, we've embraced as a consortium and here's what you will expect to see in a specification.

All contents that got lost will be part of September release.

Jaume - We probably do not need to change to the documentation (structure) but we can leverage existing structure and find a place to restore those things that have been lost.

• Consent BB

  • Working on specification version 2.0 consent delegation.

  • Created a page for frequently asked questions. Sandbox will decide which of those questions will develop into actual specification. Which of them we will resolve just by explanations and adding them somewhere in the documentation of how to make use of consent.

  • @Benjamin Balder Bach is doing a great work with the testing team

• IM BB

  • Finalised PubSub discussion in the Architecture group

Taylor - If someone who is implementing a GovStack style, a whole of government digital systems approach. If they want to use PubSub, how can they use PubSub in a normal industry standard way but make sure that implementation of PubSub still fits with the broader GS model.

It is not designing a PubSub system, but we're trying to show really clearly how PubSub standards could be implemented in a way that works with the whole mental model of GovStack.

Ramkumar - are there any changes from version one that need to be included in our definition of the terminologies in the IM spec?

Alek - We need to make changes in API definition

• Payment BB

Working with MiFos to complete API development for G2P payment and P2G payment. There is a new version for G2P payment for the report on account mapper, G2P bug disbursement process and for voucher management. Shared the APIs with G2PConnect to get their feedback, and additional changes will be made to the APIs based on the feedbacks.

The interface that would be exposed to beneficiaries for them to enter their financial information in the mapper directly was part of the items that were discussed - how the APIs for the user interface would look like. This will be documented in the account paper technical report.

It was raised that maybe there should be a similar mechanism for all the building blocks also to use the user interface that is provided by registration. This will be taken onboard by MiFos

WalwE NEED k Through recent version of compliance concept

@Nico Lueck

15 minutes

Newest version: Software Compliance Concept

New annexes:

Steps to check compliance against a GovStack API spec

Software Provider Guide

Evaluations in progress: DIGIT Workflow, Ukraine PoR Registry, OpenIMIS, New: RapidPro Messaging

Next Steps:

1. Create Confluence Template

2. Release Test Harness

3. Adapt Impact Exchange Platform

Uwe - might want to prefix the sub-pages of a tool with e.g. the name of the tool as you can only use a page-name once

• GovStack UI

• Cross building block integration

@Jaume DUBOIS

15 minutes