Document development workflow
This commit is contained in:
@@ -0,0 +1,38 @@
|
|||||||
|
# Contributing
|
||||||
|
|
||||||
|
1. Branch Strategy
|
||||||
|
2. Development Workflow
|
||||||
|
3. Commit Messages
|
||||||
|
4. Definition of Done
|
||||||
|
5. Coding Standards
|
||||||
|
6. Documentation Requirements
|
||||||
|
7. Testing
|
||||||
|
8. Creating ADRs
|
||||||
|
|
||||||
|
## Development Workflow
|
||||||
|
|
||||||
|
See ADR 0010 for the overall development workflow.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## Commit Messages
|
||||||
|
|
||||||
|
Commit messages should be:
|
||||||
|
|
||||||
|
- short
|
||||||
|
- descriptive
|
||||||
|
- written in the imperative mood
|
||||||
|
|
||||||
|
Examples:
|
||||||
|
|
||||||
|
- Add meeting import
|
||||||
|
- Implement transcript persistence
|
||||||
|
- Refactor storage layer
|
||||||
|
- Fix timestamp serialization
|
||||||
|
|
||||||
|
Avoid messages such as:
|
||||||
|
|
||||||
|
- Update
|
||||||
|
- Changes
|
||||||
|
- Fix
|
||||||
|
- Miscellaneous
|
||||||
|
|||||||
@@ -0,0 +1,55 @@
|
|||||||
|
# ADR 0010: Development Workflow
|
||||||
|
|
||||||
|
## Status
|
||||||
|
|
||||||
|
Accepted
|
||||||
|
|
||||||
|
## Context
|
||||||
|
|
||||||
|
The project is expected to evolve over an extended period and will be developed with the assistance of AI coding tools.
|
||||||
|
|
||||||
|
To maintain code quality, architectural consistency and a comprehensible project history, a common development workflow is required.
|
||||||
|
|
||||||
|
## Decision
|
||||||
|
|
||||||
|
The project follows a feature-branch based development workflow.
|
||||||
|
|
||||||
|
The `main` branch shall always represent a stable and working state.
|
||||||
|
|
||||||
|
Development of new functionality shall take place on dedicated feature branches.
|
||||||
|
|
||||||
|
Examples:
|
||||||
|
|
||||||
|
- feature/domain-model
|
||||||
|
- feature/storage
|
||||||
|
- feature/import
|
||||||
|
- feature/transcription
|
||||||
|
- feature/diarization
|
||||||
|
- feature/export
|
||||||
|
- feature/ui
|
||||||
|
|
||||||
|
Feature branches shall be merged into `main` only after:
|
||||||
|
|
||||||
|
- implementation is complete
|
||||||
|
- documentation has been updated where required
|
||||||
|
- all tests pass
|
||||||
|
- static analysis completes without errors
|
||||||
|
|
||||||
|
Architectural changes shall be documented using Architecture Decision Records (ADRs).
|
||||||
|
|
||||||
|
Project versioning follows Semantic Versioning.
|
||||||
|
|
||||||
|
Version numbers shall be maintained in:
|
||||||
|
|
||||||
|
- `pyproject.toml`
|
||||||
|
- `CHANGELOG.md`
|
||||||
|
|
||||||
|
Each released version shall be tagged in Git.
|
||||||
|
|
||||||
|
|
||||||
|
## Consequences
|
||||||
|
|
||||||
|
- Development history remains easy to understand.
|
||||||
|
- Experimental work is isolated from the stable branch.
|
||||||
|
- Architectural decisions remain documented.
|
||||||
|
- Releases are reproducible through Git tags.
|
||||||
Reference in New Issue
Block a user