To encourage active collaboration, DeSySLaG 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. Pull requests will only be reviewed when marked as “ready for review” (not in the “draft” state) and all tests for new features are passing. Lingering, non-active pull requests left in the “draft” state will be closed after a few days.
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 want to chip in, you can help out by fixing any bugs listed in our issue trackers. You must be authenticated with GitHub to view all of Laravel’s issues.
The DeSySLaG source code is managed on GitHub, and there are repositories.
Core Development Discussion
You may propose new features or improvements of existing DeSySLaG behavior in the DeSySLaG Ideas issue board. 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.
Informal discussion regarding bugs, new features, and implementation of existing features takes place in the
board. Sameera Thilakasiri, the maintainer of DeSySLaG, is typically present in the channel on weekdays from 8am-5pm (UTC-05:30 or Asia/Colombo), and sporadically present in the channel at other times.
All bug fixes should be sent to the latest stable branch or to the current LTS branch. Bug fixes should never be sent to the
master branch unless they fix features that exist only in the upcoming release.
Minor features that are fully backward compatible with the current release may be sent to the latest stable branch.
Major new features should always be sent to the
master branch, which contains the upcoming release.
If you are submitting a change that will affect a compiled file, such as most of the files in
resources/js of the
desyslag repository, do not commit the compiled files. Due to their large size, they cannot realistically be reviewed by a maintainer. This could be exploited as a way to inject malicious code into Desyslag. In order to defensively prevent this, all compiled files will be generated and committed by Laravel maintainers.
If you discover a security vulnerability within Laravel, please send an email to email@example.com. All security vulnerabilities will be promptly addressed.