## Contributing Changes to the Synchronet Source Repository

Merge requests are considered and accepted at [gitlab.synchro.net](https://gitlab.synchro.net).
Do not submit pull/merge requests in the Synchronet *mirror projects* on github.com or gitlab.com; they won't be considered.

When submitting merge requests to existing files, unless you have prior agreement with the maintainers:
* Use the dominant coding style of the file(s) being modified
* Do not perform tab to space conversions (or vice-versa)
* Do not add trailing white-space; incidental trimming of trailing whitespace is okay
* Do not include changes that are not relevant to the merge request description/message
* Keep merge requests to a single topical change (e.g. don't combine new features with bug fixes with typo-fixes and style changes)

### Commit Content
In general, if it's a large set of changes, your best bet of getting it accepted and merged into the repo would be to discuss the concept of the change with the developers in the [Synchronet Programming conference](http://web.synchro.net/?page=001-forum.ssjs&sub=syncprog) **first**.

When modifying the C/C++ source files:
* Do not call functions from `ctype.h` (e.g. `isprint()`, `isspace()`, `isdigit()`, etc.) - use the `xpdev/gen_defs.h IS_*` macros instead.
* Use safe string handling (e.g. xpdev's `SAFECOPY()` instead of `strcpy()`, `SAFEPRINTF()` or `snprintf()` instead of `sprintf()`).
* For boolean variables and parameter types, use `bool` (not `BOOL` unless Win32 API compatibility is required) and use `JSBool` when libmozjs API compatibility is required.
* Use of the `long int` type (signed or unsigned) should be avoided since it is inconsistent in size among the supported build environments / target platforms; use `int` or sized-types instead.

When modifying JavaScript (`.js`) files:
* Specify `"use strict"` when adding new files and write conforming code
* Don't introduce/use 3rd party libraries unnecessarily

When adding files:
* Prefer all lowercase characters in filenames
* Don't include spaces or other special characters (e.g. that require URL-encoding) in filenames
* Don't use misleading file extensions/suffixes (e.g. don't use `*.doc` for plain text files)

### Branches
Only approved and authenticated "developers" can create new branches in the `main/sbbs`repo. If, as a developer, you are creating a new branch in the `main/sbbs` repository, use the branch naming scheme: `<your-name>/<topic>`, where *your-name* is your abbreviated name, user-name, or alias and *topic* helps to identify the intended purpose of the branch. Branches created in user repositories (e.g. forks of main/sbbs) need not contain the `<your-name>/` prefix.

### Commit Messages
* Try to keep the commit title (first line) to 70 characters or less.
* When a comment is related to an [issue](https://gitlab.synchro.net/main/sbbs/-/issues), use the proper commit message syntax for automatic issue management as documented [here](https://docs.gitlab.com/ce/user/project/issues/managing_issues.html#closing-issues-automatically).

### Other types of contributions
If you were interested in contributing money, not code, then paypal to rob at synchro dot net.

Thank you for contributing!