Have you ever followed citations before? In my experience, they don't support what is being citated, saying the opposite or not even related. It's probably only 60%-ish that actually cite something relevant.
I don’t think they meant literally “any” but more like a device with a speaker could be delivered to you that has a speaker/microphone. Like a Bluetooth speaker you order of the internet. It seems it would probably have to be personally targeted to you, but in that case, there are probably simpler ways.
The main issue is that there isn't any governance to the plugin store. Once you have a plugin in there, you have free reign to do whatever you want with it. Getting it in there is a PITA though. For example, a library author and I created a plugin, but they wouldn't let me submit it because I wasn't the other author, and they wouldn't let him submit it because he wasn't me. True story.
TBF there is some scrutiny on existing plugins, the team is just extremely understaffed (it’s ran by volunteers after all). I got involved in a plugin that ended up getting de-listed for some minor ToS violations after several years of being “fine”, they re-reviewed the plugin with the same rigor as a new submission.
Kudos to these volunteers, but as long as one single company continues to insist on owning all the resources of the plugin and theme directories, I don't think they deserve to continue profiting from volunteer labor.
It’s like being invited to a party in someone’s house. One person starts smoking in the house. Sure, one person is no big deal. Then another person lights up because someone else did, and hey, they don’t have to live there tomorrow. Before you know it, 5–10% of people are smoking and making it stink for everyone, but it’s fine. They’ll stop eventually, and it’s not like you have to live there.
Unless someone stands up and says "no smoking in the house" ... people are going to keep smoking.
> Unless someone stands up and says "no smoking in the house" ... people are going to keep smoking
Sure. But if if someone says the house will burn down when the first person lights up, and they’re ignored, and it doesn’t, that doesn’t help. Most importantly because it isn’t true.
> if your contribution is not merged in, it should not count as "work done"
I highly disagree with this. Sometimes someone has to do the work to discover that isn't the work that should be done. As an example, last week, I got in a fight with the Go scheduler: https://github.com/php/frankenphp/pull/2016 -- in the end, we were able to find the one-liner that is a happy-medium. I didn't open that PR, but I did the work; if that makes sense.
In a program like this you can’t optimize for the assumption that every participant is acting in good faith and contributing good work even if it’s not accepted.
If a program incentivizes opening PRs even if they’re not accepted, the result will be a lot of maintainer spam from people opening useless PRs. This isn’t a personal hypothetical, it’s what we observe any time programs try to incentivize open source work. See the Hacktoberfest drama of years past where the promise of a T-shirt led to spam PRs across GitHub https://joel.net/how-one-guy-ruined-hacktoberfest2020-drama
It’s not a separate topic. You have to structure the program so that abuse is disincentivized from the start.
In the T-shirt example if you left the program as-is but then decided that tackling abuse is a separate topic, think about what that would look like: Every maintainer would now not only have to read and close the spam PRs, they’d have to go file an abuse report for every single one of them. Now you’ve put even more work on the maintainers and created an additional burden of reviewing reports, all without clarifying the program to discourage abuse from the start.
This is why it’s necessary to structure a program clearly such that abuse-level or low effort inputs can’t easily claim the rewards.
I mostly agree here, but the other side is now maintainers will be aware that not merging a PR could financially impact someone. I don't know that that's a great system, either.
There was a time when “full-stack engineer” actually meant someone who could run an entire application end-to-end—HTML/CSS, backend, databases, nginx, Linux servers, deployments, the whole thing. As Big Tech productized those environments and startups realized they could merge multiple roles into one salary, the title became increasingly attractive. People saw the compensation associated with true generalists and started putting “full-stack” on their CVs even when their experience only covered a slice of the stack. Bootcamps and junior developers adopted the term too, and hiring managers kept accepting it because the candidates were otherwise solid.
Now the title has been diluted to the point where it often just means “comfortable with JavaScript on both sides of the wire, plus maybe Mongo or Redis.” The original depth is gone, replaced by tooling and abstractions that compensate for the skills the term used to imply.
codex cli used to do this. "I can't run go test because of sandboxing rules" and then proceeds to set obscure environment variables and run it anyway. What's funny, is that it could just ask the user for permission to run "go test"
A tired and very cynical part of me has to note: To the LLMs have reached the intelligence of an average solution consultant. Are they also frustrated if their entirely unsanctioned solution across 8 different wall bounces which randomly functions (just as stable as a house of cards on a dyke near the north sea in storm gusts) stops working?
I had the pleasure of working with teams that couldn’t even figure out how to use analytics in their product. They had zero idea who was using it and how many people were using it. They ignored the thousands of DB deadlock messages in the logs; well, they just ignored the logs completely, actually. All they cared about was shipping the next feature and getting the one QA guy to agree it was working correctly so the ticket could be closed.
This is the default. I have a few teams like this under my charge, currently.
I ask them to protect themselves by logging what data they will need to troubleshoot a new feature.
Next release comes around and there is an issue and guess what...devs asking for access to prod to troubleshoot because they don't have logs.
It is really difficult to contain oneself when getting on a call to quiet three endless chat threads because someone failed to log basic shit.
Days long anxiety-filled shit storms for absolutely no reason.
I have had other teams that would do this and they had to have the fear of God put into them to wake up and start logging. We have real problems to solve without confounding ourselves...
reply