|
| 1 | +> ### Notice |
| 2 | +> *Before you continue, this is the* **ANDROID** *library. If you have an* **iOS** *device, please go here instead*: |
| 3 | +> |
| 4 | +> – https://github.com/danielgindi/Charts |
| 5 | +> |
| 6 | +> They might tell you to come back here, if they do, listen to them and ignore this notice. |
| 7 | +
|
1 | 8 | # How to contribute |
2 | 9 |
|
3 | | -Bug-fixes and features often come from users of the MPAndroidChart library and improve it greatly. We want to keep it as easy as possible to contribute changes that improve the experience for users all around the world. There are a few guidelines that we |
4 | | -need contributors to follow so that we can have a chance of keeping on |
5 | | -top of things. |
| 10 | +Bug-fixes and features often come from users of the MPAndroidChart library and improve it greatly. We want to keep it as easy as possible to contribute changes that improve the experience for users all around the world. There are a few guidelines that we need contributors to follow so that we can have a chance of keeping on top of things. |
| 11 | + |
| 12 | +## Creating Issues |
| 13 | + |
| 14 | +There are two main issue templates, one for bugs and another for feature requests. Please use them! You're issue will be much easier to understand, and bugs easier to fix, if you follow the templates. If your issue doesn't fit into those, just use the generic template. |
6 | 15 |
|
7 | | -## Simple issues and bug reports |
| 16 | +Search existing [issues] to see if your bug has already been reported or if a feature request already exists. Don't forget to remove `is:open` so you see all the issues! If you find that one already exists, use reactions to show how much you care! |
8 | 17 |
|
9 | | -If you are reporting a bug which can be observed visually, please add to your issue either: |
| 18 | +## Making Pull Requests |
10 | 19 |
|
11 | | -* Screenshots, if the bug is easily explainable |
12 | | -* A working sample project that we can compile, run, and immediately observe the issue |
| 20 | +Careful! If you fail to follow these guidlines, you're pull request may be closed, *even if it's really awesome*. |
13 | 21 |
|
14 | | -## Getting Started with Contributions |
| 22 | + 0. **Search** open [pull requests] AND existing [issues] to make sure what you want to do isn't already being worked on or already has an open pull request. |
| 23 | + 1. **Fork** the repository |
| 24 | + 1. **Create** a new branch based on `master`, and name it according to your changes |
| 25 | + 1. **Add** your commits, they MUST follow the [Commit Style](#commit-style) below |
| 26 | + 1. **Test** your changes by actually running the example app, or create a new example |
| 27 | + 1. **Create** a pull request, following the auto-generated template |
| 28 | + 1. ??? |
| 29 | + 1. Profit :money_with_wings: |
| 30 | + |
| 31 | +You are encouraged to use [GitHub Desktop] to inspect your code changes before committing them. It can reveal small changes that might have gone unnoticed, and would be requested for removal before merging. |
15 | 32 |
|
16 | | -* Make sure you have a [GitHub account](https://github.com/signup/free) |
17 | | -* Submit a ticket for your issue, assuming one does not already exist. |
18 | | - * Clearly describe the issue including steps to reproduce when it is a bug. |
19 | | - * Make sure you fill in the earliest version (or commit number) that you know has the issue. |
20 | | -* Fork the repository on GitHub |
| 33 | +Check out [#3975](https://github.com/PhilJay/MPAndroidChart/pull/3975) for an example of a good-made-better pull request. |
21 | 34 |
|
22 | | -## Making Changes |
| 35 | +## Commit Style |
23 | 36 |
|
24 | | -* Create a topic branch from where you want to base your work. This is usually the master branch. |
25 | | -* Make commits of logical units. |
26 | | -* Make sure your code conforms to the code style around it. It's easy, just look around! |
27 | | -* If you have made changes back and forth, or have made merges, your commit history might look messy and hard to understand. A single issue or change should still be in one commit. So please squash those commits together and rebase them however you need to - to make our lives easier when reading it later. |
28 | | -* Check for unnecessary whitespace with `git diff --check` before committing. |
29 | | -* Make sure your commit messages are in the proper format. |
| 37 | + * **Make commits of logical units** |
| 38 | + Don't load your commits with tons of changes, this makes it hard to follow what is happening. However, if you have done a lot of work, and there are commits and merges all over the place, squash them down into fewer commits. |
| 39 | + |
| 40 | + * **Conform to the code style** |
| 41 | + It's easy, just look around! |
| 42 | + |
| 43 | + * **Write good commit messages** |
| 44 | + You may prefer [Tim Pope's style], you might like the [commitizen-friendly] way. Regardless of the color you pick, you MUST stay within the lines! |
| 45 | + ``` |
| 46 | +The commit title CANNOT exceed 50 characters |
30 | 47 |
|
31 | | -```` |
32 | | - First line must be up to 50 chars (Fixes #1234) |
| 48 | +The body of the message comes after an empty new line, and describes the |
| 49 | +changes more thoroughly. If the change is obvious and self-explanatory |
| 50 | +from the title, you can omit the body. You should describe all changes |
| 51 | +if many were made, or maybe some trickery that only code wizards can |
| 52 | +understand. |
33 | 53 |
|
34 | | - The first line should be a short statement as to what have changed, and should also include an issue number, prefixed with a dash. |
35 | | - The body of the message comes after an empty new line, and describes the changes |
36 | | - more thoroughly, especially if there was a special case handled there, |
37 | | - or maybe some trickery that only code wizards can understand. |
38 | | -```` |
| 54 | +Be polite and wrap your lines to 72 characters, but if you prefer going |
| 55 | +to 100 characters then I guess we can't stop you. |
| 56 | +``` |
39 | 57 |
|
40 | | -* Make sure you have tested your changes well. |
41 | | -* If your changes could theoretically affect some other component or case, which you do not necessarily use, you still have to test it. |
42 | | -* Create a Pull Request from your topic branch to the relevant branch in the main repo. If you go to the main repo of the framework, you'll see a big green button which pretty much prepares the PR for you. You just have to hit it. |
| 58 | +## Final Notes |
43 | 59 |
|
44 | | -## Making Trivial Changes |
| 60 | +Thanks for reading the contributing file! Have some cake! :cake: |
45 | 61 |
|
46 | | -For changes of a trivial nature to comments and documentation, it is not |
47 | | -always necessary to create a new ticket. In this case, it is |
48 | | -appropriate to start the first line of a commit with '(doc)' instead of |
49 | | -a ticket number. Even the default commit message the GitHub generates is fine with us. |
| 62 | +[issues]: https://github.com/PhilJay/MPAndroidChart/issues |
| 63 | +[pull requests]: https://github.com/PhilJay/MPAndroidChart/pulls |
| 64 | +[GitHub Desktop]: https://desktop.github.com/ |
| 65 | +[Tim Pope's style]: https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html |
| 66 | +[commitizen-friendly]: https://github.com/commitizen/cz-cli |
0 commit comments