And regarding the corporate exploitation of open source projects, I've just discovered that a Facebook employee reimplemented the app [1] using actions and published it using the same name and configuration syntax on the GitHub Marketplace [2], so I can no longer publish my app without renaming the project.

Facebook was using my app in the React Native repository, until they have replaced it with their own implementation [3].

It would be nice if they weren't jerks and at least not casually seize the project name, but here we are.

Meanwhile I'm still banned from Facebook for no reason, after I've recently signed up to use Wit.ai, and they illegally hold control of my personal data on Facebook and Wit.ai.

https://news.ycombinator.com/item?id=25033510

https://github.com/wit-ai/wit/issues/1946

[1] https://github.com/hramos/label-actions

[2] https://github.com/marketplace/actions/label-actions

[3] https://github.com/facebook/react-native/commit/f9c2157141b8...

Hey, I remember you! I linked to that story in the entry on Facebook in my shitlist (https://blake.instantfloppy.net/shitlist#facebook).

I've always thought about making a shitlist.

Maybe you've just inspired me to actually do it.

For me it started as a bookmarks folder because I could never remember why I hated [thing]. It takes more time than I'd like to add entries (especially in bulk and especially to make archive links for them). If you make one you're welcome to take my entries so long as I can take yours!

I like your list, and now you have yet another entry to add. :(

Have you considered insisting they credit you as your MIT license requires?

I have opened an issue on the React Native repository, please share it and help me find a solution.

https://github.com/facebook/react-native/issues/30395

Hopefully they will be helpful, and I don't have to take legal action regarding the project name, nor file a GDPR complaint for the loss of control over my personal data.

I did submit your issue to HN and now it's on the front page. I hope Facebook rectifies and I also hope Facebook engineers who hang around HN finally realize what harm their shitty employer does to the ecosystem of open source.

I agree with GP that you don't need to answer anything you don't want to, and ignoring is a valid approach. And I think closing issues is also a valid approach, it's your project after all and you can do what you want. That said, I would prefer maintainers didn't close issues that aren't actually resolved, and instead just ignored them. Maybe apply a label like "Needs more info" or "too busy to investigate" or "help needed" and just filter them out of your view.

The reason for this is that it allows others to chime in and add to the issue, and for users to discuss it among themselves and even find solutions and workarounds. I can't say how many times I've had an issue with some open source project and I find related thread in the github issues. And often the solutions or workarounds are suggested by community members, not the maintainers. But I find it soooo frustrating when the issue has been closed by a "stale bot" because it hasn't been active for 30 days.

This is the spirit of open source, IMO. The creator shares their work with the world, with no commitment or obligation, and the world makes of it what they can. Maybe the maintainer volunteers to help people troubleshoot their issues, or maybe the maintainer is too busy. That's ok. Let the issue sit there, and maybe another kind soul will happen across the issue and answer the question. There isn't enough info to reproduce? That's fine, it's quite possible - even likely - that someone else experiencing the same problem will find the issue and be able to add more context.

I loathe, I despise the stale bot on GitHub. It’s a horrible idea that should never have been implemented, and should be ripped out and thrown away with prejudice in every single case. There is simply no genuine use case for it where it does less harm than good. It is honestly the single thing that I interact with on a meaningfully regular basis that infuriates me the most.

I share your loathing.

The stale bot will unhelpfully ask if "this is still an issue" or if something is being waited on for a pull request. You take the time out to reply, so that stale bot keeps the issue open. Repeat this meaningless back and forth, for months as the maintainers ignore the issue or pull request. Eventually lose the will to continue and let the bot close the issue or pull request.

Net outcome: A potential contribution or solution lost.

Stale bot only exists for aesthetic reasons, to keep issue lists clean and to close issues that maintainers don't want to deal with directly by abstracting away the interaction.

More maintainers should understand that it's OK to just ignore an issue but leave it open.

I'm tempted to make an anti-stale bot that comments on every open Terraform issue to force a human to deal with them. I find new bugs in Terraform providers at least once a week, and invariably they're bot-closed with no resolution. There's no justification for it at all.

Unfortunately, I imagine that GitHub would kill an anti-stale bot even faster than their stale bot kills issues.

I was recently thinking along the same lines. Would definitely use it!

As the maintainer of a moderately popular project on GitHub I'm torn in this. I often get issues where I try to solve the user's problem and think I have answered the question or provided a solution, but don't get any reply from the reporter when asking if it is solved, sometimes for years. I configured Stale Bot with a IMO generous delay so the user has enough time to at least give a short reply if the issue persists. If it does, I'll gladly add a 'pinned' tag to keep Stale Bot away from it. But in the end the bot just does what I'd do by hand anyway.

If it's configured with a short timeout and with preventing further comments, I totally agree. That's rally annoying. But maybe there are circumstances where it's actually useful.

I can't agree more. It's like the CADT model (https://www.jwz.org/doc/cadt.html) but on steroids.

Who owns the issue tracker — the maintainer or the user base?

If the maintainer is using the issue tracker to prioritize development, they should feel fine about closing issues, especially when those issues are underspecified, ignore the project's contribution guidelines, or are otherwise incomplete.

> That's fine, it's quite possible - even likely - that someone else experiencing the same problem will find the issue and be able to add more context.

That's not my experience with issue trackers. It's far more likely that underspecified and otherwise problematic issues accumulate until the issue tracker becomes borderline useless.

The issue is still there if it is closed, including any contributed but unapplied patches.

And you likely meant this, but I have often discovered, or provided, patches.

Upstream may not care about them, but they can help others with edge cases too.

I like your bot and have implemented similar rules in Derek to help out with the openfaas project. It's not quite as configurable as your version, but if folks are interested they can find out more at: https://github.com/alexellis/derek/blob/master/USER_GUIDE.md

There are automated actions when people delete the issue/PR template, and when they don't sign off commits for the DCO. This saves me a lot of time personally having to go and comment and explain every time. I'm going to take a closer look at your bot going forward. Thanks for sharing it.

Very cool bot! I was looking for that kind of bot a few months ago, but I couldn't find one that was still maintained, so I created my own[1]. But if you're going to continue maintaining yours (despite the FB debacle), I may just use yours instead.

[1] https://github.com/jonathanhefner/verba-sequentur

Why not just use the canned answers feature of github?

(Yes, looks like your software can do more)