All contributions are welcome. Ideas, code, documentation, production experiences, bugfixes ... we only need to define some key ideas in order to make this more efficient.
- Good documentation.
- The project strives for simplicity.
- The library itself represents a spirit of composition, it enables users, it doesn't try to drive them.
- Use testing strategies wisely. Take care of testing code equal or better than production one.
Creating a new issue it's generally a good way to share your ideas and get feedback. We do not have templates for issues. We consider creating good issues and documentation its part of the creative process, and we don't want to interfere on it. However, it's encouraged to provide as much context as possible. Feel free to talk about a specific use case, show the maintainers what we are trying to solve.
Explore the available labels in order to proper categorize it and get the fastest feedback.
If the contribution it's a bugfix, a little feature or documentation improvement that could be implemented in, lets say, a couple of days at maximum, one could go directly for a PR. It's fine.
In general, contributions should be done by the typical fork workflow. In this workflow, developers fork this repository and then just submit pull requests to this one.
Goomerang provides a laboratory for simulating a production environment. Check it here.
The project follows semver for versioning, and we keep a CHANGELOG.md. All contributions should
be done against the develop branch, in which all changes will be buffered till a new release is published.
Whenever you are interacting, just ensure that your interaction (issue, comment, reply ...) passes the T.H.I.N.K test, by asking the following questions. Is it ...
T. Truthful? H. Helpful? I. Inspiring/Interesting? N. Necessary? K. Kind?