Hacker Newsnew | past | comments | ask | show | jobs | submit | reconvene1290's commentslogin

I agree. My ideal forge would be SourceHut but with GitHub style PR workflow (as opposed to email).


It’s all in the approach: start with a “thank you for the project”, and a “hope you don’t mind but I’ve corrected a few typos” and nobody will shout you down. Only go with a blank PR description and it’ll come across as arrogant and spammy.


As a counterpoint, these kinds of formulaic ingratiating preambles turn me off. Get to the point of your PR, so I can judge on its merits!


completely agree, I'll take "fix typos" any day over three sentences that don't add anything of value


There are people hunting double spaces or typos in code? For what contributor credits?


As a maintainer of a few open source projects, yes it happens a lot.

I want to believe some people just want to send small patches to projects when they notice something (I tend to do the same for projects I use) but my impression is a lot of them do it so that it shows up as "contributions" on the GitHub profile which they can then add to their resume (or get some other kind of street cred).

At least typos are actual fixes, far more often you get complete spam (people copy-pasting the contents of PRs and issues from 5 years ago, sending bizzare pull requests with hundred of commits as a merge commit, leaving cryptic comments on 5 year old commits). The spam reporting process on GitHub is kind of annoying to go through, but I trudge through it every time we get one of these PRs. There was one year of Hacktoberfest where some streamer told people that if they just spammed projects with 5 PRs they would get a free shirt and every open source project was DoSed by hundreds of garbage PRs made by accounts created the same day.

Personally as a maintainer, if someone is fixing one typo in order to "get started" contributing to a project I would prefer that they go through and check for any other instances of typos in the project to make a more complete fix (or even better, add a CI job that runs codespell or similar spell checkers). That feels more like someone actually interested in fixing something about the project, as opposed to sending a one-line drive-by patch to pad their resume. (I'm still happy to take the patch of course!)


> Personally as a maintainer, if someone is fixing one typo in order to "get started" contributing to a project I would prefer that they go through and check for any other instances of typos in the project to make a more complete fix (or even better, add a CI job that runs codespell or similar spell checkers). That feels more like someone actually interested in fixing something about the project, as opposed to sending a one-line drive-by patch to pad their resume. (I'm still happy to take the patch of course!)

I have to disagree, changes to development processes are the worst kind of drive by contributions. I don't want CI jobs contributed from someone who isn't going to maintain them.


I mean, I would prefer that it be done as part of a discussion with upstream but if you're talking about a GitHub Action it's not really that much effort to maintain in my experience.

But even if adding CI jobs is not the preference of upstream, I would prefer that the contributor runs codespell locally and fixes all of the issues rather than just sending one-line patches. And I can imagine much worse forms of drive-by contributions than CI jobs that you can easily disable in the future.


I fix documentation typos or broken links because they really annoy me. There are some egregious examples of people doing it for GitHub-as-a-social-network reasons, but I think some are like me and just want to fix the writing.


I always start with a small patch to test the waters of a project. That way i dont waste my time with a larger patch if the project is a PITA to contribute to.


I similarly contribute only minor language and writing corrections to Wikipedia, and usually anonymously (unless my phone has randomly pulled a blocked IP and I need to sign in). I don’t consider myself enough of an expert in any Wiki-worthy topic to do anything more, but I’ll make damn sure small mistakes get addressed.

I feel even less qualified to contribute corrections on GitHub mostly for the same reasons mentioned above. Staying anonymous prevents anyone from thinking I’m attempting to capitalize on low hanging fruit.


Yes.

There’s also a couple of video tutorials that show how to make a pr, using node or nom on GitHub, and people just follow the tutorial verbatim, not thinking about what they’re actually doing.


oh boy... I am thinking of having it as an interview question - once someone raises a PR for an empty space it's an obvious NO )))))


Yes. I have a lot of long, boring stories about exactly this.


> and nobody will shout you down.

Unfortunately not my experience everywhere.

> Only go with a blank PR description and it’ll come across as arrogant and spammy.

Not at all what I was doing when I triggered the open source maintainers I was talking about.


Lover = bit on the side.

Partner = main romantic connection.


Partner doesn't mean that at all.

Warren Buffet and Charley Munger were partners. So were Jobs and Woz. Or Buffet and Gates while playing Bridge many times. There's absolutely nothing romantic or sexual about the word "partner" itself, though of course partnerships exist in those realms as well as in business, sports, music, dance and countless other pursuits.


In reality, people won’t pay for things they say they will; it’s cheap rhetoric to try to get maintainers to add their niche feature.

Nice idea though, maybe add some more data sources to increase confidence in data (and hopefully prove me wrong).


Ok, I’ll try to!


Why create new art when we already have galleries full of it?


Isn’t that ReScript?

https://rescript-lang.org/


> PHP 8.4 is a major update of the PHP language.

No it’s not: it’s a MINOR update.


It can be a major update even though it's a minor version bump.


It could have been, but isn’t. Most of those are rather small, incremental quality-of-life improvements. Nothing revolutionary.


I wouldn't consider all the new features small, but even many small improvements can result in a major improvement.


Must be one sexy LED display.


I like the closing tags (others don’t seem to) as they help with visual scanning and auto formatting. Nice project, well done!


Thank you sir. Closing tags are a very good feedback about the domains of a tag.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: