Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

Before Getting Started

Sign Individual Contributors License Agreement

Individual contributors license agreement (ICLA) needs to be filled in once before the first contribution. Follow the instructions here to fill up ICLA https://cla.developers.google.com/about/google-individual

Security Reports

Please DO NOT file an issue for security related problems. Please send your reports to security@cask.co.

Feature Requests

While proposing a new feature, we look for:

  • An issue in http://issues.cask.co that describes the problem and the action that will be taken to fix it
    • Please review existing proposals to make sure the feature proposal doesn't already exist
  • Email the CDAP mailing list
    • Include "Feature: <Name of the feature>" as the subject of the email
    • Include a link to the issue

Contribution Guidelines

Creating Issues

An issue should be created at http://issues.cask.co for any bugs or new features before anybody starts working on it. Please take a moment to check that an issue doesn't already exist before creating a new issue. If you see that a bug or an improvement exists already, add a "+1" to the issue to indicate that you have the same problem as well. This will help us in prioritization. Discuss on the Mailing List

We recommend that you discuss your plan on the mailing list `cdap-dev@googlegroups.com <mailto:cdap-dev@googlegroups.com>`__ before starting to code. This gives us a chance to add feedback and help point you in the right direction.

Design Document

Document the design the feature design in `http://wiki.cask.co`. While creating a new design document use the CDAP Design template

Pull Requests 

We love having pull requests and we do our best to review them as quickly as possible. If your pull request is not accepted on the first try, don't be discouraged. If there is a problem with the implementation, you will receive feedback on what to improve. Add a link to your PR on the issue, and in an email to `cdap-dev@googlegroups.com <mailto:cdap-dev@googlegroups.com>`__.

Conventions

  • Fork the repository and make changes on your fork in a feature branch. The branch name should be "XXXX-something", where "XXXX" is the number of the issue. 
  • Submit the code, with unit tests for the changes and documentation, if applicable. Take a look at the existing tests to get an idea of what's required.
  • Run the full test suite on your branch before submitting a pull request. This will check for common errors and style mistakes.
  • Update the documentation while creating or changing new features. Test your documentation for clarity and correctness.
  • Write clean code. Uniformity in formatting code promotes ease of writing, reading, and maintenance.
  • Pull requests should have a clear description of the problem being addressed. They must reference the issue(s) they address.
  • Commit messages should include a short summary.
  • All pull requests will be reviewed by one or more committers. Discuss, then make the suggested modifications and push additional commits to your feature branch. Be sure to post a comment after pushing. The new commits will show up in the pull request automatically, but the reviewers will not be notified unless you comment. * Committers use LGTM ("Looks Good To Me") in comments on the code review to indicate acceptance.
  • The code will be merged after the reviewer comments a "LGTM" on the pull request.
  • No labels