Code Review Process

Please refer to guidelines for details on how to use Source Code Control to create forks and contribute code to the WebsitePanel project.

As a contributor ensure you have,

Taken ownership of a particular feature request/bug tracking issue tracker item.
A core team member has assigned the issue tracker work item to you. This ensures no one else is working on the same item. This is to prevent duplicated work.
Submitted pull requests with descriptive comments. Instructions on how to use the Source Code Control is available here.
Mentioned the issue tracker number (E.g. Item #4) that the patch/module addresses.
Included test cases in the module. Different types of test cases pertain to different kinds of modules. Please follow the list of test cases per module (coming soon). The review team will rely on using the test cases that were included as part of the code to accept submissions. Pull requests with no test cases will be sent back to the contributor and results on extra communication/cycles. Additionally, test cases help testers who will help test the additions in the QA phase. Sample test cases can be found here.
Followed the Code Conventions (coming soon). This ensures code consistency.

Once the contributor has made a pull request, the core team will review the pull request and the code and test the code submissions. Test cases submitted by the contributor will be used along with other required compatibility tests. What makes a good Pull Request?

The review process is to ensure that additions to the Dev branch do not break other pieces of code. After the review, a core team member accepts or declines the pull request. Declined pull requests will contain specific reason for decline. In case a pull request is declined please be sure to review the comments and make the changes suggested or get back to us in case of queries.

As per the release cycles the build corresponding to the added patch will be available in the weekly builds following the accepted pull request. It is highly recommended that the contributor test the additions once the weekly builds have been published. Though testers will work on testing the addition, a contributor who is able to verify if the code is performing the way it was expected after integration will be very helpful for early fixes in case of bugs.