Skip to content

Latest commit

 

History

History
63 lines (47 loc) · 2.65 KB

CONTRIBUTING.md

File metadata and controls

63 lines (47 loc) · 2.65 KB

Contributing

All kinds of contributions to git-remote-dropbox are greatly appreciated. For someone unfamiliar with the code base, the easiest way to contribute is probably to submit a feature request or bug report. If you want to dive into the source code, you can submit a patch as well, either working on your own ideas or existing issues.

Feature Requests

Do you have an idea for an improvement to git-remote-dropbox? Please submit a feature request. It's great to hear about new ideas.

If you are inclined to do so, you're welcome to fork git-remote-dropbox, work on implementing the feature yourself, and submit a patch. In this case, it's highly recommended that you first open an issue describing your enhancement to get early feedback on what you're doing. This will help avoid wasted efforts and ensure that your work is incorporated into the code base.

Bug Reports

Did something go wrong with git-remote-dropbox? Sorry about that! Bug reports are greatly appreciated!

When you submit a bug report, please include relevant information such as git-remote-dropbox version, Git version, operating system, error messages, and steps to reproduce the bug. The more details you can include, the easier it is to find and fix the bug.

Patches

Want to hack on git-remote-dropbox? Awesome!

You may find the documentation in DESIGN.rst and the source code helpful.

If there are open issues, you're more than welcome to work on those - this is probably the best way to contribute code to git-remote-dropbox. If you have your own ideas, that's great too! In that case, before working on substantial changes to the code base, it is highly recommended that you first open an issue describing what you intend to work on.

Patches are generally submitted as pull requests. Patches are also accepted over email.

Any changes to the code base should follow the style and coding conventions used in the rest of the project. The version history should be clean, and commit messages should be descriptive and properly formatted.


If you have any questions about anything, feel free to ask!