| | |
|---|
Repeating the "What can FOLIO do better" survey run after Hamburg | @Tom Cramer | Survey where every council member interviewed 3 people, added to document and distilled into themes. This was revealing, should we do it again? Did we address the items brought up then? Should we consider the status of those things? Was not much structured followup Survey useful as health check. Might be good to document against previous observations and actions. PC discussed improvement of how PC works and that might a survey goal Sense of conference this year was different to last year. There was much more vendor participation this year than last year. What can we do to make more librarians show up? Question of how true this is, with more people implemented that might drive a change. More presentations than working meetings Good to not have PC meeting during conference, but one after There will also be a survey about WOLFcon Looking at results from last year, we haven't done enough follow through Topics resulting from survey are mostly medium- to long-term issue. Checkin now perhaps too soon, maybe 6 months New survey could be indicator of progress or not Reference to Jenn Colt's "Measuring the elephants in the room", might also look at OSS health What is the right timing, better to show some results/actions before doing again Summary: con: over engagement, not enough progress pro: data and health check helpful, lightweight process
PROPOSAL: Would sharing progress bias new survey? Surface that is part of longitudinal process Look at results of last years survey, self assessment of of progress and share, do new survey AGREEMENT to move forward VOLUNTEERS: @Tom Cramer (CC), @Maccabee Levine (TC), @Jesse Koennecke
|
Developer advocate role | @Mike Gorrell | Agreed at last CC meeting to take this role forward, determine details, choose between options, write up job description, funding, recruitment Heard a need for this position at WOLFcon: perhaps check in with institutions who may have developers to contribute Timeframe: asap VOLUNTEERS: @Mike Gorrell, @Boaz Nadav Manes, @Christopher Spalding (CC), @Alexis Manheim (PC), @Maccabee Levine (TC)
|
How do we advance the architectural reworking that Vince/Tod and others discussed. How is this broken up? | @Simeon Warner | Larger architectural roadmap and the part of refactoring and redrawing the microservices boundaries We need to capture details, get it down on paper and get it reviewed. Formalize the formalization of the architecture Strong governance implications PC is interested in engaging with process to understand implications and make sure it works for the product Large communication issue: how should the community engage with the change This work will define what a “product” is, so what will be managed by the PC? Is an App in Vince's paper the same as an App that a SIG would think of? PC very interested in this issue and the implications Working together will help us find a common point of reference Platform may be a second phase There is a strong architectural cases, questions are in the community/product sides Adopting this architecture does not force us to change our processes, but enables us to change our processes Maybe TC can provide a report with “these are potential questions that this shift might raise”--gather from all of the councils Applications is the first step, then “platforms” Political, practical, and technical process Can we construct a managed process to speed this up, not slow it down Clear need for an RFC process Clear need for add’l process to discuss / address additional questions on related domains Would be useful to get an authoritative “package” of info and questions ASAP to address knowledge/ information gaps Craig will pull together a list of relevant presentations and highlight items that are important Technical Architecture Evolution We will do Applications First TC will begin the RFC process during this 6 week window RFC process is lengthy – do not expect it to come to conclusion within 6 weeks. (NB: Craig also volunteered to help with overall coordination) Craig will gather and synthesize docs describing the Apps VOLUNTEERS @Jeremy Huff @Tod Olson @Maccabee Levine @Craig McNally volunteer to help surface ideas and needs, scope, questions – the “non-technical questions” – 6 weeks Craig identified need to help run the RFC processes within TC
We need the generation of a plan, and then the management of that plan to follow through Time frame: 6-8 weeks for first steps
|
How can we be more global by accommodating time zones including Australia? | @Simeon Warner | PC is also discussing and considering how to create a schedule with rotating times to accommodate Asian/Australian time zones Idea to potentially pick a week a month Make sure there are people who want to join PC individuals volunteer to work through the issue Challenge with product owners too, and would want to work out a time that is appropriate for them Perhaps survey on Slack to identify those in time zones that want to commit to group Perhaps particular meeting time, that could be different topics on different weeks Good meeting hygiene (set out agenda in advance, document decisions, provide async avenues for input, time frames for discussion) PC will provide a report and other councils will consider this as basis for wider use
|
Developer experience as a potential area of strategy for cross council work | Proposed by @Jenn Colt | Notes shared in advance https://docs.google.com/document/d/1IA0DD0hUL146MVtnQaxoMYTqlCoGt7F2OdWqIcQztk8/edit Something where we could say, here's an area of engagement with things happening in all three councils (and most of these things are also part of other things so not just a bunch of extra work) |
Cadence of tri-council meetings | Topic from CC meeting | How to check in with architecture work--decided on October 12 There have been some challenges with planning and getting tri-council meeting usefully organized Do we want more in-person meetings: F2F is good, but may be hard to do more frequently Recommend meeting every three months, with virtual meetings outside of single F2F Have them be more substantial: keep certain topics that can be handled asynchronously asynchronous Council chairs can set the agenda Space on wiki for Tri-Council meeting: https://folio-org.atlassian.net/wiki/display/CC/Tri-Council+Meetings Are meetings open to all or should they be closed to elected members?
|
Council term limits | Topic from CC meeting | Goal of the term limits was to promote new people getting engaged, we are not getting as much of that as we imagined(though 2 out of 3 elections were contested) Idea was people might move through governance structure though not sure that is idea Need to work out how to recruit people to run Meeting hygiene might help make councils more attractive If there are open seats, people who have served term could be co-opted Should we consider formal proposal to allow term limit to be waived if/when there aren't enough standing for seats In current governance can take a break and come back If abolished it would become a self-fulfilling prophecy to have continuous service and folks feeling stuck Will be a bump to get over this first set of term limits but might be better for itS CC has a lot of people that will term off next year. Would not want to have project leadership roll off. Plan two years ahead. Stand vs. active conundrum SENSE OF THE ROOM was NOT to change term limits. Consider options of co-opting past members or developing an exception process if there is concern in a specific election
|
| | |
TOPICS NOT DISCUSSED | | Encourage more individuals from more institutions to feel interested and empowered to get involved - what can we do to make this happen? Problem: while FOLIO functionality that is released isn’t working properly, institutions/support at hosting providers are too busy “filling cracks repeatedly” to contribute to further development How can we make adopting FOLIO empowering Adding resiliency to FOLIO development - how can institutions shift from keeping up their own instance to project contributions
Module/functionality review process (follow up from WOLFCon session) Review of statement, "FOLIO is a community-owned and governed, market-driven modern open source platform for libraries that provides choice and protection from vendor lock-in. Designed by librarians for librarians, its modular and flexible architecture helps solve current problems and is adaptable for future needs." Governance topics MoU for maintenance
|