September 7, 2023 Technical Committee Meeting Note
Attendees
@Meelis Zujev (Deactivated) @smita.selot @Ain Aaviksoo @Damian Borowiecki (Deactivated) @David Higgins @Dominika Bieńkowska (Deactivated) @Ingmar Vali @Kibuuka, Arnold @Martin Karner @Paweł Gesek @Rachel Lawson (Unlicensed) @PSRAMKUMAR @Steve Conrad @Taylor Downs Trev Harmon @Vasil Kolev @Wes Brown
Agenda | Presenter | Duration | Discussion |
Review pending action items | @Esther Ogunjimi | 10 minutes
| https://govstack-global.atlassian.net/browse/TECH-654 https://govstack-global.atlassian.net/browse/TECH-670 https://govstack-global.atlassian.net/browse/TECH-742 https://govstack-global.atlassian.net/browse/TECH-796
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:
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 https://keepachangelog.com/en/1.1.0/ 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
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
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 | 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 |
|
|
|