Skip to end of banner
Go to start of banner

DR - Workflow for Decisions - DRAFT

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 4 Next »

Type of DecisionExampleWorkflow
Architectural
  • Cross-app data sync via Kafka
  • Expiring access tokens / Refresh tokens
Originates from the developer community. RFC →  DR
Process
  • Support periods (LTS), release naming conventions, etc.
  • Adopting the TCR/"new module technical evaluation" process
Originates from within TC or other councils
High Level Design
  • Permission naming conventions
  • Consistent health check endpoints across all modules
  • API guidelines
  • Tenant naming conventions
Originates from the developer community. DR
Mid/Low Level Design
  • Acquisition storage modules are for internal consumption only.  Users should consume the BL module APIs.
  • mod-finance will use the java-money library for currency conversions
  • mod-users-bl will make "service-points" dependency optional instead of strictly required. The response may or may not include the user's default service point, depending on if that dependency is satisfied.
Teams to work with SAs.  SAs to escalate to TC if there are cross cutting concerns
Infrastructure
  • Introduction of new infrastructure, e.g. Kakfa, Elasticsearch, etc.
  • Clarifications on supported infrastructure, e.g. Elasticsearch vs OpenSearch, S3 vs minIO, etc.
RFC → DR or DR or could be a simple/short discussion in one of the TC meetings
Supported Technologies
  • Accepting Groovy/Grails/Gradle stack
  • Upgrade to Java 17 in Orchid
RFC → DR or DR or could be a simple/short discussion in one of the TC meetings
All others

Reach out to the TC via #tech-council for guidance. 

  • No labels