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 »
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.
| 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.
|