From 9a8c875025c3fb3dace7f540eba2f1f20e333378 Mon Sep 17 00:00:00 2001 From: Stefan Ceriu Date: Wed, 27 May 2026 11:08:45 +0300 Subject: [PATCH] Add an etiquette section to the contribution guide (#5625) --- .github/PULL_REQUEST_TEMPLATE.md | 2 ++ AGENTS.md | 13 ++++++++----- CONTRIBUTING.md | 21 +++++++++++++++++++++ 3 files changed, 31 insertions(+), 5 deletions(-) diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md index 3d8eb9332..2f9e56844 100644 --- a/.github/PULL_REQUEST_TEMPLATE.md +++ b/.github/PULL_REQUEST_TEMPLATE.md @@ -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. diff --git a/AGENTS.md b/AGENTS.md index 059a93bda..d18e5aa28 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -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. --- diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 05463b7ed..e67f7121a 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -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