- Paul Baker firstname.lastname@example.org (PB)
- Pedro Barreto email@example.com (PSB)
- Miguel de Barros firstname.lastname@example.org (MdB)
- Jason Bruwer email@example.com (JB)
- James Bush firstname.lastname@example.org (JB)
- Tom Daly email@example.com (TD)
- Johann Foley firstname.lastname@example.org (JF)
- Sam Kummary email@example.com (SK)
- Paul Makin firstname.lastname@example.org (PM)
- Michael Richards Michael.Richards@infitx.com (MR) (Chair)
- Jane Stroucken Jane.Stroucken@infitx.com (JS)
- Aung Thaw Aye AungThaw.Aye@thitsaworks.com AT
- Greg McCormick email@example.com (GM)
- Justus Ortlepp firstname.lastname@example.org (JO)
- 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)
- 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.