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
what are we marching toward without product input on app formalization
Conceptual domain modeling is hard in the FOLIO community
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