Agenda

Presenter

Duration

Discussion

• Review pending action items

• Review 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

@PSRAMKUMAR will have intial review w/c Mar 13, 2023

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

TECH-324: Create GitBook instance for wave 3 BBsDone

• Technical Risk Register

Status update

BB Leads

@Dominika Bieńkowska (Deactivated) @Satyajit Suri

30 minutes

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

• Building Blocks

• Consent BB

  • Will complete spec v1.0 tasks Mar 3, 2023

  • In the process of completing the gherkin scenarios.

• Information mediator BB

  • Started with the review process yesterday

  • Set up security server instance for stand alone testing in the repo - will be showing the development team on how to use the instance.

  • In progress of designing a new API for registration of member applications and services - first draft will be ready w/c Mar 6, 2023.

• Registration and Digital Registries BB

  • Specification v1.0 release tasks will be completed by the end of this week.

  • Should future development chapter be included in the documentation?

  • Ramukumar - suggested to move content that are not specific to the specifications out into another document, and provide a link to where it is stored.

• Messaging BB

  • Dominika - Martin to send open API files with API lists to SolDevelo team to define messaging APIs.

• Schedular BB

  • Completed v1.0 spec release tasks

  • Reduced APIs to 22 to accelerate the testing process to qualify the APIs.

• Payment BB

  • Working on the v1.0 spec release tasks.

  • G2P APIs work is ongoing and should be ready in the next three weeks.

  • Collaborating with MIFOS on the implementation of the G2P use cases.

  • P2G payment implementation will commence next week.

• Tech writer

  • Working on current tasks in Jira.

  • Ramkumar - Valeria to help to homogenise the data models. Currently, some of the BBs have given a table to explain all the data element follow by a schema to show how the data elements are grouped. For any BB that either the table or the diagram is missing, Valeria is to create what is missing.

• UI/UX BB

  • moved away from developing design system specs

  • restructured work to fit into the specifications template

  • There is a section for standards and recommendations and another for suggested patterns for specific workflows

  • Will be contacting dormant team members. Calling for support on specific tasks as its currently Betty and Lawrence and they have very limited availability.

• GIS BB

  • completed the functionalities tasks

  • Will start working on APIs and the spec structure.

USCT use case definition

Currently working on the registration steps - created valid steps, the scenarios and end points. There are some uncertainties and some things will need to be specific.

The team will be defining the alternative causes and diagrams. Draft/working version of the example implementation of the USCT use case will be moved to GitBook eventually.

Ain - who will receive PR request submitted in GitBook?

Rachel - Any BB Lead can approve and merge change request in GitBook. Steve can merge PR for specification.

All change request should include a Jira issues number in the title of the change request, and assign to the relevant people.

Testing

API Testing Roadmap

GovStack Gherkin scenarios - user guide + template

• working on the testing app MVP.

• working on the gherkin file for test.

• updating and reviewing previous tests created for BBs.

• GovStack 1.0 publication

@Steve Conrad

25 minutes

• How to embed APIs in the specs

  • in each BB repositories, there should be a yaml or Jason that have open API definitions.

  • Alex - the source of truth is GitBook for repo, how will embedded APIs reflect in repo if inserted directly into GitBook?

  • Rachel - The GitBook only references the actual YAML file in the GitBook repo.

  • Wes - What is the implications of the URL used to generate those API endpoints? Is it going to pull every time you render the page?

    • if we are linking back to for instance, development version on GitHub, it is going to be pulling changes that may not actually be part of that version of the spec.

  • Steve - it is not going to rerender anytime there are updates but it will be tested for updating file.

  • Rachel - As part of the publishing process for new version number, the links must be updated to ensure they point to a particular version number.

• Format of the Workflows section for GS 1.0 publication

  • What is the distinction between the functional requirement section and workflow section?

  • What is section 4 for? Is it just a document, internal flows or is it cross building block flows? And if it is internal flows, how does this section differ from the functional requirements section?

  • Steve - suggested maybe the workflow section should be better labeled as internal workflows where a request comes in. Then, we should also find a place to put these kind of more generic capabilities or cross building block workflows. The process flow of how a BB interact with other BBs should be very visible.

  • Martin - the workflow section is also a standard workflow. This will be the core and standard workflow for external people.

1. The workflow session will be renamed as internal workflows. The template will be updated with outline descriptions. Link will be provided to an example cross building block workflow.

• Content/format issues in Jira

  • the BB content related tasks are the tasks stacked for the BB Leads in Jira, while the tech writer tasks are format oriented.

Testing app

@Damian Borowiecki (Deactivated)

10 minutes

• yaml vs json format 

  • We should agree on the format for all BBs open APIs for consistency.

  • Rachel - GitBook will work with either json or yaml.

  • Steve - we can convert back and forth.

• metadata for testing app.

  • the data can either be defined directly in the testing web application e.g, through the configuration, static variables etc or it can be added beforehand in the BB examples directory. It will be easier to maintain multiple candidate applications and avoid inconsistencies.

Retro

@Esther Ogunjimi

15 minutes

TC Retro 3 | EasyRetro