Mojaloop Community Central

Michael Richards
Michael Richards

Posted on


DA Meeting Minutes 2023-07-19


Minutes of DA Meeting 2023-07-12





  • Report on actions from last meeting
    • SK: Go ahead with moving the Alias oracle to a new public repository
  • Further discussion on Issue 96: Clarifying Mojaloop release contents (SK)
  • Closing outstanding issues (All)
  • AOB


  • Actions from previous meeting
    • Repository will be created today
  • Issue 96: SK
    • This is an initial draft for discussion
    • TD: add acceptance criteria to conditions for release. SK: agreed
    • TD: is Finance Portal part of core, because that's deployed via IAC but not by MiniLoop? SK, no: so it's not part of the release.
    • PM: the question of what the core product is is a really important question. Core team needs to be testing and validating non-core elements to ensure they integrate properly with core.
    • SK: This is more about defining the processes. Product Council should be defining the artefacts to be packaged with the core product.
    • MR: should MiniLoop deploy Finance Portal? TD, no real value add in adding it, because in vNext the Finance Portal will be included as part of core.
    • TD: we need to flag the testing of non-core things.
    • TD: can we ensure that IAC is up to date at all times?
    • SK: IAC extends to testing with the latest component releases. TD: we should include that in the criteria for the release doc. SK: Think it's there, but will check.
    • PSB: Point 2.1, we should qualify whether we use Agile or not. Conflict between Agile and fixed timetable. SK: timetable says we should go with what we have. JB: Agile said you should have something shippable at the end of every sprint. Document says we're going to define packages of functionality. PSB: in reality features get frozen, because team is focused on delivery. JB: we exist to service our adopters, not our developers. So we need to be able to publish our release plans.
    • MR: the point about this is to reduce to a minimum the time this release process takes, so that we get as much functionality as possible...
    • TD: work should target both the existing codebase and the new codebase. JB: we will ensure that we test both, and that we have comparable performance numbers for both versions.
    • JB: workstreams should already have in their minds the need for separation of concerns and ensure that their work is applicable in the vNext world.
    • PSB: vNext team does not have sufficient visibility of feature development. Example: merchant payment - is this being addressed in relation to vNext? JB: who has the responsibility for finding out what needs to be done? vNext expects push, everyone expects pull...
    • MR: we should align with the reference architecture. PSB: what are the big chunks of functionality being added? PM: product council and community portal. PSB: is it OK to talk to the workstreams and align with vNext? MR - should align with reference architecture.
    • SK: as long as they follow the API specification, what difference does it make?
    • TD: should we evaluate the existing core against RA? MR: we will not modify existing core, but new features should be aligned with the reference architecture even if they are for core. PSB: we can still make tactical decisions not to align with RA.
    • SK: maybe this should be excluded from this discussion.


  • SK: ensure that document is clear about testing with latest component releases.
  • SK: add to Mojaloop documentation to be clearer about what support we offer and how to obtain it.

Top comments (0)