| Type of Decision | Example | Workflow |
|---|
| 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. |