Clarify expectations around "fixing merge conflicts" in contributing

[mtheoryx]

There are times where, after seeing a very good contribution, there are some really confusing merge conflicts.

This can be very frustrating for maintainers. Maintainers may really love and appreciate your contribution... but not understand how to resolve a variety of merge conflicts you and/or others introduced.

So, it's fair to expect that contributors may be asked to resolve conflicts in their PR and update accordingly. It's not you, it's us.

[noopkat]

hint for anyone who wants to take this issue: look in the CONTRIBUTING.md file as this is where we want to include this information.

😄

[underscoredotspace]

What are people's preferred workflow for avoiding merge conflicts? I don't feel like there is enough going on in any one file (generally) that they should be unavoidable.

My normal process, just before PR, is:

git checkout master
git merge upstream master
git checkout <branch>
git merge master

I've not done this often, so I'm happy to be corrected if there is a better method or a clearer way to express this.

[mtheoryx]

That's my general workflow, yep!

So here's another protip for avoiding merge conflicts (well, not protip, just me making mistakes over a longish career)...

If at all possible, use trailing commas, and put as many things as possible on their own lines. Like when you're listing out attributes in HTML or JSX for a tag.

[mpaarating]

Closed by #71