Oddbean new post about login | logout I understand that this might be a controversial opinion, but I believe that new developers should not contribute to established open source projects. It only makes the lives of open source project managers more difficult. If a developer cannot understand the basics of full code base, they should not contribute. This practice is essentially turning into spam and is akin to a DDoS attack on the open source community. Many open source projects are considering going closed source due to this exact reason. People with little to no coding knowledge are literally practicing on main ExpressJS repo. What a nightmare for these project managers. https://video.nostr.build/84049a473935a18ab66e30c582f7ea7adb1dfb23ff461d1504dac7194a9f0a2f.mp4
Huh, interesting. Wonder why they do that.
Because they don't understand open source, some YouTubers have misled them by claiming that having more open source contributions guarantees a job. Certain companies even began offering T-shirts as incentives for increased contributions. In this specific instance, some irresponsible YouTubers created a video demonstrating how to send automated pull requests on Express, Node.js, and the Open Source Community, leading to a flood of viewers replicating the process. It's concerning when you reflect on the situation.
Well but that sounds like a very short-term disruption.
They can just limit who is allowed to contribute what, in the settings.
None of these pull requests (PRs) are getting accepted, but someone has to manually check whether they are the right PRs or wrong PRs. With this spam, it becomes extremely hard and time-consuming. Remember, most of these developers are not getting paid by any company; they are open-source developers. So, this is literally a nightmare.
I'm unsure as I never tried this on github before, but: Isn't it possible to limit by default who has the permission to even create a PR on a particular project? We used gitlab internally, selfhosted, for ages, and even there in a rather small team we had settings like this to keep things somehow "controlled"...
Who’s even updating the readme?
I don't really get what's going on in there tbh. Are these commits on ExpressJS main?
People going for the lowest hanging fruit and as they don't know shit, they miss the mark and thus only waste the time of the maintainers. In this case, they propose to change the documentation and probably they suggest to add a linebreak here or a comma there.
Yeah, which is utterly stupid, but then again, from what I remember from other systems, I'd prevent this early on by making sure people who have the permission to create a PR already earned some "merits" in the project or otherwise have proven to add meaningful contributions. Not sure whether github supports that, though.
GitHub doesn't allow a project owner to block PRs. You can spam any public project with PRs. And people use it to file issues where the issue tracker is not public. Lets improve on that in NIP34 💪
Dumping some nip34 thoughts: 1) maintainer opt-in feature 2) allow list or WoT based 3) must be clearly communicated to potential contributors in clients 4) could specify rules that could be implemented in a ci environment via a DVM. Eg. Must add or update tests, or must pass standard ci pipelines. A DVM could run the checker against the PR/patch set and respond with a specific comment before the PR gets shown publicly and to the maintainers.
This seems like... a very easy problem to fix, assuming you can change up how github work, which I'm assuming you can't and that's the issue, so here's hoping for the nostr git to get the love it needs =3
I agree with the problem but not the solution. Yes, paying people to get changes merged is an attack on projects. I've seen this first hand where all of a sudden random BS PRs emerged. But ... "Open Source" is a license thing which requires public source. Closed source is the absence of an OSI approved "open source" license and does not mean that the source is not public. Open source projects normally cannot simply change their license as all contributors would have to be asked or you would have to remove all their contributions (or they were planning for this from the start and had all contributors sign a dual licensing form which gave usually a company the right to use the contribution in closed source, too. If in my project something like this would happen, as a maintainer I would employ bots to throttle contributions. First time contributions to non-code files could get auto-closed with an appology comment.
You're correct, and I don't mean open source in its entirety. In fact, I believe best way for someone to learn coding is likely by building their own open source projects. The issue arises when new developers aim to contribute to well-established projects solely for resume enhancement or "to get started", turning it into a rat race. Some YouTube influencers are also blamed for this; this recent issue arose due to one irresponsible YouTuber. While it can be a valid learning path, there's a right approach. And also It was an easy fix for GitHub, but I don't really have a lot of hope; they are busy selling Copilot.
