socialde.pt
Parse and validate AT Protocol Lexicons with DTO generation for Laravel
1# Contributing
2
3Contributions are **welcome** and will be fully **credited**.
4
5## Etiquette
6
7This project is open source, and as such, the maintainers give their free time to build and maintain the source code held within. They make the code freely available in the hope that it will be of use to other developers. It would be extremely unfair for them to suffer abuse or anger for their hard work.
8
9Please be considerate towards maintainers when raising issues or presenting pull requests. Let's show the world that developers are civilized and selfless people.
10
11It's the duty of the maintainer to ensure that all submissions to the project are of sufficient quality to benefit the project. Many developers have different skillsets, strengths, and weaknesses. Respect the maintainer's decision, and do not be upset or abusive if your submission is not used.
12
13## Viability
14
15When requesting or submitting new features, first consider whether it might be useful to others. Open source projects are used by many developers, who may have entirely different needs to your own. Think about whether or not your feature is likely to be used by other users of the project.
16
17## Procedure
18
19### Before Filing an Issue
20
21- Search existing issues to avoid duplicates
22- Check the [documentation](README.md) to ensure it's not a usage question
23- Provide a clear title and description
24- Include steps to reproduce the issue
25- Specify your environment (PHP version, Laravel version, Schema version)
26- Include relevant code samples and full error messages
27
28### Before Submitting a Pull Request
29
30- **Discuss non-trivial changes first** by opening an issue
31- **Fork the repository** and create a feature branch from `main`
32- **Follow all requirements** listed below
33- **Write tests** for your changes
34- **Update documentation** if behavior changes
35- **Run code style checks** with `vendor/bin/php-cs-fixer fix`
36- **Ensure all tests pass** with `vendor/bin/phpunit`
37- **Write clear commit messages** that explain what and why
38
39## Requirements
40
41- **[PSR-12 Coding Standard](https://www.php-fig.org/psr/psr-12/)** - Run `vendor/bin/php-cs-fixer fix` to automatically fix code style issues.
42
43- **Add tests** - Your patch won't be accepted if it doesn't have tests. All tests must use [PHPUnit](https://phpunit.de/) with [Pest](https://pestphp.com/).
44
45- **Document any change in behaviour** - Make sure the `README.md` and any other relevant documentation are kept up-to-date.
46
47- **Consider our release cycle** - We follow [SemVer v2.0.0](https://semver.org/). Randomly breaking public APIs is not an option.
48
49- **One pull request per feature** - If you want to do more than one thing, send multiple pull requests.
50
51- **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](https://www.git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages) before submitting.
52
53## Running Tests
54
55```bash
56vendor/bin/phpunit
57```
58
59Run specific test suites:
60
61```bash
62# Unit tests only
63vendor/bin/phpunit --testsuite=unit
64
65# Integration tests only
66vendor/bin/phpunit --testsuite=integration
67```
68
69## Code Style
70
71Schema follows PSR-12 coding standard. Run PHP CS Fixer before submitting:
72
73```bash
74vendor/bin/php-cs-fixer fix
75```
76
77**Happy coding**!