Icon Wiki

ILIAS Community FAQ

Frequently Asked Questions about ILIAS development and how to participate



This page is work in progress

1 Help

1.1 Who can and should I address if I need help?

ILIAS Forums
  • If you have any questions how to setup and use ILIAS, our forums offer a free and open community discussion. The forums are not intended to be used for reporting bugs or security issues. (See next topics in this FAQ)
  • List of ILIAS Forums
Product Manager/Managing Director
  • If you have questions related to the ILIAS community and its processes in general, contact our product manager and managing director of the ILIAS society.
  • Product Manager/Managing Director: Kunkel, Matthias [mkunkel]
Component Maintainers
  • Please contact one of our maintainers, when you plan to develop a new or modify an existing feature.
  • List of Maintainers
Service Providers

2 Bugs

2.1 How do I report a bug?

Please report any bugs in our ILIAS bug tracker. If you do not already have one, create an account first. More detailed information on how to report bugs can be found here (german only). Please do not report any security relevant issues in the bug tracker (see next FAQ chapter).

2.2 Can I vote on bugs?

Members of the ILIAS society can vote on bugs to influence their priority. High priority bugs should be tackled first by developers. More details can be found here.

2.3 How can I schedule a bug discussion for a Jour Fixe meeting?

If you think the ILIAS core team should discuss a bug, e.g. because there are open conceptual issues or reporter and developer do not agree on any conclusions, you can schedule a bug report for a Jour Fixe meeting.
  • To schedule a bug report for the meeting you MUST set its status to "Needs JF Decision".
  • A comment in the report should address the Jour Fixe directly and present alternative solutions.
  • If possible, the product manager may decide whether an issue is a bug or not beforehand.
  • The product manager estimates the time required per bug report and assigns a time slot for discussion (10 or 20 minutes) accordingly.
You may also contact the product manager (Kunkel, Matthias [mkunkel]) directly, if you would like to schedule a bug report discussion for a specific Jour Fixe and participate in the meeting.

3 Security Issues

3.1 How should I report a security issue?

Please make sure to understand, that treating security issues confidentially is required to keep ILIAS installations as safe as possible until the issue is fixed.

Please write an email to security@lists.ilias.de about your discovery, containing a description of the issue with the scenario in which the problem is triggered and a description of its implications. Do not file an issue in the bugtracker!

You will get an answer from a member of ILIAS society, maybe containing further questions about the issue.

3.2 Where should I publish my fix of a security issue?

We are delighted when solutions are offered together with the initial report. Please be aware, however, that our repository in GitHub is also open to the general public: commits, commit-messages and pull-requests can be viewed by anyone. It is therefore also better in this case to get in touch with security@lists.ilias.de in order to discuss further steps with us.

3.3 How do I receive security update notifications?

Please subscribe to our admin mailing list (ilias-admins@lists.ilias.de) to get notifications about security updates, updates in general and announcements for ILIAS server administrators.

4 Feature Changes

4.1 What are the differences between a core development, a plugin and a patch?

  • A core development is a code change in the trunk of the ILIAS source code that is committed to the ILIAS development repository at GitHub and is or becomes part of an official source code distribution by the ILIAS open source e-Learning e.V. Such a core development could bring new functionality, changes an existing component or removes a feature from the core.
    • Core developments MUST be discussed and accepted by the Jour Fixe before becoming a part of the source code.
    • Core developments have to be committed by the responsible maintainer or a related pull request by another developer has to be accepted by the responsible maintainer before being merged to the GitHub repository of ILIAS.
    • Core developments must not be committed to a release branch but to trunk only. All core developments have to respect the release cycle and committed to trunk before 'coding completed'.
  • A plugin is a piece of source code that addresses one of the existing plugin slots in ILIAS and extends the functionality of a standard ILIAS without changing its source code. Plugins are also needed to connect external software to ILIAS. Plugins are a good choice to extend ILIAS for specific purposes that are only needed by a very little amount of customers and have therefore no chance to become a core feature.
    • Plugins do need to be discussed in the Jour Fixe and can be developed by anyone.
    • Plugins can be published in the data collection 'Extending ILIAS' if they might be interesting for other users, too.
  • A patch is a specific change of the existing source code for the purposes of a single customer. Patches are usually done in ILIAS versions from published release branches but need to be redone with every update of the core ILIAS. A patch is the quickest way to change a feature in ILIAS according to the need of a customer, but it has no sustainability and can become a money pit quickly.

4.2 How can I suggest a new feature or a feature modification?

Follow the instructions on this page to create a new feature wiki entry. We have introduced a new template for Creating A New Feature Page. To foster a final acceptance of your feature, you will need to schedule a feature for an upcoming Jour Fixe meeting.

4.3 What are feature workshops and Jour Fixe meetings?

The Jour Fixe meeting is the key instrument for decision making in the development process. On the meeting, new features, selected bugs, pull requests and general development topics are discussed. Product manager and component maintainer finally decide upon the acceptance of a feature, after considering the opinion of the participating developers and users. The meeting takes place every two weeks in the ILIAS headquarters in Cologne. The meeting is open for everyone. It is also possible to participate at the meeting virtually (see information at Jour Fixe agenda and minutes) .

Feature workshops are similar to Jour Fixe meetings, except that they only discuss distinct features and are scheduled on demand. To enable acceptance of features for a release at least the product manager and the responsible component maintainer need to participate. Four types of workshop format exist:
  • 1 hour virtual conference
  • 2 hour virtual conference
  • half day meeting
  • full day meeting
Upcoming Jour Fixe meetings and feature workshops will be announced on the front page of the feature wiki. Alle minutes will be published here.

4.4 How can I schedule a feature for a Jour Fixe meeting?

To schedule a feature for the Jour Fixe meeting your feature wiki page should meet the following criteria. If your proposal is conceptually incomplete you may consider to schedule a feature workshop instead.
  • The proposal MUST outline the problem the proposal tries to solve.
  • The proposal SHOULD contain a brief conceptual summary of the proposal.
  • The proposal MUST indicate the current/future maintainer of the feature.
  • The feature proposal SHOULD be conceptually complete. It should not leave any conceptual issues open. It SHOULD be possible to make a final decision on the proposal (yes/no, selecting one of multiple alternatives).
  • The description SHOULD list all views (screens) of ILIAS that are to be modified, removed, or introduced.
  • For each view the description SHOULD list all user interface elements that are newly introduced, modified or removed. The description SHOULD use the terminology of the kitchen sink, if possible (Button, Glyph, etc.).
  • For each element their textual appearance (labels of buttons, headings, etc.) SHOULD be provided and for interactive elements their behaviour SHOULD be described (what happens if a button is pressed).
  • To support the understanding of the feature screen mock-ups MAY be added.
  • If new user interface elements (elements that do not exist similarly in ILIAS) should be introduced a pull request for the new elements MUST be provided, according to the guidelines of the UI Framework. If in doubt what new interface elements will be needed, a feature proposal MAY be handed in without a new UI component suggestion. However the Jour Fixe MAY request a UI proposal for a final acceptance. There also might be the possibility that existing UI elements are sufficient for the realisation of the intended functionality.
Now please fillout the form "Suggestions for Jour Fixe Agenda" up to one week before the meeting and provide the following information:
  • Your name
  • Envisaged date of Jour Fixe meeting (selection list)
  • URL to feature wiki entry
  • Slot length (15 or 30 minutes)
  • Name of presenter (the person should be able to answer all non-technical questions related to the feature request)
  • Name of responsible maintainer (the maintainer has to participate in the meeting, too)
Please contact the maintainer if you put requests on the agenda. Maintainer and product manager have some obligations, too:
  • Maintainers MUST indicate if they support or object the request in general. Objections MUST be listed on the feature wiki page. Objections at this point do not mean that the topic will not be handled during JF.
  • The product manager SHOULD indicate if she/he supports or objects the request in general. Objections SHOULD be listed on the feature wiki page. Objections at this point do not mean that the topic will not be handled during JF.
  • The maintainer's or product manager's statement to support a feature request in general does not imply the acceptance of the feature. This is only decided in the Jour Fixe.
  • Maintainers MUST provide the metadata "Related Component/Module" and "Development Status".
  • Maintainers MUST provide all relevant technical information (dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues).
Dates for upcoming Jour Fixe meetings can also be found on the front page of the feature wiki.

4.5 How can I schedule a feature workhop?

To schedule a feature workshop your feature wiki page should meet the following criteria.
  • The proposal MUST outline the problem the proposal tries to solve.
  • The proposal SHOULD contain a brief conceptual summary of the proposal.
  • The proposal MUST indicate the current/future maintainer of the feature.
Now apply for a workshop to clarify the concept and prepare a promising feature request. An input form will be provided to give in the necessary information:
  • Your name
  • Proposed date of meeting
  • Proposed location
  • URL to feature wiki entry
  • Workshop format (1 hour VC, 2 hour VC, half day meeting, full day meeting)
  • Name of presenter (the person should be able to answer all non-technical questions related to the feature request)
  • Name of responsible maintainer (the maintainer has to participate in the meeting, too)

4.6 How do I find the responsible maintainer for a feature?

You will find a list of all ILIAS maintainers here. The first maintainers are the ones to be adressed for new feature developments. If you are unsure which component is related to your request contact our product manager (Kunkel, Matthias [mkunkel]). You may also ask the ILIAS service provider of your choice.

4.7 Where do I get information on user interface elements and the kitchen sink?

General information on the kitchen sink project can be found here. From ILIAS 5.2 onwards ILIAS will offer a documentation of implemented user interface elements in the ILIAS administration, see KS: Integration in Layout and Styles. If you have any question you may contact Amstutz, Timon [amstutz].

4.8 How can I assess the risk or difficulties for a feature idea?

Since the process to include new features in ILIAS is open for many participants, it is in general not possible to get any guarantees that a specific feature idea will get approval by the JF or be implemented in the envisioned way. However, there still are some factors that can be used to assess the risk that a feature might not become a part of ILIAS and the difficulties a feature idea might face during the feature process. The factors could be considered before an idea is pursued and when schedules or budgets for projects are planned. These are:
  • How many parts of ILIAS are influenced by your idea? Will it only introduce a local change in some component or will it affect many components throughout the system?
  • How big is your idea? Will it require a minor change to an existing idea only, like adding some configuration, or will it require a whole new world of stuff?
  • How big might your idea get? Is it strictly bound to one component or are there components that might profit from a similar feature? Does your idea have implications that make it bigger than initially intended?
  • How much development is going on in the affected component? Are there a lot of open feature requests for the component? Are the many new features introduced in every release? Are there a lot of open bugs in the component?
  • How many new views and user interface components does your component require? Does it copy some screens already known from other components in the system or does it introduce mechanism in the user interface that are completely new to the system?
Please consider this list to be incomprehensive. The single items are worded in a way where "more" also means "more difficulties" and "more risk".

4.9 When will new features be released officially?

4.10 How are large developments organised?

Developments are considered being large, if they
  • are estimated to require more than 50 person days for implementation (including conceptualization) or
  • if maintainers of at least two institutions are required for its implementation.
Once a year, usually at the beginning of a new release cycle, we organise a yearly development planning meeting.
  • Identification of potential large developments for the next release.
  • Identification of potential resource bootlenecks and risks resulting from these large developments.
  • If possible, a decision which large developments should be tackled for the next release with priority.
These developments will be prioritized when PM and TB plan their resources (e.g. meeting participation).
  • The date of the planning meeting will be discussed and announced in a Jour Fixe meeting, usually shortly after a major beta release has been published, and then further disseminated through the admin- and developers-mailinglist as well as on the blog
  • Large developments should be added to the corresponding feature collection. For the future (planing for ILIAS 8) we will also ask you to create a a special kind of page in the Feature Wiki.
  • At the planning meeting everybody who proposed a development will have 10min to present her proposal and then 10min are reserved for questions. Once all proposals have been presented a short discussion takes place.
  • Based on the discussions and the presented features the Product Manager in consultation with the Technical Board will come up with a list of developments that should be prioritized for the upcoming release. The list will be presented, explained, and opened for a final discussion in the following Jour Fixe meeting.
  • We kindly ask maintainers to be present at this Jour Fixe.
  • Like today, all related feature wiki pages of an accepted development still have to be presented at a JF and the responsible maintainer and the product manager have to accept it.

5 General Development Issues

5.1 How can I participate in the ILIAS development?

5.2 How can I contribute code?

Most of the ILIAS code is written by code maintainers who committed themselves to provide long term maintenance for their components and features. If you are not a maintainer you can provide code contributions under the following rules.

5.3 How do I become a maintainer?

5.4 How can I schedule a general development discussion for the Jour Fixe?

5.5 What is the ILIAS development conference and how can I participate?

The ILIAS development conference is bi-annual meeting of developers and power-users to discuss the actual development activities and plans. It takes place before the General Meeting of Members (usually in March) and one day before the International ILIAS Conference (usually in September). The conference is a one-day event and open to all interested ILIAS users. If you want to participate, join the DevConf group and register for the next session. The conference is free of charge.

6 Sources of Information

6.1 What general source of information do you have?

6.2 What kind of mailing lists do you have?

We are offering a mailing list for ILIAS developers and a mailing list for ILIAS administrators. You can subscribe to these mailing lists to get the latest information about development and administration issues and topics. More information and the option to subscribe can be found here.
For reporting security issues we are offering the mailing list security@lists.ilias.de. In case you found a security problem, please send a mail to this list and describe the problem in the mail. But please do not create a Mantis bug report for it. You cannot subscribe to the security mailing list. All security problems and fixes will be published in the administrator list (see above).

Last edited: 14. Mar 2021, 17:42, Suittenpointner, Florian [suittenpointner]

No comment has been posted yet.