NeoComm/CONTRIBUTING.md

Contributing Guide

This is a basic contribution guide to the project. What follows are guidelines you should follow when contributing so that work flow is not broken.

• Licensing & Copyright
• Code Style
• Fractured Patches

Licensing & Copyright

All code contributions will be licensed under the GNU Affero General Public License version 3 or greater. If you create any new files you must have the following copyright notice prepended to the file:

/*
 * Copyright (C) 2017 <your name> <your e-mail>
 * Author: <your email> <your e-mail>
 *
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU Affero General Public License as
 * published by the Free Software Foundation, either version 3 of the
 * License, or (at your option) any later version.
 *
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 * GNU Affero General Public License for more details.
 *
 * You should have received a copy of the GNU Affero General Public License
 * along with this program.  If not, see <http://www.gnu.org/licenses/>.
 *
 */

Have this text commented out at the beginning of every source file you create.

Code Style

Generally just try to keep your coding consistent with the project's style, if you see things done in manner X try to do them like X. That being said, there are a few things that are important to remember:

1. This project uses tabs for indentation, please do not use spaces and most definitely do not use a mix of both.
2. When using loops and conditionals, if you're going to use brackets, please use broken brackets (ie. put brackets on their own line).
3. One instruction per line is ideal, sometimes it's not necessary, but if it's a simple conditional with a return statement or something please put the return on the next line.
4. Please document any additional interfaces you add to the library using Doxygen style comments so the API documentation can be automatically generated. If internal code is obscure or requires explanation then please do so as well, for the sake of yourself and all those that come after.

Fractured Patches

Please make sure that any patches you give do only one thing. Do not mix bug fixes with features with enhancements or anything of the sort. Even if it's just bug fixes (as an example, could be anything else) please make sure that each patch only fixes one thing. Exceptions are fine if they are required (this will be judged based on circumstance).