filebrowser
filebrowser copied to clipboard
filebrowser
chore: Remove stale bot
āStale Issue Botsā are the scourge of GitHub. A disease that has affected so many projects I use or contribute to.
It blows my mind that some people have made it their lifeās work to go around adding these bots to as many repos as possible. Said people seem to like looking at blank issues sections, āout of sight out of mindā for unresolved issues. Letās sweep it under the carpet and pretend it doesn't exist.
But high percentage of issues are open because they haven't been dealt with!
Description
:rotating_light: Before submitting your PR, please indicate which issues are either fixed or closed by this PR. See GitHub Help: Closing issues using keywords.
- [x] DO make sure you are requesting to pull a topic/feature/bugfix branch (right side). Don't request your master!
- [x] DO make sure you are making a pull request against the master branch (left side). Also you should start your branch off our master.
- [x] DO make sure that File Browser can be successfully built. See builds and development.
- [x] AVOID breaking the continuous integration build.
Further comments
This PR is critical for the survival of this project. The countless "closed" issues I have been encountering are driving me insane
Given that this is a GitHub config change, it should not affect lint or test at all. No code was touched.
I don't understand what the problem is. If the issue can't be resolved or answered by the community, I don't see a reason to keep it open indefinitely.
One reason is that reports of bugs that continue to exist in the software are being closed, which makes them less likely to be fixed IMHO
Also, the open issues can be thought as a repository of 'known bugs' that users can brows. Searching for them in the closed issues is not ideal, since it's not clear whether it was fixed, or closed for a different reason.
Closed but still an issue:
To be more exact, the stale label was added. It hasn't been closed yet, but will be at this rate :/
I agree with this. All the stale bot is doing is contributing to spam. Then we've got 60+ replies to filter through just with the word "bump".
Perfect example:
- https://github.com/filebrowser/filebrowser/issues/1827
This is not the first time this comes up, there's already been #3337 and #3007 ... I see a growing number of people who are really unhappy about this.
Anyone who is openening an issue or writing a PR is taking their precious time to contribute to this project. There are quite a lot of people that do so - but ultimately, get ignored by having their contribution auto-closed by the stale bot. This means that the time and energy these people invested is wasted, which is sad.
Ultimately, users will either adjust to the situation by no longer contributing, or walk away alltogether. OR huddle together and create a fork. But most people underestimate how much investment it takes to keep a project alive. Most forks die prettty quickly.
Anyway... It's fully OK for @o1egl to do with his project what he wants.
I'm starting to believe that we should bulk re-open all the issues that have been closed by the bot
I'm starting to believe that we should bulk re-open all the issues that have been closed by the bot
Because of the bot, I'd recon there will be plenty of duplicates there :/
I'm starting to believe that we should bulk re-open all the issues that have been closed by the bot
I don't think that's a good idea, as it'll create additional workload on the maintainers. It would clearly be better to clean up the issue tracker here in this repo.
BUT - and that's a BIG "BUT": The maintainers are not very collaborative. I already volunteered to help and keep this repo's issue tracker clean - but I never got the permissions needed.
I also thought about a script that would "ping" issues every 30 days to keep them from being auto-closed. But this ultimately doesn't make sense, because to properly triage issues in the tracker, you need permissions to close issues right away, re-open closed ones and so on.
If o1egl doesn't want help, then (except forking) the only idea I've left is to create a separate project, pull in all issues from this repo, and triage there. That would kind of defeat the purpose of having the issue tracker and repo integrated, but well...
At least we'd have a good overview on open issues. @gingerbeardman, @Mubelotix and @Guiorgy: Let me know what you think about this idea. If you're in, I'd create a new repo and pull in all issues (current and future ones) into it. We could then triage there.
Of course, all this would only create a benefit for the community, if people used that information to contribute fixes to this repo via a PR.
@Equim-chan @hacdias @o1egl: There are people trying to collaborate with you on this project. People propose to help keeping the issue tracked "clean" and up to date. How do you envisage a collaboration? What is keeping you from accepting help? Let's discuss this, perhaps we can dispel your concerns.
I'm starting to believe that we should bulk re-open all the issues that have been closed by the bot
I don't think that's a good idea, as it'll create additional workload on the maintainers. It would clearly be better to clean up the issue tracker here in this repo.
BUT - and that's a BIG "BUT": The maintainers are not very collaborative. I already volunteered to help and keep this repo's issue tracker clean - but I never got the permissions needed.
I also thought about a script that would "ping" issues every 30 days to keep them from being auto-closed. But this ultimately doesn't make sense, because to properly triage issues in the tracker, you need permissions to close issues right away, re-open closed ones and so on.
If o1egl doesn't want help, then (except forking) the only idea I've left is to create a separate project, pull in all issues from this repo, and triage there. That would kind of defeat the purpose of having the issue tracker and repo integrated, but well...
At least we'd have a good overview on open issues. @gingerbeardman, @Mubelotix and @Guiorgy: Let me know what you think about this idea. If you're in, I'd create a new repo and pull in all issues (current and future ones) into it. We could then triage there.
Of course, all this would only create a benefit for the community, if people used that information to contribute fixes to this repo via a PR.
@Equim-chan @hacdias @o1egl: There are people trying to collaborate with you on this project. People propose to help keeping the issue tracked "clean" and up to date. How do you envisage a collaboration? What is keeping you from accepting help? Let's discuss this, perhaps we can dispel your concerns.
I already pinged hacdias end of August but here's his answer
From what I can see, the closed issues are automatically closed due to lack of activity. Whether the project is abandoned or not, it doesnāt seem to be. Oleg seems to reply and interact mostly on the PR side of things. I am personally no longer involved in the project, so Iād suggest directly reaching out to Oleg
I don't have the energy to try to convince an open-source contributor to be more open.
I don't have the energy to try to convince an open-source contributor to be more open.
Me neither
That totally fine with me. I'll keep my personal fork maintained until I find a replacement.
I must think that either @o1egl is acting maliciously, or is so significantly out of touch that he is incapable of understanding why his conduct is an issue.
I don't understand what the problem is. If the issue can't be resolved or answered by the community, I don't see a reason to keep it open indefinitely.
You say "the community" should be responsible for triaging issues, and when we do this you still act incredulous when we complain about the stale bot getting in the way of said triaging. You have people that have stepped forward and offered to maintain the issues and PRsāyou do not accept their help, and instead allow the project to continue at what I must assume is your own pace.
There are clear, demonstrable, triaged, and pinpointed issues in this tracker that cover significant bugs in the project, but they are now closed because of the stale bot. And unless you or someone else plans to go back through all the legitimate closed issues, they will be buried and forgotten about until someone pops up to report the exact same issue again. This hurts the project, it hurts the maintainers, it hurts the users. No one benefits from this, except the project's issue count I guess.
If an issue can't be resolved... you triage it, categorize it, and leave it open until it gets fixed. Issue tracks bug, bug gets fixed, issue gets closed. Issue tracks user ask, community/maintainers answer, issue gets closed. Duplicates get closed and users directed to the correct issue. Issues get tagged so that potential maintainers and contributors have an easier time categorizing work needing done.
You even have issue labels set up, but there have been no active maintainers to add labels/edit titles for over a year now. Give us, "the community", ability to label our own issues and triage our own issues like you want, leave the stale bot on for unlabeled issues, and you will see issue health improve significantly.
And yes, ultimately you are allowed to structure and run your project however you want, but you shouldn't be surprised if potential users, contributors, maintainers, bug triagers, PR testers, etc. choose not to stick around when you dismiss their concerns so flippantly. Considering my current need for a good web file browser, and considering the alternative I switched to did not work out very well (Filestash), I may have opted to break out the tools and send a PR to fix my issue... But I am heavily disincentivized to do so when there's a chance my PR doesn't get reviewed for months and then closed out by the stale bot because I forgot to comment on it at regular intervals.
Why does this not make sense? I don't see what's so difficult to understand about this.
This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
The bot knows we're talking about him. He's starting the take-over. Next stop, Cyberdyne Systems.
It really seems that this project is dying. The maintainers clearly don't care about the community. Honestly, if I was a developer, I would have already tried to fork it but I'm not. Could we imagine that some people are interested enough to fork this project and maintain it from now on ? Are there some people motivated enough and with enough time to do that by any chance ?
On my side, I was interested by this project for 2Ā reasons thanks to the scripts on events :
- possibility to change permissions of a file because permissions are static in the product
- possibility to trigger a bash script to interact with borg backup archives (restore mainly) so filebrowser was a gui.
If someone is aware about a product that allows at least global file permission management and script trigger on event, I would be interested also. I'm not married to filebrowser but it was fiting all the needs at some point.
It really seems that this project is dying. The maintainers clearly don't care about the community. Honestly, if I was a developer, I would have already tried to fork it but I'm not. Could we imagine that some people are interested enough to fork this project and maintain it from now on ? Are there some people motivated enough and with enough time to do that by any chance ?
On my side, I was interested by this project for 2 reasons thanks to the scripts on events :
* possibility to change permissions of a file because permissions are static in the product * possibility to trigger a bash script to interact with borg backup archives (restore mainly) so filebrowser was a gui.If someone is aware about a product that allows at least global file permission management and script trigger on event, I would be interested also. I'm not married to filebrowser but it was fiting all the needs at some point.
This project uses all the languages I work with, the unfortunate part is that I'm already dedicated to a project, and I can't take on multiple large projects.
We don't really know what the status of the project is, other than certain aspects not being addressed. And I get sometimes that developers need breaks, otherwise they get burnt out and that's when they run from their project. So it may very well be that the developer is just taking a small break.
But I'm sure if push came to shove and the project did go in the direction of being dead, someone will fork it and take over development.
I would have implemented my own Go implementation of FIDO, but this has sort of taken a lesser priority now that I have Authentik. Yes, I'd still like for this project to integrate native FIDO / 2FA support, but I also like having seamless integration between multiple projects. And in order to do that, the developer would not only have to implement FIDO, but also integrate OAuth2 / LDAP as well, so that it can be tied into other applications.
This project uses all the languages I work with, the unfortunate part is that I'm already dedicated to a project, and I can't take on multiple large projects.
Too bad, but not everyone has enough time, I perfectly understand that as I face the same issue.
We don't really know what the status of the project is, other than certain aspects not being addressed. And I get sometimes that developers need breaks, otherwise they get burnt out and that's when they run from their project. So it may very well be that the developer is just taking a small break.
I fully agree that sometimes people need break and this is fair. However, what I don't stand is the lack of communication around that. Someone needs a break, fine but tell the community and transfer some permissions !
But I'm sure if push came to shove and the project did go in the direction of being dead, someone will fork it and take over development.
Well I really hope so.
This PR is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.
Just for info, I sent a mail to @o1egl the 21st December and no answer so far. As a comparison, when I wrote an email to @hacdias, he answered right away. So future is not bright it seems ...
@o1egl the problem is that your stale bot config says exempt-issue-labels: 'feature ā,enhancement ā,bug š' which actually is a great setting. The problem is that no labels are applied to the issues/PR created automatically. And currently there is not much activity from the maintainer(s), so those issues are closed even though the issues persist. Also there are several duplicates.
Being an open source dev myself, I know how stressful it is to maintain an open source project. Maybe this project needs some sort of a community manager to sort through the issues and give a timely feedback so that at least proper labels are assigned and (assuming you want to keep the stale bot) those issues aren't closed automatically.
