Skip to content
Snippets Groups Projects
Select Git revision
  • master default protected
  • cesnet_simplesamlphp-1.19.8
  • elixir_simplesamlphp-1.19.8
  • simplesamlphp-1.19.8
  • cesnet_simplesamlphp-1.19.5
  • simplesamlphp-2.0
  • feature/assets
  • feature/rac-source-selector
  • cleanup/remove-base64-attributes
  • simplesamlphp-1.19
  • elixir_simplesamlphp-1.19.5
  • aarc_idp_hinting
  • feature/validate-authstate-before-processing
  • feature/build-two-tarballs
  • dependabot/composer/twig/twig-3.4.3
  • tvdijen-patch-1
  • unchanged-acs-url-no-www-script
  • feature/translation-improvements
  • symfony6
  • move_tests
  • v1.19.9
  • v2.1.3
  • v2.0.10
  • v2.1.2
  • v2.0.9
  • v2.1.1
  • v2.0.8
  • v2.1.0
  • v2.0.7
  • v2.1.0-rc1
  • v2.0.6
  • v2.0.5
  • 2.0.4-alpha.1
  • v2.0.4-alpha.1
  • v2.0.4
  • v2.0.3
  • v2.0.2
  • v2.0.1-alpha.1
  • v2.0.1
  • v1.19.8
40 results
Blame History Permalink
Code owners
Assign users and groups as approvers for specific file changes. Learn more.
CONTRIBUTE.md 7.86 KiB

Contribution guidelines

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!

This guidelines briefly explain how to contribute to SimpleSAMLphp in an effective manner, making sure to keep high quality standards and making it easier for your contributions to make through.

Team members

Currently, the core team members are:

We've been lucky to have the help of many people through the years. SimpleSAMLphp wouldn't have reached so far without them, and we want to thank them from here. Unfortunately, they are so many it is nearly impossible to mention all of them. Github can offer a good summary on who has contributed to the project. Big thanks to you all!

First things first

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.

Contributing code

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 is demanding. Our roadmap might also be a good place to start if you don't know exactly what you can contribute with.

When contributing your code, please make sure to:

  • Respect the coding standards. We try to comply with PHP's PSR-2. Pay special attention to:
    • Lines should not be longer than 80 characters.
    • Use 4 spaces instead of tabs.
    • Keep the keywords in lowercase, including true, false and null.
    • 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 many changes in every commit. Commits should be focused and address one single problem or feature. By having multiple, small commits instead of few large ones, it is easier to track what you are doing, revert changes in case of an error and help you out if needed.
  • Be explicit. Add comments. Use strict comparison operators like === and check for specific values when testing conditions.
  • Keep things simple. Avoid big functions, long nested loops or if statements.
  • 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.
  • Try to keep backwards-compatibility. Code that breaks current configurations and installations is difficult to deploy, and therefore we try to avoid it.
  • 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.
  • Add proper documentation explaining your how to use your new feature or how your code changes things.
  • 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 and bug/something-not-working for bug fixes, but this is not carved in stone.

Sometimes it can take a long time until we are able to process your pull requests. Don't get discouraged, we'll eventually reach up to you. And remember that following this guidelines you are making it easier for us to analyze your request so the process will be smoother and faster. We really appreciate you helping us out, not only with your code, but also by following this guidelines.

Reporting bugs

Before reporting a bug, please make sure it is indeed a bug. Check the documentation to verify what the intended behaviour is. Review the list of issues and the pull requests to see if someone has already reported the same issue.

Pull requests are definitely more appreciated than plain issue reports, as they are easier and faster to address, but please, do not hesitate to open an issue if you don't have coding skills or just can't find the bug. It's 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?