{{>toc}}

h1. How to contribute

We suppose that you've seen the http://opencv.org/contribute.html page, and now, as an enthusiastic coder, want to contribute some code. For that purpose OpenCV project now has a mirror on the GitHub, to simplify everybody's life! All And if you're familiar with the bug fixes, new functionality, new tutorials etc. should be submitted via the GitHub's mechanism GitHub way of pull requests.

If working, you are not can contribute in a friendly and familiar with way. So, the mechanism - preferred way to submit your code is to create a pull request on the GitHub (you can even do not worry, it's very simple. Keep reading. create tickets here). This way it will be automatically tested and reviewed: http://pullrequest.opencv.org.

Ready to start? Here is the repository to fork: https://github.com/Itseez/opencv.

h2. Overall process

Here are some important details regarding the contribution to the OpenCV project.

h3. "Fork & PullRequest Pull model" for code contribution

# Install [[Git]].
# Register at GitHub. Create your fork of OpenCV repository repository: https://github.com/Itseez/opencv (see https://help.github.com/articles/fork-a-repo for details).
# Make a branch (with a meaningful name) of one of Choose the OpenCV right "base branches", to branch" onto which you pull request will submit the pull request. be applied. As of today (Feb 2013), OpenCV has two main branches for development:
## "2.4" - used for the next minor releases of OpenCV (e.g. 2.4.3, 2.4.4, etc). This branch is good for contributing performance optimizations and bugfixes. New functionality usually goes to the "master" branch. Please note, "2.4" can contain only "binary compatible code":http://upstream-tracker.org/versions/opencv.html relative to the current major version (2.4).
## "master" - used for the future major releases of OpenCV (2.5). It can contain binary incompatible with current major version changes. By default all the new code goes here.
# Modify/add the code following our [[Coding Style Guide]]. Write code, according to all prerequisites from below.
# When you are done, create a pull request with your commits (see https://help.github.com/articles/using-pull-requests for details).

h2. h3. Testing and merging of pull requests

# Your pull request will be automatically tested by OpenCV's buildbot (testing status can be checked here: http://pullrequest.opencv.org). If any builders are failed, you should fix the issue. As you fix the code and push changes to your branch at github, buildbot reruns automatically. _No need to close pull request and open a new one!_
# Once When all the builders are "green", green, one of OpenCV developers will review your code. Reviewer could ask you to modify your pull request. Please provide timely response for reviewers (within weeks, not months), reviewers, otherwise you submission could be postponed or even rejected.

Here is the flow-chart of the process:
h3. Pull request lifecycle

!https://docs.google.com/drawings/pub?id=1_m7oVQ4CvoMxZn63N1_TyhhazmLLWY5uLEGUyPCERLo&w=960&h=720!

h2. Happy End Prerequisites

#. As soon Below are some recommendations for contributors. They are raw, but can be used as a starting point for anybody who wants to see his code added to the reviewer library.

> We would gladly accept such a contribution, but because of little resources available on our side, I would ask you to do all the preparations. Here is fine with the pull request checklist, including both generic items and BuildBot likes your code, the special single-character comment ":+1:" or ":shipit:" is put, which allows OpenCV maintainers specific things related to merge your pull request. code that I found after brief inspection:

# The last, but A prerequisite: is the algorithm patented? If yes, then we may not least. Make sure you got credits. We try be that interested in putting it in.
# License - the current license is fine, it's compatible with OpenCV.
# Interface. Here some work is needed to memorize make this code a seamless part of OpenCV.
** @M_PI -> CV_PI@
** You should remove all the contributions static constants from the header. it's not portable and list major ones generally a bad practice. Use defines and enumerations.
** cv:: and std:: should not be used in the ChangeLog header, since all the stuff is already inside cv namespace and release announcements, but we may forget to already have "using std::vector", "using std::string" directives.
** "m_" in member names should be dropped, we do that, unintentionally. Please, do not hesitate this convention in OpenCV.
# Implementation.
** The code should be portable, it should compile fine on ARM too, for example. Therefore, you should not use SSE2 intrinsics outside of conditional compilation. Instead of "#ifdef USE_SSE" you should use "#if CV_SSE2".
** Avoiding duplication of existing OpenCV functionality.
** Writing to remind us, and we cerr should be replaced with CV_Error() calls.
# Documentation.
** Documentation in RST format should be provided for the functionality. Check http://docs.opencv.org/modules/features2d/doc/feature_detection_and_description.html#orb as example.
# You should provide sample code.
** help() function should be added, check opencv/samples/cpp.
# Regression tests - the code should include some regression tests.
** Please, take a look at opencv/modules/features2d/test/test_features2d.cpp. You will update opencv.org need to add a similar test for your code.
# Integration
** Take the latest version of our repository or fork from our github mirror at https://github.com/Itseez/opencv/
** Add your code
** Insert documentation and add the ChangeLog accordingly. test to the corresponding module
** Build OpenCV, run tests. If you have access to both Linux and Windows - great! Sometimes GCC-approved code does not built with MSVC and vice versa.
** Create pull request on http://github.com or create patch file or and submit it as patch at http://code.opencv.org/projects/opencv/issues/new.