Versions Compared

Old Version 3

changes.mady.by.user Craig McNally

Saved on

compared with

New Version 4

changes.mady.by.user Craig McNally

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Translator

...

TimeItemWhoNotes
1 minScribeAll

Jakub Skoczen is next, followed by Taras Spashchenko

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.

*Making architectural decisions of various scopesAllWe know that a project of this size is faced with architectural decisions of various sizes, ranging from things scoped very narrowly, which impact only one or a few modules/teams, to platform-wide decisions impacting almost everyone.  A one-size-fits all approach to making these decisions is unlikely to work well, and we've seen this already with the RFC process.  Let's enumerate the types/sizes of decisions we make, then try to identify the applicable processes for each.  If there are gaps, do we need to define additional processes or guidance for dev teams, and architects?
Time PermittingAdditional RFC process feedback Tod Olson

From Tod in slack:

I think we want to be clear about what kinds of communication and coordination we need to facilitate. That is, what kinds of agreements do we need about how FOLIO behaves at the technical level. And where have we had problems because of not having common agreements or breaking those agreements.

Previous Notes:

  • What is covered by FOLIO technical governance and needs an RFC?
  • Want the remit to be as small as possible without causing problems, only cover the things that cause problems if they don't line up
  • Could lead to fewer RFCs
  • DRs were maybe a hack to cover things that are important but don't warrant RFCs
  • Some might get refined again
  • DRs process was intended to be more lightweight than what are RFCs are
  • For now have DRs still, RFCs just don't ouptut DRs

Today:

  • ...
NAZoom Chat



...