phplrt 4.0

Contribution Guide

Bug Reports

To encourage active collaboration, we strongly encourages pull requests, not just bug reports. "Bug reports" may also be sent in the form of a pull request containing a failing test.

However, if you file a bug report, your issue should contain a title and a clear description of the issue. You should also include as much relevant information as possible and a code sample that demonstrates the issue. The goal of a bug report is to make it easy for yourself - and others - to replicate the bug and develop a fix.

Remember, bug reports are created in the hope that others with the same problem will be able to collaborate with you on solving it. Do not expect that the bug report will automatically see any activity or that others will jump to fix it. Creating a bug report serves to help yourself and others start on the path of fixing the problem.

Security Vulnerabilities

If you discover a security vulnerability within phplrt, please send an email to Nesmeyanov Kirill at nesk@xakep.ru. All security vulnerabilities will be promptly addressed.

Coding Style

phplrt follows the PER Coding Style 3.0 and the PSR-4 autoloading standard. The rules are enforced by php-cs-fixer, so you do not have to apply them by hand:

composer phpcs:check   # check the code style
composer phpcs:fix     # fix what can be fixed

The rest of the toolchain, all runnable from the repository root:

composer test:unit     # run the test suite
composer linter:check  # static analysis

New behaviour needs a test; a bug fix needs a test that fails without it.

Code of Conduct

The phplrt code of conduct is derived from the Ruby code of conduct. Any violations of the code of conduct may be reported to Nesmeyanov Kirill at nesk@xakep.ru:

  • Participants will be tolerant of opposing views.
  • Participants must ensure that their language and actions are free of personal attacks and disparaging personal remarks.
  • When interpreting the words and actions of others, participants should always assume good intentions.
  • Behavior which can be reasonably considered harassment will not be tolerated.

LLM Usage Policy

To maintain code quality, readability, and complete comprehension in production, the following LLM usage rules apply:

  • Production code must be hand-written. LLMs should not be used to write production code. Code generated by LLMs is not accepted.
  • LLM-generated comments are allowed. However, comments describing contracts (classes, methods, interfaces, etc.) must answer the question "WHAT is this?", not "HOW does it work?". Comments should describe the purpose, responsibility, or contract of the code, not its implementation details.
  • LLM-generated tests are allowed. Each AI-generated test must treat the code under test as a "black box". Tests may rely on the public contract and observable behavior, but must not depend on or make assumptions about the internal implementation.