We welcome bug reports, feature requests and pull requests. If you want to help us, please follow these guidelines, in order to avoid redundant work.
Please take a moment and read 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.
Thank you to everyone who contributes! 🙌
When commenting, keep a civil tone and stay on topic. Do not:
- Ask for support using this library
- Post "+1" or "I agree" type of comments - use the emojis instead
Asking for status of an issues can be discouraged. Unless someone is assigned to an issue or has explicitly said that the work is in progress, most likely that means no one is working on it. We do not ignore any issue but it may not be a top priority for us at that specific moment.
❗️ Keep the discussion on topic and respect other opinions
The issue tracker is the preferred channel for bug reports, features requests and submitting pull requests. But before you create one, please respect the following restrictions:
- Be sure documentation doesn't resolve your question/problem
- DO NOT use the issue tracker to ask for support (use Stack Overflow instead)
Bug is a demonstrable problem that is caused by the code in the repository. Good bug reports are extremely helpful - thank you!
Guidelines for bug reports:
- Use the GitHub issue search to check whether the issue has been reported already
- Check if issue occur on the newest version - try to reproduce it using latest
masterbranch in the repository - Isolate the problem and share with us by creating reduced test case and a live example
A good bug report should be clear so no one is forced to chase you up for more information. Try to be as detailed as possible in your report. Here are a few questions that may help you:
- What is your environment?
- What browser(s) and OS experience the problem?
- What steps will reproduce the issue?
- What is current (incorrect) behaviour?
- What is expected behaviour that should be the outcome?
All these details will help people fix any potential bugs.
Sample "template" for bug report:
General description of an issue that may direct people what the problem is
- Library: 1.2.3
- Node: 1.2.3
- Browser: XYZ 1.2.3
- Operating System: XYZ 123
Description of current behaviour that seems to be incorrect
Description of expected behaviour that should happen
- First step description
- Second step description
- Other steps...
<URL_TO_REDUCED_TEST_CASE>
- Any information you want to share that might be relevant to the issue being reported
- This might include some lines of code that you have identified as causing the bug
- It can also contain potential solutions (and your opinions on their merits)
Feature requests are always welcome! But keep in mind it might take a moment to find out whether your idea fits with the scope and aims of the project.
It's up to you to make a strong case to convince core team of the merits of this feature. Describe what would you like to add and why. Provide as much detail and context as possible to make it clear and avoid confusion.
If you want to request multiple features that aren't directly related then please create one issue per feature.
Pull requests are fantastic - they let our project grow and improve in case of features and quality! But to manage this properly, we have few rules for them:
- Ask first before embarking on any significant pull request
Otherwise you take risk spending time working on something that might not be added/merged - Pull Requests should remain focused in scope and avoid containing unrelated commits.
Otherwise it might be hard to understand changes in code review - Adhere to coding conventions used throughout a project (indentation, accurate comments, etc.)
- Be sure that current funcionality still works properly (by writing/checking tests)
Adhering to the following process is the best way to get your work included in the project:
- Fork the project
- Clone your fork
git clone https://github.com/<USER_NAME>/world-countries-capitals.git
- Configure the remotes
git remote add upstream https://github.com/bhatvikrant/world-countries-capitals.git
- Get latest changes from upstream (in case you cloned some time ago)
git pull upstream master
- Create branch to add your feature, change, or fix
git checkout -b <BRANCH_NAME>
- Commit your changes in small chunks (so it is easier to revert some unnecessary parts)
- Locally merge the upstream development branch into your branch
git pull upstream master
- Push your branch to your fork
git push origin <BRANCH_NAME>
- Open a Pull Request with clear title and description
❗️ Remember to run tests before making Pull Request. You can do that using npm test command.
It ensures that all current methods are working properly.
Sample "template" for pull request:
Reference: <ISSUE_ID>
Description:
Description of an Pull Request that may direct people what was done
- Bug fix (non-breaking change which fixes an issue)
- New feature (non-breaking change which adds functionality)
- Breaking change (fix or feature that would cause existing functionality to change)
- I have updated the documentation accordingly
- I have added tests to cover my changes
- All new and existing tests passed
Any information that you found out and you want to share (might not be connected directly to PR)
❗️ By submitting Pull Request you agree to allow the project owners to license your work under the terms of the MIT License.