Contribution Guide
As you will see our contribution guide is derived from Laravel's, since we meet in principles.
Last updated
Was this helpful?
As you will see our contribution guide is derived from Laravel's, since we meet in principles.
Last updated
Was this helpful?
To encourage active collaboration, Lucid Architecture 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 or steps to reproduce the bug.
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.
The Lucid Architecture source code is managed on GitHub, and there are repositories for each of the Lucid Architecture projects:
Lucid Architecture's GitHub issue trackers are not intended to provide help or support. Instead, use one of the following channels:
Official in the #support channel
All repositories follow Laravel's versioning in branching, where installing the branch 5.5 in any of the repositories will install Lucid with Laravel v5.5. The main repositories are the following:
If you are submitting a change that will affect a compiled file, such as most of the files in resources/sass or resources/js of the lucid-architecture/laravel 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 Lucid Architecture. In order to defensively prevent this, all compiled files will be generated and committed by Lucid maintainers.
If you discover a security vulnerability within Lucid, please send an email to Abed Halawi at halawi.abed@gmail.com. All security vulnerabilities will be promptly addressed.
Below is an example of a valid Lucid Architecture documentation block. Note that the @param attribute is followed by two spaces, the argument type, two more spaces, and finally the variable name:
The Lucid Architecture code of conduct is derived from the Laravel code of conduct. Any violations of the code of conduct may be reported to Abed Halawi (halawi.abed@gmail.com):
Participants will be tolerant of opposing views.
Participants must ensure that their language and actions are free of personal attacks and disparaging personal remarks.
When interpreting the words and actions of others, participants should always assume good intentions.
Behaviour that can be reasonably considered harassment will not be tolerated.
You may propose new features or improvements of existing Lucid Architecture behaviour in the Lucid Ideas . 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 #internals channel in the . Abed Halawi, the maintainer of Lucid, is typically present in the channel on weekdays from 8am-5pm EEST (Eastern European Summer Time), and sporadically present in the channel at other times.
Main: and are the main repos that you usually clone
: Has the extendable components of Lucid such as Feature, Job etc.
: contains the Console companion, the CLI and the dashboard
Lucid Architecture follows the coding standard and the autoloading standard.