ILIAS Community FAQ

Frequently Asked Questions about ILIAS development and how to participate

Tabs

Functions

Questions

Page Overview

[Hide]
This page is work in progress

1 Help

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

1.2 ILIAS Forums

  • If you have any questions how to setup and use ILIAS, just have a look in our community based forums. A lot of engaged ILIAS community members are following the different discussions and help with information and advice. And you find already a huge amount of questions and answers there. Notice: the forums are not intended to be used for reporting bugs or security issues. (See next topics in this FAQ)
  • List of ILIAS Forums

1.3 ILIAS 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]

1.4 Component Maintainers

  • If you you are planning to develop a new feature for an existing component (e.g. Wiki or Mail) or extend existing functions, please contact the responsible maintainer of this component. You find the right person in the following list.
  • List of Maintainers

1.5 ILIAS Service Providers

  • ILIAS service providers are offering commercial support for almost anything around ILIAS. These companies are working with ILIAS for years and are active in the community as well. Most component maintainers are working for these service providers.
  • List of ILIAS Service Providers (German version)
  • List of ILIAS Service Providers (English version)
  

2 Bugs

2.1 How do I report a bug?

Please report any bugs in our ILIAS issue tracker. To report a bug, you need to have an account for Mantis. 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?

Institutional members of the ILIAS society have the priviledge to vote on bugs and to influence their priority. Developers are encouraged to fix higher prioritised bugs first. 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 has to address the Jour Fixe directly and make clear about what the Jour Fixe should decide.
  • If possible, the product manager may decide whether an issue is a bug or not beforehand.
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 follow the process described in detail below. You will receive an answer from a member of the ILIAS security group about further steps. Do not file an issue in the bugtracker!

  1. 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. Please provide all necessary steps to reproduce the issue. We kindly ask you to withhold full disclosure of the issue until a fix is ready and the new release has been build and made available to everyone (full disclosure about 1 week after the new release is published).
  2. The Security Group will assign an issue manager.
  3. The issue manager will look into the issue and try and reproduce the problem.
  4. The issue manager will contact you on behalf of the ILIAS e.V. by email. We are grateful for any further help/information you can provide during the analysis and bugfixing process.
  5. Depending on the severity and impact of the issue at hand, the developers will build a new release ASAP or continue with the default roadmap.
  6. Optional: We are very interested in giving proper credit for your finding and your support for the project. If you want to, we can include your name and/or institution in our release notes. We will not publish your name or the name of your institution without your consent.

 

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.

 

3.4 Who takes care of security issues?

  • Robin Baumgartner, sr solutions ag, Burgdorf, Switzerland
  • Tim Bongers, CaT Concepts and Training GmbH, Cologne, Germany
  • Rob Falkenstein, University of Freiburg - IT Services, Germany
  • Manuel G. Müller, Qualitus GmbH, Cologne, Germany
  • David Tokar, WEKA Media GmbH & Co. KG, Kissing, Germany

 

  

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. You find a template for creating a new feature page with all necessary topics to address. To foster a final acceptance of your feature, you will need to schedule a feature for an upcoming Jour Fixe meeting. This requires a feature request where all necessary information is provided and mutually agreed with the responsible developer (see below chap. 4.4).

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 issues, 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 a virtual classroom on our BigBlueButton installation. The meeting is open for everyone.
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 are announced on the front page of the feature wiki. For upcoming feature workshops please have a look in the actual Jour Fixe agendas and minutes. All Jour Fixe minutes are 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.
  1. Initial Problem: The proposal MUST outline the problem the proposal tries to solve.
  2. Conceptual Summary: The feature proposal MUST give a brief summary on how you would like the problem to be solved.
    • The request SHOULD be conceptually complete and 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).
  3. User Interface Modifications: All modified and new screens that come with the suggested feature SHOULD be described (textual and/or visual).
    1. List of Affected Views: The description SHOULD list all views (screens) of ILIAS that are to be modified, removed, or introduced.
    2. User Interface Details: 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.
    3. New User Interface Concepts: 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.
    4. Accessibility Implications: If the proposal contains potential accessibility issues that are neither covered by existing UI components nor clarified by guidelines, please list them in this section. For every potential issue please either propose a solution or write down a short risk assessment about potential fallout if there would be no solution for the issue.
  4. Technical Information: This section will be completed by the responsible maintainer.
  5. Privacy: This section SHOULD list all personal data that will need to be stored or processed to implement this feature. For each date a short explanation should be given why it is necessary to use that date. This section MUST be completed by the responsible maintainer.
  6. Security: This section will be completed by the responsible maintainer.
After completing the different sections of the feature request, please add the necessary metadata for the request. This is done in the view mode of the page within the block "Status of Feature". Click on the Actions dropdown arrow to add the metadata:
  • Related Component / Module: You have to untackle the checkbox before "AAA..." and MUST mark the component(s) that is/are affected by your request.
  • Release Status: This is already preset and SHOULD NOT be modified
  • Development Status: Change from "Funding Required" to "Interest in Funding" in case you have resources to pay for the feature's development.
  • Funded by: Mark the checkbox in front of your institution if you can provide funding. In case, your institution is not listed yet, please notify the product manager.
  • Testcases and Approval by Customer should not be tackled and are needed later in the process.
If the feature request is complete and has been discussed with the responsible maintainer, it is ready for Jour Fixe. In this case, please fill out the form "Suggestions for Jour Fixe Agenda" up to one week before the meeting.
In a second step, please contact the maintainer that you put your requests on the Jour Fixe 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. ILIAS offers a documentation of implemented user interface elements within the ILIAS administration, see KS: Integration in Layout and Styles. If you have any question you may contact the UI coordinator 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?

New features will be released once a year with a new ILIAS version (e.g. ILIAS 8). Bugfix releases published during the year do not contain new features but only bugfixes. For every ILIAS version (e.g. v.7, v.8, ...) there is a timeline published on the related release page in the Feature Wiki.
In accordance with the related maintainer it is possible to get a release branch for your specific feature development. This allows you to get a new feature before the next ILIAS version is published. But this has to be coordinated with the service provider that will implement your new features. When the new ILIAS version is available you can change back xour installation to the correct release branch.

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.
Goals
  • 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.
Benefits
These developments will be prioritized when PM and TB plan their resources (e.g. meeting participation).
Procedure
  • 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?

There are several ways to participate in the ILIAS development:
  • Testing ILIAS versions
  • Joining the Online Help team
  • Writing concepts
  • Providing pull requests
  • Developing UI components
  • Improving language files and introducing new translations
  • Becoming a maintainer and develop components

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: 26. Mar 2024, 14:59, Kunkel, Matthias [mkunkel]


Information Message
No comment has been posted yet.