Open source maintainers aren’t here to teach contributors how to write better code, we’re here for maintenance of the project. The review prevents shit getting merged. Humans write shit too. This is what reviews are for
That is just mostly wrong. Around 90% of the time, when you do a review, just fixing the issue that you found is much faster than explaining the issue and saying what needs to be done instead.
Reviews plainly are for educating the contributor to what constitutes “non-shit”(using your terminology) code on the repo. If that wasn’t the case, you could just not do a review and just change the code, without any interaction at all. Why would you communicate the change that needs to be done otherwise?
Rarely of course, something is so complicated that it actually takes more time to come up with the right code than do a review. But that is only a rare thing.
Rarely of course, something is so complicated that it actually takes more time to come up with the right code than do a review. But that is only a rare thing.
This is definitely a thing though.
On this very topic, many llama.cpp PRs are good examples. A model trainer may present a PR with poor understanding of the (very complicated, highly specialized, sparsely documented) project. Then a maintainer comes to fix it, but has absolutely no knowledge of certain things the model trainer would know (“Oh, the whole thing NaNs if this one value on layer 23 isn’t FP32!”)
There has to be a back-and-forth. A whole lot of it.
That is an exception, yeah.
But I’m not sure I’d call it “rare.” There are definitely situations where fixing without explaining is ultimately a whole lot of work.
I don’t need to explain the issue, that’s what the issue report does
I’m sure every project is a little different. The one I maintain has well over 1000 merged PRs now (2000 if you count the old repo), and I’d be dead if I did even 1/4 of the work contributors do
Plus, even maintainers must have a code review and functional testing on their PRs, so doing the work yourself doesn’t relieve the human workload that must be done. It actually increases total maintainer effort to do the work yourself
I’m not talking about the work contributors do, obviously that is invaluable.
But if you do a review, and you see that a function should be extracted at one point to avoid code duplication, is it really faster to tell the contributor that a function needs to be extracted there, compared to just extracting it yourself as you see it?
The value of a review is collaborative truth finding and learning. If there is an LLM on the other end, that’s just not happening.
If I do it myself, I might be missing the reason they did it that way. The dialogue is useful, even with a machine capable of reasoning.
If I do it myself, now yet another person has to get involved because a person who has written code cannot be an impartial reviewer.
The value of any given contribution is the same, regardless of whether the code was written by a seasoned developer, a neophyte as a first project, an LLM, a team of high school students learning the language, or space aliens - the code is the code, it helps or hurts exactly the same when merged with zero connection to who or what wrote it.
Caring about who or what wrote the code is applying prejudice. Prejudice works well in a lot of cases, but it’s no guarantee.
If you are accepting submissions from anonymous, or insecurely identified (same thing, really), contributors, they should all be treated with zero prejudice. You might think you know who or what wrote the code based on the name in the linked e-mail address, the way comments are (or aren’t) written, or a million other “tells” in the code that aren’t about the function of the code - that’s really irrlelevant. What’s relevant is: what does the code actually do after it’s merged.
If you’re trusting code because you think its “tells” track with seasoned developers, be prepared - very very soon - for maliciously crafted code full of “seasoned developer” tells to slip in backdoors and other malware, because bad actors are already using AI to mimic the things you want to see in a submission in order to gain your trust and lower your guard against them slipping in the things they want in your code base.
You’re right. It’s not about the code though, it’s about the interaction with the individual submitting the code. It is natural for humans to want to use language that is meant for communication between humans to actually reach humans.
The value of any given contribution is the same, regardless of whether the code was written by a seasoned developer, a neophyte as a first project, an LLM, a team of high school students learning the language, or space aliens - the code is the code, it helps or hurts exactly the same when merged with zero connection to who or what wrote it.
Caring about who or what wrote the code is applying prejudice. Prejudice works well in a lot of cases, but it’s no guarantee.
the blog post is not about who actually wrote the code, but whether it’s worth the effort to do a thorough review. if an actual person made it, then yes because they can learn from it and the world becomes a slightly better place. if it was a vibecoder just using an LLM, then explaining what needs to be done and why does not add much to.the world, but it possibly helps to make the LLM company richer
whether it’s worth the effort to do a thorough review.
If the vibe coder learns how to vibe better…
I’ve been using LLMs for a lot of things since last October, the models have improved pretty dramatically since then, but so have my skills in using them - so it’s hard to tell (and probably unimportant) which factor is more important in the increased quality and efficiency of my code production and reviews over the last year.
Using LLMs to review code (regardless of who/what wrote it) is a more efficient way to improving code quality, security, maintainability, etc. than just reading it all yourself. Certainly don’t go blindly trusting the LLM reviews, but if you haven’t tried them for pull request review, you should…
Part of being a maintainer is helping to onboard new contributors, this is why many projects have a tag for “good first issue”. Teaching people how to use the library/tool is part of that.
deleted by creator
I have some friends that are thinking of investing into some HiLow systems and making our own intranet. Or a meshnet. Seems like a fun project.
And no random bot scans, no agencies, no nothing but our own sites.
The problem with closed meshnets is: scale. Do you have “critical mass” necessary to keep people engaged and returning and creating new content?
Cant know until we try!
deleted by creator
I wish meshtastic did any of that. Its more like a worse pager. Fun hobby to get into but its not all that great at reliable packets.
We’ve been rolling along with weak IDs on the internet since the beginning. Strong, secure identification would change the nature of most of these problems. It would make anonymity a choice instead of an illusion, you want to be anonymous, you have to work at it. As things are, people think they’re anonymous, but they really aren’t - and yet most services treat people as if they are anonymous so people tend to act that way.
Strong, secure identification would change the nature of most of these problems. It would make anonymity a choice instead of an illusion,
wrong. it would take away the choice.
Wrong yourself. Strong secure identification would be required in places that require identification. Users and useees would make a conscious choice when they are going to act anonymously or allow anonymous participants.
Already 99% of the web effectively identifies users well enough for law enforcement to track them down, this would just bring that process into the light, and when you want anonymity you would take necessary steps to make it true, instead of a false security blanket like all the BTC idiots talked like they had before (and even after) Dredd Pirate Roberts got taken down.
deleted by creator
If you’re going to TOR and discard all tracking cookies, and only use anonymized contact methods (not e-mail accounts linked to your credit cards…) then you’re on the right track.
I mean might have to go back to old school with this type of repo, before internet repos were around, have to request for access to the code and confirm you cannot use AI to help you in any way before getting it
Then don’t be prejudice and invent worries about how the code was generated. We have prs for a reason.
