Common DoD items - to be included in individual team's DoD. Mark is reviewing guidelines that TC came up and each team's DoD. Not all teams are consistent and not all teams have posted their DoDs. Mark will be summarizing and categorizing. Some will be "required" and others will be "aspirational". We may need to establish certain standards (i.e. logging, instrumentation, etc.). Mark will need a few more iterations. We can check back in on progress weekly. Mark will share the doc within the next two weeks.
???
Reporting and visibility of zero-day bugs
All
The situation is when a security vulnerability has just been "discovered"
"The Koha community has the following procedure posted: https://koha-community.org/security/. Essentially, they define a Security Team of release managers/maintainers and other folks known in the community (many of whom have assumed those roles in previous releases). Issues are filed into a separate project, presumably with tighter access controls. Once the fixes are made, they're backported into all supported releases, and the community is notified to install the latest updates to their current version."
Proposals/options:
There should be a security team for FOLIO who can review and assess impact ('blast radius')
That team decides things like
how public/private details of vulnerability are
urgency of action
Solicit input into specific actions to be taken
Determine what the communication channels and timings are for all activity
Likely a private/closed list for public installations to receive information about vulnerabilities
Establish public policy for Security/Vulnerability patches
Also determine which releases are supported going forward.
ACTION ITEM: Need someone to dig into this and work with a group of qualified set of people to establish a policy outlining how these will be dealt with. Craig volunteers to get this started
???
Security Issues - Releasing fixes
All
There were a bunch of security issues created last week, w/ varied priority.
When will these be released?
Part of Q3.2?
Wait until Q4?
Possibly a Q3.3 security release?
Need to get Jakub's input. Feeling is that we need to create a Q3.2.x as a security release. Need to also account for backporting (and timing).
(side note - we need to decide on a better way to label/name/number releases as well as how to determine what the policy is related to prior releases and which will be supported)
Performance and Longevity Testing update. From last meeting:
How can we break this problem up?
Environment - Core Platform
Defining the test scenarios (which tests, how many of each, what data is needed, how big a dataset, etc.) ← Likely community product owner-type
Building the tests themselves - Core Functional ( ? )... some teams have created sets of Jmeter tests - these may be useful too. Would be helpful to leverage all teams to build these tests
Collect and/or create data to be used - Mike and Tod to query Sys-Ops, potentially need to augment and/or curate additional data. Harry K might have a standard set of users
Identifying which tools can be used to profile the application so that we can assess the results
