Contributing to restgoose

You are here to help on restgoose? Great, welcome aboard! The following sections in order to know how to ask questions and how to work on something.

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, assessing changes, and helping you finalize your pull requests.

Restgoose is an open source project and we love to receive contributions from our community — you!

There are many ways to contribute, from writing tutorials or blog posts, improving the documentation, submitting bug reports and feature requests or writing code which can be incorporated into restgoose itself.

Ground Rules

Technical

• Don’t add any classes to the codebase unless absolutely needed. Err on the side of using functions.
• Keep feature versions as small as possible, preferably one new feature per version. If it does too much, break it up into smaller PRs.
• Ensure that code that goes into core meets all requirements in this checklist:
  • General
    • Is this change useful to me, or something that I think will benefit others greatly?
    • Check for overlap with other PRs. If another PR exists, please explain why yours is different and/or better.
    • Think carefully about the long-term implications of the change: how will it affect existing projects that are dependent on this? How will it affect my projects? If this is complicated, do I really want to maintain it forever? Is there any way it could be implemented as a separate package, for better modularity and flexibility?
  • Code quality
    • Does it pass tslint?
    • Is it consistent?
    • Review the changes carefully, line by line. Make sure your changes are as small as possible (for example, don’t fix a typo in portions of code you don’t modify otherwise).
    • Take the time to get things right. PRs almost always require additional improvements to meet the bar for quality. Be very strict about quality. The better the quality in your original PR, the faster it can get merged in the master branch.
  • Tests
    • If any new features are added, it must be tested.
    • Does it have tests? If not, explain why there is none (“I don’t know what to test” is a valid answer, as long as you explain why it’s not done).
    • Do the tests pass ? If not, write a note in the PR, or fix them yourself.
    • NEVER disable a test before discussing it in an issue.
  • Docs
    • Does it have docs? If not, explain why there is none.
    • If any new features are added, are they in docs/API.md and CHANGELOG.md?
  • Credits
    • If this is your first PR, add your name and Github account in docs/AUTHORS.md.
    • Copy and paste title and PR number into CHANGELOG.md.

Community

• Create issues for any major changes and enhancements that you wish to make. Discuss things transparently and get community feedback.
• Be welcoming to newcomers and encourage diverse new contributors from all backgrounds. See the code of conduct.

Working on your first Pull Request? You can learn how from this free series, How to Contribute to an Open Source Project on GitHub.

How to report a security vulnerability

If you find a security vulnerability, do NOT open an issue. Email xureilab@gmail.com instead.

Any security issues should be submitted directly to xureilab@gmail.com. In order to determine whether you are dealing with a security issue, ask yourself these two questions:

• Can I access something that’s not mine, or something I shouldn’t have access to?
• Can I disable something for other people?

If the answer to either of those two questions are “yes”, then you’re probably dealing with a security issue. Note that even if you answer “no” to both questions, you may still be dealing with a security issue. If you’re unsure, just email us at xureilab@gmail.com.

How to report a bug

When filing an issue, make sure to provide these informations:

1. Version of Node.js that you are using (node --version),
2. A minimal piece of code reproducing the issue,
3. The expected result,
4. The returned result

General questions should go to the subreddit r/restgoose/. Also consider StackOverflow.

How to suggest a feature or enhancement

If you find yourself wishing for a feature that doesn’t exist in restgoose, you are probably not alone. There are bound to be others out there with similar needs.

Simply open an issue with ‘Feature proposal’ in the title, describe the feature you would like to see, why you need it, and how it should work.

Code review process

The core team looks at Pull Requests on a weekly basis. At least one review from the core developers is required for a PR to be merged.

We usually answer to any issue or Pull Request in two working days. The reviewing and merging process takes typically less than a week.

Community

You can discuss with the core team on Reddit: r/restgoose/.