The Enlightenment Project is always keen to accept contributions of code, patches, and other fixes from developers. Whether you're looking to implement a feature or simply fix a typo your contributions will be warmly received, and will help to make the Enlightenment ecosystem as polished as it can possibly be.
Before contributing, please take the time to read through the following documentation.
Code contributed to the Enlightenment Project must follow the short list of project rules outlined below. Code or other contributions which do not adhere to these rules will not be accepted without modification.
valgrind) before being submitted
When contributing code to the Enlightenment Project you retain your copyright by default; no contributors are required to assign copyright elsewhere.
To ensure an approachable and maintainable code base the Enlightenment Project has a document outlining Coding Conventions, from the use of spaces rather than tabs through to naming conventions.
While all code contributions are welcomed, code which does not follow the Coding Conventions will need to be rewritten before it can be merged into the code base.
The Enlightenment Project uses the git version control system to manage its code base. The Git Best Practices guide offers advice on using the code base through git, including requirements for the format and style of all commit messages.
A web interface to the git repositories is also available at git.enlightenment.org allowing for easy browsing and search.
If you're looking for an issue to solve, the Phabricator Ticketing System tracks all the outstanding tasks relating to the Enlightenment, Enlightenment Foundation Libraries (EFL), Elementary, and Terminology code bases.
New contributors to the project are required to submit their patches through the Arcanist system, which automatically brings them through to the Phabricator Ticket System for tracking and review. The Patch Submission and Review with Arcanist guide explains how to install, configure, and use Arcanist to submit patches for review.
Before submitting code to the Enlightenment git repositories, mailing list, or through the patch submission process, always test it for errors using both positive (expected values/behavior) and negative (unexpected values/behavior) tests. Run your code inside
valgrind to ensure its memory access is correct and it does not leak.
More information on debugging is avaialble on the Phabricator wiki.
Advice on tailoring particular editors for ease of use during Enlightenment development can be found on the Phabricator wiki, presented here in alphabetical order:
If you have an idea for a new feature, first check that it is not already present within the Enlightenment Foundation Libraries (EFL) or other infrastructure. The following features are sometimes overlooked, and can often provide functionality otherwise missing:
printf()to debug code, silently ignoring errors or starting to use
If you are sure the functionality you wish to implement doesn't yet exist, talk to fellow developers on the official IRC channel or via the mailing list. Your fellow developers will almost certainly have ideas on how to implement the feature efficiently, advice on problems that have previously cropped up when trying to implement so-called "doomed features," and can coordinate to prevent future problems.
The official Enlightenment IRC channels, hosted on the Libera Chat network, are often the quickest way to communicate with fellow developers. Available in English, German, French, and Korean, the channels are accessible 24/7 and are open to both developers and end-users.
Connection information is as follows:
The Enlightenment Project maintains several mailing lists, full details of which are available on the Contact page. The developer-focused lists, which are available in English only, are as follows:
|enlightenment-devel||SourceForge||E/EFL development discussion|
|enlightenment-e-bork||Quality assurance reports|