Added the 'Contributing' file.

git-svn-id: svn://svn.code.sf.net/p/sc2/code/trunk@339 8092fc87-c524-0410-9efc-e669fe64eaf9
2002-12-05 03:08:38 +00:00
parent 783d79226f
commit 45bab537eb
1 changed files with 118 additions and 0 deletions
@@ -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:
    {
    <TAB>long l,
    <TAB>     m;
    <TAB>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.