Skip to content

Latest commit

 

History

History
60 lines (47 loc) · 2.88 KB

CONTRIBUTING.md

File metadata and controls

60 lines (47 loc) · 2.88 KB

DISCLAIMERS

  • SECURITY ISSUES SHOULD BE REPORTED TO security @ elgg . org! Please do not post any security issues in github.
  • Support requests belong on the Community site. Tickets with support requests will be closed.
  • Reports which do not give sufficient detail to diagnose the problem, cannot be reproduced, or are dealing with customized code or third party plugins will be closed.
  • We cannot make any guarantees as to when your ticket will be resolved.
  • Please search the existing list of issues before submitting new reports.

Submitting pull requests

We love pull requests! Pull requests will almost always get higher priority than just plain issues. Some things to keep in mind:

  • By submitting a pull request you are agreeing to license the code under a GPLv2 license and MIT license.
  • You may want to talk to us first before spending a ton of time on code.
  • All code is expected to conform to our coding standards.
  • Include unit tests if possible.
  • Make sure your code can be merged cleanly.

Bug reports

If you've searched for an existing ticket on the issue you're having, and can reproduce the problem on the latest version of Elgg, please submit a new issue the following information:

  • Expected behavior and actual behavior.
  • Clear steps to reproduce the problem.
  • The version of Elgg you're running.
  • Browsers affected by this problem, if applicable.

Pull requests for bugfixes should generally be submitted against the most recent bugfix branch of Elgg (i.e. not master). If your bug only appears in master, then feel free to pull against master.

Feature requests

Before submitting a feature request, check the community site for a plugin that has the features you need. You may also want to 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. If they did, you'll need to be able to explain why your suggestion should be considered this time. Please include as much of the following information as possible, when applicable:

  • Detailed explanation of the feature
  • Real-life use-cases.
  • Proposed API

It's usually best to submit a ticket for your feature request first before working on code, so that you can know whether we will accept your solution. Once your idea has been accepted, pull requests are certainly welcome! Pull requests for features should always be made against master. We do not generally introduce new features in bugfix branches.