| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | AA | AB | AC | AD | ||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Question | Day 1 impact? | Artifacts | Asked by | Question category | Assigned category | Process | Responsible | Stakeholders | Notes | Documentation | ||||||||||||||||||||
2 | What will the process be for agreeing how existing modules will be grouped into applications? | No - anticipate the day 1 grouping will not follow ideal process | PC | Application formalization | EBSCO will share their detailed analysis of the current state as well as a higher level analysis | ||||||||||||||||||||||||||
3 | What will be the on-going process for agreeing on the grouping of modules into applications? | No | WG | Application formalization | Define the process for grouping modules into applications in its ideal future state | Working group | Councils; SIGs; POs | Requires technical dependency analysis; Iterative; process should address existing modules, new modules, and the moving of modules between applications; impact on submission of new modules | |||||||||||||||||||||||
4 | Is this grouping of modules into an application a technical decision, product decision or a practical decision based on factors such as which development teams are involved, or combination of some or all of these factors? | No | PC | Application formalization | Combination; dependent on resourcing; may change as we move through development of the PoC; initial grouping 'practical', future state may be more product focused; decoupling vs app store concerns - not the same thing; desire to reduce moving parts; get what you want - product; less to install - technical; how long to get product-focused? will we; operator experience is still part of the product, but most often hear product speak as end user; breaking down the monolithic release and have separate release cycles - another set of stakeholders; sets of stakeholders vs product/technical; can this be done in reality (getting to the future state) with existing resources?; how much investment required for decomposing? a lot to be done; | ||||||||||||||||||||||||||
5 | Will the grouping of modules into applications have any specific impact on the end user experience and the functionality available in FOLIO and how should that be considered? | No | PC | Application formalization | |||||||||||||||||||||||||||
6 | What is an acceptable level of dependency between apps? Is there even a way to predetermine this? | No | |||||||||||||||||||||||||||||
7 | Will it be possible for new modules to be added to existing applications, and if so will there need to be a process for approving additions at the product level? | Yes. New modules added to the release this becomes effective in will need to be grouped. | PC | Application formalization | PC will need to determine appropriate process and have connections with POs/SIGs for when new modules are added to existing apps. | PC | Answer to the first part is "Yes." Currently, no process for reviewing existing modules, but this has been a desirable goal. It seems reasonable to review new modules even if they are part of existing applications. | ||||||||||||||||||||||||
8 | Will the current application review process need to change? | Yes. New modules added to the release this becomes effective in will need to be grouped. | PC | Application formalization | Yes. We need to work with the formal definition of application so that we don't make assumptions about what an application is. RFC has the definition of an app: Application be defined as the minimal but complete set of elements which together are intended to deliver a specific solution to Folio. Terminology definition: A FOLIO App is a cohesive set of functionality that fulfills a defined business purpose and has a user interface (whether that’s a GUI or API) within the FOLIO LSP. An App is composed of one or more FOLIO Modules. If someone comes with a development proposal to the PC, in general it will be apps. Do apps have a technical-only consideration? | ||||||||||||||||||||||||||
9 | Will the grouping of modules into applications have any specific impact on the configuration of development teams, Product Owners and SIGs, and will it still allow for the community to continue to be dynamic and flexible in how development teams work to deliver the overall functionality required by libraries? | Maybe? The proposal says teams and applications should be aligned. Given the current PoC are teams and applications aligned? This may be one of several 'soft' requirements in the proposal. Do we take them seriously on day 1? At the same time, someone has to own the application descriptor so maybe this is just a yes? | PC | Application formalization | Craig: reorganize teams around application boundaries, could be similar to usual moving of teams. / See 27-30 for questions specifically about dev teams. Line up makes sense but what responsibilities do the aligned teams have for allowing input from other teams, or even PRs? Similar for POs, SIGs, how to explicitly include people not on the development team in feedback processes. / Craig: collaboration will continue as now, there is already some cross-team work, would need similar. who manages the application descriptor - that piece may be one team. best practices if teams want to contribute. wiki page that describes how teams line up and then that could also cover collaboration principles, the responsibility matrix might be another place \ What do we owe to each other when talking about dev teams, how small teams can become sustainable, how the project makes it sustainable for them as well, don't want to overly add to small team, not adding that they must comply with new level of bureaucracy, community supporting those teams \ will small teams be able to add modules to apps that they don't own or will it always be their own app? have to define what it means to own an app, apps built, who will take on long-term maintenance after initial funding, offers new opportunities that require support, keep development from being abandoned \ Big players have had to absorb abandoned dev, apps may not really change that. Modules:app therefore have to have a process for modules going in and out of apps which requires some bureaucracy. Haven't really been able to acheive sustainability for dev teams or supporting small teams as we would like, eventually teams disappear (even big orgs) Tech Leads group did work on collaboration - owners are responsible for release, otherwise anyone can contribute (current 'official' state) \ set funding to the side, contributors work with team/po to contribute, different types of contributions require different levels of engagement \ improve ability to enhance folio independently \ how will this particular issue impact this space? will it exacerbate the problem? \ will exacerbate because it increases work & bureaucracy, teams have to either build app layer or get someone else to adopt their module into their app \ we should look up the tech leads docs to see what if anything we have on collaboration, creating new set of expectations - how do they align with values around flexibility, vertical alignment might override previous not explicit values \ an app can be one component, working with very closely aligned modules might have more difficulties \ making app requirement clear from the start might make it easier, teams who could maintain apps vs teams that are time bound or otherwise limited - different paths? \ 'holding app' is somewhat contrary to the goals, extra work to turn a module into an app is minimal - create a descriptor | ||||||||||||||||||||||||||
10 | How does this proposal differ from simply rescoping existing modules to have a shared backend and multiple UI apps? | PC | Application formalization | This would also be a reorganization of modules, but doing it in a different way. This option does not offer the higher level of abstraction and therefore reduction of 'things' that have to be enabled by the operator of a system. The feeling is that the extra layer of the application brings benefits for releases, applications are also required for the UI bundling. Even if we adopt the formalization we can still redraw module boundaries. Reducing the number of modules also reduces the operational impact of deployments etc. The current proposal is the one that was available to the community for adoption. | |||||||||||||||||||||||||||
11 | Does this proposal help with problems such as cross-application data sharing and searching? | Unlikely | PC | Application formalization | The proposal doesn't address or hinder these issues. It maybe an enabler for improving them but it is too early in the process to say for certain. | ||||||||||||||||||||||||||
12 | Is the application formalization desirable without the platform formalization? | TC | Application formalization | We hope the application formalization will make enable FOLIO easier for system operators even with out the platform formalization. | |||||||||||||||||||||||||||
13 | What benefit does introducing applications give to us? | TC | Application formalization | Beginning to operate at a higher level of abstraction for sysops staff. Explicitly clustering modules lets us think about boundaries again. Formalization of relationship between product/functionality and the technicial organization. Potential enabler for not having to do monolithic flower releases. See also the RFC. | |||||||||||||||||||||||||||
14 | What challenges does application formalization solve? | Day 1 implementation should make deployment easier | TC | Application formalization | |||||||||||||||||||||||||||
15 | Are there product requirements addressed by these changes? | TC | Application formalization | Product needs that this could address with continued development: improving data sync and access to source of truth might be enabled by these changes (might be touched upon by the thing folks refer to as “bounded contexts” However that is limited by maintaining compatibility with module only deployment); not having to install unwanted applications is a product improvement for implementers; improvements for operations staff can also be considered part of the product; | |||||||||||||||||||||||||||
16 | With this new definition of “application”, what should we call the top-level menu items in the FOLIO UI (p.24), i.e. “Check In”? | TC | Application formalization | Glossary definitions | Association of application with the top level menu is very high, might be easier to come up with new names for the new concept. App vs application; Icon; Bundle and top menu should have different names; just refer to label name; menu entries; introducing vs taking away a name | ||||||||||||||||||||||||||
17 | What is the impact of defining applications on flower releases? | The flower release this first appears in must by definition contain a specified set of applications | TC | Application formalization | |||||||||||||||||||||||||||
18 | How does that affect the marketing of FOLIO? I.e. current press releases at the flower release milestones. | TC | Application formalization | At one point we were doing this for each FOLIO release. If new features aren't necessarily all aligned how can they be marketed well? Press release for app release or do a digest of new functionality on some schedule like quarterly, etc. Press releases as changes warrant them. Some level of information between release notes and press releases, geared for decision makers, bundling could help with this level of information. Bugs and features spread across multiple modules could become easier to understand/track. | |||||||||||||||||||||||||||
19 | If we are struggling with monolithic releases, why make a change to the FOLIO architecture rather than to the release processes? | TC | Application formalization | We are really going to have to do both. The architectural changes are intended to help us make the release process changes. With the current architecture we are limited in options for changing release processes. Maybe, not really! We could make FOLIO more modular but this is the option that's been chosen. Either way, technical work is required to establish new boundaries. | |||||||||||||||||||||||||||
20 | If “evolution” (p.4) moves to the application level does governance move to the application level? | TC | Application formalization | Related to approval processes and potentially product management | |||||||||||||||||||||||||||
21 | What was meant by “evolution” (p.4)? | TC | Application formalization | Applications can progress at their own pace, being developed and released. | |||||||||||||||||||||||||||
22 | Would the Product Council evaluate (the functionality of) new applications instead of modules? | TC | Application formalization | ||||||||||||||||||||||||||||
23 | Would the Product Council evaluate (the functionality of) new modules that are added to existing applications? | TC | Application formalization | ||||||||||||||||||||||||||||
24 | Would the Technical Council review submitted applications? | TC | Application formalization | ||||||||||||||||||||||||||||
25 | Would the Technical Council continue to review new modules? What if the new modules are packaged into existing applications? | TC | Application formalization | ||||||||||||||||||||||||||||
26 | How is BugFest testing impacted by a different release cycle for individual applications? | Will we need a bugfest with and without this to guarantee backward compatibility or is one bugfest with it sufficient? | TC | Application formalization | |||||||||||||||||||||||||||
27 | What impact does the adoption of applications have on development teams, how they’re organized, and their day-to-day processes? | TC | Application formalization | ||||||||||||||||||||||||||||
28 | Both “internal” to the community, or those which operate outside of the community but share their code later | TC | Application formalization | ||||||||||||||||||||||||||||
29 | Do development team’s own modules or apps? | Maybe? | TC | Application formalization | |||||||||||||||||||||||||||
30 | If we “Line-up Applications dev team ownership/responsibility” (p.25), what implications are there on the ability to contribute development by smaller development teams or teams which do not “own” modules. | Maybe? | TC | Application formalization | |||||||||||||||||||||||||||
31 | Who is responsible for maintaining application descriptors (p.7)? | Yes | TC | Application formalization | |||||||||||||||||||||||||||
32 | “Dynamic loading” speeds up the initial UI load but slows down (to some extent) the individual application loads (p.19). What are the functional / UX implications? | Possibly. depends on when day one is. Can be incorporated later on. Could rebuild as sys ops when needed | TC | Application formalization | Much further along in development than we are now | ||||||||||||||||||||||||||
33 | If application upgrades are user-activated (p.19), what is the UX? | User upgrades unlikely to be user activated on day one. | TC | Application formalization | Much further along in development than we are now | ||||||||||||||||||||||||||
34 | From a layman’s perspective is it possible to describe why the current module system can’t be adapted to a non-monolith release? Ie Why can’t modules evolve independently? What specifically about the current module system requires monolith releases? | TC | Application formalization | ||||||||||||||||||||||||||||
35 | What are the community implications of non-commercial “Application Stores” (p.26)? | TC | Application formalization | ||||||||||||||||||||||||||||
36 | What does “non-commercial ‘Application Stores’” mean? | TC | Application formalization | ||||||||||||||||||||||||||||
37 | What are the community implications of commercial “Marketplaces” (p.26)? | TC | Application formalization | ||||||||||||||||||||||||||||
38 | How do we ensure that the initial group of applications continues to be formalized? The presentation implies inventory will be left as a mega application (p.24), how do we keep it from staying that way? | TC | Application formalization | ||||||||||||||||||||||||||||
39 | Who will be responsible for deciding application boundaries, both at the interim state, and in the final state of decomposition? | Yes | TC | Application formalization | |||||||||||||||||||||||||||
40 | During the time inventory is a mega application, who owns it? | Yes | TC | Application formalization | |||||||||||||||||||||||||||
41 | What is the implication for innovation if modules can be part of only one application? | TC | Application formalization | ||||||||||||||||||||||||||||
42 | Will the PC focus on a single platform, several platforms, or have a wide ranging remit across many platforms? | PC | Platform formalization | ||||||||||||||||||||||||||||
43 | What will the PC responsibilities be for the platforms it is engaged with? For example, will the PC define which applications are included in the functional vs extended tiers? | PC | Platform formalization | ||||||||||||||||||||||||||||
44 | How do we manage the risk to community cohesiveness raised by the multiplicity of platforms? | PC | Platform formalization | ||||||||||||||||||||||||||||
45 | What should the 'levels' of platform involvement be called? Is 'extended' the right word for the 'outer level'? it could be divisive. | Feedback | Platform formalization | ||||||||||||||||||||||||||||
46 | What challenges does platform formalization solve? | TC | Platform formalization | ||||||||||||||||||||||||||||
47 | Does the flower release belong to multiple platforms? | TC | Platform formalization | ||||||||||||||||||||||||||||
48 | If yes, what are the implications of releasing applications across multiple platforms? | TC | Platform formalization | ||||||||||||||||||||||||||||
49 | platform [definition]? | TC | Platform formalization | ||||||||||||||||||||||||||||
50 | How many platforms would the community deliver? | TC | Platform formalization | ||||||||||||||||||||||||||||
51 | For example: Is the community responsible for the LSP? | TC | Platform formalization | ||||||||||||||||||||||||||||
52 | Others as well? | TC | Platform formalization | ||||||||||||||||||||||||||||
53 | How are the decisions between functional and extended applications made | TC | Platform formalization | ||||||||||||||||||||||||||||
54 | Who decides what is in a given platform? | TC | Platform formalization | ||||||||||||||||||||||||||||
55 | Who decides what applications are “extended” | TC | Platform formalization | ||||||||||||||||||||||||||||
56 | Given that a platform is larger than the flower release, what defines the flower release? | TC | Platform formalization | ||||||||||||||||||||||||||||
57 | If current flower release monolithic releases are a problem how does converting the flower release to part of a platform help? | TC | Platform formalization | ||||||||||||||||||||||||||||
58 | If I am a developer will I be able to create a platform for the pieces of development I am working on and will that make it easier for me as a new developer to get started? | TC | Platform formalization | ||||||||||||||||||||||||||||
59 | If an application belongs to multiple platforms, what happens when the functional domains of two (or more) different platforms place different requirements on the application’s development? | TC | Platform formalization | ||||||||||||||||||||||||||||
60 | If different versions of the same application are in two different platforms, what happens when you combine the platforms? | TC | Platform formalization | ||||||||||||||||||||||||||||
61 | Are platforms intended to be composable? | TC | Platform formalization | ||||||||||||||||||||||||||||
62 | What platform(s) comprise FOLIO? | TC | Platform formalization | ||||||||||||||||||||||||||||
63 | Does the FOLIO governance organization have remit over all, or only some platforms? | TC | Platform formalization | ||||||||||||||||||||||||||||
64 | Is the word platform the best term? | TC | Platform formalization | ||||||||||||||||||||||||||||
65 | At what point will we know that we have approved moving forward with this particular solution or some other solution? (acknowledging that iteration will happen when things ‘get real’) Is this a two phase project, the first where we investigate and try to confirm this is the solution we are moving ahead with followed by a second implementation phase? Or have we decided we are going straight to an implementation phase? | TC | Process | WG Process | |||||||||||||||||||||||||||
66 | Previous efforts have been made to improve the monolithic release problem, do we have a shared knowledge of what those were and why they were not successful? Do we have knowledge from those efforts that could make this effort more successful? | TC | Process | WG Process | |||||||||||||||||||||||||||
67 | Some of the questions listed here will be matters of opinion. How will we know when a question has been answered well enough? | TC | Process | WG Process | |||||||||||||||||||||||||||
68 | Likewise some questions might have some straightforward answers that do not need to be repeated in a way that takes up meeting time, how can those answers be documented and shared? | TC | Process | WG Process | |||||||||||||||||||||||||||
69 | When listening to the recording of the tri-council meeting at WOLFcon 2023, it sounded like there was a desire to be able to have some technical conversations unfettered by political/governance concerns, it seems very reasonable to be able to scope out those kinds of discussions. One way to do this might be to assure people that both types of discussion (technical/non-technical) will have scheduled, transparent, open sessions. What mechanisms do we need to assure people they will be able to participate in the conversations that they want to? | TC | Process | WG Process | |||||||||||||||||||||||||||
70 | For the purposes of this discussion, would we benefit from an ongoing cross-council effort to address these questions? | TC | Process | WG Process | |||||||||||||||||||||||||||
71 | |||||||||||||||||||||||||||||||
72 | |||||||||||||||||||||||||||||||
73 | |||||||||||||||||||||||||||||||
74 | |||||||||||||||||||||||||||||||
75 | |||||||||||||||||||||||||||||||
76 | |||||||||||||||||||||||||||||||
77 | |||||||||||||||||||||||||||||||
78 | |||||||||||||||||||||||||||||||
79 | |||||||||||||||||||||||||||||||
80 | |||||||||||||||||||||||||||||||
81 | |||||||||||||||||||||||||||||||
82 | |||||||||||||||||||||||||||||||
83 | |||||||||||||||||||||||||||||||
84 | |||||||||||||||||||||||||||||||
85 | |||||||||||||||||||||||||||||||
86 | |||||||||||||||||||||||||||||||
87 | |||||||||||||||||||||||||||||||
88 | |||||||||||||||||||||||||||||||
89 | |||||||||||||||||||||||||||||||
90 | |||||||||||||||||||||||||||||||
91 | |||||||||||||||||||||||||||||||
92 | |||||||||||||||||||||||||||||||
93 | |||||||||||||||||||||||||||||||
94 | |||||||||||||||||||||||||||||||
95 | |||||||||||||||||||||||||||||||
96 | |||||||||||||||||||||||||||||||
97 | |||||||||||||||||||||||||||||||
98 | |||||||||||||||||||||||||||||||
99 | |||||||||||||||||||||||||||||||
100 |