All issues and pull requests to Weaver are highly appreciated. Any contributions you make will be under the MIT license, as to uphold the permissions that the source code has.
When creating an issue, you should use the template respective to what you're reporting. If you do use the incorrect template, no worries! The labels can always be changed after the fact.
Contributions to documentation are some of the most useful for Weaver. Generally, the documentation was written to hopefully clarify all of Weaver and how to use it, from the usage to the execution model, though there are always possibilities that something was wrong or mistyped. If you notice any misspellings, bad phrasing, et cetera, you're free to make an issue or pull request to have what you spotted fixed.
When reporting a bug, try to explain what you're experiencing in a reproducible way, and try to supply an error log. Clarification and your steps to finding the bug are the easiest ways to have it fixed, as sometimes, unit tests may not catch issues within Weaver.
If you're creating a pull request to fix an issue, refer to that issue in your pull request. If you don't have an issue to link to, explain what you're fixing. Any malicious or faulty pull requests will be reviewed and declined.
When requesting a feature, try to be thorough in how it could help Weaver and what use cases it may have. Feature requests may be declined if they are not frequently or commonly useful, or easy to implemented yourself without being added into Weaver's source code.
If you contribute to Weaver, please try and maintain the coding style that the main source code has. Generally, this is the convention that Weaver's internals use:
- CONSTANT_CASE for all constant values
- Pascal_Snake_Case for variables
- PascalCase for functions
Tables are formatted like this:
local Some_Table =
{
ValueA = 1;
ValueB = 2;
ValueC = 3;
}If possible, add comments to your code to explain what it does. This helps in having your pull request reviewed faster, and hopefully pulled into Weaver.