lpnf
/
lovr
mirror of https://github.com/bjornbytes/lovr.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

Update CONTRIBUTING;

This commit is contained in:
bjorn 2019-12-15 17:04:02 -08:00
parent fd437423e7
commit 0e52e49529
1 changed files with 11 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
CONTRIBUTING.md
View File

@ -12,32 +12,30 @@ may have already been asked.
Issues are okay for feature requests and questions about the development of LÖVR as well, but
usually you'll get a better response by asking in
[Slack](https://join.slack.com/ifyouwannabemylovr/shared_invite/MTc5ODk2MjE0NDM3LTE0OTQxMTIyMDEtMzdhOGVlODFhYg).
Questions about how to use LÖVR belong in Slack.
Questions about how to use LÖVR should go in Slack.
Contributing Documentation
Editing Documentation
---
If you see any typos or inconsistencies in the docs, submitting an issue or pull request in the
[lovr-docs repo](https://github.com/bjornbytes/lovr-docs) would be greatly appreciated! The `api`
folder has Lua files for each function, the `guides` folder contains tutorials in markdown format,
and the `examples` folder has source code for sample projects and other demos.
If you notice any typos or inconsistencies in the docs, speak up! You can mention it in Slack, or
if you're feeling brave you can submit a pull request in the [lovr-docs repo](https://github.com/bjornbytes/lovr-docs).
Contributing Code
---
To contribute patches, fork LÖVR, commit to a branch, and submit a pull request. Note that
contributions to the repository will be released under the terms in LICENSE. For larger changes, it
can be a good idea to engage in initial discussion via issues or Slack before submitting. Try to
stick to the existing coding style:
To contribute patches to the C code, you can fork LÖVR, commit to a branch, and submit a pull
request. Note that contributions to the repository will be released under the terms in the LICENSE.
For larger changes, it is a good idea to engage in initial discussion via issues or Slack before
submitting. Try to stick to the existing coding style:
- 2 space indentation.
- 100 character wrapping (ish, sometimes it's more readable to just have a long line).
- Use descriptive, camelCased names when possible.
- Use descriptive, camelCased variable names when possible.
If you modify the embedded `boot.lua` script, you can compile it into a C header by doing this:
```sh
pushd src/resources; xxd -i boot.lua > boot.lua.h; popd
xxd -i src/resources/boot.lua > src/resources/boot.lua.h
```
Organization
@ -54,7 +52,4 @@ in the `src/lib` folder.
much as possible, there's inevitably some overlap.
- `src/resources` contains embedded files. These are compiled to binary headers using `xxd`.
Note that currently the internal C API may change at any time. The Lua API will change less
frequently but breaking changes will still occur before version 1.0.
Branches other than master will be force-pushed during development to organize commit history.
Branches other than master can be force-pushed during development to organize commit history.