Skip to content

Latest commit

 

History

History
31 lines (20 loc) · 2.37 KB

CONTRIBUTING.md

File metadata and controls

31 lines (20 loc) · 2.37 KB
Raw

Contributing

We are thrilled that you would like to contribute to this project. Your help is essential for keeping it great.

We are happy to accept code and documentation contributions, as well as issues suggesting new features, asking questions about how things work, or generally about what we are trying to accomplish! However, we are not opening up the code review process to the public. PRs should only be reviewed by one of the project maintainers. Therefore, we ask that you refrain from leaving approvals or change requests on in-progress pull requests, as spurious reviews make it difficult to discern which patches are truly ready for integration.

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.

Submitting a pull request

  1. Fork and clone the repository
  2. Create a new branch: git checkout -b my-branch-name
  3. Make your change, add tests, and make sure the tests still pass
  4. Push to your fork and submit a pull request
  5. Wait for your pull request to be reviewed and merged.

Here are a few things you can do that will increase the likelihood of your pull request being accepted:

  • Follow the style guide about how to write code.
  • Write tests.
  • Keep your change as focused as possible. If there are multiple changes you would like to make that are not dependent upon each other, consider submitting them as separate pull requests.
  • Write a good commit message.

Unless you are a member of the RegulonDB team or a code owner, we ask that you refrain from leaving approvals or change requests on in-progress pull requests, as spurious reviews make it difficult to discern which patches are truly ready for integration.

Please be aware that contributions to RegulonDB may multiple cycles of code review—we are grateful for all community involvement, but we must maintain a high standard of code quality. For reasons of compatibility, we may also reject or require modifications to changes. We may also reject patches that don't fit with our vision of the project; should this be the case, we will be clear about our rationale.

Resources