⚠️⚠️⚠️ Please read this before create a pull request ⚠️⚠️⚠️

[louislam]

(Updated 2022-04-24) Pull requests will be welcome again, but since I don't want to waste your time, be sure to create empty draft pull request, so we can discuss first.

✅ Accept:

• Bug/Security fix
• Translations
• Adding notification providers

⚠️ Discuss First

• Large pull requests
• New features

More details:
https://github.com/louislam/uptime-kuma/blob/master/CONTRIBUTING.md

[chakflying]

It's painful to see you receive hate after all you have done, but it's also painful to see a good community fade away because we cannot move forward. The project has grown so much in popularity, people will want to add features that are more niche and at some point it doesn't make sense for 1 guy to have to test everything anyway!

If you think stability is a problem maybe we can run beta / rc releases, and if you think going through issues is too much a chore we can add people to help close duplicates, etc. But I really believe that bringing more people onboard to help is the way to keep the project healthy.

[nocturn9x]

@louislam as I recommended in my email, you should give write access to some trusted contributors so they can help you. You don't need to be a one man army, it's okay to get some help from the community :)

[louislam]

If you think stability is a problem maybe we can run beta / rc releases

This is a good idea, so that normal users could participate as well.

[mathiskir]

you should give write access to some trusted contributors

Please do it! It would be great to see all those pull requests in uptime kuma without you spending all your free time on it.
This would ensure that uptime kuma keeps getting better for example with new features like an incident system.

[finnie2006]

Yeah, you should there are alot off people that can help just look the prs, the project is a bit frozen right now and misses some features, like an incident system even that there is an pr about it

[mamiu]

@louislam In case you want to make Uptime Kuma a community project, I've reserved this group URL just for that: https://github.com/uptime-kuma

Then you could move this project to https://github.com/uptime-kuma/uptime-kuma and assign members. What do you think about it?

And who else would be interested in this?

[mathiskir]

@louislam In case you want to make Uptime Kuma a community project, I've reserved this group URL just for that: https://github.com/uptime-kuma

Then you could move this project to https://github.com/uptime-kuma/uptime-kuma and assign members. What do you think about it?

And who else would be interested in this?

Great idea

[mamiu]

@louislam @Saibamen @karelkryda @chakflying @Ponkhy @ivanbratovic @iomataani @andreasbrett @bertyhell @gaby @philippdormann @MrEddX @zsxeee @sovushik @AnnAngela @patrickhafner @MarcHagen @LLeny @justSem @Computroniks @ColdThunder11 @jimyhuang @OidaTiftla @raphaelbernhart @c0derMo @marcules @trogper @jensneuber @jcvincenti @xjoker @nixnotcastey @cmandesign @cch-aecomhk @dhfhfk @BCsabaEngine @jtagcat @Lrss @pemassi @tarun7singh @csabibela @Rayzggz
(This list has no specific order. I could've added more people, but you're one of the most active contributors.)

The reason why I referenced you

I've noticed that you've contributed in some way to the success of this project. That's awesome, thank you so much for that! All Uptime Kuma users highly appreciate your time and dedication you've put into this project so far.

The problem

The progress of this project has slowed down quite a bit lately. There are several reasons for this, but primarily because currently the maintenance effort of this project has to be done by only one person: @louislam. And this has led to Louis Lam feeling increasingly pressured and also that he has become tired of reviewing and merging all the pull requests (as mentioned in his statement on Reddit).

One possible solution

In my comment a week ago, I asked Louis Lam to make Uptime Kuma a community project. I reserved the group name uptime-kuma for this. However, to make this possible, we need several volunteers who would like to be maintainers of Uptime Kuma as a community project.

Would any of you be interested in this role?

Or does anyone have a better suggestion on how we can handle all the outstanding pull requests and the future of this great project?

[sovushik]

Greetings! I fully support the proposal, but the last word and decision, alas, is not mine. I contribute as a localizer into Russian, and the promotion of this script among Russian developers.

[MarcHagen]

I think the biggest problem is the lack of project automation. Like GitHub actions for code formatting tests and functional tests.
Now this is by no meaning perfect but will help by getting all PRs to a somewhat acceptable level.

Even bots that help sorting issues and making sure users create issues according to issue template can help release some pressure.

I think a uptime-kuma community project is a create solution.
I’m happy to help setting things up if needed, and we can look at other big community project to make this work like netbox or homeassistant (bot and automation wise).

Creating a slack group or use GitHub (private?) repo to maybe communicate about thing between volunteers is also not a bad idea.

What we maybe also need is just e definition of what the "product" should be and how it should behave.

At some point, like @louislam said, we can and will break things. Maybe look at the source code and see if splitting up / refactoring for a bigger codebase is something we need in the future. I'm "hate" to see project die because it's not maintainable.

Change something here and everything breaks, well just patch this to make it work.

Is never the right solution!

[Computroniks]

As others have said, it does seem like a good idea to split up the workload between more than one person. Well done to @louislam so far for working on this project on their own. Of course, I would love to help in any way that is seen fit.

As for a the suggestion about some form of chat/discussion by @MarcHagen, perhaps Gitter would also be an option as it offers both public and private communities whilst being totally free.

[karelkryda]

Hi,
I've tried many status sites, but I have to say that uptime-kuma is perfect. It would be a shame if it ceased to be maintained.

Of course, I would like to participate in the future of this project and I must say that I like your idea. Of course, it all depends on Louislam, but at the moment I understand that he feels under pressure.

I agree that automating some actions would certainly make the job easier and probably improve efficiency.

Let me know if I can help in any way.

Tl;dr

I will be happy to participate in maintaining uptime-kuma.

[c0derMo]

I think we all agree that splitting up the workload of maintaining would/should be the way moving forward. This isn't an issue "exclusive" to louislam, I think none of us would be able to maintain a project grown to this size all by themselves.

I support the previous ideas here, like moving the project to a more community-maintained repo, increasing the automation level, adding more contributors and communication, etc, and would be happy to help with that. Afterall, collaboration is one of the great things open-source software allows. But in the end, this is still @louislam's choice.

Tl;dr: (@mamiu)

I like the idea of moving the project to a more community-maintained repo, and would gladly help maintaining it, but in the end, it's louislam's choice.

[justSem]

Hi,
I think I side with many people here. It would be a great idea to make this a community project and I'd be willing to help out where I possibly can. But I'm not a professional programmer - though I can do some stuff in python.

I also agree with @MarcHagen in the sense that Uptime-kuma would benefit from a proper definition of what it should be, and what it should not be. This could prevent the project from growing out of proportions and maintain it's quality.
In that sense automation would also be great, to prevent an issue of patching one problem with another.

For communications/orchestration I would be willing to donate server resources if there's anything that would help the project, if that would prevent the project from having to pay for things that we could host ourselves. (I do host it in a datacenter though, so it's reliable :) )

[Ponkhy]

Heyo,
first of all, it's really nice to see how this project grew over the last months!
If course that's a lot of work for one person to maintain and i entirely agree to the people here.
@louislam has and does a fantastic job!

Of course i'd love to contribute and help to main this this project more!
I've done most of the german translation and will probably work them quite a bit in the near future and would love to contribute even more like i've done more in the early days ^^

[tarun7singh]

Hey,

I've worked on small parts of the project earlier.
I agree Github actions related to testing, building, issue maintenance & automated PR testing will help us a ton in maintenance of the project.
Making it a community project is also a great idea.
I'll be happy to contribute to this project as a maintainer or volunteer as well as I would love for this project to grow even more.

[AnnAngela]

I agree that automated tools will make this project better in many ways.

And I also support @mamiu 's opinion about making Uptime Kuma a community project, and would gladly help maintaining it, but in the end, it's @louislam 's decision, I really respect his unparalleled contribution to this project.

English isn't my primary language, I'm not good at it. All I want to say is that, @louislam makes a great, excellent statuspage project, this project helps me a lot, and it would be my honor if I could be a part of it.

[gaby]

@MarcHagen Not only the lack of automation (bots, etc), but the lack of an open-source CI process as I pointed out back in August, 2021 #740

@mamiu I'd be more than happy to help! I was already in the process of creating a fork under a different name and merging some of the big PR's, and going from there.

[OidaTiftla]

I respect how much effort @louislam has put into this project. It would be great if I can contribute and help as a volunteer.

[zsxeee]

@louislam did lots of efforts for this project but still has too many issues and PRs piled up. I'm afraid to commit changes in this situation, too many potential conflicts, especially only one person to handle this. It can not be avoided when maintaining a project alone. Really needs more maintainers to do that.

BTW, we can close "help" issues that have been responded. (Move to Discussion?)

[jimyhuang]

I carefully read the comment from @louislam above. I can totally understand the pressure from pull request, and sometimes it's different with personal plan. I just want to say: it's totally fine with me. Whatever the project is more personal or more community. I can always help as long as it's open source and I have time to spent on it. For example, my personal pull request is more likely an idea or suggestion. It's totally fine to accept or reject. It's not a big deal to me (I can use my folked version for now).

I think it's positive suggestion that @mamiu said to change the project ownership to an github organization. This may solve current situation. But I need to say, changing ownership is not the only option. Louis can always have his personal version of this project, and community may have another one. That's also not a big deal. Open source will sustain when time passed.

Thanks for everyone especially the @louislam made this great project and made this open. I will always happy to join in whatever the decision.

Just for reference: examples which project owner have different plan:

• Some project may freezing because creator finished their goal. And someone took the responsibility for actively maintain version. ( eg. https://github.com/boltdb/bolt vs https://github.com/etcd-io/bbolt )
• Some project may be more personal (but open source). And community have another version of it. Both version have a lots of users. (eg. https://github.com/gogs/gogs vs https://github.com/go-gitea/gitea )

[MarcHagen]

While this is the nature of opensource (when licenses allow) it’s not always practical to just fork it.
Which 2 people are talking about now.

statping and statping-ng are a good example that people still get confused and frustrated over.

Let we all please try to first keep just one version? Give it some time, it’s not that the project is dead…

[justSem]

While this is the nature of opensource (when licenses allow) it’s not always practical to just fork it.

Which 2 people are talking about now.

statping and statping-ng are a good example that people still get confused and frustrated over.

Let we all please try to first keep just one version? Give it some time, it’s not that the project is dead…

This, please don't fork while we still have a chance to keep a single project.

[mathiskir]

I think it doesn't really make sense to talk about that without louislam telling us what he thinks about it.

[karelkryda]

I think it doesn't really make sense to talk about that without louislam
telling us what he thinks about it.

I would say it's more about discussing possible solutions than deciding behind his back.

Of course, everything depends on him, but for myself I can say that I am willing to help.

[jensneuber]

Just here to let you know that I would be happy to help.

I think this project has so much potential and would love see it thrive.
@louislam Thanks for starting it! Let us know if and how we can help out.

[gaby]

@louislam Thoughts on this?

[louislam]

Thanks everyone for your help!

I think @mamiu's approach is good ultimately, but I also think it might be a too big step, because trust might take some time to build. It would be hard for me to judge who should be added to the group. Also at this moment, Uptime Kuma development is just my hobby in my free time. Working as a group of people sounds too serious for me.

With the current approach, the relationship would be less complicated in my opinion.

Too be clear, Uptime Kuma was/is not actually maintained by one person in the past. Many active users such as @chakflying @Ponkhy @Saibamen @gaby (More...) are here helping the project.

And I think the main issue is that pull requests are required a lot of test. I try to list some tasks here if you want a clear path to help or to test this project. (From easy to expert)

General

Test as a Normal User

As @chakflying suggested, now I release beta release for testing purpose. You just need to play Uptime Kuma as a user, see if any unexpectedly behaviors. The docker tag beta is always pointing to the latest beta version.

docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:beta

Helping other Uptime Kuma users

They will be on:

• https://github.com/louislam/uptime-kuma/issues
• https://www.reddit.com/r/UptimeKuma/

Test Pull Request

I will mark pull requests into Milestones if they are going to be merged, so you can focus on these pull requests too.

Pull Request - Code Review

Read the source code (File changed) on GitHub, see if the pull request is including some inappropriate code or formatting issues.

Pull Request - Testing as a Normal User

Checkout a pull request and test the feature as a normal user. Check if it is working fine or any potential breaking changes.

Pull Request - Testing as a Hacker

Checkout a pull request and try to break it.

Create a new Pull Request

If you have some ideas that really want to implement into Uptime Kuma, be sure to open an empty draft pull request with description, so we could have a discussion first.

[nocturn9x]

We understand you may be busy, but the point stands: progress on the repository is slow. If this isn't addressed quickly, development will drive to a halt and people will just fork the repository and maintain it on their own, which is less than ideal. People have offered to help develop this as a community. It's sad to say this, but uptime kuma is no longer a toy project that one person can develop in their free time. Something needs to change.

[mamiu]

@louislam Thanks a lot for taking the time to respond.
I honestly appreciate everything you've done so far! All the time and dedication you've put into a truly awesome piece of software.
As you've probably already noticed, there was a huge demand for an open source uptime monitor solution, which caused Uptime Kuma to skyrocket immediately. Also the state of the art technology you chose for building Uptime Kuma made it super easy for a lot of devs to participate. This whole project was a blessing for many people so far.
The only person who suffered from the ever-increasing responsibility and technical debt was you. The very person we have to thank for this entire project in the first place. And that should no longer be the case!
BTW: I'm sure I've spoken here in behalf of many.

All I'm trying to say is: We've a problem... and please don't just bandage it.

I know I've done it before but give me another try.

Current problem:

• You spend a huge chunk of your free time for the maintenance of this project
• You feel pressured by all the people who want a lot of new features or to get bugs fixed quickly
• You're afraid that with every code change you accept the stability of Uptime Kuma might suffer (which quite serious for an uptime monitor application)
• The progress of this project is slower than it could be since all the weight is on your shoulders
• You don't know how to get out of this situation

Possible solutions:

1. I don't know if you could imagine that, but if you want you could replace your current full time job with Uptime Kuma easily (and get a better income than you do right now). If you're interested, let me know. I'm doing business for quite a while now. Also have been a lead developer for the biggest IT consulting company for several years and can tell you everything from monetization (while staying completely open source) to managing a development team (if you're interested in that).
2. Set a trial period (e.g. 3-6 months) during which you grant at least write or preferable maintainer access to the (let's say) 5 collaborators you trust the most. I wouldn't take many more on board but also not less than 3. Otherwise you have no real comparison at the end of the trial period. When the trial period is over you decide whether you wanna keep doing it that way or if just one person gets maintainer access while some others "only" get write access or whatever you think is the best for the project in the long term. Trust me, devs like @karelkryda who have a bunch of big outstanding features (which they have developed in their free time as well) definitely won't disappoint you! They will do their best to push the project forward in all aspects. From my experience so far I can tell you that the greatest things in life always started with a leap of faith.
3. If you're really concerned that multiple people with write or maintainer permission would mess up the project you could still do what I've suggested in the previous possible solution (number 2.) with the difference, that you tell them (or restrict access) not to work on the "master" branch. Instead they can work on separate branches and use a different main branch (e.g. called "main") which diverges from master. Don't do any changes to master during the trial period or if you want to also always integrate them in the other main branch (where all the new devs work on). After the trial period you can then directly compare the master with the main branch in terms of stability, features, user satisfaction, etc. If it ended up as a real mess, just ditch the new main branch. But if you prefer it over the current master branch, you can make the "main" branch the default branch. You could also create separate contribution guidelines for the other main branch, like the use of gitflow or something like that (which you think is beneficial when having multiple maintainers) and check the adherence to these if that's important to you.

If anyone has other / better suggestions, just add them here as comments.

[bertyhell]

A lot of these issues would be fixed with automated tests.
Tests take a lot of time to write though.
The nice thing is that we can easily split up the work among multiple developers.

All we need is a PR setting up a ci/cd flow to run the end-to-end tests automatically on every PR/beta release.
And one example test. Something in Cypress or Playwright would work well.

And then we would need to write out what scenarios to test. Maybe a google doc where everyone can just add to the same list of scenarios until every little features is checked.

Then we divvy up scenarios to developers who want to help create these tests.

After that @louislam can be reasonably sure new PR's do not break any existing features. It moves a lot of the checking work to the developer making the PR, instead of @louislam

We'll just have to include an end-to-end testing requirement for all future feature PR's.

This would solve these issues:

• 🟧 (partial) You spend a huge chunk of your free time for the maintenance of this project
• ✅ You feel pressured by all the people who want a lot of new features or to get bugs fixed quickly
• ✅ You're afraid that with every code change you accept the stability of Uptime Kuma might suffer (which quite serious for an uptime monitor application)
• 🟧 (partial) The progress of this project is slower than it could be since all the weight is on your shoulders
• 🔳 You don't know how to get out of this situation

[Saibamen]

About Cypress: I don't recommend it (yet) for SPA application because of this bug: cypress-io/cypress#7306

[AlexDaniel]

About Cypress: I don't recommend it (yet) for SPA application because of this bug: cypress-io/cypress#7306

Ha, because of one bug! That's not the only painful issue with cypress. Here are the issues from the top of my head that affect every single work day for me:

• Re-query elements that are found 'detached' from the DOM cypress-io/cypress#7306 – yes, as already mentioned, but I'll expand a bit: it's absolutely impossible to have stable tests, you'll have to bump the retries in CI a lot, and locally just accept that you will be hitting the rerun button all the time. It's good if you get a “Detached from DOM” error, but it's more likely that cypress itself will be attempting to make calls on undefined (how does it even manage to do that I have no idea! Like you'd have cy.contains('…').click() and it'll say that it cannot click on undefined, WAT).
• max 1 site... support visiting multiple superdomains in one test cypress-io/cypress#944 – no way to test integrations, no way to test navigating away. Even if you isolate all of your individual tests to a single domain, then still, every time you go from one it to another and run cy.visit, Cypress will drop its entire state and start the test from scratch. Ugh!
• You can do something like this to test multi-domain stuff, basically separating the tests into separate its that depend on each other. Except that in that case you're throwing away the ability to use retries, which you ABSOLUTELY need because of the detached DOM issues!!
• Need tab support cypress-io/cypress#299 – no tab support, similar to the previous issue, but you might not necessarily need it
• Something that is not reported anywhere, is that when cypress does switch to another domain, it will start loading all of the tests again, which can take up to 10 seconds (doing nothing, just loading!)
• Execution time increased drastically after upgrading from 8.3.0 to 8.6.0 cypress-io/cypress#18564 – the latest version of cypress that you can use is 8.5, all next releases are completely useless because you won't be able to use them in GitHub CI. Something about a regression in video recording taking so much CPU resources that your tests will crawl to a stop even on relatively nice github runners.
• Enable Video only on Retry cypress-io/cypress#16672 – you might be wondering why does Cypress even need to write videos of absolutely everything, well, that's because it doesn't have video: 'on-first-retry' option, and the ticket asking for that option is closed without resolution! (No, it's not an insane request, in fact Playwright already has that option!)
• Multithreading or process based parallized test runs cypress-io/cypress#3599 – and on top of all that, you're not allowed to have parallelized runs! Because it's a paid feature! WAT
• Of course you're not going to live without parallelized runs, but you might not actually want to deal with Cypress Dashboard or Sorry Cypress, so you will do something like this:
  
  Except that Cypress doesn't have an option like --shard=1/10 to automatically divide the tests (unlike, ahem, Playwright), so you'll be maintaining the sharding by yourself!!
• cy.visit() occasionally loads blank page cypress-io/cypress#4383 – sometimes cypress will open a blank page and will not run your tests! That's OK, just hit the rerun button!
• Tests randomly finish early and passes cypress-io/cypress#9102 – OK, now it's running, except that it will now prematurely finish “successfully” without running all of your tests!!! WAAAAAAAAT. AND THE TICKET IS CLOSED WITHOUT RESOLUTION!

I've been waiting for a year for these issues to resolve. It has not improved even a single bit… or maybe it did? I can't upgrade to a newer version of cypress (because of the still unresolved major performance regression) so I can't even tell!!!

At the time, I've made a good decision to write e2e tests, but unfortunately I've made a horrible mistake of using Cypress. My current understanding is that Playwright is the way to go, and that you should avoid cypress at all cost.

P.S. I actually don't know about Uptime Kuma, I just found a backlink from a comment that I found interesting, so my rant mode got activated.

[github-actions]

We are clearing up our old Pull Requests and yours has been open for 3 months with no activity. Remove stale label or comment or this will be closed in 2 days.