Date
...
| Item | Who | Notes |
|---|---|---|
| Announcements |
| |
Council Updates: Community Council Technical Council Product Owners Capacity Planning updates | Community CouncilMembership drive
FOLIO Resources
Scope Criteria feedback
Elections
Website (www.folio.org)
WOLFcon '22
Technical CouncilTechnical Reviews: no changes, translation app still waiting on Translations subgroup Subgroups:
FOLIO Scope Criteria presented their work to TC, engaged conversation, broad agreement that the issues raised are important issues for FOLIO to address, with several practical and conceptual particulars. The Technical Council's RFC process is nearly finalized. There is a backlog of important technical decisions under consideration now that will use this process. This includes the discussion/notification of important changes to dependencies (for instance, the version of Postgres the project is using). Tools/Dependency decisions: How do we make decisions about updating required versions of tools/packaged used by the project, e.g. how do we decide to upgrade the version of Java that we use? Considerations are somewhat different between front end and back end. Starting point is to document current versions of software needed by each release and collecting comments on a draft process. (See Officially Supported Technologies and Managing Tools/Frameworks/Dependencies Version - v0.1 DRAFT VERSION.) Accepted proposal to formalize conventions for tenant and module names (ADRDR-000002 - Tenant Id and Module Name Restrictions). Localization RFC for back end is nearly complete. The Security Team has asked about the support period for Morning Glory and Kiwi. There are older versions running in production that are not ready to upgrade, but the cost to back-port security fixes is high. TC is not the decision maker here. Most recent statement seems to be in the Long-term Support (LTS) Recommendation document, but it is unclear where this was presented and whether it was accepted by the project. Team will reach out to the authors of the document. As a project, we have not yet declared the first long-term release, which would then start the burden of back-porting security fixes. As FOLIO is made up of many modules, does it make sense to declare an LTS on a module basis rather than a flower release basis? Much of the burden of support is on the hosting providers, and they are contributing developers and other resources back to the project as well. Most of the conversation about FOLIO is around flower releases with the aspiration that it be based more on apps and modules. The PC, while not being responsible for development resources, would need to see if the LTS concept can be supported. The practical issue is that if/when an issue is found, what is the expectation for how far back the fix will go? How long is it "safe" to be on a release? The request from the Security Team is an urgent one for knowing how to handle this. The practice in effect now is the current flower release and previous flower release by product owners, support SIG, and the development teams. As modules stabilize, we can expect to see the same module be included in successive flower releases; how does this impact the support and technical aspects of the project? Kafka issues: There was a presentation this week pointing out specific scalability (and security) issues with the way FOLIO is using Kafka, particularly in the way we organize topics. The outcome is that there will be an RFC process to address the scalability issues. Product Owners
Capacity Planning updatesCapacity Planning has not met since the last report due to holidays and vacations. The group will try to schedule a time next week to meet. | |
| Browser Support for FOLIO |
| Continue discussion from last week. Note from 6/16: Knowing what we mean by "support" is important for this discussion, as the community itself is not charged with supporting end-users. Product Owners would treat a rendering bug that only happens in Firefox or Safari as at most a priority-2 bug because there is a valid work-around ("Use Chrome"). There is an overlap with the previous discussion about what it means to "support" a version. (An issue that wasn't a Chrome browser problem wouldn't be treated as a P1 priority and eligible for a hotfix.) What is the definition of supporting a browser? Desktop Chrome is overwhelmingly most used browser in the project. Is there something supported for mobile users? This has an impact on testers and developers as they need to test with other than desktop Chrome (and develop any test variations needed for browsers other than desktop Chrome). Is a small group needed to study this question, including what the expectations are in the community? There are also complexities of different mobile browsers outside of North America and Europe. Are organizations making decisions about enterprise software based on the supported browser? It has come up in organizations in the past, and it was a highly political decision. It is also a local tech support issue when there is various browser-dependent software to be supported; flexibility is important and valued. With Stripes built on React and Reduct, it has support already for different browsers. There isn't anything preventing testing from happening on other browsers; the question is do we want to raise the priority beyond P2 for browser support issues? Does support mean we've tested FOLIO across all browsers? that we'll fix a bug if we find one? that our expectations/experience are that any browser can be used? Does the product council want to see this browser support group set up? If so, do we need to write a clear charter for that group? Who would want to be in that group? Product Council decided a group should be created for this. Owen to work on getting a group started. |
| Future agenda topics | Review the status of the long-term support policy (recommended this would be reviewed at end of 2022), when it goes into effect, and what the implications are for the project–Start discussing with the Security SIG and their concerns about the LTS Owen Stephens agreed to provide a small group scope/charge to the PC and after review by PC have review FOLIO browser support issue. The scope/charge will be reviewed by PC & if approved then proceed with a call for volunteers & convene a small group. The PC discussion today asked for a small group to define support for browsers in the FOLIO project, state the need for supporting browsers in the FOLIO project and what are the support parameters; does this support include mobile devices as well? And other questions to be answered |
...