TCR-9
-
Getting issue details...STATUS
- There has been no activity or interest in this task for some time now. TC agreed to close the issue.
We should evaluate the module even if TC sees issues from architecture standpoint. Maybe we need to optimize TCR process?
We can evaluate them but these modules are based on some very important architectural changes (fundamental change) to how Stripes / UI works. It actually affects all UI components (because it's about interception for translation capabilities).
Zak Burke will provide a written summary to be included in the TCR explaining why we're closing this and next steps. We will not close the TCR until that has been done.
Today: proposed summary:
The TCR process is designed to evaluate whether a module meets objective technical criteria rather than to assess whether its features and architecture fit well with FOLIO's scope and established design patterns. At present, there is no formal process to evaluate the latter, and thus TCR-9 is in a gray zone: it landed on the TC's plate fully-formed but without its features and architecture ever being evaluated, or even discussed, with POs and developers who are actively involved in the FOLIO community.
Although a feature it provides – translation in the UI of run-time values such as a tenant's patron groups and locations – is extremely compelling, many community members expressed concerns with both the feature itself (translating values exclusively at the UI level rather than at the API level means that any API client other than stripes would have to duplicate the functionality of this module in order to leverage these translations) and its implementation (a single module storing translations for multiple modules goes against the grain of independent microservices). Without an active champion working with the community to resolve these concerns, we cannot accept this module at this time.
Statement makes sense
Translation modules have been added to responsibility and tagged for being included in a product release. Listed as Nolana but that has already released. May have been listed there for a while. Maybe we should update the page to remove the Nolana reference
Haven't found a way to carry this forward without more active engagement between the developer and the FOLIO community interested in translations
Suggest to remove ever/even
Level of engagement needed is higher than it would need to be for a completely independent module, has high impact on FOLIO
This module can still be useful without being part of the flower release
Laudable that the work was done
Prioritize how something can "belong to the project" without being part of a release
Where do TCRs come from? Product Council? Not really, in practice teams submit the TCR - usually the PO. Consider focusing on the ones from the product council.
This TCR is likely a couple years old. We likely haven't been vetting who is submitting the TCR
Working on bringing more consistency and clarity to the process
This TCR was requested by the PC
TC agreed to close the issue, discussion/vote is about the text surrounding the decision
Technical concerns were so significant and unable to be overcome that stopping before proceeding with regular review seemed appropriate
Exception is being proposed for the module review process that allows this type of decision without the full review
Code is 2 years old now, could be way out of date
Objection to wording of comment - comment should be scoped to technical reasons.
AWS - see written update from two weeks ago, no changes since then. Think kitfox may have shut down the two temp enviroments. In sprint reviews will be reporting on the costs. Negotiated discount from TestRails company to be able to get more licenses. Kitfox also implementing jobs to shut down idle envs which will also help. Kitfox playing significant role in this work, group not meeting regularly. Want to reinvigorate monitoring of the costs by the group. Craig McNally will revisit refreshing the group next week.
Breaking changes - adjusting related to feedback. Show to TC again next wednesday. Maybe a Monday meeting will be needed.
TCR group - working on slides, need to get feedback. Some changes perhaps based on the discussion of TCR9 today. Discussion of group scope next meeting.
Tod Olson - All we need is votes whether to accept the documentation. Asked people to read on and give their votes.
Discussion:
"Periodically revise" → how often? 1-2x? per year? Quarterly?
Jeremy Huff raised a concern over the list including things which aren't very clear. "feels like we're signing a blank check"
Marc Johnson provided the history of this effort, and clarified that we don't have a good way to prioritize these things
Jenn Colt maybe we could accept this as-is, but immediately start a group to go through the list and capture the status of each item. Also note that the charter revisions mention this type of planning/vision work.
Do we really want to start another subgroup? How do we prevent that group from falling into the same trap (working on this for ever)?
Voted to accept the document in it's current form and start a conversation about next steps, e.g. how to use this document.
Today:
Deferred discussion on next steps for now since Tod isn't here today.
folio-perf-firebird was destroyed on Thursday (2nd March).
The team is preparing to terminate folio-perf-bulk-edit as well, but there are still some tasks that need to be completed before they can do it.
Specifically, they need to fix some issues related to handling bad data in Bulk edit (Firebird) and memory leaks in Acquisitions (Thunderjet).
The PTF team is currently working on improving the bulk edit performance, and once they complete all the necessary actions, the second environment will be destroyed.
Thoughts about pulling the cost control team together and the next steps?