Contribution Guide

Bug Reports

To encourage active collaboration, Laravel 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.

Core Development Discussion

You may propose new features or improvements by creating a new issue and assigning the suggestion label. If you propose a new feature, please be willing to implement at least some of the code that would be needed to complete the feature.

You can tag the internal developers @webhaikal or tagging the whole team with @strixtech-bot in your suggestions and we will get back to you with our input.

Which Branch?

All bug fixes should be made into a pull request and be merged into the develop branch before merging into master. We publish sources for openClinic in a few branches:

develop is the hub of changes from all our team. This branch will always be packed with the latest features but expect instability and bugs.

master is extensively tested by our QA team. We work hard to make releases stable and reliable, and aim to publish new releases every few months.

Individual teams have their own development branches for day to day work. These branches reflect the cutting edge of the system and may be buggy. Battle-hardened developers eager to test new features or work lock-step with us should head to one of these. We aim to merge development branches to develop every 3-4 weeks.

Other short-lived branches may pop-up from time to time as we stabilize new releases or hotfixes.

PHPDoc

Below is an example of a valid Laravel documentation block. Note that the @param attribute is followed by two spaces, the argument type, two more spaces, and finally the variable name:

/**
 * Register a binding with the container.
 *
 * @param  string|array  $abstract
 * @param  \Closure|string|null  $concrete
 * @param  bool  $shared
 * @return void
 * @throws \Exception
 */
public function bind($abstract, $concrete = null, $shared = false)
{
    //
}

Semantic Versioning

openClinic follows semantic versioning. We release patch versions for bugfixes, minor versions for new features, and major versions for any breaking changes. When we make breaking changes, we also introduce deprecation warnings in a minor version so that our users learn about the upcoming changes and migrate their code in advance.

We tag every pull request with a label marking whether the change should go in the next patch, minor, or a major version.

Every significant change is documented in the changelog file.

StyleCI

Don't worry if your code styling isn't perfect! StyleCI will automatically merge any style fixes into the main repository after pull requests are merged. This allows us to focus on the content of the contribution and not the code style.

License

By contributing to openClinic, you agree that your contributions will be licensed under its GPLv3 license.