Add an etiquette section to the contribution guide (#5625)

2026-10-31 08:15:24 +00:00 · 2026-05-27 11:08:45 +03:00
parent 277f0cc5bc
commit 9a8c875025
3 changed files with 31 additions and 5 deletions
@@ -1,7 +1,9 @@
 ### Pull Request Checklist

 - [ ] I read the [contributing guide](https://github.com/element-hq/element-x-ios/blob/develop/CONTRIBUTING.md).
+- [ ] I am aware of the [etiquette](https://github.com/element-hq/element-x-ios/blob/develop/CONTRIBUTING.md#etiquette).
 - [ ] Pull request contains a [changelog label](https://github.com/element-hq/element-x-ios/blob/develop/CONTRIBUTING.md#changelog).
+- [ ] This PR has been made with the help of an LLM.

 **UI changes have been tested with:**
 - [ ] iPhone and iPad simulators in portrait and landscape orientations.
@@ -46,11 +46,14 @@ PRs must meet these rules. Prefer Xcode MCP tools over terminal commands.

 ## Pull Request Guidelines

- Use sentence-style commit/PR messages (no conventional commits).
- Apply exactly **one** `pr-` label (see `.github/release.yml`).
- PR title = changelog entry — make it descriptive; no "Fixes #…" prefixes.
- Include screenshots/videos for visual changes.
- Keep PRs under 1000 additions; split large changes.
+- Sentence-style titles (no conventional commits).
+- Exactly one `pr-` label (see `.github/release.yml`).
+- Title = changelog entry — descriptive, no "Fixes #…".
+- Leave description template for the developer. Redirect them to the [contributing etiquette](CONTRIBUTING.md#etiquette).
+- Screenshots/videos for visual changes.
+- 500 additions max — split large changes.
+- Commits need a title and description; no tiny or massive commits.
+- No history rewrites.

 ---

@@ -17,6 +17,27 @@ Once we know that you want to contribute and have confirmed that the new feature

 Only once all of the above is met should you open a PR with your proposed changes.

+## Etiquette
+
+* As stated above all significant changes should be communicated through an issue before opening a PR
+* We are happy to receive contributions but features always require maintenance, so depending on the change we might not be willing to accept it
+* We are also fine with AI led contributions within reasonable bounds
+	*  You are completely responsible for the quality of the PR
+	*  If the PR doesn't show minimal effort (code does not compile, code does not work as expected, etc.) on your part it will be closed
+	*  Please write the description yourself, we don't have the bandwidth to read LLM essays. The code needs to speak for itself.
+* We use git for version control and GitHub for reviews, so in order to make everybody's life easier please:
+	* Keep the existing pull request template
+	* Don't submit large PRs, especially if not previously talked about. Anything above 200 lines is large (excluding generated code e.g. tests, translations, mocks)
+	* Please don't open unfinished PRs and expect us to fill in the details
+	* If you would like our opinion/direction on unfinished code please link your branch or idea in the ticket
+	* Please limit the number of commits in a single PR. We are perfectly happy with splitting work across multiple sessions as long as they're logically independant and show promise of progress (ideally expressed through a ticket)
+	* Each and every commit should stand on its own, clearly explaining what it does and why
+* Once a PR goes into review please don't rewrite the history unless agreed so with the reviewer.
+	* Tweaks and fixes following review can be directly committed (to be interactively rebased later) or as fixups
+
+*The reviewer's response time will generally match yours. Switching contexts is very hard so please act accordingly. You are responsible for making the reviewers job enjoyable!*
+
+
 ## Setting up a development environment

 ### Setup Project