@@ -161,10 +161,101 @@ git push -u origin feat/short-desc
161161
162162Open PR, set base branch to ` dev ` .
163163
164+ ### Conventions for branches, commits and changelogs
165+
166+ The following conventions are intended to make contributions legible to other contributors
167+ and, ultimately, users.
168+ They are also there to help you, as a contributor, focus on doing one task at a time.
169+
170+ The following are common types of contributions, sorted roughly by order of interest
171+ to the reader:
172+
173+ | Contribution type | Branch prefix | Commit prefix | Changelog section |
174+ | -------------------| ---------------| ---------------| -------------------------|
175+ | Bug fix | ` fix/ ` | ` fix: ` | Fixed |
176+ | Feature | ` feat/ ` | ` feat: ` | Added |
177+ | Documentation | ` doc/ ` | ` doc: ` | Added or Infrastructure |
178+ | Refactor | ` rf/ ` | ` rf: ` | Changed |
179+ | Testing | ` test/ ` | ` test: ` | Changed |
180+ | Style-only | ` sty/ ` | ` style: ` | Infrastructure |
181+ | Maintenance | ` chore/ ` | ` chore: ` | Infrastructure |
182+
183+ If you are contributing a bug-fix, it can help focus your efforts to name your branch
184+ ` fix/problem-with-X ` , and start commit messages where you write fixes with ` fix: ` .
185+ Similarly, branches and commits that focus on features, documentation, refactors,
186+ and so on, all have prefixes that help your reader understand what you were trying to do.
187+
188+ If you find your contribution spanning more than one of these sections,
189+ it might be worth breaking into multiple pull requests.
190+ Exceptions include tests and documentation relevant to the main thrust of the PR,
191+ which are always welcome.
192+
193+ None of this is set in stone, and we all make mistakes, so don't worry about
194+ following it to the letter.
195+ We will let you know if your contribution is doing too many things and work with
196+ you to split it into more manageable pieces.
197+
198+ #### Changelog entries
199+
200+ We are using the [ scriv] changelog management tool to help keep our changelog organized.
201+
202+ Most pull requests will deserve changelog entries, and some may deserve more than one.
203+ Scriv allows changelog entries to be made as part of the pull request, which gives
204+ the contributor and the reviewer a chance to consider the impact of the pull request.
205+
206+ To add an entry, run:
207+
208+ ```
209+ scriv create --edit
210+ ```
211+
212+ (If you're wondering how to install ` scriv ` , we recommend using [ uvx scriv] [ ] .)
213+
214+ Your editor will open a Markdown file with commented sections.
215+ Find the appropriate section(s) for your contribution and write a 1-3 line description.
216+
217+ #### Style contributions
218+
219+ Style changes in code can be a source of frustration.
220+ Some editors will reformat entire files when a single line is changed,
221+ swamping the meaningful change with a large number of cosmetic changes.
222+
223+ We have provided a [ ` .editorconfig ` ] ( https://editorconfig.org ) file in the repository,
224+ which should be respected by [ most editors] ( https://editorconfig.org/#pre-installed ) ,
225+ and there are plugins available for [ others] ( https://editorconfig.org/#download ) .
226+ Additionally, we use ` deno fmt ` to format the code in this repository.
227+ Using an autoformatter like this helps avoid (ongoing) disagreements over style preferences
228+ so we can focus on the content of the work.
229+
230+ Even with these, it is possible that when you go to commit your changes,
231+ you have changed more than you intended to.
232+ One reason this can happen is that we might have forgetten to autoformat our code.
233+
234+ One tool for this situation is ` git add --patch ` (or ` -p ` ).
235+ This tool shows you each change in turn, allowing you to decide whether or not to
236+ "stage" the change. Stage only the chunks containing the pieces you meant to change,
237+ and commit those. You can then ` git checkout . ` to discard the remaining changes.
238+
239+ It is sometimes unavoidable to reformat large portions of code.
240+ In these cases, please make a style-only commit,
241+ followed by a commit with the meaningful changes.
242+ This will speed up review significantly.
243+
244+ Overall, a style-only pull request should be a rare event,
245+ typically when adopting or upgrading an autoformatter.
246+ This will generally have the effect of introducing merge conflicts,
247+ so we may refrain from doing it for a while.
248+ If you're feeling the urge, it's best to ask!
249+
250+
164251[ link_git ] : https://git-scm.com/
165252[ link_handbook ] : https://guides.github.com/introduction/git-handbook/
166253[ link_swc_intro ] : http://swcarpentry.github.io/git-novice/
167254[ link_signupinstructions ] : https://help.github.com/articles/signing-up-for-a-new-github-account
168255[ link_pullrequest ] : https://help.github.com/articles/creating-a-pull-request-from-a-fork
169256[ link_fork ] : https://help.github.com/articles/fork-a-repo/
170257[ link_clone ] : https://help.github.com/articles/cloning-a-repository
258+ [ conventional commits ] : https://www.conventionalcommits.org/en/v1.0.0/
259+ [ git blame ] : https://docs.github.com/en/repositories/working-with-files/using-files/viewing-a-file#viewing-the-line-by-line-revision-history-for-a-file
260+ [ scriv ] : https://scriv.readthedocs.io/en/latest/
261+ [ uvx ] : https://docs.astral.sh/uv/guides/tools/
0 commit comments