summaryrefslogtreecommitdiff
path: root/src/contrib/SDL-3.2.20/docs/README-contributing.md
diff options
context:
space:
mode:
Diffstat (limited to 'src/contrib/SDL-3.2.20/docs/README-contributing.md')
-rw-r--r--src/contrib/SDL-3.2.20/docs/README-contributing.md107
1 files changed, 107 insertions, 0 deletions
diff --git a/src/contrib/SDL-3.2.20/docs/README-contributing.md b/src/contrib/SDL-3.2.20/docs/README-contributing.md
new file mode 100644
index 0000000..02a37bf
--- /dev/null
+++ b/src/contrib/SDL-3.2.20/docs/README-contributing.md
@@ -0,0 +1,107 @@
1# Contributing to SDL
2
3We appreciate your interest in contributing to SDL, this document will describe how to report bugs, contribute code or ideas or edit documentation.
4
5**Table Of Contents**
6
7- [Filing a GitHub issue](#filing-a-github-issue)
8 - [Reporting a bug](#reporting-a-bug)
9 - [Suggesting enhancements](#suggesting-enhancements)
10- [Contributing code](#contributing-code)
11 - [Forking the project](#forking-the-project)
12 - [Following the style guide](#following-the-style-guide)
13 - [Running the tests](#running-the-tests)
14 - [Opening a pull request](#opening-a-pull-request)
15 - [Continuous integration](#continuous-integration)
16- [Contributing to the documentation](#contributing-to-the-documentation)
17 - [Editing a function documentation](#editing-a-function-documentation)
18 - [Editing the wiki](#editing-the-wiki)
19
20## Filing a GitHub issue
21
22### Reporting a bug
23
24If you think you have found a bug and would like to report it, here are the steps you should take:
25
26- Before opening a new issue, ensure your bug has not already been reported on the [GitHub Issues page](https://github.com/libsdl-org/SDL/issues).
27- On the issue tracker, click on [New Issue](https://github.com/libsdl-org/SDL/issues/new).
28- Include details about your environment, such as your Operating System and SDL version.
29- If possible, provide a small example that reproduces your bug.
30
31### Suggesting enhancements
32
33If you want to suggest changes for the project, here are the steps you should take:
34
35- Check if the suggestion has already been made on:
36 - the [issue tracker](https://github.com/libsdl-org/SDL/issues);
37 - the [discourse forum](https://discourse.libsdl.org/);
38 - or if a [pull request](https://github.com/libsdl-org/SDL/pulls) already exists.
39- On the issue tracker, click on [New Issue](https://github.com/libsdl-org/SDL/issues/new).
40- Describe what change you would like to happen.
41
42## Contributing code
43
44This section will cover how the process of forking the project, making a change and opening a pull request.
45
46### Forking the project
47
48The first step consists in making a fork of the project, this is only necessary for the first contribution.
49
50Head over to https://github.com/libsdl-org/SDL and click on the `Fork` button in the top right corner of your screen, you may leave the fields unchanged and click `Create Fork`.
51
52You will be redirected to your fork of the repository, click the green `Code` button and copy the git clone link.
53
54If you had already forked the repository, you may update it from the web page using the `Fetch upstream` button.
55
56### Following the style guide
57
58Code formatting is done using a custom `.clang-format` file, you can learn more about how to run it [here](https://clang.llvm.org/docs/ClangFormat.html).
59
60Some legacy code may not be formatted, so please avoid formatting the whole file at once and only format around your changes.
61
62For your commit message to be properly displayed on GitHub, it should contain:
63
64- A short description of the commit of 50 characters or less on the first line.
65- If necessary, add a blank line followed by a long description, each line should be 72 characters or less.
66
67For example:
68
69```
70Fix crash in SDL_FooBar.
71
72This addresses the issue #123456 by making sure Foo was successful
73before calling Bar.
74```
75
76### Running the tests
77
78Tests allow you to verify if your changes did not break any behaviour, here are the steps to follow:
79
80- Before pushing, run the `testautomation` suite on your machine, there should be no more failing tests after your change than before.
81- After pushing to your fork, Continuous Integration (GitHub Actions) will ensure compilation and tests still pass on other systems.
82
83### Opening a pull request
84
85- Head over to your fork's GitHub page.
86- Click on the `Contribute` button and `Open Pull Request`.
87- Fill out the pull request template.
88- If any changes are requested, you can add new commits to your fork and they will be automatically added to the pull request.
89
90### Continuous integration
91
92For each push and/or pull request, GitHub Actions will try to build SDL and the test suite on most supported platforms.
93
94Its behaviour can be influenced slightly by including SDL-specific tags in your commit message:
95- `[sdl-ci-filter GLOB]` limits the platforms for which to run ci.
96- `[sdl-ci-artifacts]` forces SDL artifacts, which can then be downloaded from the summary page.
97- `[sdl-ci-trackmem-symbol-names]` makes sure the final report generated by `--trackmem` contains symbol names.
98
99## Contributing to the documentation
100
101### Editing a function documentation
102
103The wiki documentation for API functions is synchronised from the headers' doxygen comments. As such, all modifications to syntax; function parameters; return value; version; related functions should be done in the header directly.
104
105### Editing the wiki
106
107Other changes to the wiki should done directly from https://wiki.libsdl.org/ ... Just click the "edit" link at the bottom of any page!