Vous ne pouvez pas sélectionner plus de 25 sujets Les noms de sujets doivent commencer par une lettre ou un nombre, peuvent contenir des tirets ('-') et peuvent comporter jusqu'à 35 caractères.

CONTRIBUTING.md 8.5KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185
  1. Contributing to Leaflet
  2. =======================
  3. 1. [Getting Involved](#getting-involved)
  4. 2. [Reporting Bugs](#reporting-bugs)
  5. 3. [Contributing Code](#contributing-code)
  6. 4. [Improving Documentation](#improving-documentation)
  7. 5. [Code of Conduct](#code-of-conduct)
  8. ## Getting Involved
  9. Third-party patches are absolutely essential on our quest to create the best mapping library that will ever exist.
  10. However, they're not the only way to get involved with Leaflet development.
  11. You can help the project tremendously by discovering and [reporting bugs](#reporting-bugs);
  12. [improving documentation](#improving-documentation);
  13. helping others on [Stack Overflow](https://stackoverflow.com/questions/tagged/leaflet),
  14. [GIS Stack Exchange](https://gis.stackexchange.com/questions/tagged/leaflet)
  15. and [GitHub issues](https://github.com/Leaflet/Leaflet/issues);
  16. showing your support for your favorite feature suggestions on [Leaflet UserVoice page](http://leaflet.uservoice.com);
  17. tweeting to [@LeafletJS](http://twitter.com/LeafletJS);
  18. and spreading the word about Leaflet among your colleagues and friends.
  19. ## Reporting Bugs
  20. Before reporting a bug on the project's [issues page](https://github.com/Leaflet/Leaflet/issues),
  21. first make sure that your issue is caused by Leaflet, not your application code
  22. (e.g. passing incorrect arguments to methods, etc.).
  23. Second, search the already reported issues for similar cases,
  24. and if it's already reported, just add any additional details in the comments.
  25. After you've made sure that you've found a new Leaflet bug,
  26. here are some tips for creating a helpful report that will make fixing it much easier and quicker:
  27. * Write a **descriptive, specific title**. Bad: *Problem with polylines*. Good: *Doing X in IE9 causes Z*.
  28. * Include **browser, OS and Leaflet version** info in the description.
  29. * Create a **simple test case** that demonstrates the bug (e.g. using [Leaflet playground](http://playground-leaflet.rhcloud.com/)).
  30. * Check whether the bug can be reproduced in **other browsers**.
  31. * Check if the bug occurs in the stable version, master, or both.
  32. * *Bonus tip:* if the bug only appears in the master version but the stable version is fine,
  33. use `git bisect` to find the exact commit that introduced the bug.
  34. If you just want some help with your project,
  35. try asking on [Stack Overflow](https://stackoverflow.com/questions/tagged/leaflet)
  36. or [GIS Stack Exchange](https://gis.stackexchange.com/questions/tagged/leaflet) instead.
  37. ## Contributing Code
  38. ### Considerations for Accepting Patches
  39. While we happily accept patches, we're also committed to keeping Leaflet simple, lightweight and blazingly fast.
  40. So bugfixes, performance optimizations and small improvements that don't add a lot of code
  41. are much more likely to get accepted quickly.
  42. Before sending a pull request with a new feature, check if it's been discussed before already
  43. (either on [GitHub issues](https://github.com/Leaflet/Leaflet/issues)
  44. or [Leaflet UserVoice](http://leaflet.uservoice.com/)),
  45. and ask yourself two questions:
  46. 1. Are you sure that this new feature is important enough to justify its presence in the Leaflet core?
  47. Or will it look better as a plugin in a separate repository?
  48. 2. Is it written in a simple, concise way that doesn't add bulk to the codebase?
  49. If your feature or API improvement did get merged into master,
  50. please consider submitting another pull request with the corresponding [documentation update](#improving-documentation).
  51. ### Setting up the Build System
  52. The Leaflet build system uses [Node](http://nodejs.org/), and the [Jake](http://jakejs.com/) Javascript build tool.
  53. To set up the Leaflet build system, install Node then run the following commands in the project root to install Jake:
  54. ```
  55. npm install -g jake
  56. npm install
  57. ```
  58. You can build minified Leaflet by running `jake` (it will be built from source in the `dist` folder).
  59. For a custom build with selected components, open `build/build.html` in the browser and follow the instructions from there.
  60. ### Making Changes to Leaflet Source
  61. If you're not yet familiar with the way GitHub works (forking, pull requests, etc.),
  62. be sure to check out the awesome [article about forking](https://help.github.com/articles/fork-a-repo)
  63. on the GitHub Help website — it will get you started quickly.
  64. You should always write each batch of changes (feature, bugfix, etc.) in **its own topic branch**.
  65. Please do not commit to the `master` branch, or your unrelated changes will go into the same pull request.
  66. You should also follow the code style and whitespace conventions of the original codebase.
  67. In particular, use tabs for indentation and spaces for alignment.
  68. Before committing your changes, run `jake lint` to catch any JS errors in the code and fix them.
  69. If you add any new files to the Leaflet source, make sure to also add them to `build/deps.js`
  70. so that the build system knows about them.
  71. Also, please make sure that you have [line endings configured properly](https://help.github.com/articles/dealing-with-line-endings) in Git! Otherwise the diff will show that all lines of a file were changed even if you touched only one.
  72. Happy coding!
  73. ## Running the Tests
  74. To run the tests from the command line,
  75. install [PhantomJS](http://phantomjs.org/) (and make sure it's in your `PATH`),
  76. then run:
  77. ```
  78. jake test
  79. ```
  80. To run all the tests in actual browsers at the same time, you can do:
  81. ```
  82. jake test --ff --chrome --safari --ie
  83. ```
  84. To run the tests in a browser manually, open `spec/index.html`.
  85. ## Code Coverage
  86. To generate a detailed report about test coverage (which helps tremendously when working on test improvements), run:
  87. ```
  88. jake test --cov
  89. ```
  90. After that, open `coverage/<environment>/index.html` in a browser to see the report.
  91. From there you can click through folders/files to get details on their individual coverage.
  92. ## Improving Documentation
  93. The code of the live Leaflet website that contains all documentation and examples is located in the `docs/` directory of the `master` branch
  94. and is automatically generated from a set of HTML and Markdown files by [Jekyll](http://jekyllrb.com/).
  95. The easiest way to make little improvements such as fixing typos without even leaving the browser
  96. is by editing one of the files with the online GitHub editor:
  97. browse the [`docs/ directory`](https://github.com/Leaflet/Leaflet/tree/master/docs),
  98. choose a certain file for editing (e.g. `plugins.html` for the list of Leaflet plugins),
  99. click the Edit button, make changes and follow instructions from there.
  100. Once it gets merged, the changes will immediately appear on the website.
  101. If you need to make edits in a local repository to see how it looks in the process, do the following:
  102. 1. [Install Ruby](http://www.ruby-lang.org/en/) if don't have it yet.
  103. 2. Run `gem install jekyll`.
  104. 3. Enter the directory where you cloned the Leaflet repository
  105. 4. Make sure you are in the `master` branch by running `git checkout master`
  106. 5. Enter the documentation subdirectory by running `cd docs`
  107. 6. Run `jekyll serve --watch`.
  108. 7. Open `localhost:4000` in your web browser.
  109. Now any file changes will be updated when you reload pages automatically.
  110. After committing the changes, just send a pull request.
  111. ### API documentation
  112. Since Leaflet 1.0.0-rc1, the API documentation in `reference-1.0.0.html` is handled
  113. via [Leafdoc](https://github.com/Leaflet/Leafdoc). This means that next to the
  114. code for every method, option or property there is a special code comment documenting
  115. that feature. In order to edit the API documentation, just edit these comments in the
  116. source code.
  117. In order to generate the documentation, just run
  118. ```
  119. jake docs
  120. ```
  121. and you'll find a `.html` file in the `dist/` directory.
  122. On every release of a new Leaflet version, this file will be generated and copied
  123. over to `docs/reference.html` - there is no need to send pull requests with changes to this file to update the API documentation.
  124. ## Code of Conduct
  125. Everyone is invited to participate in the Leaflet community and related projects:
  126. we want to create a welcoming and friendly environment.
  127. Harassment of participants or other unethical and unprofessional behavior will not be tolerated in our spaces.
  128. The [Contributor Covenant](http://contributor-covenant.org/version/1/3/0/)
  129. applies to all projects under the Leaflet organization.
  130. Report any issues to agafonkin@gmail.com.
  131. ## Thank You
  132. Not only does your contribution to Leaflet and its community earn our gratitude, but it also makes you AWESOME.
  133. Join [this approved list of awesome people](https://github.com/Leaflet/Leaflet/graphs/contributors)
  134. and help us push the limits of what's possible with online maps!