Important
If you are a developer wanting to make any changes to the codebase, you should always open an issue first to initiate a discussion about whether the change is needed. This is especially important for larger features. After receiving confirmation that the change is indeed required, you can be sure that you are not wasting your time coding something that won't be merged.
- Do not open up a GitHub issue if the bug is a security vulnerability. Contact WWW/IT-team via email webmaster@luuppi.fi.
- Ensure the bug was not already reported by searching on GitHub under Issues.
- If you are unable to find an open issue addressing the problem, open a new one. Please fill out the corresponding bug report template and answer all questions to the best of your knowledge.
- The threshold for opening an issue is low. You can, and indeed should, open an issue even if you are unsure whether something constitutes a bug. There is no harm in doing that.
- You can also open an issue regarding new features using the feature template.
- Similarly to bug report cases, make sure there is no open issue regarding this feature request.
- There are no strict limits on what your commit message should look like. However, you should follow general best practices regarding commit messages.
Short (72 chars or less) summary
More detailed explanatory text. Wrap it to 72 characters. The blank
line separating the summary from the body is critical (unless you omit
the body entirely).
Write your commit message in the imperative: "Fix bug" and not "Fixed
bug" or "Fixes bug." This convention matches up with commit messages
generated by commands like git merge and git revert.
Further paragraphs come after blank lines.
- Bullet points are okay, too.
- Typically a hyphen or asterisk is used for the bullet, followed by a
single space. Use a hanging indent.
(source)
By contributing, you agree that your contributions will be licensed under its MIT License.
Luuppi ry