vis.js is a dynamic, browser-based visualization library
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

67 lines
4.6 KiB

  1. # HowTo Help
  2. The company that developed vis.js for the main part, *almende* is [not able to maintain the project at the moment](./we_need_help.md). So help from the community is very needed and welcome!
  3. ## There are many ways to help:
  4. ### Answering questions
  5. There are new [issues with questions](//github.com/almende/vis/issues?q=is%3Aissue+is%3Aopen+label%3Aquestion+sort%3Acreated-desc) how to use vis.js opened almost every day. Be part of the community and help answer them!
  6. A better way to ask questions on how to use vis.js is [stackoverflow](https://stackoverflow.com/tags/vis.js). Questions are posed here also and need to be answered by the community. [Please help answering questions](https://stackoverflow.com/tags/vis.js) here also.
  7. ### Closing old issues
  8. A new issue is often opened fast and then forgotten. Please help go trough [the old issues](//github.com/almende/vis/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc) (especially the [questions](//github.com/almende/vis/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc+label%3Aquestion)) and ask the creator of the issues if the problem still exists before closing the issue. The support team uses the **issue inactive** label to mark these issues.
  9. ### Improve the webpage
  10. The visjs.org webpage is hosted on the [gh-pages branch](//github.com/almende/vis/tree/gh-pages). If you find a typo or anything else that should be improved feel free to create a pull-request to *gh-pages*. Please make changes in your own fork of gh-pages so the support team can view the changes in your hosted fork.
  11. ### Create new examples
  12. We have [a collection of examples](//github.com/almende/vis/tree/develop/examples). Please help by creating interesting new ones that show a specific problem or layout. Keep the examples easy to understand for beginners and remove unnecessary clutter.
  13. ### Provide interesting showcases
  14. If you use vis.js to develop something beautiful feel free to create a pull-request to our show cases page in the gh-pages branch](//github.com/almende/vis/tree/gh-pages/showcase). [These showcases are displayed on our webpage](http://visjs.org/showcase/index.html) and we are always looking for new examples.
  15. ### Confirming and fixing bugs
  16. Every software has bugs. We also have [quite a nice collection](https://github.com/almende/vis/issues?q=is%3Aissue+is%3Aopen+label%3Abug+sort%3Areactions-%2B1-desc) ;-)
  17. Feel free to fix as many bugs as you want!
  18. You can not only help by fixing bugs, but also by confirming the bug or even creating a minimal code example to prove this bug exists.
  19. ### Implementing Feature-Requests
  20. A lot of people have a lot of ideas for improving vis.js. [We label these issues as **enhancement**](https://github.com/almende/vis/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc+label%3Aenhancement). Feel free to implement a new feature by creating a new Pull-Request.
  21. [Some issues are labeled **For everybody!**](//github.com/almende/vis/issues?q=is%3Aissue+is%3Aopen+label%3A%22For+everyone%21%22+sort%3Areactions-%2B1-desc). These are a good starting point.
  22. ### Reviewing Pull-Requests
  23. We use [GitHub's two-step review](//help.github.com/articles/about-pull-request-reviews/) to make sure pull-requests are clean. You can help by checking out pull-request branches and testing them. You also can comment on lines of code and make sure the pull-request introduces no new bugs or typos.
  24. ## Creating Pull Requests
  25. There are some rules for pull-request:
  26. * All pull-request must be to the [develop-branch](//github.com/almende/vis/tree/develop). Pull-request against the [master-branch](//github.com/almende/vis/tree/master) must be closed. (Changes to [gh-pages](//github.com/almende/vis/tree/gh-pages) are also ok.)
  27. * Only commit changes done in the source files in the folder `lib`, not to the builds
  28. which are located in the folder `dist`.
  29. * Keep your changes small and clear. Only work on one topic at one time and only change lines of code that you have to change to reach your goal.
  30. * Test your changes before creating a pull-request. The easiest way is to open the existing examples and playing with them.
  31. * If you are fixing or implementing an existing issue, please refer to it in the description and in the commit message.
  32. * If you are introducing a new feature, add some documentation and a new example to make it easy to adapt.
  33. * If you introduce breaking changes, like changing the signature of a public function, point that out in your description. Breaking changes result in a new major release.
  34. * Always adapt to the code style of the existing source. Never adapt existing code to your personal taste. :trollface:
  35. **Happy Helping!!**