57 lines
2.5 KiB
Markdown
57 lines
2.5 KiB
Markdown
# Ways of Working
|
|
|
|
## Version Control Discipline
|
|
|
|
- **One task = one branch = one owner.**
|
|
Every issue gets its own branch. Branch names: `owner-identifier/short-description` (e.g., `ceo/ELF-3-hiring-plan`).
|
|
- **No direct commits to `main`.** All changes go through a pull request.
|
|
- **Rebase before merge.** Keep history linear and readable. Squash fixup commits.
|
|
- **Commit messages explain why, not what.** The diff shows what changed; the message explains the reasoning.
|
|
|
|
## Task Lifecycle
|
|
|
|
```
|
|
backlog → todo → in_progress → in_review → done
|
|
↑___________| ↑___________|
|
|
```
|
|
|
|
- **backlog:** Valid idea, not scheduled. Anyone can add items.
|
|
- **todo:** Scheduled and ready. Has clear acceptance criteria.
|
|
- **in_progress:** Checked out by an owner. Active work is happening.
|
|
- **in_review:** Owner has handed off for review or approval.
|
|
- **done:** Accepted and merged. No further action required.
|
|
- **blocked:** Cannot proceed. Must name the blocker and who must act.
|
|
|
|
## Standups
|
|
|
|
We do not do live standups. We do **async written standups** in the issue thread or project channel.
|
|
|
|
### Standup Template
|
|
|
|
```
|
|
**Yesterday:** What did I complete?
|
|
**Today:** What am I working on?
|
|
**Blocked:** What is in my way and who needs to act?
|
|
```
|
|
|
|
- Posted by 10:00 AM local time, every working day.
|
|
- If you are blocked, you must name the owner of the unblock action.
|
|
|
|
## Definition of Done
|
|
|
|
A task is not done until **all** of the following are true:
|
|
|
|
1. **Code is written and reviewed.** At least one approval from a qualified reviewer.
|
|
2. **Tests pass.** CI is green. New code has relevant test coverage.
|
|
3. **Documentation is updated.** If the change affects APIs, interfaces, or runbooks, the docs are updated in the same PR.
|
|
4. **No secrets in plain text.** Credentials, tokens, and keys are never committed.
|
|
5. **User-facing changes are validated.** QA or the owner has verified the change in a staging environment.
|
|
6. **Rollback path is known.** For infra or deploy changes, the owner can articulate how to revert.
|
|
7. **Handoff is clean.** If follow-up work exists, it is captured in a new issue with acceptance criteria and an owner.
|
|
|
|
## Working Hours and Availability
|
|
|
|
- **Async-first.** We do not require synchronous availability. Write things down.
|
|
- **Response-time expectations:** 4 hours during business hours for blocking questions; 24 hours for non-blocking context.
|
|
- **Deep work blocks.** Meetings and interruptions are the exception. Protect 2-4 hour blocks for focused work.
|