How to Contribute

Join the cdk-dev group

Join the cdk-dev group for discussion of CDK development.

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 are 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. It’s 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.

It’s 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 people’s shoes and ask if this is something that is useful to them.

• Follow existing style and standards.

It’s 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, it’s very likely your contribution can’t 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.

It’s likely that you’ll receive feedback on your contribution, especially those who are new to contributing to open source projects. Don’t panic! We’re all very nice people. Keep a few things in mind:

• If we disagree, help us understand the rationale behind a decision. Maybe we’re missing something.
• Questions are usually just questions, and are not meant to question your ability. It’s 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. It’s important to recognize that one person’s “simple” is another person’s “complex,” except in the case of “simply complex.”
• We are incredibly grateful you took the time to contribute, even if we decide we can’t accept your code.

• Disagree and commit

Sometimes, there’s 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 we’re all just trying to do what we think is right. If a contribution is rejected, or something doesn’t 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