ILIAS software is developed in a community-based open source process and published under the General Public Licence version 3 (see also licence information in source code). This page describes how you can get involved in the software development of ILIAS and what you have to take into consideration. The ILIAS feature development process consists of these major steps:

Anyone who envisages an improvement or extension of ILIAS should share ideas with the user community. An optional first step is to discuss your idea in the ILIAS forums. A mandatory step to bring anything into the ILIAS development is to add your idea to the Feature Wiki and to put it onto our Jour Fixe agenda.

Notice: You do not need to have any funding suggesting a new feature. But the chance that your suggestion becomes part of ILIAS is much higher when you - or someone else - has funding to pay the developers.

In the Feature Wiki all community members are invited to share their ideas and comments. Often the responsible maintainer (see list of maintainers) of the feature is also adding comments or ideas to a feature request. This step of the development process should create a common understanding of the feature and generalise its concept to make the feature usable for as much users as possible.

The decision whether a new feature should be part of a future ILIAS release or not is made in the bi-weekly Jour Fixe where the Head of Development, the ILIAS Product Manager and developers meet to discuss the current ILIAS development. The decision is documented in the agenda of the meeting and published in the Feature Wiki, see list of Jour Fixes. Notice: Everytime you want the core team to get involved in the discussion or to make a decision, put the topic on the Jour Fixe agenda. Sometimes the core team asks for additional concepts papers, use cases or mock-ups, especially when it comes to more complex features. All this is collected in the Feature Wiki.

Every suggested feature needs funding to be implemented. If funding is not settled yet, the community is asked to look for supporters of new features. Sometimes multiple institutions join to fund a new development. For selected features the ILIAS society is setting up crowdfunding activities, see here.

Usually, new features fit into existing components of ILIAS. In this case, the first (or second) maintainer takes care of the development, see our list of maintainers. Sometimes, new components are developed or other developers provide the implementation of the functionalities, see our rules for getting involved as developer. Every developer has to respect the guidelines described within this document.

Since ILIAS 5.1[1] , all new features should be developed in feature branches first and then committed to the edge branch of ILIAS if they maintain the functionality of other components and if they are ready for approval. Exceptions may be decided upon by the Jour Fixe. Before a new feature is integrated into the trunk, it must be approved by the funding party (either on a separate feature branch provided by a service provider or on the ‘edge’ installation maintained by the ILIAS society. All new features must be integrated before the first beta release.

Alexander Killing, 20 Mar 2018: The edge branch is currently not used anymore. Developers need to create their own feature branches before mering to the trunk following the procedure above.

New source code has always to be tested locally by the programmer on his or her installation before committing it to the GitHub repository of ILIAS. Every new feature is also tested by the customer that has ordered this implementation. If the customer has accepted the feature it is committed to the trunk of ILIAS.

Test cases to test this feature have to be available with the implementation of the feature (with the first beta release at the latest). They can be written by the customer or the service provider. During the beta phase of the upcoming version new and existing features are tested by voluntary community testers, see list of component testers. Testing is done on a dedicated test installation and supported by Testrail test case management system.

All bugs discovered in maintained ILIAS versions have to be reported to our Mantis bug tracker where they are assigned to the responsible maintainer and treated according to the defined bugfixing process, see below.

The user documentation is currently maintained by one of our service providers, Qualitus. The online help for ILIAS is coordinated by the Head of Help and written and updated by a group of community members.

In the last step a new release is packed and published. Major ILIAS releases are published once a year. Stable versions are to be used for productive systems. For each major release a number of maintenance releases will be published for up to two years. Information about every published release is added to the Roadmap and Releases document.

Major releases are identified by increasing the second field in the release number, e.g. 4.2.0, 4.3.0, ... Major releases include new features and are published once a year.

For maintenance releases (aka bug fix releases) the last number is incremented, e.g. 4.2.0, 4.2.1, ... Bug fix releases do not include new features. Upgrading should be usually painless and customized templates or style sheets should not be affected.

This picture gives an overview on a typical timeline of our yearly major release development.

• New features can be suggested for an upcoming release until feature freeze, usually end of March. Already before and also after feature freeze, the core team decides which features will go into the new release and which not. The decisions are documented in the feature wiki.
• Coding of the new feature can already begin as soon as a the core team made a positive decision  and the ILIAS development server is opened for the new release, usually in January.
• Testing starts as soon as the first new features have been developed. We provide an general edge installation for all customer testing and a test installation for each major release, see www.ilias.de/test52, www.ilias.de/test53 ... and so on.
• Up to our first beta release - planned for end of August - all new features should be fully developed. After that we focus on testing and bugfixing.
• Our target for a stable major release is mid December.