/
DR - Workflow for Decisions

DR - Workflow for Decisions

Owned by Radhakrishnan Gopalakrishnan
Last updated: Jan 17, 2023
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.

Depending on the scope it could be one of the following

  • RFC → DR
  • DR
  • Could be a simple/short discussion in one of the TC meetings
  • Could be something else that is less informal
Supported Technologies
  • Accepting Groovy/Grails/Gradle stack
  • Upgrade to Java 17 in Orchid

Depending on the scope it could be one of the following

  • RFC → DR
  • DR
  • Could be a simple/short discussion in one of the TC meetings
  • Could be something else that is less informal
All others

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

Related content