Contribution Guide

Assumptions:

• Have some idea what MADlib is for.
• Get familiar with the project, and the hotest issues:

0. Get

1. Decide what to work on. Get advice using Google groups.

2. Get access to GitHub and Fork MADlib project.

3. Develop away using your own copy/fork of the MADlib repo. Things to watch for:

• Good coding practices: Coding Patterns & Best Practices Guide
• Proper API: SQL API Guide
• Full documentation: Documentation Guide (Doxygen)
• Installer Compliance: MADlib Installer Guide
• Good Unit Tests: Unit Testing Guide

4. Done? Send pull-request from your fork. This will generate an email to project commiters. Someone will review your changes and merge them or not.

1. Coding:
   • Core functionality (SQL, C, Python)
   • Use MADLIB_SCHEMA as the schema prefix.
   • Packaging and migrations (follow: PackMan notes)
2. Documentation (using Doxygen tags):
   • Write a user guide under under @namespace tag. See http://doc.madlibrary.org
   • Dev reference is (currently) just an unlimited version of the user doc. See http://devdoc.madlibrary.org
3. Unit tests:
   • Use PGXS regression tests
     • (Notes from PostgreSQL.org)
     • See example in the sketch method
4. Schedule code reviews (use Caleb, Gavin for now, unless you know someone else can help) using Crucible at http://codereview.madlibrary.org:
   • Initial code review on whole files.
   • Further code review on full files or specific commits.
5. Integration testing and QA:
   • Ask someone (you can also open a gitgub issue for tracking purposes)
   • We are currently looking for resources.