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 not longer exists, or for whatever reason the team doesn't use their scratch env, etc.).
Are there plans/need for additional hosted reference envs?
Hosted reference envs
Can any of these be shut down?
How are they being used?
Are there plans/need for additional hosted reference envs?
10-15 min
Quarterly Community Update
All
Tentative plans for the next quarterly community update to be held on
We should start thinking about the TC update... What have we accomplished, what are our goals for Q1 2022? Longer term goals worth mentioning?
mod-ldp and ui-ldp should be re-evaluated for meeting all acceptance criteria as the initial approval was preliminary – it's not clear who should request the re-evaluation, the TC or the team
Where does this stand? Update from Jeremy Huff who volunteered to reach out to Charlotte Whitt to establish re-evaluation of mod-ldp and ui-ldp for Lotus
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 minimal 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:
Discussion around whether the goals and objectives are commitments for the TC and how should they be prioritised along with other tasks the TC participates in
It's not clear if a commitment is needed
Jakub Skoczen categorising objectives into short/mid/long term indicates 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 in to priorities/work items for the TC to make them actionable?
Craig McNally we can turn the goals/objectives into a prioritised list and work our way through them rather than commit to a specific timeline
Tod Olson short/mid/long term categorisation can be still useful to establish priorities
Any updates on these two things from before the break?
Jeremy Huff suggested that we form a working group to define more detail around this topic. Craig McNally agreed that was a good idea or alternatively, we need other proposals
Zak Burke volunteered to identify categories of decisions the TC makes and suggest applicable processes
Time Permitting
Another meeting rules thing: should we have a formal policy/discussion about attendance, discussion, and decision making when attendance is low/less than half?