|
2 | 2 |
|
3 | 3 | Contributions are **welcome** and will be fully **credited**. |
4 | 4 |
|
5 | | -Please read and understand the contribution guide before creating an issue or pull request. |
| 5 | +Before creating an issue or pull request, please take a moment to read and understand this contribution guide. |
| 6 | + |
| 7 | +--- |
6 | 8 |
|
7 | 9 | ## Etiquette |
8 | 10 |
|
9 | | -This project is open source, and as such, the maintainers give their free time to build and maintain the |
10 | | -source code held within. They make the code freely available in the hope that it will be of use to other |
11 | | -developers. It would be extremely unfair for them to suffer abuse or anger for their hard work. |
| 11 | +This project is open source, and the maintainers volunteer their time to build and maintain it. They provide the source code freely with the hope that it will be useful to others. Please be respectful and considerate when raising issues or submitting pull requests. |
| 12 | + |
| 13 | +- **Be respectful**: Avoid abusive, angry, or impatient behavior toward maintainers or contributors. |
| 14 | +- **Stay constructive**: Provide detailed, actionable feedback and clearly describe issues or suggestions. |
| 15 | +- **Understand maintainers' decisions**: Contributions are accepted at the discretion of the maintainers. Respect their decision, even if your submission is not used. |
12 | 16 |
|
13 | | -Please be considerate towards maintainers when raising issues or presenting pull requests. |
14 | | -Let's show the world that developers are civilized and selfless people. |
| 17 | +Let’s show the world that developers are civilized, collaborative, and selfless! |
15 | 18 |
|
16 | | -It's the duty of the maintainer to ensure that all submissions to the project are of sufficient |
17 | | -quality to benefit the project. Many developers have different skill sets, strengths, and weaknesses. |
18 | | -Respect the maintainer's decision, and do not be upset or abusive if your submission is not used. |
| 19 | +--- |
19 | 20 |
|
20 | 21 | ## Viability |
21 | 22 |
|
22 | | -When requesting or submitting new features, first consider whether it might be useful to others. |
23 | | -Open source projects are used by many developers, who may have entirely different needs to your own. |
24 | | -Think about whether your feature is likely to be used by other users of the project. |
| 23 | +Before suggesting new features or changes, consider their viability: |
| 24 | +- Will the feature benefit other users of the project? |
| 25 | +- Is the feature aligned with the project's scope and goals? |
| 26 | +- Could the feature introduce unnecessary complexity or maintenance challenges? |
| 27 | + |
| 28 | +Open source projects serve a diverse group of developers with varied needs, so your contributions should aim to add value to the broader community. |
| 29 | + |
| 30 | +--- |
25 | 31 |
|
26 | | -## Procedure |
| 32 | +## Reporting Issues |
27 | 33 |
|
28 | 34 | Before filing an issue: |
| 35 | +1. **Attempt to replicate the problem** to rule out one-off incidents. |
| 36 | +2. **Search existing issues** to ensure your problem or suggestion hasn’t already been raised. |
| 37 | +3. **Check pull requests** for ongoing work that may address the issue. |
29 | 38 |
|
30 | | -- Attempt to replicate the problem, to ensure that it wasn't a coincidental incident. |
31 | | -- Check to make sure your feature suggestion isn't already present within the project. |
32 | | -- Check the pull requests tab to ensure that the bug doesn't have a fix in progress. |
33 | | -- Check the pull requests tab to ensure that the feature isn't already in progress. |
| 39 | +--- |
34 | 40 |
|
35 | | -Before submitting a pull request: |
| 41 | +## Submitting Pull Requests |
36 | 42 |
|
37 | | -- Check the codebase to ensure that your feature doesn't already exist. |
38 | | -- Check the pull requests to ensure that another person hasn't already submitted the feature or fix. |
| 43 | +When submitting a pull request: |
| 44 | +1. **Ensure the feature doesn’t already exist** in the codebase. |
| 45 | +2. **Review existing pull requests** to ensure no one else is working on the same feature or fix. |
| 46 | +3. Follow these best practices: |
| 47 | + - **One pull request per feature**: If you want to contribute multiple changes, submit separate pull requests for each. |
| 48 | + - **Provide a coherent commit history**: Squash intermediate commits into meaningful ones. |
| 49 | + - **Document your changes**: Update the `README.md` or other relevant documentation to reflect your changes. |
| 50 | + - **Adhere to coding standards**: Use the PSR-12 coding standard. |
| 51 | + |
| 52 | +--- |
39 | 53 |
|
40 | 54 | ## Requirements |
41 | 55 |
|
42 | | -If the project maintainer has any additional requirements, you will find them listed here. |
| 56 | +This project follows specific standards and guidelines to ensure consistency and maintainability: |
| 57 | + |
| 58 | +1. **Coding Standard** |
| 59 | + - Follow **[PSR-12](https://www.php-fig.org/psr/psr-12/)**. |
| 60 | + - Use tools like [PHP Code Sniffer](http://pear.php.net/package/PHP_CodeSniffer) to check your code. |
| 61 | + |
| 62 | +2. **Semantic Versioning** |
| 63 | + - This project adheres to **[SemVer v2.0.0](http://semver.org/)**. |
| 64 | + - Avoid making random or unnecessary breaking changes to public APIs. |
| 65 | + |
| 66 | +3. **Documentation** |
| 67 | + - Document any changes in functionality. |
| 68 | + - Update all relevant files, including `README.md` and other documentation, as needed. |
43 | 69 |
|
44 | | -- **[PSR-12 Coding Standard](https://www.php-fig.org/psr/psr-12/)** - The easiest way to apply the conventions is to install [PHP Code Sniffer](http://pear.php.net/package/PHP_CodeSniffer). |
| 70 | +--- |
45 | 71 |
|
46 | | -- **Document any change in behaviour** - Make sure the `README.md` and any other relevant documentation are kept up-to-date. |
| 72 | +## Contribution Workflow |
47 | 73 |
|
48 | | -- **Consider our release cycle** - We try to follow [SemVer v2.0.0](http://semver.org/). Randomly breaking public APIs is not an option. |
| 74 | +To contribute effectively: |
| 75 | +1. Fork the repository and create a new branch for your work. |
| 76 | +2. Ensure your branch is up-to-date with the `main` branch. |
| 77 | +3. Implement your feature or fix, ensuring compliance with the guidelines. |
| 78 | +4. Run tests and ensure no existing functionality is broken. |
| 79 | +5. Create a pull request with a clear description of the changes and why they are necessary. |
49 | 80 |
|
50 | | -- **One pull request per feature** - If you want to do more than one thing, send multiple pull requests. |
| 81 | +--- |
51 | 82 |
|
52 | | -- **Send coherent history** - Make sure each individual commit in your pull request is meaningful. If you had to make multiple intermediate commits while developing, please [squash them](http://www.git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages) before submitting. |
| 83 | +**Thank you for contributing!** Your effort and time are greatly appreciated. Let’s build something amazing together. |
53 | 84 |
|
54 | 85 | **Happy coding**! |
0 commit comments