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

TECH-796: Define method to track relevant standards for each building block Done

Steve: The process for API changes

Where there are API changes, the process should be that we have to notify both the testing and sandbox teams so they are aware of changes that need to be made and then ensure that the swagger docs are updated. Create PR in the directory in the spec, so tests can be built and integrate any changes in the sandbox.

This will be documented in Confluence as:

1. Notify testing and sandbox teams of the changes

2. Ensure that OpenAPI documentation is updated in your spec so that testing and sandbox teams can use the new definition

Dominika - It was agreed that a good process might be to create a PR with the new change and do not merge it before tests and mocks are updated to make sure they are up to date, and part of a release.

Wes - The testing practically might lag a little bit. Testing is part of the release specifically because it relates to compliance.

If we are making changes to existing APIs from previous versions, we need to highlight that, so the people that reviewed the previous version know what changes are in the new version.

Taylor - we should consider using Keep a Changelog to track the changes made to the tests.

Status updates

Leads

30 minutes

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

Issues to be addressed for release are tracked here: https://govstack-global.atlassian.net/jira/software/c/projects/UX/issues/TECH-825

Wave 3 Specs

Wes - the narrative for wave 3 BB specs description sections are significantly different to the template in terms of the content. The Leads should move the content into the appropriate sections like the functional requirements or the key digital functionalities.

Testing team

July 7, 2023 API Testing

• Finalised tests review to ensure they align with the test template. There are few changes to made i.e., assertion of positive test or lack of content type in a format string. There is also inconsistency in the API between the BBs.

• Working on versioning and it will be finalised w/c Sep 11, 2023

• Completed the outreach communication steps and waiting for the final review from @Martin Karner . Also, waiting for @Ingmar Vali to review of the use cases.

• Started working on permit issuing UC, the team will be reviewing the test and make sure it is with minimal errors.

Sandbox Team

The team is discussing sandbox integration; how to connect the real application to example use cases.

Working on online building permit testing page to go through fire frame to get feedback.

Architecture Team

Reviewing the wave 3 building blocks specs.

In the process of reviewing the document that will guide implementers and governments on how to use GovStack.

Egypt deep dive debrief

@PSRAMKUMAR

15 minutes

BB leads and participants should compile key takeaways in this document: Egypt Deep Dive Takeaways

Open

Ramkumar - Egypt is willing to participate in the BB WG and contribute. We need to show them the value of GovStack, and map out how we will engage with them.

Wes - we should create issues for all of the different things that were identified (at Egypt deep dive) as things that can be improved for each of the building blocks in Jira for us to include in future roadmap.

Re. Egypt group looking to setup their own working group - we should figure out ways to incorporate groups that are interested in providing feedback into what we are doing in GovStack more holistically. We should not continue to involve people in isolation, the goal is to bring people into GovStack initiative and not create individual little divisions of work. Also, we should start to have conversations with groups that relate to systems rather than individual services and use cases. As an initiative, we need to figure out how to engage with external groups, and capitalise on the momentum that we have gained.

Martin - Egypt has agreed to engage with GovStack but they are expecting engagement in turn from GovStack.

Vasil - What are the expectations for Egypt team to participate in GovStack? Are they going to contribute to the specs or validate the specs? Are they going to contribute software that they have which will provide new specification opportunity to create something new or to fill in gaps that we have in use cases? We need to create a plan of involvement for the external partners into GovStack.

The Egypt team will not get involved in GovStack if we do not solve their problems either with advisory or with some product that we presented to them. One is the reasons why they do not want to onboard external products is that, they do not want an open source software because it lacks enterprise support unless GovStack is ready to provide this support.

Smita - We need to understand the challenges Egypt is facing and how we can build solution that is generic, and can also be used by other countries.

Kenya roadshow debrief

@Wes Brown

15 minutes

If there are similar takeaways from Kenya roadshow, we should create a Confluence document to track them. (Agenda moved to next week)

Requirement and progress for multi-step enrolment

@smita.selot

10 minutes

Open

Wes - Is the multi step enrolment a MOSIP process? re. specification, if MOSIP is the representative of what everybody is doing, then it is okay to capture only MOSIP. But is there are other approaches to the multi step enrolment, this approaches should be taken into consideration because our BBs are attended to be vendor neutral.

Smita - MOSIP process is being followed because they are the most compliant, but the team have also included the element of OCF specification, and looking into open crsv to see if there are things to take form there.

AOB