Time/Place

Time: 12:00pm Eastern Daylight Time US (UTC-4)

URL: https://duraspace.zoom.us/my/fedora

Or iPhone one-tap :

  • US: +14086380968,,8128353771#  or +16468769923,,8128353771#

Or Telephone:

  • US: +1 408 638 0968 or +1 646 876 9923 or +1 669 900 6833
  • Canada: +1 647 558 0588
  • Australia: +61 (0) 2 8015 2088
  • United Kingdom: +44 (0) 20 3695 0088

Meeting ID: 812 835 3771
International numbers available: https://duraspace.zoom.us/zoomconference?m=dLuIIwXLUv5-UK4kIXYkkH9mryRETY08

Attendees

  • Chris Awre 
  • Danny Bernstein 
  • Robert Cartolano 
  • Aaron Choate
  • Sayeed Choudhury
  • Stefano Cossu
  • Tom Cramer
  • Jon Dunn
  • Karen Estlund
  • Declan Fleming
  • Maude Francis
  • Neil Jefferies
  • Mark Jordan
  • Susan Lafferty
  • Danny Lamb
  • Steve Marks
  • Rosalyn Metz 
  • Tom Murphy 
  • Este Pope (star)
  • Robin Ruggaber
  • Doron Shalvi
  • Tim Shearer Julie Rudder
  • Dustin Slater
  • Roger Smith
  • Erin Tripp
  • Jennifer Vinopal
  • Ben Wallberg (called for jury duty)
  • Evviva Weinraub Carolyn Caizzi
  • Jared Whiklo
  • David Wilcox
  • Andrew Woods
  • Maurice York
  • Patrick Yott

Agenda

Topic

Lead

Welcome to new and returning Leaders:

  • Joanna DiPasquale, Vassar College (nominated as a community representative)
  • Roger Smith, UCSD (replacing Declan on the group)
All
Pairings for new LeadersStefano

Fedora Vision and Strategy

Stefano
VOTE: Policy for long-term support and Supported JVMAndrew
Spending reserve funds on Danny Bernstein's continued engagement in 2018David


RoundtableAll


Previous Action Items

  • All: Explore how to bring better cross-effort alignment between Fedora and other repository efforts.
  • Andrew Woods / David Wilcox: send budget information for slack
  • Stefano Cossu setup spreadsheet for on boarding buddies.
  • Robin Lindley Ruggaber take discussion back to Samvera SG to gain commitment for implementing Samvera over Fedora5.

Minutes

  1. Welcome to Joanna DiPasquale (now as a Community member) and Roger Smith (replacing Declan Fleming), joining Leaders. Looking for ideas for next year for expanding the Community members - continuing to get better representation on the group. There were two Community member slots and only 1 person (Joanna) was nominated.

  2. Pairing new members to acclimate to Fedora Leaders. Members can add their names to the document and then partner folks up. Pairings haven't been assigned yet, the two columns in the document are just for listing names. Will help to have a smoother onboarding process for new Leaders.

  3. Fedora Vision and Strategy update (Stefano).
    1. Subgroups have been created to address different aspects of the Strategy and Vision process. Most groups are well staffed now (thank you for volunteering, everyone). Sub-Groups will self-organize into biweekly meetings and report back to Fedora Leaders. The sub-groups can now begin working together.
    2. Also the Guiding Principles has been updated, this document summarizes the Strategy and Vision spreadsheet along with a brief Value Proposition. 
    3. We still will want to create a letter to send the the larger Fedora community.
    4. Great appreciation for everyone in making the time to help move this effort forward!
    5. Gratitude for Stefano for organizing this and making a commitment to this effort!! And for Maurice as well, for the spreadsheet structure and backbone for our work!

  4. Voting on Policy for long-term support and Supported JVM

    1. These are not new documents, looking for comments and then voting to make them official.

    2. LTS software will require effort to support and maintain

    3. LTS releases will come with the following guarantees: (from the document)

      • 3 year period of support
      • Ensure stability of the API
      • Ensure compatibility with a supported version of the JVM per: Policy - Supported JVM
      • Ensure backporting of critical bug fixes and security patches
      • Provide documentation and tooling for migration from one LTS to the next
    4.  Next steps - an email to the Leadership group looking for support to both of these policies.

    5. Question: what are the current LTS versions? What is the overlap with the next LTS (if given a three year support window), could it be that at times you have three supported versions, in terms of the window of three years? (ex: two LTS versions and the current release)
      1. Suggest 4.7 the LTS, b/c 5.0 reflects a significant change
      2. Suggest that there be overlap, that we don't wait the full three years between LTS versions. But might not be possible to have every time. Will want to consult with Committers and Leadership group about this topic.
    6. Question: can you estimate the cost of the LTS versions 
      1. Can identify significant costs , budgeting with milestones (tooling, breaking changes, etc)
      2. Not sure quantifying the costs of the effort is possible in all cases
    7. Question: Community manager - what are the activities specified, and are the resources needed for this at odds with the needs of the current release. Not wanting to put community manager in an awkward position. Can we put it into the policy that community manager is not responsible for tooling work.
      1. Need to put a system in place, identifying a person who is known and can pay attention to things such as security patches, and noting these are things that need to be backported to LTS version. Coordinating/helping with the testing and the release. Community volunteer wouldn't be tied to the migration and tooling for one release to the next, but would be focused on making sure LTS versions are secure and patched up over time.
      2. Will want to create documentation, identify what it entails doing this work, and encouraging the community to participate in project sustainability.
    8. Question: Is there a notion that the current release  (4.7) but is not aligned with the spec would be a long term release?
      1. It hasn't been decide yet if any version is an LTS. Andrew suggesting 4.7 line be a reasonable candidate for LTS. B/C there is a hump to overcome getting from 4.7 - 5.0. And there is interest in ensuring institutions who might face challenges with migrating to 5.0 have a current version that is LTS.
    9. Question: Can we make 5.1 the LTS, rather than the 5.0 version? Essentially LTS being one version after the major hump
      1. Sounds reasonable, this is a conversation that will need to be had, but it is still too early to identify the 5.x release at this early stage. Should be determined on a case by case basis, maybe it is 5.7 not 5.1.
    10. Want to provide most valuable, providing long term support for releases that the community is using. Separate conversation about 3.8 since there are many people using that still.
    11. Question: we need to think about the strategy for support. Need to think about the impact and effect of system migration/support. We are challenged by not having a registry. It would be helpful to have a chart of installed versions and where. Process is very good, but we are guessing on who is using what version.
      1. Had in the past proposed a 'call home' in the code to register/track. That was not popular in the community. We don't have a way to contact people using the platform outside of the community. If there is an expectation of support, we also need to have an expectation of community. Could be phrased as an opt-in, that benefits Fedora for strategic decision making. The more you can give to the community the more you benefit.
      2. On the splash page of Fedora installation, there is a link to the registry of Fedora users, encouraging self-register. Is there more we can do to incentivise participation. 
      3. Could we have service providers helping people install share this kind of information? We could look into strengthening this language.
      4. Can we bring this to the Communication and Community strategy groups

  5. Spending reserve funds on Danny Bernstein's continued engagement in 2018
    1. A subgroup is looking at membership overall, David happy to share if folks are interested in more detail.
    2. Andrew 25% on VIVO, and 25% of Danny Bernstein for Fedora. 
    3. Danny is doing a great job, energizing community, but hours are closer to 50% of his time on Fedora. 
    4. We'd like for Danny to continue working at 50% at least for this year, to get the 5.0 release out, it is an important technical milestone. VIVO may commission more time of Andrew and David, potential grant (in the pipeline that may pay for some of the time, but need to make a decision at this point because we may be spending down some reserve funds.
    5. Looking at possibly having to use reserve funds this year. Through the end of the calendar year. Also looking at the calendar for next year. David at 100% right now. Waiting to see about membership funds for the coming year.
    6. Timeframe for Fedora 5? Fall 2018.
    7. Alternatives to using reserve funds? 
      1. Double whammy - 5.0 release requires more time, and also a decline in membership this year, which means less funds to use.
    8. Membership call later today. Will send summary later.
    9. A learning experience from this - when we need more development support. We to some degree underestimated time needed, and didn't necessarily have the community involvement for all of the development work. 

Action Items 


  1. Draft letter about Strategy and Vision (Stefano), along with executive summary (David will get in touch with Aaron Choate who offered to draft the summary), to send out to the Fedora community. 
  2. Voting on the Policy for long-term support and Supported JVM will happen over email soon.
  3. Raise the topic of how to get better data on who is installing/using what versions of Fedora with the Communication and Community strategy groups.
  4. David will send membership/budget summary later.