The package contributing considerations are basically a Ctrl-c, Ctrl-v from Laravel Framework contribution guide
To encourage active collaboration, I 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.
If you discover a security vulnerability within our package, please send an email to Samuel Martns at [email protected]. All security vulnerabilities will be promptly addressed.
The package follows the PSR-2 coding standard and the PSR-4 autoloading standard.
Below is an example of a valid package 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
*/
public function bind($abstract, $concrete = null, $shared = false)
{
//
}Don't worry if your code styling isn't perfect! StyleCI will automatically merge any style fixes into the package repository after pull requests are merged. This allows us to focus on the content of the contribution and not the code style.