Time/Place

Time: 11:00am Eastern Time (US)

Please see the calendar invite for the Zoom link.

Attendees

1. Chris Awre 
2. Thomas Bernhart
3. Danny Bernstein 
4. Robert Cartolano 
5. Dan Coughlin
6. Jon Dunn 
7. Dan Field
8. Raman Ganguly
9. Jennifer Gilbert
10. Mark Jordan
11. Danny Lamb
12. Rosalyn Metz 
13. Este Pope 
14. Scott Prater
15. Robin Ruggaber 
16. Tim Shearer
17. Dustin Slater 
18. Jennifer Vinopal 
19. David Wilcox
20. Arran Griffith
21. Maurice York
22. Laurie Arp 
23. Robert Miller
24. Ben Wallberg
25. Emily Gore
26. Oliver Schöner

Agenda

Previous Action Items

Notes

Technology Update - Fedora 6.0 Release Criteria

• The group reviewed the release criteria as described in the agenda
• No disagreement with the criteria presented
• Danny Lamb noted that the Islandora 8 integration with Fedora 6.0 Beta is already complete in ISLE
• Danny Bernstein noted that Fedora has well established, comprehensive testing practices in place that help ensure all new contributions are tested using both unit and integration tests

Strategic Sub-Group Reports

Product Technology (David)

• Developed a test plan for Fedora 6.0
• Focused on criteria for production release
• Compiling a list of potential technical requirements to be validated by the community

Communications (Este)

• Working alongside Arran to generate new ideas and offer support and suggestions
• Have generated a new logo to represent Fedora 6 (shared image seen in link in agenda)
• Logo nearly complete, not looking for complete over-haul but any feedback on it would be good (see link to logo in agenda)
• Arran submitted opportunity to participate in #DLFTeach twitter chats as a way to get Fedora in front of new people so will be working on formulating a topic for that

Governance/Business Model (Rosy)

• Piloting migration support service (CATALYST grant submitted)
• Idea submitted - if approved, Lyrasis would fund the project
• Left it fairly open, but we won’t know results until it gets reviewed
• (Robert) Lyrasis acts as broker for the action/idea - put back to community for voting

Strategic Planning for Upcoming Fiscal Year

• Larger group broke into smaller groups for discussion
• Need to decide what technical roles we want to have on the program starting next fiscal year
• Some tension between heads-down development and growing the community - possible to do some of both but we don’t have enough staff time to fully support both activities

Group 1 (David)

• Institutions feel committed to Fedora, and not necessarily to the direction
• Building technical communities is
• DEIA - encouraging community contributions and how to broaden this
• Getting fixes/maintenance is harder sell than building new things, so make sure individuals know this is what they’re here to do
• Having background knowledge on community/engagement, international relationships and soft skills required to do that important

Group 2 (Este)

• Tech lead roll is important to continue on with
• Need someone coming in after Fedora 6 to help guide roadmap
• Also recognize that there is need for heads-down development AND engage with community
• Ie bringing in new committers
• Concern about burn-out is real, and there is a need to secure this
• Personality geared toward building community
• Feel like there is saturation in the field of people who have time or have capacity to help
• Institutions don’t necessarily want to invest in persistence layer like Fedora
• Consider this opportunity to use Fedora 6 as a 
• Need a combo of leadership/technical expertise
• Is there a possibility to explore options like one-time contractors for specific partners?

Group 3 (Tim)

• (Rosy) - book about open-source: What is Fedora as an Open-Source project in the context of this book? - https://project-types.github.io
• Where do we fit? And what would this mean for employment?
• If we fall in one category, how can we pivot to be in a different one that we would like to be in
• Vast majority of all open-source projects are “stadiums” - handful of contributors but a large number of users
• Institutions are struggling enough to find developers, so why would they then hand over their people to projects?
• Do we just embrace our “stadium-ness” and hire to support this need because we may never be able to overcome this set up therefore hire senior developer to just write code and develop products
• (Tim) maybe this changes the direction of Governance and their responsibilities 
• Challenges of employment - competing with salaries, and the available people
• Really important to take care of the software, and those that curate it because it’s valuable and critical
• (Maurice) “membership” sounds too much like a club, and clubs are not as big a sell anymore
• There needs to be tech underneath the sales piece

• (Jon) feel like there needs to be a balance of both pieces (tech development AND outreach)
• Is there a possibility to make a combo position within Lyrasis
• (Laurie) we first need to figure out what we need, because we can try to make it happen as best we are able, but making the decision is the first step
• (Danny L) if people feel like you have competent developers working, then community may be less inclined to offer support
• Need also to have a balance of people that can handle a myriad of problems (ie documentation, bug fixes, etc)

David:

• Sounds like consensus around the need for some staff-led development and some community outreach / growing the committers group
• 50/50 split between development and community engagement / coordination as a starting point
• LYRASIS staff will work up a proposal to share with Steering for approval

Laurie's Group Discussion/Perspectives on Strategic Planning

• Committed to Fedora, impt to us – specific direction won’t impact membership dues
• Strengthen community efforts; reached fedora 6.0 milestone, should focus on consolidation now
• Islandora is focused on building tech community now (there are risks) 
• Risky to have too few community developers
• Important to focus on representatives from broader community and underrepresented groups – need deliberate efforts for inclusivity to occur and important for long term sustainability
• Harder to generate enthusiasm around doing work for fixes and maintenance vs building new software (requires soft skills)
• Someone doing technical leadership would need experience with engaging global participation - issues around time zones, membership models, using same tooling, silos

Este's Group Discussion/Perspectives on Strategic Planning

• Gap is tech lead, to help shape what happens post 6. It's nice to have software developers come in, if we're not clear what we're asking them to develop, not the best use of resources. Having someone come in to help shape the future is most needed.
• Also someone able to work with implementers, understand gaps that haven't been previously identified. And help implementers with issues - lean toward tech lead role as priority.
• If we have major technical needs down the road with more implementations, we may need intensive technical development for issues that arise. 75% tech leadership, 25% technical work
• Concern about only three committers - we need the community to be bulked up more, to avoid burnout/job changes
• How to characterize building community aspect - recruiter? People capacity, that portion of the role is important. Needs to be included in the job description.  
• Want to rely on committers more for building code - role of leadership in building this.
• Balance between what you ask the community to do and what you have staffing for? Struggle to identify members in the community to contribute
• Fedora 4 was really community led - given the testing and engagement in Fedora 6 has been a positive sign of community engagement - ride on crest of Fedora 6 wave to get more people involved.
• Challenge of attracting volunteer committers? Can't justify involvement in Fedora as much because it isn't as visible to users - application layer isn't visible, it is a utility. It's hard to drum up developers even at the application layer. Saturation in the field - are we setting up the role for struggle/challenge? Will we even be able to get more committers? 
• We also need to be able to train new committers - that ties into someone's role. Can't rely on committers to train new committers. 
• Someone with ability to do both leadership and hands on work and judgment about when to shift between the two.
• What about a model of using contract work on a regular basis - do we need to allocate all of the position funds to a position/use it now?

Tim's Group Discussion/Perspectives on Strategic Planning

The group talked extensively about open source projects through the lens of the author Nadia Eghbal from her book: "Working in Public: The Making and Maintenance of Open Source Software"

A useful chart can be found here.

https://project-types.github.io/

The group discussed which descriptor best fits Fedora (likely "stadium") and how that influences how we might think about how to staff the project.

Additional topics of discussion largely centered on things that influence contribution to valued open source projects:

• • Individual, institutional, and other motivations for open source participation.  One archetype from our communities is the "popular," but not always productive, effort.  For a variety of reasons an idea takes off (reach of the proponent's voice, jockeying to participate in the next thing, a compelling story, career aspirations, funding) but may not provide a good return on investment.
  • The challenges of a tight labor market.  Competition for developers is high.  This leaves not-for-profit employers (such as academic institutions) challenged to work on their own projects.  And leads to additional challenges in the capacity to provide those developers time and focus to work on open source projects when it is hard enough to resource local development efforts...to get strong software engineers.
  • Reasons a developer might work on an open source project.  Passion for it and capacity (some times self-generated capacity).  An entrée into the profession. Because the institution has decided to contribute time to the project (developer who's not necessarily drawn to the project but is being "spent" on it as an intuitional asset).

Action Items 

• Community to continue to add list of specific requirements for performance and scale for their institutions - Fedora 6.0 Performance and Scale Criteria
• Outreach to Leaders for more members to join sub-groups