1 | Contributing to Leaflet.MarkerCluster
|
2 | =====================================
|
3 |
|
4 | 1. [Reporting Bugs](#reporting-bugs)
|
5 | 2. [Contributing Code](#contributing-code)
|
6 | 3. [Building](#building)
|
7 | 4. [Testing](#testing)
|
8 |
|
9 | ## Reporting Bugs
|
10 |
|
11 | Before reporting a bug on the project's [issues page](https://github.com/Leaflet/Leaflet.markercluster/issues),
|
12 | first make sure that your issue is caused by Leaflet.MarkerCluster, not your application code
|
13 | (e.g. passing incorrect arguments to methods, etc.).
|
14 | Second, search the already reported issues for similar cases,
|
15 | and if it's already reported, just add any additional details in the comments.
|
16 |
|
17 | After you've made sure that you've found a new Leaflet.markercluster bug,
|
18 | here are some tips for creating a helpful report that will make fixing it much easier and quicker:
|
19 |
|
20 | * Write a **descriptive, specific title**. Bad: *Problem with polylines*. Good: *Doing X in IE9 causes Z*.
|
21 | * Include **browser, OS and Leaflet version** info in the description.
|
22 | * Create a **simple test case** that demonstrates the bug (e.g. using [JSFiddle](http://jsfiddle.net/) or [JS Bin](http://jsbin.com/)).
|
23 | * Check whether the bug can be reproduced in **other browsers**.
|
24 | * Check if the bug occurs in the stable version, master, or both.
|
25 | * *Bonus tip:* if the bug only appears in the master version but the stable version is fine,
|
26 | use `git bisect` to find the exact commit that introduced the bug.
|
27 |
|
28 | If you just want some help with your project,
|
29 | try asking [on the Leaflet forum](https://groups.google.com/forum/#!forum/leaflet-js) instead.
|
30 |
|
31 | ## Contributing Code
|
32 |
|
33 | ### Considerations for Accepting Patches
|
34 |
|
35 | While we happily accept patches, we're also committed to keeping Leaflet simple, lightweight and blazingly fast.
|
36 | So bugfixes, performance optimizations and small improvements that don't add a lot of code
|
37 | are much more likely to get accepted quickly.
|
38 |
|
39 | Before sending a pull request with a new feature, check if it's been discussed before already
|
40 | (either on [GitHub issues](https://github.com/Leaflet/Leaflet/issues)
|
41 | or [Leaflet UserVoice](http://leaflet.uservoice.com/)),
|
42 | and ask yourself two questions:
|
43 |
|
44 | 1. Are you sure that this new feature is important enough to justify its presence in the Leaflet core?
|
45 | Or will it look better as a plugin in a separate repository?
|
46 | 2. Is it written in a simple, concise way that doesn't add bulk to the codebase?
|
47 |
|
48 | If your feature or API improvement did get merged into master,
|
49 | please consider submitting another pull request with the corresponding [documentation update](#improving-documentation).
|
50 |
|
51 | ## Building
|
52 |
|
53 | Install the dependencies:
|
54 | ```
|
55 | npm install -g jake
|
56 | npm install
|
57 | ```
|
58 |
|
59 | Then to build:
|
60 | ```
|
61 | jake
|
62 | ```
|
63 | Output will be in the ```dist/``` directory
|
64 |
|
65 | ## Testing
|
66 |
|
67 | To run unit tests:
|
68 | ```
|
69 | jake test
|
70 | ```
|
71 |
|
\ | No newline at end of file |