Obviously, there will be some differences, but are there some points of etiquette that are common to most open source projects and should be taken into account before contributing?
Well, there is no rule for etiquette, but there is common sense. Most internet communities have a form of etiquette, many explicitly did write it down. And you will find common points: don't hate, don't insult, don't threaten, don't troll. Be nice to others. This is no official common code, but it shows fast that if you actually tolerate bad behaviour your community will go down the toilet.
Actually, already the earliest internet communities in the usenet developed such an etiquette, they called it netiquette back then. It later got written down as RFC 1855. This also shares these common points.
So to get it simple: there is one uncodified general etiquette, but not specific for open source but for all forms of internet communities. Every project itself may have special rules though, you should ask or read documentation (if the specific community wrote their stance down).
When working on an open source project some things you should always keep in mind before starting the project:
Who is working on what? You don't want to start a project and have 3 people doing EXACTLY the same thing at the same time.
How much is each person going to contribute? This is important if you are working in a company and prevents some developers from working 1hr a week while others are working 20hr + a week. Make sure the other members of the group are comfortable working / dedicating X amount of time each day / week / month to the project.
Exactly where do you want the project to go? Make sure all members of the group know what EXACTLY what direction you want the project to go. If you don't to this some people may start doing things that are unnecessary to the project.
Different communities have different standards and different etiquette, but there are some shared notions that apply to most communities.
First, do your homework. Most projects document what they expect from contributors, at least to some degree of details (usually in files like
CONTRIBUTING.md). Contributors are expected to read these guidelines and act accordingly. Statements like "I didn't know I was expected to write a unit test" when the contribution guide explicitly states that are considered lazy, if not rude. Owning up to shortcomings in meeting the guidelines, especially apriori, is often fine, especially for new contributors who need some extra guidance (e.g., "I know I'm supposed to add a unit test, but this bug only reproduces in load conditions with thousands of active connections. If anyone could suggest a way to simulate that in a test, I'd be happy to add it").
Second, make reviewing your work as easy as possible. When submitting a patch (or PR, or MR, whatever terminology you're using), make sure to document why this change is needed, and if the implementation isn't trivial, also how it's done.
Third, respect the code style. This may be viewed as a subset of the first point, but it's often prominent enough to justify it being singled out. Almost all the (serious) projects have coding standards. Some provide automated ways to follow them (such as
.editorconfig files or linter configurations), some explicitly state them, and some do neither but still implicitly have all the source files use the same coding conventions. Even if there aren't any explicit guidelines, it's considered polite to follow suit. If the project uses spaces, it doesn't matter that you personally prefer tabs, stick to the project's convention.