Page Comparison

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. 

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