2024-03-13 - RFC Proposal to RSMG

Owned by Jeremy Huff
Last updated: Mar 13, 2024 by Jenn Colt
4 min read

Date

Attendees 


Discussion items

TimeItemWhoNotes
1 minScribeAll

Ingolf Kuss is next, followed by Maccabee Levine Jenn Colt will scribe

Reminder:  Please copy/paste the Zoom chat into the notes.  If you miss it, this is saved along with the meeting recording, but having it here has benefits. 

*RFC Proposal to the RSMGAll

Goal:  Review the proposal to the RSMG for language in the release schedule template suggesting RFCs

Notes:

  • Proposal:

  • This is written as if an updated to the Quesnelia schedule just to understand the timeline, even though obviously we are not editing the Q schedule at this point.

    Existing: 11 Mar 2024
    Ramsons R2 2024 release scope refinement deadline
    POs prepare list of UXPROD features aligned with Ramsons R2 2024 team capacity. PO present prepared scope at next PO Weekly meeting at <TBD>

    Add four weeks later: 08 Apr 2024
    Ramsons R2 2004 RFC Consideration
    Consider whether Ramsons planned development will introduce any [architectural changes or other innovations](https://github.com/folio-org/tech-council/blob/master/NEW_MODULE_TECH_EVAL.MD#before-development) that might conflict with existing TCR criteria.  If so, contact #tech-council for a recommendation on whether to conduct an RFC.

    Existing: 13 Sep 2024 (existing deadline)
    Deadline for acceptance of new modules by Technical Council at Ramsons (R2 2024)
  • This language was added to the TCR process:
    • If some of the failures are due to proposed architectural (or other cross-module) changes, the TC may request that Submitter first propose those changes via the RFC process to get sufficient community input. In that situation the TC may defer its decision pending the resolution of the RFC. (See Before Development.)
  • Doing RFCs is meant to help smooth out the TCR process when large changes are part of a module
  • Is it clear enough whether or not something should get an RFC?
  • If this is discretionary does it belong on the schedule?
  • Goal is to encourage early contact to see if RFC is recommended for any changes/additions. The contact with TC is what we'd like to see more on the 'required' side
  • Are we saying teams MUST inform TC of architectural changes they are planning to make?
  • This would be a four month heads up, approximately
  • Does the community actually back this kind of oversight in the face of political pressures in the community?
  • Maybe being clearer about what really is or is not a requirement would help?
  • The original intentional was to be a friendly and useful reminder not a new requirement, is that still what we want?
  • If we are going to have standards we should stick to them and let the political conflicts play out
  • How are teams going to know they should do an RFC if we don't tell them? We should at least make the desire to have them clear
  • Community moves at a slower pace?
  • Work has been done to streamline RFCs but we need more experience to see how long it takes
  • Desire to see RFC time point remain as a suggestion
  • RMS group only wants to see required things on their timeline
  • TC is comfortable with sharing the language proposed and see if RMS will accept it
  • Four weeks after scope refinement, 5 months before TCR submission deadline
    • team has to
      • abstract
      • draft refinement
      • public review
    • what if something still in public review at TCR time?
    • time could not be enough but is it still better than having it come up fresh at TCR time?
    • when do teams discover a change is going to be required? can vary in development
NAZoom Chat

11:14:47 From Maccabee Levine to Everyone:

If some of the failures are due to proposed architectural (or other cross-module) changes, the TC may request that Submitter first propose those changes via the RFC process to get sufficient community input. In that situation the TC may defer its decision pending the resolution of the RFC. (See Before Development.)

11:27:01 From Marc Johnson to Everyone:

What benefit do the teams get for doing this beyond satisfying governance requirements?

11:27:27 From Marc Johnson to Everyone:

My language is riffing on the language folks have conveyed from the RMS group

11:28:00 From Huff, Jeremy T to Everyone:

They may be able to adopt an implementation approach that has community and governance buy in

11:28:24 From Marc Johnson to Everyone:

Replying to "They may be able to …"

Why would they do that if the app / module goes in anyway?

11:28:57 From Huff, Jeremy T to Everyone:

Replying to "They may be able to ..."


🙂 good will?

11:29:58 From Huff, Jeremy T to Everyone:

Replying to "They may be able to ..."


Maybe they have no, or don’t want to spend the political capital to force the module through?

11:30:56 From Marc Johnson to Everyone:

Replying to "They may be able to …"

That comes down to the culture of the community

11:31:32 From Marc Johnson to Everyone:

If the need outweighs the governance, we should consider dropping the module evaluation process entirely

11:33:56 From Marc Johnson to Everyone:

Until the community is aligned on the fundamentals, this conflict will continue to happen

11:33:58 From Jenn Colt to Everyone:

But EBSCO also fills all those roles

11:44:46 From Marc Johnson to Everyone:

Which modules did we turn down?


The only one I can think of is the translations work

11:45:03 From Jenn Colt to Everyone:

I think he said "nearly"

11:45:43 From Marc Johnson to Everyone:

Reacted to "I think he said "ne…" with 👌

11:46:54 From Huff, Jeremy T to Everyone:

The translation work is what I was thinking of

11:47:11 From Jenn Colt to Everyone:

But teams will just release to the customers who need it rather than to main line folio if they have to

11:47:49 From Marc Johnson to Everyone:

Reacted to "But teams will just …" with 👍

11:50:05 From Marc Johnson to Everyone:

We don’t know if the RFC process is any quicker as none have completed in the new processes

11:55:12 From Jenn Colt to Everyone:

Implied required

11:56:56 From Marc Johnson to Everyone:

The whole schedule is artificial

11:57:05 From Huff, Jeremy T to Everyone:

Reacted to "The whole schedule i..." with 😁

11:57:53 From Marc Johnson to Everyone:

Except for the one bit where modules must be ready to go into BugFest and then the release

12:01:27 From Marc Johnson to Everyone:

If 4 months is not enough, then we have to accept modules not making it in within 1 release cycles which means a lead time of more than a year