phpmon/app
1
0
Fork 0
mirror of https://github.com/nicoverbruggen/phpmon.git synced 2026-03-30 08:20:09 +02:00
Code Issues Activity

📝 Updated contribution guidelines

Browse Source
This commit is contained in:
Nico Verbruggen
2025-12-01 11:46:10 +01:00
parent 507a3e2f1c
commit d7cb125417
2 changed files with 21 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
.github/contributing.md vendored
View File

@@ -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.)

29
.github/pull_request_template.md vendored
View File

@@ -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)