First off, thanks for taking the time to contribute! 🤗
Please take a moment to review this document in order to make the contribution process easy and effective for everyone involved.
Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project. In return, they should reciprocate that respect in addressing your issue or assessing patches and features.
The issue tracker is the preferred channel for bug reports, features requests and submitting pull requests, but please respect the following restrictions:
-
Please do not derail or troll issues. Keep the discussion on topic and respect the opinions of others.
-
Please do not post comments consisting solely of "+1" or "👍". Use GitHub's "reactions" feature instead. We reserve the right to delete comments which violate this rule.
-
Please do not open issues regarding the extension itself, this repository is reserved for the API only. If you want to report a bug or request a feature for the extension, do it here.
Our bug tracker utilizes several labels to help organize and identify issues. Here's what they represent and how we use them:
bug- Issues that are identifying a bug.docs- Issues for improving or updating our documentation.duplicate- Issues that already exist.feature- Issues asking for a new feature to be added, or an existing one to be extended or modified.help wanted- Issues we need or would love help from the community to resolve.question- Issues for general questions regarding the API, in most cases this can be handled by e-mail instead. See this page for contact information.wontfix- Issues with an identified bug that will not be fixed.
For a complete look at our labels, see the project labels page.
Pull requests for new features, bug fixes, etc. are often appreciated.
Working on your first Pull Request? You can learn how from this free series How to Contribute to an Open Source Project on GitHub
Guidelines for pull requests:
- Make your commit messages as descriptive as possible. Include as much information as you can. Explain anything that the file diffs themselves won’t make apparent.
- Document your pull request. Explain your fix and link to the relevant issue.
- Make sure the target of your pull request is the relevant branch. Most of bugfix or new feature should go to the
masterbranch. - Include only related work. If your pull request has unrelated commit, it won't be accepted.
Before creating an feature request, please search to see if someone has requested the feature already. If there is an open request, please add a 👍.
If the feature has not already been requested, create an issue with a title of Feature request: <feature name> and add as much information as possible.
Before reporting an issue, please search to see if someone has filed a similar issue before. If there is already an open issue, please add a 👍 and/or leave a comment with additional information.
When creating a new issue make sure to include the following:
- Time of bug. This makes it easier for us to figure out what went wrong when looking at the error logs. Make sure it is in UTC-format.
- Steps to reproduce. Even if the step is small, include it! Include the actual result and what you expected.
- Any message or error you get in the response, if you do.
- A screenshot of any visual bug.
Here is what a great bug report would look like:
## Prerequisites
Time of bug: 2019-04-05 14:31:38
## Step to reproduce
1. Make a `GET` request to endpoint `https://api.quotesnewtab.com/v1/quotes/random`
2. Get response.
### Actual behavior:
Response is empty.
### Expected behavior
Response contains a random quote.
## Any message or error
No response error.
...
## Screenshot
Link to screenshot
...By contributing your code, you agree to license your contribution under the MIT License.