|
| 1 | +# Contributors guide v0.1 |
| 2 | + |
| 3 | +## How can I help? |
| 4 | + |
| 5 | +We are always happy to help you in contributing to Watermill. If you have any ideas, please let us know on our [Slack channel](https://github.com/ThreeDotsLabs/watermill#support). |
| 6 | + |
| 7 | +There are multiple ways in which you can help us. |
| 8 | + |
| 9 | +### Existing issues |
| 10 | + |
| 11 | +You can pick one of the existing issues. Most of the issues should have an estimation (S - small, M - medium, L - large). |
| 12 | + |
| 13 | +- [Good first issues list](https://github.com/ThreeDotsLabs/watermill/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22) - simple issues to begin with |
| 14 | +- [Help wanted issues list](https://github.com/ThreeDotsLabs/watermill/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22) - tasks that are already more or less clear, and you can start to implement them pretty quickly |
| 15 | + |
| 16 | +### New Pub/Sub implementations |
| 17 | + |
| 18 | +If you have an idea to create a Pub/Sub based on some technology and it is not listed yet in our issues (because we don't know it, or it is just some crazy idea, like physical mail based Pub/Sub), feel free to add your own implementation. |
| 19 | +You can do it in your private repository or if you want, we can move it to `ThreeDotsLabs/watermill-[name]`. |
| 20 | + |
| 21 | +*Please keep in mind that you will not be able to push changes directly to the master branch in a project in our organization*. |
| 22 | + |
| 23 | +When adding a new Pub/Sub implementation, you should start with this guide: [https://watermill.io/docs/pub-sub-implementing/](https://watermill.io/docs/pub-sub-implementing/). |
| 24 | + |
| 25 | +### New ideas |
| 26 | + |
| 27 | +If you have any idea that is not covered in the issues list, please post a new issue describing it. |
| 28 | +It's recommended to discuss your idea on Slack/GitHub before creating production-ready implementation - in some situations, it may save a lot of your time before implementing something that can be simplified or done more easily. :) |
| 29 | + |
| 30 | +In general, it's helpful to discuss a Proof of Concept to align with the idea. |
| 31 | + |
| 32 | +## Local development |
| 33 | + |
| 34 | +Makefile and docker-compose (for Pub/Subs) are your friends. You can run all tests locally (they are running in CI in the same way). |
| 35 | + |
| 36 | +Useful commands: |
| 37 | +- `make up` - docker-compose up |
| 38 | +- `make test` - tests |
| 39 | +- `make test_short` - run short tests (useful to perform a very fast check after changes) |
| 40 | +- `make fmt` - do goimports |
| 41 | + |
| 42 | +## Code standards |
| 43 | + |
| 44 | +- you should run `make fmt` |
| 45 | +- [CodeReviewComments](https://github.com/golang/go/wiki/CodeReviewComments) |
| 46 | +- [Effective Go](https://golang.org/doc/effective_go.html) |
| 47 | +- SOLID |
| 48 | +- code should be open for configuration and not coupled to any serialization method (for example: [AMQP marshaler](https://github.com/ThreeDotsLabs/watermill-amqp/blob/master/pkg/amqp/marshaler.go), [AMQP Config](https://github.com/ThreeDotsLabs/watermill-amqp/blob/master/pkg/amqp/config.go) |
0 commit comments