update STYLE, add PATCHES

Signed-off-by: Julien Danjou <julien@danjou.info>

PATCHES

@@ -0,0 +1,25 @@
+If you plan to submit patches, here's a checklist:
+
+ Commits:
+
+- make commits of logical units;
+- check for unnecessary whitespace with "git diff --check" before commiting;
+- do not check in commented out code or unneeded files;
+- provide a meaningful commit message;
+- the first line of the commit message should be a short;
+  description and should skip the full stop;
+- if you want your work included, add a
+  "Signed-off-by: Your Name <you@example.com>" line to the
+  commit message (or just use the option "-s" when commiting);
+- make sure that you have tests for the bug you are fixing.
+
+ Patch:
+
+- use "git format-patch -M" to create the patch;
+- do not PGP sign your patch;
+- be careful doing cut & paste into your mailer, not to corrupt whitespaces;
+- if you change, add or remove the user API, the associated documentation
+  should be updated as well;
+- send the patch to the list (awesome-devel@naquadah.org) if (and only if)
+  the patch is ready for inclusion. If you use git-send-email(1), please
+  test it first by sending email to yourself.

STYLE

@@ -1,9 +1,28 @@
-If you intend to patch and contribute awesome, please respect the following coding style:
+If you intend to patch and contribute to awesome, please respect the
-- Use 4 space indentation, do not use tabulator characters
+following guidelines.
-- Place braces alone on new lines;
+
-- Do not put a space after if, for, while or function call statements;
+Imitate the existing code style. For concrete rules:
-- The preferred line length is 80 characters;
+
-- Be clear in what you do;
+ - Use 4 spaces indentation, do not use tabulator characters
-- Write documentation for any new functions, options, whatever.
+
+ - Place braces alone on new lines, and do not place braces for single
+   line statement where it is not needed, i.e no:
+   if(bla) {
+       x = 1;
+   }
+
+ - Do not put a space after if, for, while or function call statements;
+
+ - The preferred line length is 80 characters;
+
+ - Use /* */ for comments;
+
+ - Use the API: there's a list of a_*() function you should use instead
+   of the standard libc ones. There is also common API for linked list,
+   tabulars, etc;
+
+ - Be clear in what you do;
+
+ - Write documentation for any new functions, options, whatever.
 
 A vim modeline is set in each file to respect this.