Before submitting your contribution, please make sure to take a moment and read through the following guidelines.
Thank you very much for your interest, we are really excited working with you.
This guideline proposes a simple set of rules and requirements that dictate how version numbers are assigned and incremented. Given a version number BREAKING.FEATURE.FIX, increment the:
- BREAKING version for any breaking changes, even small.
- FEATURE version when you add functionality in a backwards-compatible manner
- FIX version when you make backwards-compatible bug fixed
We believe that releases and versions are two different concepts. Similar to semantic versioning, we consider though that the major version (or BREAKING) should be an indication for software that there is a breaking change down coming down the pipe. This new versioning format allows developers to break code and push often. They don't have to resist the need to advance the breaking version (major) because they're not yet ready to release their software.
With that being said it is important to:
- start with the version 1.0.0 (instead 0.X.X)
- to increment the breaking version number for any braking changes (even small)
- name releases for humans
see inspiration
The issue list of the repository you working on is exclusively for feature requests, ideas and bug reports. Issues that do not conform with our code of conduct will be closed immediately.
-
for questions, please refer to the twitter account or gitter chat room listed in the project README.
-
make sure the issue entered do not already exist or been already answered (closed issues might contain the branch or software version containing the fix).
-
please indicate the version you are using and try reproducing the issue with the latest stable version of the project your are working on
-
Use clear language and describe the step necessary to reproduce the issue you are running into. Issues with no clear description will be fixed later on.
-
It is recommended to fork the project and create a test case for your issue if the project has unit tests.
inspired by Github PR guidelines
We consider pull request as the primary process to communicate, explore and share ideas and features. Pull Request should be created at the beginning of this process and not at the end.
-
Include a brief sentence to explain the purpose of this Pull Request. For example:
- This is a spike to explore…
- This simplifies the display of…
- This fixes handling of…
-
Consider providing an overview of why the work is taking place (with any relevant links); don’t assume familiarity with the history.
-
Remember that anyone could be reading this Pull Request, so the content and tone may inform people other than those taking part, now or later.
-
Use clear language and be explicit about your expectations.
-
@mention individuals or teams that you specifically want to involve in the discussion, and mention why.
Pull Request are a safe place, there are no wrong questions and any feedback are welcomed.
Feedback and criticism should always be positive and draw attention to a good or positive aspect of something which is being ignored, disregarded or overlooked. If you disagree with something, please consider giving it a few minutes to familiarize yourself with the issue and before responding. We won't accept language that do not respect our community guideline.
-
Ask, don't tell and most important, explain your reasons why you disagree and why code should be changed. Communication is about trying to understand other's people perspective and background.
-
Avoid using derogatory terms, like “stupid”, when referring to the work someone has produced.
-
Be humble. (“I’m not sure, let’s try…”)
-
Avoid hyperbole. (“NEVER do…”)
-
Be aware of negative bias with online communication. (If content is neutral, we assume the tone is negative.) Can you use positive language as opposed to neutral?
-
Use emoji to clarify tone. Compare “✨ ✨ Looks good 👍 ✨ ✨” to “Looks good.”