@liw I'm really tired of this at work. Lots of "I really like this technology, we should use it for something" with no reasoning behind what actual problem would be resolved. And when questioned, just respond with "but it's so great!".
I had occasion to look up the truisms we (or Daniel) wrote for the Yakking blog. I still think they're a good read, so I'm spamming you all with the link.
Before suggesting a solution to a problem, it's usually best to first describe the problem.
"Let's start keeping spare change in a glass jar on the kitchen table."
That might be an excellent solution to spare change getting lost and making the couch uncomfortable. It's a really bad solution for debugging a build problem in Rust.
Those receiving the suggestion will have a hard time responding without context. Don't assume they can deduce or guess the context. That way likes misunderstandings.
There's treating people like objects. There's cheating on your wives. There's defrauding people financially. There's asking foreign powers to help you get elected. There's lying thousands of times a year as president.
And there's being nakedly evil, like trying to prevent much of humanity from getting access to life-saving medication.
Good places for project documentation:
* project web site
* project source tree in README
* anywhere referred to explicitly from the above
Bad places for project documentation:
* blog posts
* mailing list archives, public
* mailing list archives, private
* private emails
* chat logs
* commit messages
* closed tickets
* open tickets
* letters to the editor, published
* letters to the editor, unpublished
* people's heads
* cave paintings
* DNA of custom bacteria
* interstellar probes
* value of pi
Dangerzone: Working With Suspicious Documents Without Getting Hacked https://tech.firstlook.media/dangerzone-working-with-suspicious-documents-without-getting-hacked
http://suihkulokki.blogspot.com/2020/03/this-is-year-not-to-fly.html blogged about the other reason why not to fly this year