From d7cb1254177edd7adb13e48409e9c0466c3e2992 Mon Sep 17 00:00:00 2001 From: Nico Verbruggen Date: Mon, 1 Dec 2025 11:46:10 +0100 Subject: [PATCH] =?UTF-8?q?=F0=9F=93=9D=20Updated=20contribution=20guideli?= =?UTF-8?q?nes?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .github/contributing.md | 18 ++++++------------ .github/pull_request_template.md | 29 +++++++++++++++-------------- 2 files changed, 21 insertions(+), 26 deletions(-) diff --git a/.github/contributing.md b/.github/contributing.md index a1b1f4c9..09b0106f 100644 --- a/.github/contributing.md +++ b/.github/contributing.md @@ -1,22 +1,16 @@ # Contribution Guidelines -Thank you for your interest in contributing to PHP Monitor. +Thank you for your interest in contributing to PHP Monitor! -I consider this project a bit of a nice side-project to my daily gig, so it is very much a personal affair where I love to tinker around. +While the code of the latest PHP Monitor release is public, many things are constantly in flux that may not be pushed to this repository yet. -**While the code of the latest PHP Monitor release is public, many things are constantly in flux that may not be pushed to this repository yet.** +In particular, certain changes may only be available to [GitHub Sponsors](https://github.com/sponsors/nicoverbruggen) via the [EAP repository](https://github.com/phpmon/early-access). -I don't mean to be rude, but I don't want other people involved with the project beyond simply contributing a few small things here and there, as has been the case in the past. +Please consider creating an issue before working on anything related to the project, so that I can confirm you are not just wasting your time. -The extra mental overhead of having additional contributors to report to, whose code will need to be reviewed... it's a lot and it makes working on PHP Monitor less enjoyable for me. +**Making any changes in a fork and opening a pull request WITHOUT properly documenting your changes and referencing an issue may require me to close your PR.** -Plus, at this point, the majority of PHP Monitor's main functionality is also done. - -As a result, I may refer you to this file at some point. Again, I don't wish to be rude, but this general rule stands: - -**Making any changes in a fork and opening a pull request without opening an issue first will most likely result in your PR being closed without mercy.** - -To repeat, I am **not opposed** to small contributions and fixes, if they are **meaningful or insightful**. +To repeat, I am not opposed to small contributions and fixes, if they are meaningful or insightful, but low effort changes are generally not accepted. To learn more, please check out the [pull request template](/.github/pull_request_template.md) which contains more information about my contribution requirements. (This will also show up when you open a new PR.) diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 3477d277..4128754a 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -2,25 +2,26 @@ Hello there! Thank you for considering a pull request for PHP Monitor. Please read the text below first before you submit your PR. -## Do not PR unless... +## Keep this in mind! -In order to make development and maintenance of PHP Monitor easier, I ask that you _avoid_ making a pull request in the following situations: - -* No issue has been associated with the changes you‘d like to merge -* You have not announced you will be addressing a particular issue -* The PR is a low effort change: e.g. commits that only fix typos or phrasing may not be accepted - -(If you believe the phrasing of particular text in the app is unclear or incorrect, please open an issue first.) - -In short: It is usually best to *get in touch first* if you are making substantial changes. +- Some code changes available to the sponsor repository may not be pushed to the public repository yet, so it's common that the public repository is a little behind. +- Because of this, it is usually best to *get in touch first* if you are making substantial changes. +- Low effort changes may not be accepted. +- When in doubt, open an issue or discussion and ask me if it's worth doing something. ## About destination branches -Please keep in mind that `main` is reserved for the current code state of the latest release and should *never* be the destination branch unless a new release is happening. **Pull requests that target `main` will be closed without mercy.** +Please keep in mind that `main` is reserved for the current code state of the latest release and should generally *not* be the destination branch unless a new release is happening. -Usually, the best target is the stable `dev/x.x` branch that corresponds with the latest major version that is released. +**Pull requests that target `main` will usually be retargeted.** -There may be a newer branch available, which is an appropriate place for bigger changes, but please keep in mind that it is usually best to announce you‘ll be working on such a change before you spend the time, since as the lead contributor I might not even want said change in the app. Thank you. +Usually, the best target is the stable `dev/x.x` branch that corresponds with the latest major version that is released, although that branch may not be available or up-to-date at all times. + +There may be a newer branch available, which is an appropriate place for bigger changes, but please keep in mind that it is usually best to announce you‘ll be working on such a change before you spend the time, since as the lead contributor I might not even want said change in the app. + +Thank you. + +--- ## Your changes @@ -29,7 +30,7 @@ There may be a newer branch available, which is an appropriate place for bigger * Affected parts of the app: shared code / UI code / CLI (remove what does not apply) * Estimated impact on performance: none / low / high (remove what does not apply) * Made a new build with Xcode and tested this: yes / no (remove what does not apply) -* Tested on macOS version + architecture: (e.g. "Monterey on M1" or "Big Sur on Intel") +* Tested on macOS version + architecture: (e.g. "Tahoe on M4" or "Ventura on Intel") * References issue(s): (please reference the issue here, using # and the number of the issue) (please describe what you have changed here) \ No newline at end of file