CodeRcar is meant to be a user-friendly, contribution-friendly project. However, because some people just don't seem to know what that means, this project has a code-of-conduct that we ask all contributors to follow. If this code seems a bit obvious to you, it should, since most of it is simple stuff, anyway.
It's just basic common sense that people generally want to be treated fairly. Thus, any personal attacks against, the use of crude/hurtful/derogatory language in conversation with, or the trolling/stalking/harassment of any fellow contributors IRL/online isn't going to be tolerated.
That is not to say that contributors should not be free to speak their minds, or that any hint of derision will be immediately and forcefully crushed. But, a rule of thumb in this case is that, if it can't be fun for somebody, it shouldn't be fun for anybody.
When it comes to criticism, obviously remember that somebody's code is not them. Feel free to give constructive, honest, non-biased criticism of any code submissions. However, a contributor's code is all you should be criticising.
For example, it's fine to comment that a fellow contributor's code is not syntactically-correct, won't run in the way it's written, or goes against the project's style guides (or is drastically different from any other code in the project).
If it's bad code, it's bad code; there's no way around that. If it won't run, doesn't do what it should, isn't necessary, is spurious, is incorrectly-formatted, doesn't pass through a reasonable linter without errors, or uses outdated or deprecated functions, methods, dependencies, etc., it very well may be bad code, and it's never really worth sacrificing code quality for any reason.
It's also fine to say that a contributor's code could use a bit of tweaking. Examples of tweaking can include refactoring, adding comments, whitespace, or more-informative variable names for the sake of clarity, or updating to use features present in newer versions of the language in which it was written - obviously.
But it's never fine to up and attack/insult a contributor personally because you don't like their code. Harrassing someone because of their assumed experience, coding skill, or intelligence, etc. - especially things they can't control about themselves - is uncalled for and directly goes against this code-of-conduct.
Every one of us is different - there's no denying that fact. Our differences often define us, and sometimes are used to divide us. But, in the world of open-source, our differences really don't have to matter. Whoever you are, whatever you do, whatever others think about you - if you have an idea for a contribution, you should be able to voice it. If you aren't able to code up a contribution yourself, it's fine to just make a suggestion.
That being said, it's important to remember that this open-source project is not a commercial software product. You as a user aren't paying to use it, and there's no warranty or service package real or implied. No one has the right to force anything upon the contributors of this project, and contributors should never feel as if they're obligated to integrate a feature or update. All contributions should be done out of generosity, goodwill, and a desire to contribute to open-source development - not obligation or requirement.
Furthermore, if you are contributing, make sure that the code you're suggesting belongs to you or you have the right to use it. If it comes from an existing open-source project, make sure you cite the source and are abiding by that project's license - and that it isn't plagiarised from another open-source project or hacked out of the decompiled source code of a commercial piece of software. But you already knew that, didn't you?
Finally, the project's authors reserve the right to accept/reject any pull requests, open/close any issues, and generally moderate the project and enforce its code-of-conduct - obviously.
Any blatant breaches of this code-of-conduct should be reported to [matthew@botinabox.ca] with the subject "CodeRcar - Code-of-Conduct Breach Detected". Doing this allows the project's authors to figure out what to do about it - the authors reserve the right to review all reports. Except in cases where the details have to be kept private (like in cases that involve private data or legal stuff), a disclosure of the report will be made publicly, via an issue on this project's repository that will remain open as a PSA.