## Contributing changes to the Synchronet Source Repository
## 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); incidental trimming of trailing whitespace is okay
* 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
### 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 `safe_snprintf()` instead of `sprintf()`).
* Use safe string handling (e.g. xpdev's `SAFECOPY()` instead of `strcpy()`, `SAFEPRINTF()` or `snprintf()` instead of `sprintf()`).
When modifying JavaScript (`.js`) files:
* Specify `"use strict"` when adding new files and write conforming code
...
...
@@ -23,12 +24,12 @@ When modifying JavaScript (`.js`) files:
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. `*.doc` for plain text files)
* Don't use misleading file extensions/suffixes (e.g. don't use `*.doc` for plain text files)
### Branches
Only approved and authenticaed "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.
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
### 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).
