Skip to end of banner
Go to start of banner

2024-10-09 Sunflower OST Discussion

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Translator

Date

Attendees 

Discussion items

TimeItemWhoNotes
1 minScribeAll

Craig McNally is next, followed by Tod Olson

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.

*Officially supported technologies for Sunflower
Sunflower OST
Alternative/related topicMaking architectural decisions of various scopesAll

We 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?


Types/sizes of technical decisions

  • Team/Module-specific 
    • Process:  ad-hoc/team-specific, sometimes with the help of SAs
    • Who:  typically make internally by dev teams
    • Example(s): 
      • Whether certain functionality is added to an existing module, or to a new module.
      • Technology choices - shared libraries, frameworks, etc., e.g. quartz timers, various npm packages
      • Storage layout, e.g. jsonb vs traditional relational tables, etc.
  • Problem-specific (needs to be defined better)
    • Process:
    • Who:
    • Example(s):
      • Pub-sub/Event-driven communications 
      • Adoption of spring-way
  • Security-driven
    • Process:
    • Who:  Security Team
    • Example(s):
      • ...
  • Platform-level/Fundamental
    • Process: RFC process
    • Who: Technical Council
    • Example(s):
      • Eureka
      • Consortia support (ECS) and cross-tenant requests (possibly problem-specific)
  • UI architectural decisions
    • Process: A proposal or problem is brought to stripes-architecture, it's discussed, and a decision is made.
    • Who: Attendees of the stripes-architecture meeting
    • Example(s):
      • How GitHub actions are organized/implemented/used
      • Migration away from Yarn v1
  • Module inclusion into a release
    • Process: TCR process
    • Who: Technical Council
    • Example(s): ...
  • Officially Supported Technologies
    • Processes: 
      • Delegation to other groups/teams (e.g. stripes-architecture, security team)
      • Discussion with stakeholders, esp. those for whom there are work/effort implications (e.g. DevOps, developers)
      • Technical Council dedicated discussion
    • Who:  Technical Council w/ input from other groups
    • Examples: ... 

Existing Processes

  • RFC process
  • Officially Supported Technologies (OST)
  • Decision Records
    • We have used this in the past as a decision making process, but more recently have used it only as a centralized log of decisions made via some other process, e.g. RFCs, etc.
  • New module technical evaluations (TCR)
  • Ad-hoc
    • Example:  module descriptor validation & fixes
  • Team-specific 
  • Delegation to other groups/teams
    • e.g. stripes-architecture, security team, etc.
  • Technical Council dedicated discussion
NAZoom Chat





  • No labels