ryujinx-backup/Opentk
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Update based on feedback.

Browse source
This commit is contained in:
Jarl Gullberg 2017-12-31 20:12:47 +01:00
parent 8991be20bd
commit f5446819cd
No known key found for this signature in database
GPG key ID: 750FF6F6BDA72D23
1 changed files with 47 additions and 49 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
CONTRIBUTING.md
View file

@ -5,12 +5,13 @@ First of all, thank you for considering contributing to the OpenTK project! It's
with a lot of twists and turns, and a helping hand is always welcome. with a lot of twists and turns, and a helping hand is always welcome.
There are multiple ways to contribue to the project - creating bug reports, opening pull requests, There are multiple ways to contribue to the project - creating bug reports, opening pull requests,
commenting on either and engaging in discussions about other contributions to name a few. This as well as commenting on and engaging in discussions about other contributions, to name a few. This
document is intented as a set of guidelines to help your contribution get accepted faster, maintain document is intented as a set of guidelines to help your contribution get accepted faster, maintain
a high standard, and to help us (the maintainers) set a few ground rules for working with us. a high standard, and to help us (the maintainers) set a few ground rules for working with us.
If you have any questions about the contents of this document, the code, or how to contribute, please If you have any questions about the contents of this document, the code, or how to contribute, please
drop us a line on [Gitter](https://gitter.im/opentk/opentk). We'll be happy to answer as best we can. drop us a line on [Gitter](https://gitter.im/opentk/opentk) or [Discord](https://discord.gg/GZTYR4s).
We'll be happy to answer as best we can.
#### Table of Contents #### Table of Contents
1. [Things to keep in mind](#things-to-keep-in-mind) 1. [Things to keep in mind](#things-to-keep-in-mind)
@ -41,6 +42,7 @@ To make this at least somewhat easier, here's a few concrete general tips which
* Always consider cross-platform gotchas. * Always consider cross-platform gotchas.
* Always work in small, iterative chunks which you can easily describe. * Always work in small, iterative chunks which you can easily describe.
* It's a good idea to open your PR early, so that you can get quick feedback. Tag it with "WIP" in the title.
* Avoid cosmetic or visual changes, unless your contribution is strictly focused on that. * Avoid cosmetic or visual changes, unless your contribution is strictly focused on that.
* Don't be afraid to ask, especially before diving in. There might be someone else working on the very * Don't be afraid to ask, especially before diving in. There might be someone else working on the very
same thing already! same thing already!
@ -100,8 +102,8 @@ Once you've finished up a change, it's time to commit it. In doing so, you'll be
commit message, and there are some guidelines for how this should be formatted. Primarily, commit message, and there are some guidelines for how this should be formatted. Primarily,
* Keep the first line of the commit message 50 characters or less * Keep the first line of the commit message 50 characters or less
* If you need a longer description, keep the second line blank, and keep all subsequent more descriptive * Always keep the second line blank.
lines at 72 characters or less. * If you need a longer description, keep all subsequent more descriptive lines at 72 characters or less.
The first line is what will be visible on the commit lists on GitHub, so make sure it's as descriptive as The first line is what will be visible on the commit lists on GitHub, so make sure it's as descriptive as
you can make it. you can make it.
@ -158,8 +160,6 @@ description and fully understand what accepting it would mean without having to
All pull requests should have the following: All pull requests should have the following:
* If applicable, a compilable example which demonstrates the changes. A git repository is preferred, and * If applicable, a compilable example which demonstrates the changes. A git repository is preferred, and
your changed branch should be included as a submodule. your changed branch should be included as a submodule.
A pull requests may have the following:
* A short explanation of why you think these changes are neccesary, if it is not readily apparent from * A short explanation of why you think these changes are neccesary, if it is not readily apparent from
the rest of the pull request. the rest of the pull request.
@ -211,8 +211,6 @@ Cosmetic and stylistic changes are those changes which do not affect executing c
operates exactly the same way before and after change, but the code might look nicer or follow the style guide operates exactly the same way before and after change, but the code might look nicer or follow the style guide
better. better.
These types of pull requests are given less priority than others, and may have to wait some time.
A cosmetic pull request must: A cosmetic pull request must:
* Not break any outstanding pull request, or, if both would modify the same code, be prepared to wait * Not break any outstanding pull request, or, if both would modify the same code, be prepared to wait