Skip to content

Latest commit

 

History

History
92 lines (62 loc) · 3.31 KB

CONTRIBUTING.md

File metadata and controls

92 lines (62 loc) · 3.31 KB
Raw

Contributing Guidelines

First of all, thank you for contributing, you are awesome!

Before starting, you should read, agree to, and follow these three things:

How to contribute?

Report Bugs

Report bugs at: https://github.com/IFB-ElixirFr/Wasm4Learn-doc/issues/new.

When reporting a bug, please include:

  • Any details about your local setup which might be helpful in troubleshooting
  • Detailed steps to reproduce the bug. Where possible, please write a test case

If you are not able to do that, that's fine! Open an issue anyway and let us know as much information as you can. We will get back to you to determine the problem, and (hopefully) fix it.

Fix Bugs

Check out the open bugs - anything tagged with the [easy pick] label could be a good choice for newcomers (and we are willing to help you).

We have two kind of bugs: [critical] and [bug]. We tend to fix critical bugs as soon as possible. Feel free to come up with a patch before we do though!

Implement Features

Look through the GitHub issues for features. Anything tagged with [improvement] or [feature] is open to whoever wants to implement it.

If the issue is unclear or you are not sure what is expected, ask for more information by commenting on the issue.

Submit Feedback

Any issue with the [question] label is open for feedback, so feel free to share your thoughts with us!

The best way to send feedback is to create a new issue on GitHub.

If you are proposing a feature:

  • Explain how you envision it working. Try to be as detailed as you can
  • Try to keep the scope as narrow as possible. This will help make it easier to implement
  • Feel free to include any code you might already have, even if it is just a rough idea. This is a volunteer-driven project, and contributions are welcome :)

Your issue will be flagged as [feature request] first, and if we agree on it, we will label it as [feature], meaning it has been accepted and the feature will eventually be added to the project.

Pull Request Guidelines

Here are a few rules to follow in order to make code reviews and discussions go more smoothly before maintainers accept and merge your work:

  • you MUST run the test suite
  • you MUST write (or update) unit tests
  • you SHOULD write documentation

Please, write commit messages that make sense, and rebase your branch before submitting your Pull Request.

You may be asked to squash your commits too. This is to "clean" your Pull Request before merging it (we don't want commits such as fix tests, fix 2, fix 3, etc.).

Also, while creating your Pull Request on GitHub, you MUST write a description which gives the context and/or explains why you are creating it.

For further information about creating a Pull Request, please read this blog post.

Thank you!