We'd love for you to contribute to our source code and to make Tesla better than it is today! We actively welcome your pull requests. If you run into problems, please open an issue on GitHub.
If you have questions about how to use Tesla, please direct these to the Telsa Group discussion list.
If you find a bug in the source code or a mistake in the documentation, you can help us by submitting an issue to our [GitHub Repository][github]. Even better you can submit a Pull Request with a fix.
Please see the Submission Guidelines below.
You can request a new feature by submitting an issue to our [GitHub Repository][github]. If you would like to implement a new feature then consider what kind of change it is:
- Major Changes that you wish to contribute to the project should be discussed first on our dev mailing list so that we can better coordinate our efforts, prevent duplication of work, and help you to craft the change so that it is successfully accepted into the project.
- Small Changes can be crafted and submitted to the [GitHub Repository][github] as a Pull Request.
If you want to help improve the docs, it's a good idea to let others know what you're working on to minimize duplication of effort. Before starting, check out the issue queue. Comment on an issue to let others know what you're working on, or create a new issue if your work doesn't fit within the scope of any of the existing doc fix projects.
For large fixes, please build and test the documentation before submitting the Pull Request to be sure you haven't accidentally introduced any layout or formatting issues. You should also make sure that your commit message is labeled "docs:" and follows the Pull Requests outlined below.
If you're just making a small change, don't worry about filing an issue first. Use the friendly "pen" button at the top right of the doc page to fork the repository in-place and make a quick change on the fly. When naming the commit, it is advised to still label it according to the commit guidelines below, by starting the commit message with docs and referencing the file name. Since this is not obvious and some changes are made on the fly, this is not strictly necessary and we will understand if this isn't done the first few times.
- Fork the repo and create your branch from
master. - If you've added code that should be tested, add tests.
- If you've changed APIs, update the documentation.
- Ensure the build successes and unit test passes (
mvn clean install). - Make sure your code lints.
- After your pull request is merged, you can safely delete your branch and pull the changes from the main (upstream) repository.
Sundeep, fill this!