Two prongs - new application do what they want - or does product council have involvement in that - does decision making lie with councils development teams, or someone else - can have discussion but who gets to decide - decentralized control for new but not for the existing stuff - why are the two different enough for one to be dev team decision making and one have non development team decision making - how to decompose the big mega applications - might not be as simple as new stuff new apps, and nothing new in old stuff - what happens when something comes along and they want to put a new module into an existing application - what if still have mega application? - would you put it in a nascent application? - key: distinction between new app - does PC or dev decide? - councils would decide on initial arrangement of applications?? - for new - devs make proposal which councils review and accept or reject/suggestion modification? - craig - when have direct dev/council interaction - devs have sprint boundaries, feature focused and bring to councils and then takes three weeks for council to decide and it becomes a blocker for the team, and they will just do what they have to do - if try to gate decisions at council level - martin: from dev perspective would make sense to have decision on developer side, have to make progress, they can do what they want, the councils don't have any way to suppress or. steer the behavior of the development teams so dev teams decide just matter of fact. on the other side, PC have other perspectives. councils have whole picture and applications should reflect functionality, dev teams don't have whole picture, have better technical picture. some kind of communication/discussion but councils won't be able to stop definition. of application if teams want to do it. - marc: at the moment pc and tc have been asked to act as gatekeepers, somewhat of an oddity because never says no, just bureaucracy. challenge with the timing of this becaus governance doesn't have same cycles as dev teams do. misaligned. if councils don't have authroity to say. yay or nay then why have the module thing? drop it? either have authority or don't nominally we have it. possible for community as a collective to reject something. the community owns the github organization so they could keep stuff out. don't say no to stuff becaus governance sturctures don't want to go there. whatever we do for applications should be consistent for modules. if no value for centralized gate, shouldn't be one for modules either. process is very involved. if can come for advice but don't have to. folks who can actually make the call are product owners and funders. dev teams have other governance structures making calls. if the call is, its developers all the way then. there is no incentive to talk to the councils because even talking to the councils is delaying things. devs wouldn't do module evals unless they have to. teams don't want to, and don't want to talk to councils at all. councils as too slow/unresponsive but good for advice doens't make sense - martin: no one can stop dev team/vendor from creating application descriptor, they can make their own. ultimate decision is on the development team side. if they don't agree with the councils they can just set up for themselves. already folio. modules not going through. the councils for different reasons. teams are building folio functionality without the interference of the councils. councils could have say with functionality, etc. develop without confirmation of the council, approval can be done later or never. councils should do more like badging/endorsement than approval - marc: that is what happens now. only. badged things are in t he flower releases. anyone can. develop module right now today and use it separately to the folio releases. something though compells organizations to do that with some stuff. some modules that come in now are not that general purpose but people want the kudos or ease of use of the flower release. eval already happens after development, which is one of things that leads to never saying no. leads to the idea that shouldn't have council as a barrier and if we are going to do it for modules. the situation with modules has come about alongside complete decentralized decision making. the same will be true because of applicaitons unless we decide to change it. - martin: council audit as promotion instead of barrier - tod: glaring exception is that we rejected front end translations that would allow tenants who have multi lingual users to see all of the labels in the language of the users preference. going as deep as controlled vocabularies and configuration data. if you take councils out, who brokers that kind of conflict. i want to do x and such that requires changes in other places. what is the proper role of the councils? we have had situations where something controversial happened and it was pulling between two different needs. also open access. community able to deal with these things. not dealing with effectively or in way that encourages developers to come forward. - charlotte: loosen up, otherwise community where we have a/b/c citizens so maybe we have been too strict in our ask of what apps should be complying to. if there is real need for open access application then we should make it part of folio and loosen up what LC asks for folio as well. apps that get in vs apps that don't as secondary citizens and then people are using but living this not really. approved state in folio landscape. don't like that some work is jsut going in the golden route without anyone able to put in any questions at all and other libraries wish to have new fucntionality stuggling to get in - craig: things aren't going in without being evaluated. tc has been as fair as possible. - charlotte: LC work all being approved in advance - craig: LC stuff might be in. folio community like GH but it isn't in the flower release, hasn't been submitted for inclusion. need to get through RFCs and other stuff at a high level. need due diligence first.
00:18:52 Wayne Schneider: I think the document does a good job trying to reflect the conversation from the last two weeks.
00:19:04 Maccabee Levine: Reacted to I think the document... with "ðŸ‘"
00:21:51 Charlotte Whitt: Maybe share the document Jenn
00:22:08 Charlotte Whitt: then it’s easier to follow what it is we are discussing :-)
00:23:13 Charlotte Whitt: + 1 Martin 00:24:55 Charlotte Whitt: So Reading Room Access is a LoC application?
00:27:03 Charlotte Whitt: Will Reading Room Circulation then be a National Library of Sweden application? Or a regular FOLIO Community application?
00:28:52 Wayne Schneider: Need to drop; will rejoin shortly...apologies.
00:36:48 Charlotte Whitt: I think what is being weird is, that we suddenly do this LoC mega application and then old stuff application and then new applications (which is to be approved by the councils)
00:37:32 Charlotte Whitt: That is really difficult to communicate, that this is a reasonably way to drive the development of FOLIO overall
00:48:42 Maccabee Levine: Sorry have to drop off early
00:54:32 Charlotte Whitt: Also Open Access - did not make it to be approved by TC (if I remember correct)
Action items
Type your task here. Use "@" to assign a user and "//" to select a due date.