From 45bab537eb67a174bdbe9736600f57c153ce08de Mon Sep 17 00:00:00 2001 From: meep-eep Date: Thu, 5 Dec 2002 03:08:38 +0000 Subject: [PATCH] Added the 'Contributing' file. git-svn-id: svn://svn.code.sf.net/p/sc2/code/trunk@339 8092fc87-c524-0410-9efc-e669fe64eaf9 --- sc2/Contributing | 118 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 118 insertions(+) create mode 100644 sc2/Contributing diff --git a/sc2/Contributing b/sc2/Contributing new file mode 100644 index 000000000..4b81c785e --- /dev/null +++ b/sc2/Contributing @@ -0,0 +1,118 @@ +These are some guidelines for people who want to contribute to the code. +Don't be surprised if your contributions get tossed in the bit-bucket if you +do not follow them. We don't want to be unfriendly, but our time is limited. +These guidelines are there so that you won't waste both our and your time. + +Before making changes: +- Read this entire document +- Read the TODO list to see if there are any comments on what you're + planning to do. +- Make sure you're using the most recent cvs version +- Discuss in advance what you're planning to do, with the core team. + The best place to do this is on #sc2 on irc.freenode.net. + This prevents you from wasting your time when + - someone else is already working on your issue + - we've got a very clear idea of how we want it to be + - the code you're planning to change will be completely rewritten + in the near future. +- Don't bother on adding "great ideas" you have for the game. + Our current goal is a straight port. The code is GPL, so feel free + to start your own modified version, but don't bother sending them + in for the official version. + +Making changes: +- Follow the coding style of the existing source. You don't have to like it, + we don't even always do, but we've accepted this as our standard. The main + reason is that this is very close to the original style. + Trying to start a discussion about the standard is pointless and is + definately NOT appreciated. + - Use 1 tab per indentation level + - Use about 70 chars (or less) on a line, when using a tabsize of 4. + - Use 2 extra indentation levels for the continuation of a broken line, + like this: + if (blablablabla || foobar || + zut || linefiller || + morezut) + printf ("Yeah!\n"); + - Don't use tabs for anything but indenting. If you would, and someone + has a different tab size, or something in the line changes, other stuff + on the line may or may not move, depending on where on the line it is. + If you for instance want to align a list of declarations, use spaces, + like this: + { + long l, + m; + int i; + } + (Though in this particular case, I personally would repeat the 'long', + or place l and m on the same line) + - Put { on a seperate line, both for the start of a function and + for the start of a block. + - one space around binary operators, and after commas. + - one space between the function name and following '(', both in + declaration and call (unusual as it is). + - one space after 'if', 'while', 'do', 'for' and 'switch'. + - even for short selections or repetitions, don't have the statement + to execute on the same line as the guard. So: + if (a) + a--; + - Use unix-style line-endings, that is '\n' only. If the editor you're + using doesn't support this, please pass your code through a conversion + program before submitting. +- Don't hurry into changing code. All code is there for a reason. Be sure + you understand that reason before changing it. Don't just go recode a part + because you think that would be easier than trying to understand the + original. If you don't have the skills or patience to do so, this is not + the place for you. +- Only use portable functions. The code is intended to work on Windows, + Linux, FreeBSD, BeOS and MacOS X. + Try to avoid unnecessary system-dependant code, but use #ifdefs if you + really have to. +- No shortcuts. Don't assume anything about user input (like the length), + and check the return values of functions that may fail. + +Making the patches: +- One issue per patch. + We need to keep track of what's being changed, and multiple changes + in one patch will make that more difficult. + Also, we might want to accept one patch, and reject the other. +- Use unified diffs. + That way, there's a bigger chance the patch can be automatically applied + successfully against modified files. +- Make the patches against the current cvs tree. + +Test the patches: +- If possible, test your changes both on Windows and a *nix platform, or + send them to someone to test them for you. + +Getting the patches committed: +- Send the patches to one of the committers, in plain-text format. + This can be done by email, DCC from within the #sc2 channel, or by + mentioning an URL where we can get the patch. + The committers are listed below (in alphabetical order), with their + particular field of expertise with the source. Though all of us + should have enough experience to deal with most issues not explicitely + mentioned. + Serge van den Boom (svdb at stack.nl), Meep-Eep at #sc2 + - Resource system + - 3DO historical code + - *nix build system + - General issues (particularly on *nix) + Mika Kolehmainen (mimakole at cc.jyu.fi), Gwl at #sc2 + - Graphics + - Sound + - General issues + Michael Martin (mcmartin at stanford.edu), McMartin at #sc2 + - Threading + - Alien communications code + - Graphics + - General issues +- Only submit code that can be used under the GPL. By submitting code you + hold the copyright to, you agree that it can be used under the term of + the GPL. If you use code by someone else, make sure that it can be used + under the GPL and let us know, so that adequate credit can be given. + + +Initial version of this file by Serge van den Boom, 2002-12-05. + +