2025-03-05 RFC Retrospective

https://easyretro.io/publicboard/dY8fCRqguiSDP3wtvSLhNzlULdM2/dae10f92-7cf9-48a0-ab4a-116b1758899b

What could we have done differently?

• Tri-council group
  • started too early maybe
  • scope focused on app formalization and that was seemed too narrow?
  • trying not to be technical
  • focus on app form and the work not being used
• Once all of Eureka was the topic and not just app formalization things changed
• Granting blessing to things already done
• As soon as it was clear Eureka was going into prod, we should have asked what the alternative was and realized there weren't any
• After a certain point, given the community structure, we spent a lot of time making a decision that wasn't a decision, should have focused on how to get there
• Community need to be open to the conversation
• Hard to know what is going to happen at the beginning
• Community had questions so it was reasonable to try
• Not able to get needed answers on app form and platform form further down the road - releases, bugfest, etc. Would have liked a way to focus on them
• seems like it's often too early and also often too late!
• not too early - group determined its own scope, that was in our name!
  
  • spun wheels maybe because of make up of the group? hard to get everyone on the same page
  • lots of head scratching conversations
  • from a product PoV what is the ideal composition?
  • two initiatives to ask community for ideal, asked for input
    • couldn't do that
    • in parallel took baby steps toward app formalization
  • what are we marching toward without product input on app formalization
• Conceptual domain modeling is hard in the FOLIO community
  • Leaves the technical driving things
• When there's a big change with no alternatives then could be more prudent acknowledging where we are at
• Shouldn't have had a Eureka RFC
• We never got into questioning Eureka enough to understand the tradeoffs, etc so we can't really make a statement about Eureka
• When we get large change proposals, if something is already a certain amount along so there would be a negative impact to saying no, we shouldn't do the RFC at all
• TC's responsibility to 'set general technical direction'
• We can add value. How can we do this? When things are already crystalized
• What did we get out of this process for this time around? What did we get? What value did we add?
• Maybe RFCs aren't really the right thing. Feedback vs approval on changes.
• RFC process heavy, not helping when rapid change is needed, doesn't help community move faster
• Something more lightweight
• Hard to find time to generate a big RFC
• There was overlap with pre-existing needs in the project- permissions, applications, authentication
• Our RFC process is different from the IEEE process
• People in the solution architect role should be helped by the process
• Helpful to know what is being on worked so community can know when we should be working on something
• In this case how fast TC was working wouldn't have mattered, competing concerns with building the thing and getting the RFC done
• Even before the RFC existed it was too late for a goal of approval
• Can make current process more efficient or reframe it to do a different job, to figure out what valuable input the TC has
• Time to market issue for developers/hosting companies.  If decisions made during that affect others building, we have a responsibility  to make sure these are workable for the whole community
• No upcoming RFC to get feedback on most recent set of changes
• RFCs driven  by customer needs and schedules, need to be clear on what we are trying to accomplish
• How do we add value while still moving quick enough.  Not helpful to make a decision after a decision has already been made
• Timeliness is also an issue in the product space
• Understanding  the reach of a proposed change
• Community awareness vs gatekeeping