If you're thinking about contributing, then before you write any code, please communicate with the ToDD community first. In these early days, ToDD is going through a lot of changes, and I would hate for you to waste your time writing code that may already be in progress, or no longer needed. For any immediate issues, please open a Github issue, and be specific about the problem you're having and/or would like to tackle. For longer conversations, please use the mailing list.
I am still building out the CI pipeline, but I will be fairly strict about contributions with respect to Golang idioms and proper unit/integration testing. Now that ToDD is open sourced, I want to focus on these much more, and as a result I want to make sure contributions help, not hurt this effort. Here are some resources that may help you in this regard:
My preferred methodology for contributing is still being worked out, so for the time being, err on the side of caution and start a conversation with me via a github issue first. I'll do my best to be responsive towards that medium.
Please refer to the .travis.yml file in the root of the repository in order to see the build steps being performed. I will not look at a PR until it produces a passing build, so to save time, try to run these build steps yourself on your own machine first.
Also, and this is important - the smaller and more single-purpose your PRs are, the better. I am happy to review just about any PR that passes the build and seems to be a good idea, but I do have a day job and if you want a quick turnaround, keep them small!
If you're wondering what there is to work on, I try to keep the issues for this project populated with any known issues, so feel free to peruse that list.
If you have a QUESTION, please ask on the #todd channel at Network to Code slack channel, or via the todd-developers email list. See additional resources for info on these communities.
If you are trying to report a bug, or other problems with ToDD, please open a Github issue. When opening an issue, be aware that you're going to be asked for a few things, and it will save you time to just provide them from the beginning:
- Clear, concise explanation of the steps leading up to the problem (a.k.a how can a maintainer reproduce this issue on their own?)
- ToDD server and agent configuration files
- ToDD server and agent logs
Generally, the more information you can provide from the beginning, and the clearer it is, the more likely you'll get a quick, useful response. ToDD's used by folks all around the world, and sometimes waiting 12+ hours for a response is bad enough - having to go through the boilerplate discussions just adds to that.