There should still be a zero-tolerance policy for hidden undisclosed functionality in open source repos
Because when I argue that and give example of easter eggs which caused security vulnerabilities or broke shell scripts on certain dates people reply "oh, lighten up, you are just a party killer, allow some human touch"
Absolutely! Undocumented Easter Eggs cannot be tolerated in any software project today.
Larry Osterman wrote about why Microsoft (and most other major software vendors) banned easter-eggs: https://docs.microsoft.com/en-US/archive/blogs/larryosterman...
The important point is (to quote):
> If the manufacturer of the software that's on every desktop in your company can't stop their developers from sneaking undocumented features into the product (even features as relatively benign as an Easter Egg), how can you be sure that they've not snuck some other undocumented feature into the code.
But if an easter-egg is is documented and implemented following normal software engineering practices then that's fine (of course paying customers won't be happy to learn that's where the team is putting their resources), and you can still keep things "secret" by hiding them in spoiler-tags or similar in your changelist - but there must never be any unaccounted-for functionality in a software project.
But there is absolutely a difference between an easter egg, something that usually takes real effort to discover and trigger, and something that runs as part of normal execution.
In regards to the examples you give where it causes vulnerabilities or bugs, I think it can be a test if the software you're actually embedding the egg in needs to be improved. If an easter egg breaks something then that's probably indicative of a larger problem.
This shouldn't be a difficult discussion in this way.
That describes basically all the code I install from open source repos, bar the very specific section of code I actually use.
There are other solutions.
$ npx create-react-app sample-app
$ cd sample-app
$ cat package-lock.json | jq '.packages | length'
1393
Like one month almost all their posts are about COVID and the next month almost all their posts are about BLM.
But the "current thing" often isn't a new thing, and instead touches on some core value. For example, people who have never been to Ukraine or know anything about it still care about Ukraine because the situation speaks to issues of violence, freedom, honesty, safety, etc. And people who have never watched a college swim meet care about the trans swimmer because it speaks to issues of fairness, inclusion, gender, etc.
I think there's some validity to pointing out that we don't all have to weigh in on national conversations or lose sight of the bigger picture. But I think it's also a way to try to shut down conversations using a blanket criteria: new, popular conversation == bad conversation. That philosophy can't reasonably be applied to all new conversations without doing more harm than good. In my experience the "current thing" critique is very selectively applied to discussions the commenter is opposed to or bored with, which is subjective and very personal.
This has nothing at all to do with the correctness of any of the positions, just their pervasiveness.
So do you. So do I.
It's not a coincidence, and it's not the implied other explanation.
It's because the structure of vote-sorted top-N list sites like HN, Reddit, and so on, focuses most people on the same short list of topics.
We will all bump into each other again, whether or not we have any intention of doing so.
We're all chatting on the first two pages of stories. We will all collide frequently with people holding similar hours.
I'll give less benefit of the doubt with the next troll.
Personally, I don't think I'd count console.log as "hidden/undisclosed functionality", while I would claim opening a browser window is.
But some people might, and if I was creating a FOSS library I would not include it.
---
EDIT: On second thought, I might consider it functionality:
People have application logs that are exposed to customers (so it would cause the company to appear to be taking a stance), or exported to other systems which only understand certain log messages, causing issues there.
it's open source
Just because something is in the source code doesn't mean it's acceptable - it's not disclosed anywhere the majority of people would look: A readme, a NPM description, documentation, etc.
You're looking for better documentation/a community contract.
If I could I'd update my original comment to be more explicit, with either "unadvertised" or "undisclosed where the majority of people would look"