1Contributing
2============
3
4Issue tracker
5-------------
6
7The Issue tracker serves mainly as a place to report bugs and request new features.
8Please do not abuse it as a general questions or troubleshooting location.
9
10General troubleshooting
11-------------
12
13For these questions please use [Discussions](https://github.com/mpdf/mpdf/discussions). Add your enquiry
14to appropriate category and as always, include a reproducible code example when applicable (see code example guidelines below).
15
16You can also use the [mpdf tag](https://stackoverflow.com/questions/tagged/mpdf)
17at [Stack Overflow](https://stackoverflow.com/)
18as the StackOverflow user base is more likely to answer you in a timely manner.
19When doing so, make sure you comply to StackOverflow question guidelines.
20
21Bug reports
22-------------
23
24* Bug reports **MUST** contain a small example in php/html that reproduces the bug.
25* The code example **MUST** be reproducible by copy&paste assuming composer dependencies are installed. That means:
26    * No calling unrelated funcions,
27    * an actual final HTML code has to be present, pasting a template file is not enough,
28    * if the bug considers import or fonts, example source PDF/TTF/etc files have to be included.
29* Failing to provide necessary information or not using the issue template will cause the issue to be closed until required information is provided.
30* Please report one feature or one bug per issue.
31
32Feature requests
33-------------
34
35Feature requests have to be labeled as such and have to include reasoning for the change in question.
36
37
38Pull requests
39-------------
40
41Pull requests should be always based on the default [development](https://github.com/mpdf/mpdf/tree/development)
42branch except for backports to older versions.
43
44Guidelines:
45
46* Use an aptly named feature branch for the Pull request.
47* Only files and lines affecting the scope of the Pull request must be affected.
48* Make small, *atomic* commits that keep the smallest possible related code changes together.
49* Code must be accompanied by a unit test testing expected behaviour whenever possible.
50* To be incorporated, the PR should contain a change in the CHANGELOG.md file describing itself
51
52When updating a PR, do not create a new one, just `git push --force` to your former feature branch, the PR will
53update itself.
54