- Update on Stripes UI assessment and set next steps
|5 min||Architecture evaluation by OTS|
Open Tech Strategies is hired to evaluate FOLIO architecture for suitability for running in a hosted multi-tenant environment.
The assessment will consist of virtual meetings/interviews, observations as well as source code review. The focus of this high-level evaluation is for them to highlight significant ‘red flag’ issues (if any) covering the areas, such as Architecture, code quality, security, multi-tenancy, performance and scaleability, maintainability.
Report will be shared with community, hope by end of year.
Goal is to address the big items, gotchas that we need to address before go live.
|5 min||Update on AES RFC|
AES RFC process has effectively stalled.
Would like reviewers to complete task, come to closure, and bring to TC.
Options for next steps:
Pursue two options in parallel:
|30 min||Stripes UI assessment|
Most Q4 & Q1 changes related to new fields
First major changes related to this assessment comes in Q2, adding more details and sophistication in the UI, especially in search/sort and hierarchical navigation.
No stories fix usability issues in this assessment
How to help inventory team? If we do nothing now, the team will need to do substantial work to meet the design goals.
Solution would take solution in e-holdings and extend that pattern into search and sort.
Could start to finalize that routing architecture, distill the patterns and make them comprehensible and extensive enough to allow Inventory to build what they want. Could start this work in December.
Would need to take an existing module that has search and sort, dissect, and refactor to use these patterns. Once finished, the components would be available to other teams off-the-shelf. Could do this with the requests module, document, create tests. Would then be ready in time for inventory to use in Q2, and they would be able to retain all the work they are currently working on.
If the strategy makes sense, then get into details with Jakub and others on tactical approach. End goal would be to address routing architecture, bring in GraphQL, and set up the patterns so that we set up for the accessibility concerns and FrontSide can be a resource.
V: Seems to have drifted from revising an architecture to delivering specific features
Z: These are interlinked in non entirely obvious ways. The feature change becomes an outcome of the architecture change
V: so where are these features recorded in JIRA. We don't want to bury them, but rather collect them in a way that keeps in mind that these changes are all part of the architecture changes.
Discussion: What are next steps? Specifically about funding this work? Do we need to restructure this plan as an RFC, or would an RFC capture the architecture that results from this plan? The latter; we should move ahead with this and then capture/codify it as an RFC later. Let's take it to PC to get funding now.
Take to PC. This work should NOT effect the Chalmers go-live release; the request is for net new developers. We can still go-live with the Chalmers implementation as is. It is advisable to address these issues post Chalmers release in time for the next wave of the early implementors (Q3'19).
Possible staff: Jeffrey Cherewaty from FrontSide to lead + 2 net new senior devs from community to assist: candidates: Wil Wilsman from FS for routing and John Coburn for SearchAndSort would be a good team. Also Yurii Danylenko from EPAM a good candidate (would require a backfill), has experience with that code. Would want the team to be productive as soon as possible.
Next steps: Tod Olson to get this onto PC's agenda ASAP