- SECURITY ISSUES SHOULD BE REPORTED TO security @ elgg . org! Please do not post any security issues on github.
- Support requests belong on the Community site. Tickets with support requests will be closed.
- We cannot make any guarantees as to when your ticket will be resolved or your PR merged.
We love pull requests! Here's how to get your patch accepted as quickly as possible:
Before submitting a pull request:
- By submitting a pull request you are agreeing to license the code under a GPLv2 license and MIT license.
- For new features, submit a feature request or talk to us ([email protected]) and make sure the core team approves of your direction.
Good PR checklist:
- Clear, meaningful title
- Detailed description
- Includes relevant tests (unit, e2e, etc.)
- Includes documentation update
- Passes the continuous build
- Is submitted against the correct branch:
- New features should be submitted against master. We do not introduce new features in bugfix branches.
- Bugfixes should be submitted against the latest non-master branch (unless the bug only appears in master).
Before submitting a bug report:
- Search for an existing ticket on the issue you're having. Add any extra info there.
- Verify the problem is reproduceable
- On the latest version of Elgg
- With all third-party plugins disabled
Good bug report checklist:
- Expected behavior and actual behavior
- Clear steps to reproduce the problem
- The version of Elgg you're running
- Browsers affected by this problem
- Post bug report using Github issues
Before submitting a feature request:
- Check the community site for a plugin that has the features you need.
- Consider if you can develop a plugin that does what you need.
- Search through the closed tickets to see if someone else suggested the same feature, but got turned down. You'll need to be able to explain why your suggestion should be considered this time.
Good feature request checklist:
- Detailed explanation of the feature
- Real-life use-cases
- Proposed API