These guidelines are here to facilitate your contribution and streamline the process of getting changes merged into this project and released. Any contributions you can make will help tremendously, even if only in the form of an issue report. Following these guidelines will help to streamline the pull request and change submission process.
If you notice any problems with any documentation, please fix it and we'll get it merged as soon as we can. For small things like typos and grammar, just click the "Edit this file" button and send in the pull request for the fix. For larger changes and big swaths of documentation changes, a regular pull request as outlined below is more appropriate.
Before doing anything else, we ask that you file an issue in the Issues list for this project. First, be sure to check the list to ensure that your issue hasn't already been logged. If you're free and clear, file an issue and provide a detailed description of the bug or feature you're interested in. If you're also planning to work on the issue you're creating, let us know so that we can help and provide feedback.
The work you are doing for your pull request should not be done in the master branch of your forked repository. Create a topic branch for your work. This allows you to isolate the work you are doing from other changes that may be happening.
Github is a smart system, too. If you submit a pull request from a topic branch and we ask you to fix something, pushing a change to your topic branch will automatically update the pull request.
See the previous item on creating a topic branch.
If you don't use a topic branch, we may ask you to re-do your pull request on a topic branch. If your pull request contains commits or other changes that are not related to the pull request, we will ask you to re-do your pull request.
When you've completed your work on a topic branch, we prefer that you squash your work down into a single commit to make the merge process easier. For information on squashing via an interactive rebase, see the rebase documentation on GitHub.
You should also follow the AngularJS Git Commit Message Conventions for you commit message since we are using the grunt-conventional-changelog grunt task to generate our CHANGELOG.
See Github's documentation for pull requests.
Pull requests are the preferred way to contribute to angular-kendo. Any time you can send us a pull request with the changes that you want, we will have an easier time seeing what you are trying to do. But a pull request in itself is not usually sufficient. There needs to be some context and purpose with it, and it should be done against specific branch.
It is very important to provide a meaningful description with your pull requests that alter any code. A good format for these descriptions will include three things:
-
Why: The problem you are facing (in as much detail as is necessary to describe the problem to someone who doesn't know anything about the system you're building)
-
What: A summary of the proposed solution
-
How: A description of how this solution solves the problem, in more detail than item #2
-
Any additional discussion on possible problems this might introduce, questions that you have related to the changes, etc.
Without at least the first 2 items in this list, we won't have any clue why you're changing the code. The first thing we'll ask, then, is that you add that information.
We're not dogmatic about code style, here, but we do believe that a project should adhere to a consistent style. All Kendo UI Labs projects are expected to follow the following style guidelines, so please keep these in mind before you submit your Pull Requests:
- Tab indentation, size of 2
- Semicolons are nice. Use them
- Single quotes
- No trailing whitespace
- Declare variables at the top of a scope
- Return early
- Be JSHint Valid
Beyond these, you're best bet, when it doubt it to follow idiomatic.js.