Time: 9:00am - 3:00pm Eastern Time (US)
Location: Congressional B, Omni Shoreham Hotel
Meeting ID: 812 835 3771
Dial by your location:
888 475 4499 US Toll-free
877 853 5257 US Toll-free
855 703 8985 Canada Toll-free
0 800 031 5717 United Kingdom Toll-free
Find your local number: https://zoom.us/u/ad6Xb7q3ia
Tammy Allgood Wolf
- Melissa Anez (remote, probably for only part of the meeting)
- Laurie Arp (attending remotely)
- Thomas Bernhart (attending remotely)
Danny Bernstein Robert Cartolano Aaron Choate Sayeed Choudhury(Aaron Birkland will attend for JHU) Stefano Cossu Dan Coughlin
- Jon Dunn
- Dan Field (Remote. Possibly Morning sessions only)
- Jennifer Gilbert
Babak Hamidzadeh Neil Jefferies
- Mark Jordan
- Rosalyn Metz
- Este Pope
- Scott Prater
- Robin Ruggaber
- Tim Shearer
- Jennifer Vinopal
Evviva Weinraub Jared Whiklo
- David Wilcox
- Andrew Woods
- Maurice York
Topic 9:15 - 10:45 (1 hour 30 min) 11:00 - 12:00 (1 hour) 1:45 - 2:45 (1 hour)
Time Lead 9:00 - 9:15
Governance and community practice review
10:45 - 11:00 Break
Technical Roadmap and Resourcing
12:00 - 1:45 Lunch
2:45 - 3:00
9:15 - 10:45
(1 hour 30 min)
11:00 - 12:00
1:45 - 2:45
Strategy Doc (holds/tracks the work of the sub-groups)
Summary of high-level priorities (5 minutes)
- Stabilize membership
- Ensure Fedora 6 is adequately resourced, meets community needs, and is widely adopted
Ensure current members renewing, upgrades, maybe some new members. Stabilize membership and get commitments to renew for next year so we don’t have a lot of surprises this coming year. For those on the fence, give the project another year to start working on adoption.
Were there surprises last time around, what are the membership trends? More losses the last time around, and at the last minute/invoice already out. Some attrition is expected but the last year the drop was more precipitous than anticipated. To maintain staffing levels on project we need to stabilize the membership. Make a pitch for those on the fence.
Do we have a sense of institutions who are on the fence? Yes and we can discuss this today and in an online meeting in the future.
Adoption of Fedora 6 - making sure this effort is adequately resourced, that software is meeting the needs of community, and making sure it is widely adopted.
Governance and community practice review
- Governance Practices (45 minutes)
- Which practices should change? Which should we keep?
- How can we best utilize the members of this group?
- Number and purpose of meetings, relationship between Leaders and Steering, etc.
- Review of governance practices from other LYRASIS programs that might be useful (15 minutes)
- Review of current Fedora governance practices (30 minutes)
Use the goals of Stabilizing membership and implementing Fedora 6 as framing for this discussion. David reviewng the spreadsheet prepared by Lyrasis to call attention to different governance structures in compare/contrast with Fedora.
Columns in red most useful for us to look at. Not talking about total overhaul of governance right now, but small things we can do.
Archivespace - meet quarterly, but online meetings are 2 hours long. Less often but for longer time allows them to dig in on topics.
Question - how mature of a community is Archivespace and how much active development is going on? In relation to Fedora. Program manager, technical lead, community engagement person, and junior developer. Stable in terms of members, but a lot of development happening. Not a lot of competition in Archivespace in the way Fedora has competition. Archivespace has always had people pay some for engagement (“Freemium”). Has both staff developers and also contract developers. Not a lot of community developers, partially the nature of archivists driving the tool means there aren’t that many developers. Archivespace has a different history - did try more of a model like Fedora but needed to adjust to have a successful project. Community engagement in the prioritization of features.
Collectionspace - in a different phase, subset of LYRASIS leadership team. Had more of a community model but weren’t getting much engagement, so fell back to LYRASIS. In a critical phase so meets every other week.
SimplyE public - in a different phase, different governance structure. Gives us something to look at as context.
Observation on the spreadsheet - Fedora leadership appointed by contribution. Archivespace - levels of size of institution and it is based on that. Membership model is based on the size of institution, not a pay what you want. Smaller institutions for Fedora/Samvera/etc don’t tend to give money anyway, but perhaps we could in the longer term get people to kick some ‘license fee’ towards Fedora even if they aren’t directly working on it.
Observation that Fedora has two leadership groups - originally Steering was the more active group and Leaders were more advisory. Lines have blurred a lot between discussions in Steering and Leaders.
Within Fedora we have quite a few meetings. Each of the groups is meeting monthly - so for some that is 24 meetings! Plus two in person, plus subgroup meetings! For chairs it is even more in planning agendas. In next section of our meeting, for priorities, we can discuss what kind of meeting structure and focus these groups should have. Example: leadership group meets quarterly for 2 hours, maybe steering meets more frequently, and focus more on subgroups for getting work done.
Can we review the subgroups, the focus, and who is on them for new people? Also see the Strategic Plan agenda item for today’s meeting for more information. We need to figure out how to prioritize the strategic work for Fedora 6 and membership stabilization this year.
Leadership group, with ~23 members, is challenging to get a lot of work done not everyone can get involved/attend every time. We can pilot some change - meet quarterly for 2 hours, to give subgroups time to work in between meetings.
How should we get the work done this year? Groups exist for governance, but also for community - engagement, voices to be heard. If we only met quarterly, our team wouldn’t be as tight, which has allowed us to feel comfortable and to be able to have open conversation. On the other hand, there are layers of engagement on the Fedora leaders team - some are more engaged, some less, for various reasons. For quarterly meetings, you would be more likely to participate perhaps. Calls seem like mostly for reporting out, and then decisions/work done via email and in subgroups. Could time in person meetings with quarterly meeting structure. Do we meet in person once a year for a full day, and then 3 other times? Are we going to continue meeting at CNI, or at the LYRASIS summit? If LYRASIS summit becomes something this group wants to attend. Talking about organizing the summit to have space for these types of meetings. CNI and this time of year has been when we’ve held an in person meeting because more people come to this, and the type of staff who would participate in Fedora, compared with LYRASIS attendees from institutions.
We should ask members about attendance at in person meetings - are you unable to attend, why can’t you attend, why don’t you want to attend? (cost, no CNI membership, lack of engagement).
Having subgroups with focus on specifics seems like a very useful way to move forward on many of our goals. Hard to get a lot done in the larger group - more talking, less decision making. Changing the leadership meeting cadence to quarterly would be helpful. Hold Steering meeting on calendar, but cancel if we don’t have things to discuss. We should be celebrating how many people are sitting around the table in the Fedora meetings. Subgroups can be our focus of getting things done.
Inclusion thing - how to expand inclusion and keep the core momentum. Dan Field notes he’d never heard of CNI until this meeting. Trying to do a meeting at Open Repositories because of the international participation.
Need to have video conferencing available at in person meetings, important to allow people to participate virtually because for many folks they won’t be able to meet in person. Also modifying our meeting norms a bit, especially for longer meetings, so that we can ensure everyone is able to fully participate.
Recommendations from Laurie - doodle poll for schedule at start of year. Get the most out of meetings when sending out packet and reading material in advance.
Voting - some we would do via email with documentation of what needs voting on, and some things might be postponed for quarterly meetings. Depends on time sensitivity or contentiousness.
Islandora board - sometimes need to call emergency meetings for contentious topics, but often vote via email. Will at times move things for voting/discussion at their meetings.
Suggestion: send poll to group about spring/summer events about which people plan to attend and can organize event around, may just do online.
Recommendation: try the quarterly meeting structure, then check in to see how it is working after 6 months or so - put this out for a vote for Leaders group. Next meeting February. Next meeting at Spring CNI potentially. Could build out a calendar for the year. Can use the wiki to create subgroup area.
Planning membership and community engagement
Review of Mic's membership analysis and recommendations:
- Mic ID’d 3 issues: Community engagement, long-tail of membership, diversity
- Recommended Governance should focus on high-level coord activities - this would be a big governance change for us
- Lots of known implementation sites who are not members - biggest growth opportunity
- Diversity is bad:
- we effectively have no international events
- no real diversity on steering
- Contribution is primarily north america - contributions both in dollars and membership
- Because of this report we added a “copper” level for lower option for paid membership
- Rosy and Evviva did editing on the report
- Proposal for Leadership to move away from pay-to-play and toward participation-based contribution
- We’ll never have the level of engagement in leadership as other projects because if Fedora is running well it’s invisible
- We need to stabilize membership
- Some structural problems with Fedora are because of the way it was created by large institutions.
- Discussion about having everyone using Fedora to paid something, even if it wasn’t much:
- Possible to think of this as crowdfunding - would orgs fund this even if they aren’t using it? Can we really base core operations on crowdfunding? We’d more likely get crowdfunding for smaller projects/initiatives.
- Last year we did try crowdfunding and some orgs did give money. We haven’t been as intentional with a broader call for support for e.g., development in a particular sprint.
- Crowdfunders would want some kind of report on how their money was spent.
- This crowdfunding convo was about cash and to solve our membership issue we need to talk about how to get recurring funding.
- We need to look again at or budget to figure out how to stabilize core funding for core services/initiatives.
- How are our “go-tos” when we’re looking for more members? How many large institutions need “a fedora”? Smaller institutions, community colleges, won’t want to participate.
- Some smaller institutions are using Islandora.
- The current way Fedora has been framed doesn’t lend itself to selling this to smaller orgs
- Idea: Revisit opening up leaders group -- anyone who is paying could attend the meeting -- in order to engage more institutions.
- Q: Can anyone participate in subgroups? A: this was a new idea so to date it was only leadership members on the subgroups.
- Is there a way to open up Leadership and be more engaged without losing the idea of benefit for membership?
- What do Directors/Deans think they’re getting out of the 20k/year? Would opening to non-platinum members dilute the rationale from a Dean’s perspective? For some of us, this is not a reason to not open the Leadership group.
- To do: Governance can look again at Mic’s report and think about recommendations for increasing participation and paid membership.
- Operations: Even if we retain our current members we won’t be able to maintain our staffing after July.
- Work with Lyrasis Director of Marketing & Communications on a marketing strategy
Technical Roadmap and Resourcing
Supporting Fedora 6 development
- We’ve had two successful sprints that have removed ModShape. Thanked Scott P. for committing the developer who wrote the replacement bespoke library that replaces it. Work remains to expose this new functionality to the Fedora API. This is close.
- Also coming out of the sprints, we have migration tooling. Thanks to Aaron, Thomas, and Dan. This needs more field testing.
- Doodle for first 2020 sprints is open.
- Engagement in sprints so far has been very high.
- “Not a lot of open questions” left - remaining work is heads down release prep. Aaron concurs.
- New devs (Thomas and Dan) are very successfully being onboarded.
David remarks that the current dev team is very engaged and productive. But we need to keep this energy high to get F6 to a production release.
Consensus is that there is no need for the next sprints to be face to face, given the cost vs. the type of work that remains.
Robin asks if the success of the sprints can be converted to more membership engagement. Scott says “a resounding yes.” Some discussion around this, since Deans may or may not know how impactful concentrated dev time is.
Post Fedora 6
- Perhaps a direction for “post-F6” is integrations, working with adjacent communities, increased adoption.
- Low-latency cloud storage would be a candidate focus.
- Rosie says OCFL 2 will address issues like efficient storage, fixity checking, and effective cloud storage.
- David mentioned ongoing interest in OAI-PMH, partic. from European users.
- Gathering use cases around stability and scalability will be important going into this phase. In other words, we need to have a clear idea of what our focus should be post-release. Adoption should be one of these foci, one which we should have a clear plan for before the release.
- Scott says stability and scalability will be a key motivation for migrating from 3.x to 6. Tim says that 2021 should be spent encouraging adoption, not building a Fedora 6.2. This is related to follow up from the Barriers to Migration grant. Dan speculates that many institutions are “stuck” in a pre-Fedora 4 state because of bespoke development against Fedora 3.
- Robin says that we need to make sure that pilot implementers can be sidetracked by issues with the content (IP, etc.). Luckily that doesn’t seem to be the case according to the pilot sites.
- In response to Tim’s question, Scott points to the BitCurator Consortium’s focus on getting users up and running. Thomas asks if we should focus efforts on institutions who don’t use Samvera or Islandora. Mark remarked that Islandora sites won’t have a problem migrating to Fedora 6, their problems will be mapping their MODS metadata and achieving feature parity on the front end. Jon says that there is a risk in the Samvera community of not migrating to F6 at all but to choose a different back end. To mitigate this, he suggests making Fedora 6’s value proposition clearer and stronger (e.g. as a piece of a preservation platform).
- Scott reminds us of the Barriers survey where most Fedora 3 users were in Islandora and Samvera with fewer using other frontends. These numbers should drive our priorities for F6 adoption.
- David says that data cleanup and enhancement in the implementer registry will help us define priorities, including communication and marketing efforts. Maurice says we need to develop a narrative about reasons to migration that does not prioritize self interest, e.g. being part of a larger community, greater sustainability.
- Tim asks if LYRASIS can act as a broker of incentives to migration. Lori says yes but we’d need to do some research first. She would want to pull in John Herbert.
- Maurice notes that specialized applications for media, research data, and preservation (e.g. OCFL) should be part of the “larger” narrative. Robin notes the impression that F4 has been focused on linked data but that we should shift that to preservation.
- David summarized this section by saying the focus post-6 should be on adoption. But Andrew reminds us that we still need to invest efforts and resources in making sure that F6 is production ready and meets its release schedule.
- He says that testing and bullet-proofing efforts would benefit from contracting out. Aaron adds optimization would also qualify for outsourcing work.
- Este asks if 2 more sprints will be enough? Andrew responds no, but the 2 sprints will get us to beta functionality. It will take time for the software settle.
- Mark asked if concerted effort on testing would be a good investment for external contractors paid by crowd-sourced funding.
- Andrew reminds us that part of the failure of Fedora 4 was that the community didn’t step up to the challenge of performance and other testing early on. We can learn from this with F6 because now is the moment when we need to get a lot of engagement from the community to make sure that F6 is thoroughly tested before it reaches production release.
- Aaron adds that consultant effort might be a good investment in regaining confidence in the Samvera community. Rosie relates that this is a sensitive area because of the way that the perceived performance issues around Fedora’s role in this poor performance is not totally clear.
- We should also keep in mind that the sites that are interested in testing Fedora may not have the resources to fix the issues they identify. We need a model that acknowledges this. Also, specific resources such as support from the dev team (and other resources) would be important in a model that addresses this.
- Consensus that we should not risk releasing F6 until it has been tested thoroughly.
- Ben’s performance testing provides a good model for how the community can do this testing;maybe it’s not worth raising and spending money on consultants. One way of doing this is to ask current users to provide content that can provide useful edge cases for performance testing. Discussion about whether any of the sites represented within the Leaders group could take a more active role in testing. Depends on the type and amount of work involved. Maybe the 3.x sites are the best venue for testing, because of the large proportion of 3.x within the existing user base. We need to develop a clear test plan before we start performance testing, since potential sites need to know what their commitments are before they agree to be guinea pigs. Maybe each site needs to define its expected outcomes for testing.
Andrew points out that even though testing is extremely important, we need to make sure we resource development during the next 6 months to ge at least a testable version out. But, we also need to keep a test plan in mind at the same time. There is definitly an open question around resourcing the current dev work.
Reports from each group in a pre-meeting report (25 minutes)
- Product Technology (David Wilcox - 5 minutes)
Fedora as a high level technology:
What’s going on/been going on.: Focused on F6. Facilitate and communicate. Working actively. Publishing API spec info. Improving documentation. Requirements around cloud hosting. Applying a digital preservation framework. David et al looking to leadership for more prioritization.
- Product Position (Robin Lindley Ruggaber - 5 minutes)
Decision to gather threads and create a white paper on position. Focused on interoperability. Fedora as a part of a larger ecosystem. Flexible object support. Preservation role. Fedora 6 doubling down on this.
- Communication & Community (Este Pope - 5 minutes)
Merged comms and community sub-groups into this new one. Goals and accomplishments: community survey on training needs. Tracking spreadsheet for events. Documenting ecosystem to identify and strengthen (potential) partnerships. Reading group proposal.
- Governance (Jennifer Vinopal - 5 minutes)
Documented and updated the wiki. Enhanced on-boarding process. Viability of business model and associated strategies. Membership analysis work. Move to Lyrasis has good potential. Need new members. Should it continue or be reallocated. Scott volunteered to join. Metrics and mentorship are potential agenda items to tackle. Look to spreadsheet.
Communication about the product position needs to happen. David: Fedora 6 webinar and lots of folks (75) attended. Great Q&A. Lyrasis team can/will help. Videos very effective. David has help from Lyrasis colleagues to build branded slide deck.
Discussion (30 minutes)
- Prioritizing the work
- Gaps and requests from each sub-group - what else can we do to implement the plan?
Communications and Community:
- Revisit/update conferences/meetings spreadsheet
- Should we set a goal of, e.g., at least three presentations by members of Leaders and/or community on Fedora 6?
- Need product position communications plan - work w/ Lyrasis via David
- Work with Lyrasis Director of Marketing & Communications on a marketing strategy
- Schedule conversation w/ David for next Communications meeting
- Plan for Open Repositories in South Africa
- Develop standard slide deck, communications toolkit (w/ David, Lyrasis)
- look again at Mic’s report and think about recommendations for increasing participation and paid membership - look at other Lyrasis communities for possible models
- Identify requirements and coverage needed for testing; outreach to recruit testers
Recruiting more sub-group members to move this work forward
- Product Technology could use 1-2 more
- Governance: Scott Prater joining, might be good to have a few more depending on work
- David will send out general call for involvement in subgroups along with info on voting on the new proposed Leaders call structure/schedule
Review discussion, summarize main points and takeaways, create action items (5 minutes)
- All groups should update strategy tracking template