Cavemanon/SnootGame
25
Fork 18
Code Issues 4 Pull Requests 1 Actions Projects Releases 10 Wiki Activity

Update 'Ettiqute'

MichaelYick
2021-06-16 08:56:31 +00:00
parent 0651475efe
commit 8dc9b552cc
1 changed files with 2 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
Ettiqute.md

@ -3,4 +3,5 @@ Things are quite simple ettiqute wise:
* 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). * 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. * 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. * 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. * 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.