2024-07-24 Formalization Working Group Meeting notes

Date

https://openlibraryfoundation.zoom.us/j/88432586375

Recording: https://prod-zoom-recordings-openlibraryfoundation-org.s3.amazonaws.com/866a9f09-8201-46c5-860d-b98d5e6af78c%2Fshared_screen_with_speaker_view.mp4

Attendees: 


Discussion items

TimeItemWhoNotes
50minUpdates on RFCs, PoC, etcCraig, others



Current projectsAll
  • Wayne Schneider can generate a dependency graph from Okapi, possibly by area
    • Here are the graphs:

  

    • Okapi raml allows generating some visualizations
    • Worked from Q CSP 1 list of modules
    • Can fake out okapi to generate graph of modules even if they aren't installed to get the graph
    • Q full graph is overwhelming!
    • built an install file of what okapi thinks you need to run UI and users module by telling okapi wanted to enable users module with simulate=true then okapi will respond with list of what it thinks that module needs based on module descriptors
    • pinned snapshots to the Q version to get list of requirements and added in stripes core and stripes smart components
    • okapi doesn't perfectly portray the NPM requirements, have to know
    • minimal system of stripes with users a bit less overwhelming
      • surprises: calendar, batch print, circulation, fees fine, etc
    • add in inventory and it gets a few more things, surprises: SRM, entities links
    • add in ERM, minor surprises as well
    • would want to look at minimum graph and start chopping out what shouldn't be there, and move on to other areas
    • only shows documented dependencies, bugs do get filed for those
    • is there anything in this that tells us no we can't enact the draft in the spreadsheet?
    • is there a way to work through some of these that seem especially off?
    • the scale of the challenge to actually have loosely coupled applications
    • are there algorithms to help identify the work
      • only analysis but not the work
    • find part of the system that mostly lives on its own and start from there, ie lowest hanging fruit not inventory or circulation
    • maybe guidance for new things? might not know yet what the guidance would be, having to do the low hanging fruit first to figure out what is possible
    • some decoupling impossible right now
    • some things all apps depend on
    • try and build rigorous minimal platform and then add, leaving off the big things until later, then work from edges in on minimal
    • previously minimal chopped things out smaller to make it seem smaller, eventually every approach hits the constraint around config options vs testing things actually work
    • community compromise on testing only one (or two) configs which is why missing deps don't matter because no one installs stuff indepdently
    • testing and config constraints in the community
    • dev rancher envs leads to long lasting branches, hosted env build breaks in part because of this
    • number of configs being tested separately are probably in high single digits but no one testing subsets with subsets
    • can eureka handle what is in the spreadsheet?
      • it depends. can compose apps however you like as long as deps are defined accurately but it means you have to enable all apps in one go and then behind the scenes okapi/eureka makes sure everything comes online
      • grouping in applications but still a monolith in the background doesn't really help
      • is there benefit in trying to implement grouping and seeing where we need to create more independence? does it give edges? or is it better to start with monolith and do the chipping?
    • need to define applications is both technical and functional, from technical perspective it is hard to decompose right now so maybe we need to punt on technical and just go on functional point of view
    • spreadsheet is aspirational
      • may be used as reference but folks making decisions are on the development teams
      • actual decomp has to be done by teams
    • what should this group try and grasp?
    • once the work starts will the group be able to influence at all?
    • ok for this group to present aspirational
    • community seems to want to have a say
    • iteration on mega applications over time, which aspirational model can lend a goal to
  • Initial grouping spreadsheet: https://docs.google.com/spreadsheets/d/1a2b1nxnKk6wcZnY2OtsG0kFa4r4UJe-WpuAg2CUEqjI/edit?gid=1717710204#gid=1717710204
  • WolfCon planning
  • Tracking TC/Sysops work
  • Holding for now:




Action items

  • Type your task here. Use "@" to assign a user and "//" to select a due date.