The future development and key decisions sessions of the wave 1 & 2 specification should be moved to Confluence. Link to the template
Status update
All BB Leads
35 minutes
Scrum standup-style (what we did this week; plans for next week; blockers/pain points and open/unresolved questions?)
Specification 1.0 publication
Information Mediator BB
Semi ready for management interface for Information Mediator.
Example of IM integration in test is created and posted in repo.
need to refer to architecture and non functional requirement for remarks - where are these document in GitBook format?
Rachel - the documents in the main specification in the development space.
Ramkumar - Beyond the testing of integration of IM BB with other BBs, we should focus on completing the API definitions and testing for IM as this is the most important piece connecting everything else.
Taylor - the next step for IM BB is to start using the test harness that has been developed by the SolDevelo team and making sure that it runs those tests automatically from the CI environment.
Workflow BB
Making progress with the specification v1.0 release tasks.
Taylor - need more clarity on the request to remove content from the architecture requirements.
Ramkumar - If the architecture specification is compliant to something in the architecture specification, there is no need for it to be written.
Wes - The intent is to note things that are different in the architecture requirements.
Payment BB
Making progress with the specification v1.0 tasks
Ramkumar - clarification on the sequence diagrams of workflow inside the BB specifications, this is meant to showcase the workflows that are internal to the BBs for the services that the BBs should orchestrate.
Scheduler BB
Recasting the API definitions in swagger
Written gherkin scripts for about six APIs
USCT use case definition
working on the registration step
Next step
the team will be defining the whole process of the example implementation development.
Will be defining the payment step
Wes - because these example implementations are the link between use cases, product use cases and the technical building blocks, there should be someone from the product team involved in the review to ensure the example implementation is accurately reflecting what the use case steps is intending to do.
Dominka - we need to discuss how exactly this review process should look like them and will be involved from each WG.
Testing
Finalise the first stage of the testing app. Now working on the resolve page of the app.
Working on improving the existing tests.
Starting the review process with ID BB
Tech writing update
@Valeria Tafoya
5 minutes
reviewing structure with the BB Leads
USCT use case
Extended Update from Sandbox Team
Gofore team @Heidi Kuum (Deactivated)@Meelis Zujev (Deactivated)@jarkkohyoty@Jonas Bergmeier
15 minutes
Intro (1min)
Bridge -> USCT Simulation + Technical Sandbox will become USCT MVP
Working on the simulations and had review session for the wireframe. The team will be having the payment simulation by the end of May.
Milestone - to have the sandbox as the building block integration environment available by the end of March.
Started working on toward the USCT MVP
Jake - the power of Gov Stack is in these reference builds. Anyone who is capable and technical could take it and then perhaps swap out a product or build upon it. What would be the appropriate packaging once we have gone through the whole process and we validated it? How are we going to preserve the diagram as a snapshot/reference implementation?
Wes - We may need to shift expectations slightly as there are some BBs that we may not really want to fully implement (in terms of a real software system) because of the complexity and cost (thinking of Payments BB)
The limited MVP is a good approach as it allows us to finish up the 1.0 publication so that the remaining BBs can be incorporated according to the real-world specs (and USCT use case, for that matter) after the sandbox team has designed, built and tested the foundational systems.
Taylor - Suggested to use the HAPI FHIR server implementation for "registries"? This would be a nice time to build an adaptor or two - . Adaptor = application that provides payload, protocol, and request instance transformation so that a given candidates API responds with the appropriate behaviours when called according to the BB specification's openAPI spec.
Ramkumar - the adaptor concept is being discussed in the information mediator BB working group. it will be helpful if someone from sandbox team also joins in to nail down the minimum requirements in sync with practical requirements of usct.
Capacity Development on BB - Request by MCIT Egypt
@Nico Lueck
10 minutes
redesigning the citizen services
Wes - Can this be done after the 1.0 publication and based on that version?
Jake - is there a scoping document? and what is the aim/goal? Are they trying to build their own sandbox, for example?
Wes - The BB needs to include which version of the BB is that is being tested. Having a BB-focused and Software-focused view would be helpful
Taylor - If some DPG owner submits their application for compliance testing (opening a PR against the spec repo) then they already know what they're doing. And suggested it can be publicised and knowing that OpenFn is (as of a couple of weeks ago b/c of the change from generic to specific) currently 0% compliant! Mock SHOULD always have 100% compliance!
Jake - this should be linked to and from the govstack.global website and the Exchange, which is currently being rebranded (existing Catalog is here for those that haven't seen it: ). (the Exchange is label-able, i.e. we will have a GovStack branded version).
Nico - The reference from his perspective will include an ideal UC. There are some fundamental work that need to be done as the concept of an adapter is not yet clear
