2022-01-26 Meeting notes

Dennis Benndorf  next followed by Zak Burke 

Action items reviewed

Jakub Skoczen to follow up with Devops and POs wrt scratch envs and hosted reference envs.  How do we determine if an environment isn't being used?  May required discussions with PO/Dev teams, and/or looking at usage metrics.

All

Jeremy Huff 

Zak Burke 

The state of TCR-9 and TCR-12?

Jeremy Huff TCR-10 & TCR-11 update

Zak Burke TCR-7 update

All

Chulin Meng

Zak Burke

Mike Gorrell 

Steffen Köhler 

• Application Technical Evaluation Subgroup (?)
• Technical Evaluation Process Subgroup (Chulin Meng ) 
• Translations Subgroup (Zak Burke )
• LTS / Versioning Subgroup (Mike Gorrell / Steffen Köhler )

Jakub Skoczen 

Jakub Skoczen Update up on Devops and POs comments.

From last week:

The CC has asked us to take stock of the hosted AWS environments and make recommendations for any changes (adding/removing/modifying). The context here is that the CC is:

The Community Council is about to undertake a membership drive and in prep for that we discussed what costs we need to cover, and AWS is a large part of that. We have seen AWS costs rise over the last year (potentially scary), and also see Open Sources-based credits applied from AWS (good news!). So we aren’t sure what things will look like going forward.

Essentially they're trying to make some AWS cost projections and want to know if there are any changes on the hosting side that might impact the AWS costs going forward.  

Ideally, we can elicit volunteers to look into the following and report back next week:

• Scratch/dev envs
  • Are any of these not being used? (e.g. because the team no longer exists, or for whatever reason the team doesn't use their scratch env, etc.).
  • Are there plans/need for additional scratch envs?
• Hosted reference envs
  • Can any of these be shut down?
  • How are they being used?
  • Are there plans/need for additionally hosted reference envs?

Craig McNally - this was posted earlier in TC's Slack channel; provided more details on the topic; make sense to handle this as much as possible offline

It's unclear with dev envs who and how is being used them; the general concern is the cost projections

Jakub Skoczen - there might be a way to control this though no immediate answer. Action item for Jakub Skoczen to follow-up with Devops and POs

Steffen Köhler - can some envs be stopped/removed? and how to check if env is still active and required?

Raman Auramau - proposed to think about tagging of AWS resources

Jakub Skoczen - monitoring for stale resources; the similar issue is with GitHub repos

Mark Veksler - agreed that resources should be tagged; one other common practice is to shut down some envs in off-work hours; another thing is a test data set (based on University of Chicago); an approach with several data sets for different needs - this seems to be a different topic

Jeremy Huff 

Review: Quarterly Community Update (Q4 2021)

Jeremy Huff will take the lead on this update.

Goal: continue working through this...

Previous notes from 2021-12-22 Meeting notes:

• Ready for review, see TC comments on CC designation of the leading council for FOLIO Vision, Strategic Objectives and Initiatives for PC and TC usage
• Has everyone (anyone) had a chance to review this yet?
• Tod Olson summarized the comments/input from TC members to date. Some of the dates needed to be pushed ahead as "near-term", "long-term" etc. mean something different now than they meant when the document was drafted.
  • In some instances, the commenters felt that certain objectives were really under the control of the service providers rather than the TC (dependencies on hosting environments and such). In such cases, Mike Gorrell and Ian Walls believe we might want to remove those objectives.
  • Zak Burke proposed that the TC could structure some of the minimum performance requirements, while also ensuring that performance is a priority of the developers and tech architects (preventing things like memory leaks etc)
  • VBar asked whether the bullet in question (#6) was really a performance requirement.
  • Jakub Skoczen sees this as belonging to the realm of SLA terms. The TC should not have a defining role on point 6.
  • VBar indicated we should be able to provide performance metrics within the project.
  • Marc Johnson believes that the TC needs to clarify and agree on concepts like performance/stability requirements first before moving forward with this document. Also, for today, we're just trying to figure out which Council should own #6 and whether it should be the TC.
  • Ingolf Kuss offered to take this point to the SysOps SIG for discussion - to help define the requirements and report them back to the TC.
  • Craig McNally recommended that we first note the topics in the document that we agree on, then focus in later meetings on the topics in the document that need additional discussion. 
  • Tod Olson noted that the PC and TC would have input on FOLIO "roadmaps," just need to specify which roadmaps - a technical one vs a "shared roadmap"?
• Discussion around whether the goals and objectives are commitments for the TC and how should they be prioritized along with other tasks the TC participates in
• It's not clear if a commitment is needed
• Jakub Skoczen categorizing objectives into short/mid/long term indicates a certain level of commitment from the TC to complete them, it's not clear how would these items be aligned with other work the TC is involved in
• Craig McNally should the objectives from the document be distilled into priorities/work items for the TC to make them actionable?
• Craig McNally we can turn the goals/objectives into a prioritized list and work our way through them rather than commit to a specific timeline
• Tod Olson short/mid/long term categorization can be still useful to establish priorities