Please take a moment to review this document in order to make the contribution process easy and effective for everyone involved.
Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project. In return, they should reciprocate that respect in addressing your issue, assessing changes, and helping you finalize your pull requests.
Contributions to CouchDB are governed by our Code of Conduct and a set of Project Bylaws. Apache CouchDB itself also has a CONTRIBUTING.md if you want to help with the larger project. Come join us!
If you never created a pull request before, welcome 🎉 😄 Here is a great tutorial on how to send one :)
The Readme file has information about how to get the project set up for development.
We follow our coding-styleguide to make it easier for everyone to write, read and review code: https://github.com/apache/couchdb-fauxton/blob/main/styleguide.md
To start working on a specific ticket, create a branch with the GitHub Issue # followed by a traincase description of the issue.
e.g. 1234-Added-support-for-list-functions
If there is no GH Issue for the issue you have, you don't have to create one. Please describe the issue, how it happens and how you fixed it in the commit message.
Commit messages should follow the following style:
A brief one line description < 72 chars
Followed by further explanation if needed, this should be wrapped at
around 72 characters. Most commits should reference an existing
issue
Fixes #XXX (if there is a GH Issue)
Fixes apache/couchdb#XXX (if there is a CouchDB project GH Issue)
Before you submit the Pull Request, please run our test suite and make sure that it passes.
We regularly check the PR list for Fauxton and should get back to you with a code review.
We appreciate constructive feedback from people who use CouchDB, so don't be shy. We know there are bugs and we know there is room for improvement.
ʕ´•ᴥ•`ʔ Thanks!
-- Fauxton team