02-17-2015, 06:21 PM
Hello, welcome to the community.
Some issues on GitHub are marked with the "easy" label, those should be good for people starting to tinker in the server. See if there's anything you'd like to try: https://github.com/mc-server/MCServer/is...bel%3Aeasy (also note that some people have expressed interest in solving some of them, see the comments inside on whether someone's working on it or not)
When coding, try to observe the code style. I personally am very strict about it
There's a script file, $/src/CheckBasicStyle.lua, that will help you by checking some of the easily-detected style violations. This script is being run as part of the integration tests, so your code needs to pass it.
As for commit granularity, the general rule of thumb is to make changes in reasonable "chunks", so that each chunk is one logical change that could be later viewed in the history and, if needed, reverse-merged to undo just the one change. We don't need you to squash your commits into one before submitting a PR, and we don't want a thousand of little commits pertaining to a single logical change. If in doubt, imagine yourself looking at a specific line in a file in the "git blame" viewer and whether your commit description would enlighten you as to why it was needed.
Some issues on GitHub are marked with the "easy" label, those should be good for people starting to tinker in the server. See if there's anything you'd like to try: https://github.com/mc-server/MCServer/is...bel%3Aeasy (also note that some people have expressed interest in solving some of them, see the comments inside on whether someone's working on it or not)
When coding, try to observe the code style. I personally am very strict about it
There's a script file, $/src/CheckBasicStyle.lua, that will help you by checking some of the easily-detected style violations. This script is being run as part of the integration tests, so your code needs to pass it.As for commit granularity, the general rule of thumb is to make changes in reasonable "chunks", so that each chunk is one logical change that could be later viewed in the history and, if needed, reverse-merged to undo just the one change. We don't need you to squash your commits into one before submitting a PR, and we don't want a thousand of little commits pertaining to a single logical change. If in doubt, imagine yourself looking at a specific line in a file in the "git blame" viewer and whether your commit description would enlighten you as to why it was needed.