OpenCloud
/
mastodon
mirror of https://github.com/tootsuite/mastodon
1
1
Fork 0
Code Issues Releases Wiki Activity

Brevity

pull/33517/head
Matt Jankowski 2025-01-08 13:41:27 -05:00
parent 0879ba3c31
commit 2ffee52a4e
1 changed files with 12 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
CONTRIBUTING.md
View File

@ -34,27 +34,23 @@ reviewed and merged into the codebase.
### Size and Scope
The smaller and more focused a set of changes in a Pull Request is, the easier
it is to review. Splitting tasks into multiple smaller PRs is often preferable.
Team time is limited and pull requests making large sprawling changes are harder
to review and less likely to get any feedback at all. If your change only makes
sense in some larger context of future changes, note that in the description,
but still aim to keep each distinct PR to a "smallest viable change" size.
The smaller and more focused changes in a Pull Request are, the easier they are
to review. Team time is limited and PRs making large sprawling changes are
unlikely to get any feedback at all. If your change only makes sense in some
larger context of future ongoing work, note that in the description, but still
aim to keep each distinct PR to a "smallest viable change" size.
### Description of Changes
Unless the Pull Request is about refactoring code, updating dependencies or
other internal tasks, assume that the person reading the PR is not a programmer
or Mastodon developer, but a Mastodon user or server admin, and try to describe
things from their perspective.
other internal tasks, assume that the audience are not developers, but a
Mastodon user or server admin, and try to describe from their perspective.
We use commit squashing, so the final commit in the main branch will carry the
title and description from the Pull Request. Commits from the main branch are
then fed into the changelog and ultimately into release notes. We try to follow
the [keepachangelog] spec, and while that does not prescribe how the entries
ought to be named, for easier sorting, starting your pull request titles using
one of the verbs "Add", "Change", "Deprecate", "Remove", or "Fix" (present
tense) is helpful when it makes sense.
The final commit in the main branch will carry the title from the PR. The main
branch is then fed into the changelog and ultimately into release notes. We try
to follow the [keepachangelog] spec, and while that does not prescribe how the
entries ought to be named, starting titles using one of the verbs "Add",
"Change", "Deprecate", "Remove", or "Fix" (present tense) is helpful.
Example: