November 3, 2022 Technical Committee Meeting Notes
Attendees
@Wes Brown
@Esther Ogunjimi
@Steve Conrad
@Ain Aaviksoo (Deactivated)
@PSRAMKUMAR
@Jaume DUBOIS
@Taylor Downs
@Jake Watson
@Rachel Lawson (Unlicensed)
@nashcroft (Unlicensed)
Apologies
@Aleksander Reitsakas
@Satyajit Suri
Previous Action Items
Action Item |
---|
BB Leads to set up the examples with the demo application - if they do not have DPG identified. Demo application is required to expose the endpoint. (Demo mock example) @Satyajit Suri and all BB Leads Backup the data in digital ocean - @Aleksander Reitsakas and @Taylor Downs to support in overseeing All BB leads yet to, should write their test plan and send to @Taylor Downs and @PSRAMKUMAR (architecture team) to review and sign off. Pending with @Satyajit Suri Account mapper keeps the ID with payment discussion will be planned with Jaume (IDV BB) to better understand the API - @Mauree, Venkatesen Have focus discussion on role based access control for consent BB and feedback to TC - @Ain Aaviksoo (Deactivated) |
Meeting Notes
Agenda | Presenter | Duration | Discussion |
| @Esther Ogunjimi | 5 minutes |
Jake - Managing AWS is easier with the scrip |
BB cook book | @PSRAMKUMAR | 20 minutes | Govstack Building Block Cookbook
Taylor
Ramkumar We can publish the specs later as suggested by Taylor but there could be two stages of review; first to review the rest of the spec (product related TAC review) and the second to focus solely on API (technical TAC review) Taylor When publishing a spec, there should be some very experienced business users who are familiar with the problems in the space - to determine if the spec solves the business problems and there should also be some very experienced technical people - who could review the spec to know if it is implementable There must be very experienced business and technical people that need to look into the specs before publishing. Jake People might not be providing feedback on API might be because it is at the low level. There need to be varying degrees of explanation for what the BB does At the product level, there is need to verify at the high level, we need to highlight the responsibilities of the BBs and in natural language, what they do - the domain need to be described better and not to over indexed on some of the API details
Ramkumar There are two end goals; first, to leave it at the specification level Secondly, manifestation of a demo - for this API is required
Jake We have different consumers and we need to close the gaps. All BB need to look at the SDG Digital Investment Framework to verify if the use cases, identify if any UC is missing and can start with UC from their domain Wes PC help define the UCs
Jaume Working more on prototyping the API to see how it works.
Steve The specs should have what the higher level business need and the technical user. There should be a similar process developed for the PC to show what the development of the UC looks like and linking to the BB process. |
| @Steve Conrad | 15 minutes |
Jake The only way to secure more resources to support the BB WGs is when we can show metric through sizing the tickets to get some duration. Each BB should set their own sprints. |
Update | BB Leads | 35 minutes | Workflow BB
Consent BB
ID BB
|
API test & Integration update | @Satyajit Suri | 15 minutes |
|
PC read out | @Wes Brown | 5 minutes |
Taylor Important to have healthy overlap with the PC &TC and not a redundant overlap |
AOB
| @PSRAMKUMAR |
|
|
Meeting Recording
Action Items
Decision
- No posting of TC meeting recording on YouTube