Skip to content

Latest commit

 

History

History
121 lines (80 loc) · 4.62 KB

CONTRIBUTING.md

File metadata and controls

121 lines (80 loc) · 4.62 KB

Contributing

👍🎉 First off, thanks for taking the time to contribute to Inspect-JS! 🎉👍

The following is a set of guidelines for contributing to Inspect-JS managed by @LJHarb, which are hosted on GitHub. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.

How Can I Contribute?

There are lots of ways to get involved. Here are some suggestions of things we'd love some help with.

Resolving existing issues

You can consider helping out with issues already requiring attention - look for a "help wanted" label.

Reporting issues

If you run into problems in the project, you can report them by opening a new issue within the repository. Before filing an issue, please perform a cursory search to see if the problem has already been reported. If it has and the issue is still open, add a comment to the existing issue instead of opening a new one.

How Do I Submit a (Good) Bug Report?

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 which command exactly you used in the terminal. 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 or a command, 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.
  • Provide as much context as possible in order to help others verify and ultimately fix the issue.

Documentation

We are happy to welcome contributions from anyone willing to improve documentation by adding missing information or making it more consistent and coherent.

Dev Environment

Style Guide / Coding conventions

Pull requests

Create a new branch

git checkout -b issue1234

Commit the changes to your branch, including a coherent commit message that follows our standards

git commit -a

Before sending the pull request, make sure your code is running on the latest available code by rebasing onto the upstream source

git fetch upstream
git rebase upstream/main

Verify your changes

npm test
# or
npm run tests-only

Push your changes

git push origin issue1234

Send the pull request, make requested changes, and get merged.

Commit Messages

  • Limit the first line of the commit message (message summary) to 72 characters or less.
  • Use the present tense ("Add feature" not "Added feature") and imperative mood ("Move cursor to..." not "Moves cursor to...") when providing a description of what you did.
  • If your PR addresses an issue, reference it in the body of the commit message.
  • See the rest of the conventions here

Commit message example

[Tag]: Short description of what you did

Longer description here if necessary

Fixes #1234

Note: Add co-authors to your commit message for commits with multiple authors

Co-authored-by: Name Here <email@here>

Code of Conduct

Code of Conduct

Where can I ask for help?

If you have any questions, please contact @LJHarb.