37 lines
1.7 KiB
Markdown
37 lines
1.7 KiB
Markdown
# English workflow
|
||
|
||
The project documentation is 100% English on purpose: the repo is an immersion environment.
|
||
Rust is learned through English, English through Rust.
|
||
|
||
## Daily habits (zero extra time)
|
||
|
||
- **Commit messages in English** — Conventional Commits format forces short, structured sentences.
|
||
- **DevLog entry** (10 min, last step of every session): 3–5 sentences about what you did,
|
||
in English. Don't translate from Russian in your head — describe the code, not the feelings.
|
||
- **Read error messages and docs in English only.** Never switch the compiler or Rust Book to Russian.
|
||
|
||
## Weekly habits
|
||
|
||
- **One article per sprint** in `articles/` (comparison, tutorial, retro) — reviewed for
|
||
language quality, not only content. Keep sentences short; prefer active voice.
|
||
- **Glossary growth**: every new term goes to `learning/glossary.md` with your own example
|
||
sentence. Re-using a term in your own sentence is what makes it stick.
|
||
- Weekly self-check: read Monday's DevLog aloud — if you can't, the sentence was too complex.
|
||
|
||
## What gets reviewed
|
||
|
||
| Artifact | Language focus |
|
||
|----------|----------------|
|
||
| Commit messages | imperative mood, conciseness |
|
||
| DevLog | past simple, describing actions |
|
||
| Issues / task notes | acceptance criteria phrasing ("must exist when done") |
|
||
| Articles | structure, connectors, technical vocabulary |
|
||
| Code comments & rustdoc | explaining "why", not "what" |
|
||
|
||
## Rules of thumb
|
||
|
||
1. Simple sentences first; compound later. Clarity beats sophistication.
|
||
2. If you needed a dictionary twice for one sentence — rewrite the sentence, not the vocab.
|
||
3. Write first, polish after; never let language anxiety stop the log entry.
|
||
4. Track words you *meet* vs words you *use* — the second list is the real progress.
|