Contribution Guide

Before You Start:

• You should have some idea about the project and it's purpose. If you don't... start here: http://madlib.net
• You should be familiar with the project contents. If you are not... look at this:
  • Existing Methods: http://devdoc.madlib.net
  • Development Status
  • Future Methods: Contrib Status
• You should have some knowledge on relational databases, SQL, Python, C/C++, statistics and machine learning.

Step 1: Make friends with GitHub

• Create an account on GitHub.com.
• Get a git client from git-scm.com.
• Play with it. Follow Bootcamp guides on help.github.com to gain some confidence.

Step 2: Pick your project

• Create an account on MADlib JIRA and review the Open issues.
• Found one that you like? Write a Comment and ask for assignment.
• Can't find anything to work on or have a question? Send a message to Dev Forum

Step 3: Fork MADlib project

• Go 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.