Thank you for considering contributing! I write libraries in my free time and contributions from others help me make great tools.
Following these guidelines helps to communicate that you respect my time, as the developer managing and developing this open source project. In return, I should reciprocate that respect in addressing your issue, assessing changes, and helping you finalize your pull requests.
Questions and pull requests are more than welcome. I follow Elixir's tenet of bad documentation being a bug, so if anything is unclear, please file an issue! Ideally, my answer to your question will be in an update to the docs.
Please note that this project is released with a Contributor [Code of Conduct]. By participating in this project you agree to abide by its terms.
- Follow the [Code of Conduct].
- Keep your commits clear and your pull requests small. This isn't a big library.
- Run
mix format
on your files before committing them. I like clean diffs. - Run
mix credo
and resolve anything of yours that comes up. - Delegate as much as possible to the user, or let them override everything.
- Provide sensible defaults.
If you can
use Liberator.Resource
in an empty module in an empty Phoenix project, and make a request that returns200 OK
, you're doing great. - Don't pollute the user's context.
- Ask questions! I like writing good documentation, and questions make that work more meaningful. Use the mailing list for questions or comments. I promise I'll respond promptly.
- Tests are always welcome! Liberator is a project with a lot of conditional logic, with a lot of resulting complexity.
- Searching issues or pull requests tagged "[help wanted]" or "[good first issue]" are great places to get started.
If you're on GitHub, it's really easy to submit a pull request. Just:
- Create your own fork of the code
- Do the changes in your fork
- Submit a pull request
I don't require a CLA or anything like that.
You can also email a patch to the mailing list if you like things old-school.
If you find a security vulnerability, do NOT open an issue. Contact Rosa on keybase.io instead!
In order to determine whether you are dealing with a security issue, ask yourself these two questions:
- Can I access something that's not mine, or something I shouldn't have access to?
- Can I disable something for other people?
If the answer to either of those two questions are "yes", then you're probably dealing with a security issue. Note that even if you answer "no" to both questions, you may still be dealing with a security issue, so if you're unsure, message me directly. For more information on security, see SECURITY.md.
Otherwise, please open an issue.
The philosopy of this project is to create a small, sharp tool that takes the burden of the HTTP spec off of the shoulders of developers. Feature requests and enhancements should stick to this philosophy. Help me implement the HTTP spec more closely, or help me do anything that lets developers do more with their valuable time.
Feature requests give meaning to my work. Open an issue that decribes the feature you'd like to see, why you need it, and how you'd like it to work.
As the primary developer, I will be the one reviewing all pull requests. I'm online far too much, so you should be able to hear back from me quickly. However, I only do this in my free time, so please allow me flexibility.
Participate in our mailing list! This is a small project, but I care about the people that care about my work. I'm also on keybase if you need to message me directly.
If you like this contribution guide, please give a star to Nadia Eghbal's contributing-template
project on GitHub.
It was a great help.
[help wanted]: https://todo.sr.ht/~cosmicrose/liberator?search=label%3A"help wanted" [good first issue]: https://todo.sr.ht/~cosmicrose/liberator?search=label%3A"help wanted" [Code of Conduct]: code_of_conduct.md