Contributing

Thanks for taking a look at connect-assets — and thanks for considering contributing to the project!

One of the most difficult things about managing an open-source project is managing issues and pull requests. The responsibility of the repo owner is to keep an eye on these areas of the project to make sure that they are:

1. not polluted with stale issues and pull requests and are
2. useful, workable items.

If an issue is reported but nobody can actually work on the issue (due to lack of information or other reasons) then it is in the way of making progress on other issues and should be closed.

Keeping this in mind, you should not consider a closed issue or pull request to be dead — it just doesn’t have enough information to be found useful. If you have had an issue or pull request closed, don’t give up! Make sure that you are communicating clearly.

Opening Issues

Sorry to hear that you’re having an issue with connect-assets. Before you open a new issue, be sure to search for a similar issue — you might find an answer to your problem faster.

If you’re unable to find an answer already, here are some tips for creating an issue that will be addressed quickly:

1. Clearly describe the issue you are having, including any relevant errors you are seeing.
2. Include the version of node, connect-assets, and all relevant packages that you’re using.
3. Include a reduced test case or minimal working example. The more code, the harder your issue is to solve. Please be as brief as possible.

Pull Requests

Wahoo! Thanks for considering submitting a pull request! Before you open a new pull request, be sure to search for a similar issue or pull request - you might find an answer to your problem faster.

If you anticipate your pull request being large, you may consider opening an issue first so you don’t spend a bunch of time working on an idea which isn’t something that is in the future of this project.

When you submit a pull request:

1. Clearly describe the issue that you’re trying to fix or the feature you’re adding. It’s a good idea to follow the issue guidelines above, if an issue doesn’t already exist. If you’re fixing an issue, be sure to mention that issue by number in your pull request. If your pull request doesn’t have a clearly written description, it’s unlikely to be merged.
2. Include at least 2 commits. The first commit should be a test which fails. The second commit should fix that test.
3. Follow the syntax and style of the file that you’re editing. Pay attention to spacing, variable naming conventions, and be sure to make your changes as simple and self-explanatory as possible.
4. Expect your pull request to be reviewed. You’ll likely receive feedback about specific lines of code and will be asked to change some things. Please don’t consider this to be a personal attack — thank you for taking the time to dig into the code!