What to Avoid When Contributing to Open-Source Projects
qvault.io
qvault.io
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".
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.
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.
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.
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.