contributing.rst 4.6KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118
  1. Contributor guide
  2. =================
  3. This project is open source, and is built on a voluntary basis by developers like you. You can help to improve it by contributing code & documentation to the repository, or by interacting with other developers and users on the issue tracker.
  4. Where to ask a question
  5. ^^^^^^^^^^^^^^^^^^^^^^^
  6. If you need to seek clarification, then you are welcome to post questions about the library to the `gfx-php issue tracker`_. They will be tagged ``question``, and closed once there is an answer.
  7. If your question is incomplete or not specific to this project, then it will be tagged ``invalid`` and closed with a short explanation. We do this to keep the issue tracker focussed, on-topic and actionable by project contributors.
  8. The StackOverflow help page `How do I ask a good question?`_ contains advice about writing complete questions.
  9. .. _`How do I ask a good question?`: https://stackoverflow.com/help/how-to-ask
  10. How to report a bug
  11. ^^^^^^^^^^^^^^^^^^^
  12. We track bugs as GitHub issues. If something does not work as documented, then you are welcome to make a bug report on the `gfx-php issue tracker`_
  13. When posting a bug:
  14. - Check for open issues first. If the same issue has already been reported, then you should post any additional information to the existing thread.
  15. - Describe what you are trying to do, and how the actual behaviour of the library differs from what you expected.
  16. - Include a self-contained code snippet that demonstrates the issue, as PHP code formatted in a `code block`_
  17. - Try to use images from the repository to demonstrate the problem. If you need to use a specific example image, then attach it to the issue in a ``.zip`` file.
  18. Bug reports will stay open as long as they are actionable. Generally, this means that they can be replicated on the current stable release, and there is some expectation that the issue is solvable.
  19. The title and tags on your bug may be edited so that it can be distinguished from other bugs.
  20. .. _`code block`: https://help.github.com/articles/creating-and-highlighting-code-blocks/
  21. .. _`gfx-php issue tracker`: https://github.com/mike42/gfx-php/issues
  22. Feature requests
  23. ^^^^^^^^^^^^^^^^
  24. You can also make suggestions for new features on the `gfx-php issue tracker`_. These are tagged ``enhancement``.
  25. Please keep the scope and resources of the project in mind when making suggestions.
  26. Development process
  27. ^^^^^^^^^^^^^^^^^^^
  28. The project is hosted online on the services below:
  29. :Code:
  30. https://github.com/mike42/gfx-php
  31. :Continuous integration:
  32. https://travis-ci.org/mike42/gfx-php
  33. :Code coverage reporting:
  34. https://coveralls.io/github/mike42/gfx-php
  35. :Documentation:
  36. https://gfx-php.readthedocs.io/
  37. :Package manager:
  38. https://packagist.org/packages/mike42/gfx-php
  39. For a change to be accepted, it will first need to meet some basic technical criteria, such as passing existing unit tests, a style check, and not breaking any of the examples.
  40. Secondly, it will need to pass a human review, to confirm that it improves the overall product. You are encouraged to submit changes which address one open issue, so that this review can be as constructive as possible.
  41. Commands to use locally
  42. -----------------------
  43. To make code changes, fork the repository on GitHub, and set up
  44. your local copy with composer.
  45. .. code-block:: bash
  46. composer install
  47. To run unit tests, execute:
  48. .. code-block:: bash
  49. php vendor/bin/phpunit --coverage-text
  50. To test all examples:
  51. .. code-block:: bash
  52. mkdir -p tmp && (cd tmp && find ../example -name '*.php' -print0 | xargs -n 1 -0 sh -c 'echo $0; php $0 || exit 255')
  53. To run a style check and fix formatting issues:
  54. .. code-block:: bash
  55. php vendor/bin/phpcs --standard=psr2 src/ -n
  56. php vendor/bin/phpcbf --standard=psr2 src/ -n
  57. Submitting changes
  58. ------------------
  59. Changes should be submitted as a GitHub pull request to the ``master`` branch.
  60. Licensing considerations
  61. ------------------------
  62. You are not required to assign copyright for contributions to this project, but
  63. you do need ensure that your changes are suitable for release under the project's
  64. `copyleft` license.
  65. If you hold the copyright to the submitted code, then indicate this in your pull request.
  66. If you are thinking of including code which you do not hold the copyright to,
  67. please post relevant details to the issue tracker first. Only works which are
  68. licensed under an LGPL-2.1-compatible license may be combined with `gfx-php` code.
  69. Release process
  70. ---------------
  71. Git tags are automatically reflected as releases in packagist.
  72. Release numbers approximately follow semantic versioning, and do not follow a particular schedule.
  73. Updates are not typically made to old releases.