The following is a set of guidelines for contributing. These are mostly guidelines, not rules. Use your best judgment, and we are just getting started so feel free to propose changes to this document in a pull request.
This section guides you through submitting a bug report for Atom. Following these guidelines helps maintainers and the community understand your report 📝, reproduce the behavior 💻 💻, and find related reports 🔎.
Before creating bug reports, please check open issues as you might find out that you don't need to create one. When you are creating a bug report, please include as many details as possible.
Bugs are tracked as GitHub issues.
Explain the problem and include additional details to help maintainers reproduce the problem:
- Use a clear and descriptive title for the issue to identify the problem.
- Describe the exact steps which reproduce the problem in as many details as possible. For example, start by explaining how you started the repository, e.g. which command exactly you used in the terminal, or how you started it otherwise. When listing steps, don't just say what you did, but explain how you did it. For example, if you moved the cursor to the end of a line, explain if you used the mouse, or a keyboard shortcut, and if so which one?
- Provide specific examples to demonstrate the steps. Include links to files or GitHub projects, or copy/pasteable snippets, which you use in those examples. If you're providing snippets in the issue, use Markdown code blocks.
- Describe the behavior you observed after following the steps and point out what exactly is the problem with that behavior.
- Explain which behavior you expected to see instead and why.
- Include screenshots and animated GIFs which show you following the described steps and clearly demonstrate the problem. If you use the keyboard while following the steps, record the GIF with the Keybinding Resolver shown. You can use this tool to record GIFs on macOS and Windows, and this tool or this tool on Linux.
- If the problem wasn't triggered by a specific action, describe what you were doing before the problem happened
The process described here has several goals:
- Maintain quality
- Fix problems that are important to users
- Enable a sustainable system for marketplace maintainers to review contributions
Please follow these steps to have your contribution considered by the maintainers:
- Only make pull requests with a completed/functional features, if you are trying to add a feature but having trouble feel free to reach out to the maintainers - we love to help new developers!
- Use in-line comments to document your code contributions.
- Write a clear and meaningful commit title and be descriptive in your pull request comments.
- If there are elements that need improvement or adjustment in your feature clearly indicate that in your pull request e.g. needs additional styling, needs internationalization
- After you submit your pull request, verify that all status checks are passing
What if the status checks are failing?
If a status check is failing, and you believe that the failure is unrelated to your change, please leave a comment on the pull request explaining why you believe the failure is unrelated. A maintainer will re-run the status check for you.
While the prerequisites above must be satisfied prior to having your pull request reviewed, the reviewer(s) may ask you to complete additional design work, tests, or other changes before your pull request can be ultimately accepted.