I know Hacktoberfest is certainly exacerbating the problem, but as an open-source contributor for ~2 years myself, but someone who has been working on side projects using GitHub for like 7 years now I've noticed a significant uptick in bullshit PRs in the past year or so.
I have a hunch it's because a lot of bootcamps / tutorials / etc are encouraging students to just "contribute to open source." People may either not know exactly what that entails, or may just be just as lazy in their bootcamp as they were in school.
I've gotten PRs on my school projects from 5 years ago fixing typos in comments. I'm not sure how people even find those repos, and I'm even more confused why they'd feel the need to "contribute" unless someone is telling them to without any additional context.
I feel like trying to get meaningless PRs accepted on big projects is a desperate attempt at gaining clout by being listed on contributors so people can say "yeah I've worked on this huge thing" and people likely won't check what they have actually done.
Would people actually do this? Any context in which "having participated in this huge thing" would be valuable (such as a job interview) would require the person to explain their role in such "huge thing". This can backfire awfully if the answer to that is "I replaced « I'm with I am ».
A lot of people do this - just like I've seen a lot of people put "Arctic Code Vault Contributor" on their LinkedIn pages, or list that they're a student at MIT because they're taking a Coursera course taught by an MIT professor. Typically, the folks who do this do not really consider the quality of work put on a resume/LinkedIn. Having contributed to some open-source projects over the past couple, I've come across this a lot.
It's definitely partly thanks to the bootcamps and whatnot because a bunch of the advice when finishing the programs revolves around having a consistent amount of github projects and commits to fill up that chart with green squares on your profile.
They didn't tell us to pick random projects from 5 years ago but they also didn't go into ettiquette about commits or really how to properly contribute, just "make sure your github is very active because that's what employers and recruiters want to see." My anxiety shoots through the roof just thinking about hitting up some random school project though...that's a bit far for me lol.
Ugh, I hate stuff like that. Number of GitHub contributions, lines of code, number of commits - these don't actually tell people anything. I know to a recruiter doing a cursory glance, these things may be important, but it's just frustrating. I'd so much rather see one high-quality, ideally squashed PR/commit per week.
What constitutes "bullshit"? I ask because I wouldn't want new contributors, or folks considering a contribution to shy away from one after reading a comment like that. In the large projects I'm a part of maintaining, even small typo fixes are welcome (and encouraged) because as maintainers we just can't see everything. Will people abuse small PRs to try and raise their profile? Sure. Do I believe everyone has ill intent? Not at all.
I really appreciate small Pull Requests that come in to fix small things - it's something I don't have to do as maintainer, and it lets someone take a small step towards a larger contribution.
Definitely a valid point, I'll clarify because I definitely don't want people to shy away from open-source as I think it's some of the more altruistic work developers can do. Even typo fixes may not be a bad thing. I more mean things like a PR that removes a contraction (i.e. I've gotten a PR changing "won't" to "will not" in one place).
That's very odd advice, as the reverse actually should apply.
Since (in GitHub) merging with squash costs just one click more to the maintainer, and one can't separate squashed commits, having separate commits should be the default behavior.
I'd say that it's preferrable to squash a disorderly branch history, but then, it's about being orderly rather than squashing for its own sake.
When working to maintain a large open source project with hundreds of monthly contributors, in which those forks/branches contain a significant number of commits themselves, squashing is preferable when merging to master. We only really care about the end result of a Pull Request (in the context of Github), and we use that to assemble changelogs and release notes.
There isn't a one-size-fits-all doctrine here. It's subjective based on the goals, size, contributor base, etc of an individual project and the leadership of the project.
Yes, and that excellent commit would make an excellent PR all on its own. It’s entirely self-contained and should not be lumped in with some other change, so there is no reason it would be squashed in the first place.
>We only really care about the end result of a Pull Request
The thing we care about is a bisectable repository where each commit does one thing only and that thing is described in the commit message. Squashing makes this impossible unless the pull request could have been written as a single patch without violating the above rules. Hopefully this is what the OP means with his first point. PRs that mix fixes to existing code and new features in a single commit will most likely be rejected.
> That said, there are no projects that require not squashing commits.
This isn't true either. I've worked on projects before where if you have a PR that makes changes all across the codebase in one commit, then you will get asked to split that commit up.
Looks like low quality blog spam to promote their site. Anyhow, for talking about these issues it seems like there should be a focus of getting individuals on the contribution to understand the workflow of a typical maintainer rather than dictating off a list of rules.
Positive contributions help the project in a meaningful way while respecting the time commitments of both the contributor and the maintainers responsible for integrating such improvements. Often posts like this say what to do which IMO doesn't work too well given the project-to-project variation rather than trying to give contributors the tools they need to understand why they would really do certain things on a case by case basis. Outside of that it does boil down to "keep things simple, consistent, and easy to integrate".
This is not a hard rule. It depends on how much you value your time.
If you try to change some behaviour that the project wants to guarantee to its users, I might reject your contribution based on the idea it embodies, if my idea as the maintainer is different.
If you fix a bug, your chances of simply getting through are much higher, and you may even save me time if your change is "good enough" and I don't need to do anything but say "thanks" and merge.
I don't really care if you report an issue by filing an issue or by requesting a merge.
And now imagine you're going to fix/add something to a big project with many devs and even more active contributors. Usually the bigger the project the higher the possibility that you may cross over with someone else doing essentially the same. In that case a prior announcement of your intent is a very logical thing to do and the issue tracker looks indeed the most suitable method of synchronization between contributors.
So I find the point 3 in the post actually the most important of all (at least for me, I haven't thought about it before)
You highlight an important point: in a big project, where a lot is going on, your thing might be going on without you realizing too. If you start the work without checking past attempts and current claims, you risk wasting your effort.
In smaller projects, the chance of making an obsolete contribution is lower due to things moving slower in general.
On the flip side, there are people who announce their intention and never follow up on the promise, while potential new contributors may think the problem is getting solved. As the maintainer, I'd rather have them announce nothing.
Then there are ideas that are not easily expressible in worrds. Sometimes you just have to show it for others to be able to meaningfully consider the topic.
23 comments
[ 9.4 ms ] story [ 67.5 ms ] threadI know Hacktoberfest is certainly exacerbating the problem, but as an open-source contributor for ~2 years myself, but someone who has been working on side projects using GitHub for like 7 years now I've noticed a significant uptick in bullshit PRs in the past year or so.
I have a hunch it's because a lot of bootcamps / tutorials / etc are encouraging students to just "contribute to open source." People may either not know exactly what that entails, or may just be just as lazy in their bootcamp as they were in school.
I've gotten PRs on my school projects from 5 years ago fixing typos in comments. I'm not sure how people even find those repos, and I'm even more confused why they'd feel the need to "contribute" unless someone is telling them to without any additional context.
They didn't tell us to pick random projects from 5 years ago but they also didn't go into ettiquette about commits or really how to properly contribute, just "make sure your github is very active because that's what employers and recruiters want to see." My anxiety shoots through the roof just thinking about hitting up some random school project though...that's a bit far for me lol.
I really appreciate small Pull Requests that come in to fix small things - it's something I don't have to do as maintainer, and it lets someone take a small step towards a larger contribution.
That's very odd advice, as the reverse actually should apply.
Since (in GitHub) merging with squash costs just one click more to the maintainer, and one can't separate squashed commits, having separate commits should be the default behavior.
I'd say that it's preferrable to squash a disorderly branch history, but then, it's about being orderly rather than squashing for its own sake.
There isn't a one-size-fits-all doctrine here. It's subjective based on the goals, size, contributor base, etc of an individual project and the leadership of the project.
Hmm, I'm not sure that's true. Imagine if this excellent commit got squashed, there'd be something really lost: https://dhwthompson.com/2019/my-favourite-git-commit
The thing we care about is a bisectable repository where each commit does one thing only and that thing is described in the commit message. Squashing makes this impossible unless the pull request could have been written as a single patch without violating the above rules. Hopefully this is what the OP means with his first point. PRs that mix fixes to existing code and new features in a single commit will most likely be rejected.
This isn't true either. I've worked on projects before where if you have a PR that makes changes all across the codebase in one commit, then you will get asked to split that commit up.
1. if submitters squash their commits into one by default, it's hard to split, if the maintainer wants;
2. if they send separate commits by default, it takes only one extra click to the maintainer to squash them, if they want.
So, the second case is more flexible.
Positive contributions help the project in a meaningful way while respecting the time commitments of both the contributor and the maintainers responsible for integrating such improvements. Often posts like this say what to do which IMO doesn't work too well given the project-to-project variation rather than trying to give contributors the tools they need to understand why they would really do certain things on a case by case basis. Outside of that it does boil down to "keep things simple, consistent, and easy to integrate".
This is not a hard rule. It depends on how much you value your time.
If you try to change some behaviour that the project wants to guarantee to its users, I might reject your contribution based on the idea it embodies, if my idea as the maintainer is different.
If you fix a bug, your chances of simply getting through are much higher, and you may even save me time if your change is "good enough" and I don't need to do anything but say "thanks" and merge.
I don't really care if you report an issue by filing an issue or by requesting a merge.
In smaller projects, the chance of making an obsolete contribution is lower due to things moving slower in general.
On the flip side, there are people who announce their intention and never follow up on the promise, while potential new contributors may think the problem is getting solved. As the maintainer, I'd rather have them announce nothing.
Then there are ideas that are not easily expressible in worrds. Sometimes you just have to show it for others to be able to meaningfully consider the topic.