Skip to main content
182 votes
Accepted

Should I submit a pull request to correct minor typos in a Readme file?

Just fix all the typos you noticed and create a pull request with a comment along the lines of 'Fix typos'. Then it's one button to click for a person with the correct access. You don't need to ...
RiaD's user avatar
  • 1,700
56 votes

Should I submit a pull request to correct minor typos in a Readme file?

Some context that may or may not be relevant. A cloud hosting provider named DigitalOcean hosts an event every year called Hacktoberfest to encourage people to contribute to open source projects in ...
Zach Lipton's user avatar
  • 1,608
46 votes
Accepted

Best practices for reverting others' work (commits) and the 'why' for it?

Creating a revert-commit sends a message that the original commit was flawed and should not have been made. Sometimes, that message is justified, for example when a commit introduced a serious bug, ...
Bart van Ingen Schenau's user avatar
31 votes
Accepted

I accidentally overhauled someone's entire project. Any acceptable way to pull request?

If the project was "5 years untouched" as you wrote, it is likely that pull requests are not going to be accepted, regardless if someone fixed a typo in a comment or did a complete rewrite. The ...
Doc Brown's user avatar
  • 209k
27 votes

Best practices for reverting others' work (commits) and the 'why' for it?

I think there's a lot more thought about blame and pride going into this than is necessary. When I see a revert I only think one thing: I can ignore the reverted code because it doesn't feed into ...
candied_orange's user avatar
15 votes

Should I submit a pull request to correct minor typos in a Readme file?

Correct the typos and submit a pull request with the position of each correction in the summary field. That information is already visible when looking at the changes themselves, and any pull request ...
Flater's user avatar
  • 52.5k
15 votes
Accepted

Etiquette of mentioning issues/PRs from other projects (backlinks)

I don't understand the equivalence between linking issues (even across projects) and "me too" messages. They are not the same at all. We can continue to assume large project godzilla which ...
Thomas Owens's user avatar
  • 83.3k
11 votes
Accepted

Etiquette for reverting others' work

Have code reviews. That should solve most of them, if you are using a commit you can still make pull requests even if it's just for one other person to review on your team. If mistakes make it in, ...
enderland's user avatar
  • 12.1k
7 votes

Should I submit a pull request to correct minor typos in a Readme file?

Not that this specifically answers the question, as there are already answers, but here is the general advise I give people on commits and messages. Break up commits into logical chunks. The example I ...
Ben's user avatar
  • 179
6 votes

Best practices for reverting others' work (commits) and the 'why' for it?

TL;DR: Pull Requests and Commits are different things. Let's talk about workflow: A Commit is a unit of change. It is focused, to make review easy. A Pull Request is a unit of "deployment". ...
Matthieu M.'s user avatar
  • 15.1k
6 votes

Good etiquette for 2 optional arguments that can't both be used

For clarity, I would make two functions, norm_pdf_from_variance(x, mu, variance) and norm_pdf_from_precision(x, mu, precision). They could call a common "private" function to do the calculation....
user949300's user avatar
  • 8,869
4 votes

Good etiquette for 2 optional arguments that can't both be used

An alternative to creating two different methods (as in user949300's answer is to use method overloading along with custom types to make it clear what the "number" you're passing in means. I'm not ...
Avner Shahar-Kashtan's user avatar
4 votes

Why squash git commits for pull requests?

I would see if the code is going public or not. When projects stay private: I would recommend to not squash and see the making of the sausage. If you use good and small commits, tools like git ...
Vince V.'s user avatar
  • 153
3 votes

Why squash git commits for pull requests?

Because of the perspective ... The best practice is to have a single commit per single <<issue-management-system>> issue if possible. You could have as many commits as you want in your ...
Yordan Georgiev's user avatar
3 votes

Etiquette for reverting others' work

You either had a good reason to revert his commit, or you didn't. If you had a good reason, then "makes me look like an idiot" is not a good counterargument. That said, it would be polite to inform ...
gnasher729's user avatar
  • 45.9k
2 votes

Best practices for reverting others' work (commits) and the 'why' for it?

When you call out a revert (as a separate commit) you are basically saying: The potential downside of the original commit outweighs the potential upside. I threw the word "potential" in ...
DavidT's user avatar
  • 3,358
2 votes

Should I submit a pull request to correct minor typos in a Readme file?

The other answers are good, but first check if there are any instructions for contributing - in particular regarding signing a CLA. (I see that @eckes also stated this as a comment on the original ...
Hans Olsson's user avatar
2 votes

Etiquette for reverting others' work

The root question to this matter is "who owns the component on a technical level"? If there is no answer to this, or the aswer is "we all do" or "no one does" or you just get glazy puzzled looks and ...
Martin Maat's user avatar
  • 18.5k
1 vote

Good etiquette for 2 optional arguments that can't both be used

There are some good ways of doing this with overloads etc. But to answer your question about how its done in practice, we can look at a random example function from numpy or any stats library. https:/...
Ewan's user avatar
  • 77.2k
1 vote
Accepted

Should I fork in Github if I won't make pull requests?

Fork or creating a new repository is a detail, in particular if there is no chance of pull requests. As far as comparing these options goes, forking may ease discovering your repository, while ...
Theraot's user avatar
  • 9,151
1 vote

Etiquette for reverting others' work

Don't just revert, let them do the revert themselves. Typical reasons you can give when requesting a revert: "Your Commit XYZ breaks this and that usecase/functionality/testcase" "Your Commit XYZ ...
arved's user avatar
  • 111
1 vote

Etiquette for reverting others' work

I think it's fair to ask to be consulted if someone has significant time investment into something, especially if it was quite recent. It's better to come to a consensus first. Ideally you'd convince ...
Joppe's user avatar
  • 4,596

Only top scored, non community-wiki answers of a minimum length are eligible