app-platform-minimal - foundational/core stuff which is always needed
app-platform-complete - everything else, aside from edge modules
app-edge-complete - the edge modules
The naming of these is a little unfortunate - the word "platform" probably shouldn't be present in any of these.
These are based on the (pre-)poppy versions of modules, I believe from around the time Poppy Bugfest began. They will be updated to the Poppy GA versions of modules at some point.
The goal here was to group the modules into smaller chunks while still maintaining composability, i.e. allowing for some applications to be optional, as opposed to all applications always being required.
These groupings prioritized dependencies and composability over logical/business boundaries.
It's likely that these groupings make very little sense to non-technical audiences.
These are based off the Orchid SP6 versions of modules.
The "aspirational" or ideal set of applications/module groupings have not been formed yet, but a reasonable starting point might be the analysis Vince B. did a couple years ago and shared with the community:
Discussion of council questions
Did not discuss today
Discussion of app grouping spreadsheet
Kristen walked through the spreadsheet Vince created that she updated:
Vince's original mark up is still in the spreadsheet
Based on team responsibility matrix
Vince used Domain, App, Parent
Team information changes over time, as does the PO
New modules since Vince did this, added as they were on the module responsibility matrix
Vince did in functionality way, or little icon in the UI App icon in the UI
What SIG has been working on it? Best guess on SIG
Also tried to look at development funding, who is the team?
Community vs EBSCO not a helpful dichotomy but has been talked about that Proko had been the "community team"
Information from the wiki about what kind of module it is
For the modules that weren't there when vince was doing them, added
Domain vs App
SIG. might not be one to one
information from. the scope criteria group as well
charlotte will update the PO information
Kirsten on steps to future state:
what is product
what needs to be in it
then what does it mean when apps don't fit
technical dependencies
Craig on backwards compatibility:
maintain backward compatibility
proxying the requests to okapi to create, register, etc with okapi
things behind the scenes could still be deployed in the legacy way
