mirror of
https://github.com/outbackdingo/UltraGrid.git
synced 2026-03-20 05:40:06 +00:00
Corrected various spelling mistakes in comments, documentation, and variable names across the project. Changes include: - Documentation files (CONTRIBUTING.md, README.md, etc.) - Source code comments in C/C++ files - Function parameter names and descriptions No functional changes were made.
97 lines
3.1 KiB
Markdown
97 lines
3.1 KiB
Markdown
# How to contribute to UltraGrid
|
|
First, thanks to contribute to UltraGrid by using UltraGrid, reporting bugs,
|
|
adding code or ideas. Further section contains basic information how to
|
|
contribute. Feel free to inform us if you need to contribute in a different
|
|
way or extend this document.
|
|
|
|
## Table of Contents
|
|
|
|
* [Resources](#resources)
|
|
* [Reporting bugs](#reporting-bugs)
|
|
* [Feature requests](#feature-requests)
|
|
* [Pull requests](#pull-requests)
|
|
* [Coding standards](#coding-standards)
|
|
* [Style](#style)
|
|
* [Naming conventions](#naming-conventions)
|
|
* [Conclusion](#conclusion)
|
|
|
|
## Resources
|
|
|
|
- [Adding modules HOWTO](doc/ADDING-MODULES.md)
|
|
- [Doxygen](https://frakira.fi.muni.cz/~xpulec/ultragrid-doxygen/html/)
|
|
- [GitHub devel page](https://github.com/CESNET/UltraGrid/wiki/Developer-Documentation)
|
|
- [Trello board](https://trello.com/b/PjZW4sas/ultragrid-development) tracking the development
|
|
|
|
## Reporting bugs
|
|
|
|
Preferred way to report a bug is to open an issue on GitHub. If not possible,
|
|
you can also contact the development team directly with an e-mail.
|
|
|
|
Please look also at detailed instructions here [here](doc/REPORTING-BUGS.md).
|
|
|
|
For general questions, ideas or remarks you are encountered to use the project's
|
|
[GitHub Discussions](https://github.com/CESNET/UltraGrid/discussions).
|
|
|
|
## Feature requests
|
|
Feature requests can be submitted with the same channels as bugs.
|
|
|
|
## Pull requests
|
|
|
|
Pull request should be issued as a single branch originating from repository
|
|
master branch, preferably rebased to current version. If multiple features are
|
|
created, multiple pull requests containing every single feature should be
|
|
issued.
|
|
|
|
The pull request should represent a coherent unit, like a single feature added.
|
|
More features should be separated to multiple pull request (of course if possible
|
|
and eg. not firmly bound together).
|
|
|
|
The contained commits should present clearly what was changed. Ideally,
|
|
if refactoring is done, it should not be mixed with functional changes
|
|
in a single commit, similarly for the code movement.
|
|
|
|
### Copyright and license
|
|
|
|
Code added to existing file must keep the license. Newly created files should be
|
|
3-clause BSD licensed.
|
|
|
|
## Coding standards
|
|
**TODO:** incomplete
|
|
|
|
### Style
|
|
|
|
Recommended style is modified LLVM clang-format style:
|
|
```
|
|
BasedOnStyle: LLVM
|
|
AlignArrayOfStructures: Left
|
|
AlignConsecutiveAssignments: true
|
|
AlignConsecutiveDeclarations: true
|
|
AlignConsecutiveMacros: true
|
|
AlignEscapedNewlines: DontAlign
|
|
AlwaysBreakAfterReturnType: TopLevelDefinitions
|
|
BreakBeforeBraces: Linux
|
|
Cpp11BracedListStyle: false
|
|
IndentWidth: 8
|
|
ReflowComments: true
|
|
SpaceAfterCStyleCast: true
|
|
````
|
|
|
|
The style is deduced from original _rtp/rtp.{c,h}_ formatting and it
|
|
is similar to [Linux Kernel
|
|
style](https://www.kernel.org/doc/Documentation/process/coding-style.rst)
|
|
(see [here](https://clang.llvm.org/docs/ClangFormatStyleOptions.html#examples))
|
|
without using tabs.
|
|
|
|
### Naming conventions
|
|
|
|
Logged module name (`MOD_NAME`) should be lower-case.
|
|
|
|
#### Macros
|
|
|
|
It is recommended for the function-like macros to be typed upper-case.
|
|
|
|
## Conclusion
|
|
Aside of what is enumerated above, we will be glad if you share with us your
|
|
setup, photos or just ideas.
|
|
|