From 36d5cae7ef9aa8cf165bd30bf4db75010a8e7570 Mon Sep 17 00:00:00 2001 From: sk89q Date: Thu, 25 Oct 2012 11:45:04 -0700 Subject: [PATCH] Added CONTRIBUTING.md for GitHub --- CONTRIBUTING.md | 74 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 000000000..c767e289f --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,74 @@ +Contributing +============ + +Thank you for your interest in contributing to WorldEdit! We appreciate your +effort, however, we'd like to ask you to review the following guidelines in +order to streamline the process and assist us in getting your patch implemented +quicker. Remember that our fellow contributors are doing so when they have free +time, and the little things that you can go a long way. + +* **Follow the [Oracle coding conventions](http://www.oracle.com/technetwork/java/codeconv-138413.html).** + We can't stress this enough; if your code has notable issues, it may delay + the process significantly. +* **Target Java 6 for source and compilation.** Make sure to mark methods with + ` @Override` that override methods of parent classes, or that implement + methods of interface (Java 6+). +* **Use only spaces for indentation.** Our indents are 4-spaces long, and tabs + are unacceptable. +* **Wrap code to a 89 column limit.** We do this to make side by side diffs + and other such tasks easier. Ignore this guideline if it makes the code + too unreadable. +* **Write complete Javadocs.** Do so only for public methods, and make sure + that your `@param` and `@return` fields are not just blank. +* **Don't tag classes with @author.** Some legacy classes may have this tag, + but we are phasing it out. +* **Make sure the code is efficient.** One way you can achieve this is to spend + around ten minutes to think about what the code is doing and whether it + seems awfully roundabout. If you had to copy the same large piece of + code in several places, that's bad. +* **Keep commit summaries under 70 characters.** For more details, place two + new lines after the summary line and write away! +* **Test your code.** We're not interested in broken code, for the obvious reasons. +* **Write unit tests.** While this is strictly optional, we recommend it for + complicated algorithms. + +Sometimes failure to abide by the guidelines may result in your pull request +falling into a "black hole" where it sits in a state of inaction until it is +needed to be closed a few months later. + +Checklist +--------- + +Ready to submit? Perform the checklist below: + +1. Have all tabs been replaced into four spaces? Are indentations 4-space wide? +2. Have I written proper Javadocs for my public methods? Are the @param and + @return fields actually filled out? +3. Have I `git rebase`d my pull request to the latest commit of the target + branch? +4. Have I combined my commits into a reasonably small number (if not one) + commit using `git rebase`? +5. Have I made my pull request too large? Pull requests should introduce + small sets of changes at a time. Major changes should be discussed with + the team prior to starting work. +6. Are my commit messages descriptive? + +You should be aware of [`git rebase`](http://learn.github.com/p/rebasing.html). +It allows you to modify existing commit messages, and combine, break apart, or +adjust past changes. + +Example +------- + +This is **GOOD:** + + if (var.func(param1, param2)) { + // do things + } + +This is **EXTREMELY BAD:** + + if(var.func( param1, param2 )) + { + // do things + }