SimpleSAMLphp welcomes all contributions. It is impossible to make a product like this without the efforts of many people, so please don't be shy and share your help with us. Even the tiniest contribution can make a difference!
These guidelines briefly explain how to contribute to SimpleSAMLphp effectively and consistently, making sure to keep high quality standards and making it easier for you to contribute.
[TOC]
Before embarking yourself in a contribution, please make sure you are familiar with the way SimpleSAMLphp is written, the way it works, and what is required or not.
- Make sure to read the documentation. If you use the search engine in the website, please verify that you are reading the latest stable version. If you want to make a change, check the development branch of the documentation.
- If you have a question about using SimpleSAMLphp, please use the mailing list.
- If you have a question about developing SimpleSAMLphp, please ask in the development mailing list.
- If you think you have discovered a bug, please check the issue tracker and the pull requests to verify it hasn't been reported already.
New features are always welcome, provided they will be useful to someone apart from yourself. Please take a look at the list of issues to see what people are asking for. Our roadmap might also be a good place to start if you do not know exactly how you can contribute.
When submitting a pull request, please make sure to account for:
- Respect the coding standards. We try to comply with PHP's PSR-12. Pay special attention to the rules below:
- Lines should not be longer than 80 characters.
- Use 4 spaces instead of tabs.
- Keep the keywords in lowercase, including
true
,false
andnull
. - Make sure your classes work with autoloading.
- Never include a trailing
?>
in your files. - The first line of every file must be
<?php
. - Use namespaces if you are adding new files.
- Do not include too many changes in every commit. Commits should be focused and address one single problem or feature. By having multiple, small commits instead of fewer large ones, it is easier to track what you are doing, revert changes in case of an error and help you make changes if needed.
- Try to write clean commit messages, largely based on the seven rules:
- Write a short subject line, followed by a blank line and a longer explanation.
- Prefix the subject line with the component(s) changed, e.g. "docs: Update foo", or "SAML: Don't log bar twice", or "tests: Add tests for quux".
- Explain what and why in the commit message, not just how. Things that seem obvious now might become quite confusing when rediscovered years later.
- Add comments that describe why/how your code works.
- Include complete phpdoc documentation for every property and method you add. If you change a method or property, make sure to update the existing phpdoc accordingly. Do not forget to document all parameters, returned values and exceptions thrown.
- Use strict comparison operators like
===
and check for specific values when writing tests. - Avoid big functions, long nested loops or
if
statements. - Try to keep backwards-compatibility. Code that breaks current configurations and installations is difficult to deploy, and therefore we try to avoid that as much as possible.
Add unit tests to verify that your code not only works but also keeps working over time. When adding tests, keep the same directory structure used for regular classes. Try to cover all your code with tests. The bigger the test coverage, the more reliable and better our library is. Read our guidelines to learn more about tests.
In order to keep this library user-friendly, we ask that you add proper documentation explaining how to use your new feature or how your code changes things.
Please follow all instructions below:
- Submit your code as a pull request in github from a branch with a descriptive name in your own fork of the repository.
- Add a meaningful, short title, and explain in detail what you did and why in the description of the PR.
- Add instructions on how to test your code. We appreciate branch names like
feature/whatever-new-feature
for new features andbug/something-not-working
for bug fixes, but this is not required.
Sometimes it can take a long time before we are able to process your pull requests. Do not get discouraged, we will eventually reach your change. Remember that by following these guidelines, you are making it easier for us to analyze your request so the process will be smooth and fast. We really appreciate you helping us out, not only with your code, but also by following these guidelines.
Before reporting a bug, please make sure it is indeed a bug. Check the documentation to verify what the intended behaviour is. Review the issue tracker and the pull requests to see if someone has already reported the same issue.
If you are able, a pull request is much more appreciated than just a new issue. If not, please do not hesitate to open one. It is better to have just an issue report than nothing!
You can help us diagnose and fix bugs by asking and providing answers to the following questions:
- How can we reproduce the bug?
- Is it reproducible in other environments (for example, on different browsers or devices)?
- Are the steps to reproduce the bug clear? If not, can you describe how you might reproduce it?
- What tags should the bug have?
- How critical is this bug? Does it impact a large amount of users?
- Is this a security issue? If so, how severe is it? How can an attacker exploit it? Read more about security issues in the next section.
Please see SECURITY.md for how to report security vulnerabilities. Please do not use the public issue tracker.
SimpleSAMLphp is translated to many languages, though it needs constant updates from translators, as well as new translations to other languages. For the moment, translations can be contributed as pull requests.
Before starting a new translation, decide what style you want to use, whether you want to address the user in a polite manner or not, etc. Be coherent and keep that style through all your translations. If there is already a translation and you want to complete it, make sure to keep the same style used by your fellow translators.
Did you find a typo in the documentation? Does something make no sense? Did we use poor English? Tell us!
Documentation is included in our own repository in markdown format. You can submit pull requests with fixes. If you encounter some feature that is not documented, or the documentation does not reflect the real behaviour of the library, please do not hesitate to open an issue.
Good documentation is key to make things easier for our users!
You do not feel capable of contributing with your code, but are using SimpleSAMLphp and can share your knowledge and experience? Please, do so! Join our users mailing list and help other users when you can. Your experience might be valuable for many!