Because maintainer time is precious, junior maintainers may merge
@@ -210,8 +205,8 @@ to review the appropriate one for your contribution.
be sure to **create an empty draft pull request or open an issue, so we can
- have a discussion first**. This is especially important for a large pull
- request or when you don't know if it will be merged or not.
+ have a discussion first**.
+ This is especially important for large pull requests or when you don't know if it will be merged or not.
Because of the large impact of this work, only senior maintainers may
merge PRs in this area.
@@ -245,43 +240,9 @@ to review the appropriate one for your contribution.
7. **Select the correct source and target branches**.
8. **Link to related issues** for context.
- 9. **Provide a clear and concise description** explaining the changes and
- their purpose.
-
- - **Type of changes**
-
- - Bugfix (a non-breaking change that resolves an issue)
- - New feature (a non-breaking change that adds new functionality)
- - Breaking change (a fix or feature that alters existing functionality in a
- way that could cause issues)
- - User Interface (UI) updates
- - New Documentation (addition of new documentation)
- - Documentation Update (modification of existing documentation)
- - Documentation Update Required (the change requires updates to related
- documentation)
- - Other (please specify):
- - Provide additional details here.
-
- - **Checklist**
-
- - My code adheres to the style guidelines of this project.
- - I ran ESLint and other code linters for modified files.
- - I have reviewed and tested my code.
- - I have commented my code, especially in hard-to-understand areas (e.g.,
- using JSDoc for methods).
- - My changes generate no new warnings.
- - My code needed automated testing. I have added them (this is an optional
- task).
- - Documentation updates are included (if applicable).
- - I have considered potential security impacts and mitigated risks.
- - Dependency updates are listed and explained.
- - I have read and understood the
- [Pull Request guidelines](#recommended-pull-request-guideline).
-
- 10. **When publishing your PR, set it as a** `Draft pull request` **to allow
- for review and prevent automatic merging.**
- 11. **Maintainers will assign relevant labels** (e.g., `A:maintenance`,
- `A:notifications`).
+ 9. **Provide a clear and concise description** of the changes you've made.
+ 10. **When publishing your PR, set it as a** `Draft pull request` to allow you to self-review and address any issues before a public review.
+ 11. **Maintainers will assign relevant labels** (e.g., `pr:needs-review`, `pr:needs-testing`, `pr:please address review comments`).
12. **Complete the PR checklist**, ensuring that:
- Documentation is updated if necessary.
@@ -297,18 +258,12 @@ to review the appropriate one for your contribution.
change the status to **Ready for Review** when:
- You have implemented all planned changes.
- - You have addressed all feedback.
- - Your code is fully tested and ready for integration.
+ - Your code is fully tested and ready for review.
- You have updated or created the necessary tests.
- You have verified that CI/CD checks pass successfully.
-
-
- A **work-in-progress (WIP) PR** must stay in **draft status** until everything
- is finalized.
-
- Since maintainer time is valuable, junior maintainers may merge
- uncontroversial PRs.
+ A volunteer maintainer will review your PR as soon as possible.
+ You can also help by reviewing other PRs or taking a look at open issues.
@@ -335,18 +290,14 @@ to review the appropriate one for your contribution.
- Don't modify or delete existing logic without a valid reason.
- Don't convert existing code into other programming languages for no reason.
-I ([@louislam](https://github.com/louislam)) have the final say. If your pull
-request does not meet my expectations, I will reject it, no matter how much time
-you spent on it. Therefore, it is essential to have a discussion beforehand.
+I ([@louislam](https://github.com/louislam)) have the final say.
+If your pull request does not meet my expectations, I will reject it, no matter how much time
+you spent on it.
-I will assign your pull request to a [milestone], if I plan to review and merge
-it.
+We will assign your pull request to a [milestone](https://github.com/louislam/uptime-kuma/milestones), if we plan to review and merge it.
-[milestone]: https://github.com/louislam/uptime-kuma/milestones
-
-Please don't rush or ask for an ETA. We have to understand the pull request,
-make sure it has no breaking changes and stick to the vision of this project,
-especially for large pull requests.
+Please don't rush or ask for an ETA.
+We have to understand the pull request, make sure it has no breaking changes and stick to the vision of this project, especially for large pull requests.
## I'd Like to Work on an Issue. How Do I Do That?
@@ -354,92 +305,9 @@ We have found that assigning people to issues is unnecessary management
overhead. Instead, a short comment stating that you want to work on an issue is
appreciated, as it saves time for other developers. If you encounter any
problems during development, feel free to leave a comment describing what you
-are stuck on.
+are stuck on, we are here to help.
-### Recommended Pull Request Guideline
-
-Before jumping into coding, it's recommended to initiate a discussion by
-creating an empty pull request. This approach allows us to align on the
-direction and scope of the feature, ensuring it doesn't conflict with existing
-or planned work. It also provides an opportunity to identify potential pitfalls
-early on, helping to avoid issues down the line.
-
-1. **Fork** the [Uptime-Kuma repository].
-2. **Clone** your forked repository to your local machine.
-3. **Create a new branch** for your changes (e.g.,
- `feature/add-new-notification-provider-signal`).
-4. **Initiate a discussion before making major changes** by creating an empty
- commit:
-
- ```sh
- git commit -m "" --allow-empty
- ```
-
-5. **Push** your branch to your forked repository.
-6. **Open a pull request** using this link: [Compare & Pull Request].
-7. **Select the correct source and target branches**.
-8. **Link to related issues** for context.
-9. **Provide a clear and concise description** explaining the changes and their
- purpose.
-
- - **Type of changes**
-
- - Bugfix (a non-breaking change that resolves an issue)
- - New feature (a non-breaking change that adds new functionality)
- - Breaking change (a fix or feature that alters existing functionality in a
- way that could cause issues)
- - User Interface (UI) updates
- - New Documentation (addition of new documentation)
- - Documentation Update (modification of existing documentation)
- - Documentation Update Required (the change requires updates to related
- documentation)
- - Other (please specify):
- - Provide additional details here.
-
- - **Checklist**
-
- - My code adheres to the style guidelines of this project.
- - I ran ESLint and other code linters for modified files.
- - I have reviewed and tested my code.
- - I have commented my code, especially in hard-to-understand areas (e.g.,
- using JSDoc for methods).
- - My changes generate no new warnings.
- - My code needed automated testing. I have added them (this is an optional
- task).
- - Documentation updates are included (if applicable).
- - I have considered potential security impacts and mitigated risks.
- - Dependency updates are listed and explained.
- - I have read and understood the
- [Pull Request guidelines](#recommended-pull-request-guideline).
-
-10. **When publishing your PR, set it as a** `Draft pull request` **to allow for
- review and prevent automatic merging.**
-11. **Maintainers will assign relevant labels** (e.g., `A:maintenance`,
- `A:notifications`).
-12. **Complete the PR checklist**, ensuring that:
-
- - Documentation is updated if necessary.
- - Tests are written or updated.
- - CI/CD checks pass successfully.
-
-13. **Request feedback** from team members to refine your changes before the
- final review.
-
-### When Can You Change the PR Status to "Ready for Review"?
-
-A PR should remain in **draft status** until all tasks are completed. Only
-change the status to **Ready for Review** when:
-
-- You have implemented all planned changes.
-- You have addressed all feedback.
-- Your code is fully tested and ready for integration.
-- You have updated or created the necessary tests.
-- You have verified that CI/CD checks pass successfully.
-
-A **work-in-progress (WIP) PR** must stay in **draft status** until everything
-is finalized.
-
-## Project Styles
+## Project Style
I personally do not like something that requires a lot of configuration before
you can finally start the app. The goal is to make the Uptime Kuma installation
@@ -501,8 +369,6 @@ npm ci
## Dev Server
-(2022-04-26 Update)
-
We can start the frontend dev server and the backend dev server in one command.
Port `3000` and port `3001` will be used.
@@ -549,16 +415,10 @@ in the `socket.io` handlers. `express.js` is also used to serve:
It binds to `0.0.0.0:3000` by default. The frontend dev server is used for
development only.
-For production, it is not used. It will be compiled to `dist` directory instead.
+For production, it is not used. It will be compiled to `dist` directory instead via `npm run build`.
You can use Vue.js devtools Chrome extension for debugging.
-### Build the frontend
-
-```bash
-npm run build
-```
-
### Frontend Details
Uptime Kuma Frontend is a single page application (SPA). Most paths are handled
@@ -566,7 +426,7 @@ by Vue Router.
The router is in `src/router.js`
-As you can see, most data in the frontend is stored at the root level, even
+Most data in the frontend is stored at the root level, even
though you changed the current router to any other pages.
The data and socket logic are in `src/mixins/socket.js`.
@@ -577,6 +437,8 @@ See:
## Unit Test
+To run unit tests, use the following command:
+
```bash
npm run build
npm test
@@ -584,8 +446,8 @@ npm test
## Dependencies
-Both frontend and backend share the same `package.json`. However, the frontend
-dependencies are eventually not used in the production environment, because it
+Both frontend and backend share the same `package.json`.
+However, the frontend dependencies are eventually not used in the production environment, because it
is usually also baked into `dist` files. So:
- Frontend dependencies = "devDependencies"
@@ -605,26 +467,10 @@ Patch release = the third digit ([Semantic Versioning](https://semver.org/))
If for security / bug / other reasons, a library must be updated, breaking
changes need to be checked by the person proposing the change.
-## Translations
-
-Please add **all** the strings which are translatable to `src/lang/en.json` (if
-translation keys are omitted, they can not be translated.)
-
-**Don't include any other languages in your initial pull request** (even if this
-is your mother tongue), to avoid merge-conflicts between weblate and `master`.
-The translations can then (after merging a PR into `master`) be translated by
-awesome people donating their language skills.
-
-If you want to help by translating Uptime Kuma into your language, please visit
-the [instructions on how to translate using weblate].
-
-[instructions on how to translate using weblate]:
- https://github.com/louislam/uptime-kuma/blob/master/src/lang/README.md
-
## Spelling & Grammar
-Feel free to correct the grammar in the documentation or code. My mother
-language is not English and my grammar is not that great.
+Feel free to correct the spelling and grammar in the documentation or code.
+None of our mother languages are English.
## Wiki
@@ -633,47 +479,8 @@ repo to do that.
-## Docker
-
-### Arch
-
-- amd64
-- arm64
-- armv7
-
-### Docker Tags
-
-#### v2
-
-- `2`, `latest-2`: v2 with full features such as Chromium and bundled MariaDB
-- `2.x.x`
-- `2-slim`: v2 with basic features
-- `2.x.x-slim`
-- `beta2`: Latest beta build
-- `2.x.x-beta.x`
-- `nightly2`: Dev build
-- `base2`: Basic Debian setup without Uptime Kuma source code (Full features)
-- `base2-slim`: Basic Debian setup without Uptime Kuma source code
-- `pr-test2`: For testing pull request without setting up a local environment
-
-#### v1
-
-- `1`, `latest`, `1-debian`, `debian`: Latest version of v1
-- `1.x.x`, `1.x.x-debian`
-- `1.x.x-beta.x`: Beta build
-- `beta`: Latest beta build
-- `nightly`: Dev build
-- `base-debian`: Basic Debian setup without Uptime Kuma source code
-- `pr-test`: For testing pull request without setting up a local environment
-- `base-alpine`: (Deprecated) Basic Alpine setup without Uptime Kuma source code
-- `1-alpine`, `alpine`: (Deprecated)
-- `1.x.x-alpine`: (Deprecated)
-
## Maintainer
-Check the latest issues and pull requests:
-
-
### What is a maintainer and what are their roles?
This project has multiple maintainers who specialise in different areas.