docs: contributing guideline#4347
Conversation
aminvakil
left a comment
There was a problem hiding this comment.
Except .env.custom all are nitpicking really.
| Generated and managed config files live in the repo working tree: | ||
|
|
||
| - `.env` is the default environment file. | ||
| - `.env.custom` is loaded automatically when present and should be your normal place for local overrides. |
There was a problem hiding this comment.
This does not get picked up by docker compose automatically, you should use something like this for it to get passed to containers:
docker compose --env-file .env --env-file .env.custom up --wait
There was a problem hiding this comment.
This should get changed before merging.
| - Call out any generated files, config migrations, or operator-visible behavior changes. | ||
| - Include the exact validation you ran locally. | ||
| - Link upstream issues or PRs when the root cause is outside this repository. | ||
| - Keep commit history readable. A small number of focused commits is better than a long stream of fixups. |
There was a problem hiding this comment.
I want to add "Take it easy though, focus on your development instead of commits" somehow, but I cannot think of a good sentence.
There was a problem hiding this comment.
What do you mean by "instead of commits"?
There was a problem hiding this comment.
Never mind, it's not really important, I just wanted to tell users to take it easy, shift your focus to your development and really fixing the bug, or perfecting the feature you're adding, rather than breaking your commits into good one change / one commit, good commit messages, ...
That would be great if commits are tidy as well, but that's not as important as code change itself.
Overall I think current sentence of yours is correct, users are not going to hurt themselves after reading this :)
Co-authored-by: Amin Vakil <info@aminvakil.com>
No description provided.