Contributions via pull requests on GitHub are welcome and will be fully credited.
The ZAPHYR project is committed to maintaining a high standard of code quality and readability. To achieve this, the project strictly adheres to the PSR-12 coding style guideline. By following PSR-12, ZAPHYR ensures consistency and uniformity in its codebase, making it easier for developers to collaborate and maintain the project. The easiest way to apply the conventions is to install PHP Code Sniffer.
Document any change in behaviour. Make sure the README.md and any
other relevant documentation are kept up-to-date.
Consider the release cycle. ZAPHYR tries to follow SemVer v2.0.0. Randomly breaking public APIs is not an option.
One pull request per feature. If you want to do more than one thing, send multiple pull requests. 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 before submitting.
There are some rules for what a commit message should look like. Here is an example of a final commit message:
New: A super new feature
Most importantly, describe what is changed with the commit and not
what is has not been working (that is part of the bug report already).
* Bullet points are okay, too
* An asterisk is used for the bullet, it can be preceded by a single space.
A summary line starts with a keyword (e.g. New) and a brief summary of what the
change does. Make sure to describe how the behavior is now, not how it used to be - in the end,
telling someone what was broken doesn't help anyone,
you want to tell what is working now.
Prefix the line with a keyword. Possible keywords are:
| Keyword | Description |
|---|---|
| New | A new feature or element. Also small additions |
| Changed | A change (which is not a bugfix) to an existing component |
| Deprecated | A new deprecation of a feature or function |
| Removed | Removal of a feature or function |
| Fixed | A fix for a bug |
| Security | A security fix |
Here you can go into detail about the how and why of the change. It should be brief, but yet descriptive so people reviewing your change get an idea what they need to look out for.
If you discover any security-related issues within our repositories, we kindly request that you refrain from using the issue tracker on GitHub! Instead, we encourage you to immediately report such matters to security@zaphyr.org.
At ZAPHYR, we prioritize the safety and integrity of our software. By reporting security vulnerabilities directly, you can help us ensure a swift and efficient response, allowing us to address the issue promptly and implement necessary safeguards.
Using email for reporting security vulnerabilities provides an added layer of confidentiality and security. It allows for a more focused and discreet discussion of the specific details involved, preventing potential misuse or exploitation of the vulnerability before appropriate actions can be taken.
The ZAPHYR code of conduct is derived from the Ruby code of conduct. Any violations of the code of conduct may be reported to merloxx@zaphyr.org