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
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 .
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.
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.
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.
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 define 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.
PSRAMKUMAR will have the intial review w/c of the BB defined data core model in GitHub.
Decisions
The future development and key decisions sessions of the wave 1 & 2 specification should be moved to Confluence. Steve Conrad will provide a template for this to the BB Leads.