How to Contribute

Complete a Contributor License Agreement

In order to accept any contribution, the contributor must complete and return a Contributor License Agreement, or CLA. Separate CLAs exist for individuals (an individual contributor license agreement, or ICLA) and corporations (a CCLA). The CLA grants a copyright and patent license to Cloudera, and users of the software, states that you are legally entitled to grant such a license, as well as other important stuff. See the Cloudera ICLA and Cloudera CCLA files included with this software for all of the details.

Completed CLAs may be emailed to cla@cloudera.com, faxed, or snail mailed to Cloudera.

Create a Pull Request

This project uses Github. Pull requests are the easiest form of contribution to accept and preferred. If this sounds like Klingon to you, Github has an excellent description of using pull requests. We follow the _Fork & Pull_ model described in the Github documentation.

Tips

Contributions are strongly encouraged. Its the easiest way to get the features you want into the code, and fast. However, the project maintainers are tasked with developing software for many people with diverse requirements and, as a result, may not accept all contributions. Here are some tips for ensuring a contribution is accepted.

• Think about everyone.

Its really important to remember that many people use this software. Features, improvements, or changes that do not apply to a wide audience may not make sense to include in the project. Put yourself in other peoples shoes and ask if this is something that is useful to them.

• Follow existing style and standards.

Its critical that the code base, docs, and examples behave and look the same. If some parts of the code use different libraries to do the same thing, have slightly different semantics or guarantees, use different naming conventions, or track different standards, its very likely your contribution cant be accepted. Put yourself in the shoes of a new contributor; they should only have to learn a single way of doing things.

• Accept feedback and provide rationale.

Its likely that youll receive feedback on your contribution, especially those who are new to contributing to open source projects. Dont panic! Were all very nice people. Keep a few things in mind:

• If we disagree, help us understand the rationale behind a decision. Maybe were missing something.
• Questions are usually just questions, and are not meant to question your ability. Its just as awkward for us to ask as it is for you to defend your decisions. Bear with us, and remember that our goal is to serve the larger community of users.
• It helps to detach your idea from your implementation. Sometimes, you may be asked to make changes to your implementation, but everyone agrees that the idea is great. Be open to that.
• Many times feedback is subjective. Words like elegant, simple, and easy are often thrown around, but hard to define. Its important to recognize that one persons simple is another persons complex, except in the case of simply complex.
• We are incredibly grateful you took the time to contribute, even if we decide we cant accept your code.

• Disagree and commit

Sometimes, theres no compromise, no middle ground. Sometimes, people are just going to see things differently. Some people like baseball; not everything in life makes sense. When this happens, please understand were all just trying to do what we think is right. If a contribution is rejected, or something doesnt make sense, tell us, accept the decision, and move on.

Watch this: http://ecorner.stanford.edu/authorMaterialInfo.html?mid=1642

Now watch it again: http://ecorner.stanford.edu/authorMaterialInfo.html?mid=1642