SnootGame

Things are quite simple ettiqute wise:

If you wish to fork, MAKE SURE TO FORK A VERSION BRANCH. Master is our stable branch and any forks of it likely wont be in date. A version branch (such as Patchy-Patch5, Monster-Update6, etc.) should be forked as to declare that this will be an implemented feature in that version!
Don't do discussion that relates to a PR in the issue that the PR is fixing unless you are bringing up some further issues that people haven't seen, please keep the talking in the PR!
Anyone can make issues or PRs. It is up to commit-access devs though to review and implement them. Discussion is encouraged and honest opinions are great.
Keep conversations tangentally related to an issue or PR. If you notice there is a new problem, don't comment it on another issue, create a new issue.
Check for duplicate issues or PRs before making a new one, if you have more information about an issue or PR, simply comment it on an open issue/PR. If your issue is grander in scope, but includes an old issue, make said issue anyway (i.e if theres a broken sprite, but you found multiple broken sprites including that first broken sprite, then make a new issue with the greater number of issues enumerated).
Alert others when you are working on something. If know one knows your working, they may pick up the job and then you'll end up with redundant code. Best to be effective and save time, communicate.
Avoid pushing to master unless said push is absoltely nessecary. A merge between an update/patch branch and the master to make it the new stable, or the update is to something like documentation or licensing are fine though. This is to keep master always stable and of our last release.
Over all, just be responsive and cordual whenever possible. Don't shy away from speaking because you're unsure. Don't be afraid to be corrected, don't be afraid to give corrections, don't be afraid to critique. Simple as, just be a rational person.
Principle of least privilege dictates forks > branches for working, thus, make a fork if you want to contribute. Best to work via forks rather than branches as branches would require commit access for people. We rather not have to give commit access to anyone in everyone incase someone's account gets cracked into, someone makes a mistake, or someone decides to go rogue. Its purely a security thing and, like many practices, shoudln't be taken as a personal slight. Forks and PRs also allow code to be more easily vetted by contributors.