Development Guide

Functions

PreviousThe Development Process 
  Getting Involved as Developer Next

Component Maintainers and Testers

ILIAS Maintenance

The development of the ILIAS source code is coordinated and maintained by a coordination team within the ILIAS network. Besides the main responsibilities for the project, several developers and users are maintaining certain modules of ILIAS.

Special Roles

  • Product Management: [Matthias Kunkel]
  • Technical Board: [Timon Amstutz], [Michael Jansen], [Richard Klees], [Fabian Schmid], [Stephan Winiker]
  • Testcase Management: [Fabian Kruse]
  • Documentation: [Ann-Christin Gruber]
  • Online Help: [Alexandra Tödt]

Maintainers

We highly appreciate to get new developers but we have to guarantee the sustainability and the quality of the ILIAS source code. The system is complex for new developers and they need to know the concepts of ILIAS that are described in the development guide.

Communication among developers that are working on a specific component needs to be assured. Final decision about getting write access to the ILIAS development system (Github) is handled by the product manager.

ILIAS is currently maintained by three types of Maintainerships:

The following rules must be respected for everyone involved in the programming of ILIAS for all components having a listed component maintainer (see below):

  1. Decisions on new features or feature removals are made by the responsible first maintainer and the product manager in the Jour Fixe meetings after an open discussion.
  2. All components have a first and second maintainer. Code changes are usually done by the first maintainer. The first maintainer may forward new implementations to the second maintainer.

Responsibilities of a component maintainer:

  • Component maintainer must assure maintenance of their component for at least three years (approx. three ILIAS major releases).
  • Component maintainers must agree to coordinate the development of their component with the product manager.
  • Component maintainer are responsible for bug fixing of their component and get assigned related bugs automatically by the Issue-Tracker.
  • Component maintainers are responsible for Pull Requests to their component and get assigned related Pull Requests by the Technical Board according to the [Rules for Maintainers and Coordinators assigned to PRs[(Rules for Maintainers and Coordinators assigned to PRs)

Becoming a Maintainer

Applications for maintainerships can be handed in to the product manager. The product manager together with the technical board decide on who becomes a maintainer. Maintainerships are listed with the name of the maintainer. In addition the company the maintainer is working for can be listed, too. In this second case, the company has the right to propose an alternative maintainer at any time. In particular, if the maintainer resigns from his maintenance, a proposal for a new maintainer by the company of the old maintainer will be preferred, if the company recently invested substantially in the general condition of the component and the proposed maintainer meets the criteria.

Implicit Maintainers

If a component is currently unmaintained a developer can take responsibility for it without agreeing to give full support. An implicit maintainer will get assigned related bugs automatically and will keep the compontent working through the update cycle. S/he will not implement new features or develop the component further. If enhancements of the component are wanted, an explicit maintainer or coordinator must be assigned.

Additional Competences

A maintainer can pass certain of her/his competences to other people in the community. Currently these are:

  • The competence to handle pull requests including the rights to merge or close them.
  • The competence to handle issues in Mantis including the rights to relable, reassign, close, or reopen them.

If nobody is fullfilling the responsibilities of the component maintainer the Product Manager together with the Technical Board can look for members of the community and assign these competences to them.

Tracking Maintainerships

Maintainerships are tracked in maintenance.json files placed in the root of the corresponding components of ILIAS. The file containes the following fields:

  • maintenance_model: Currently there are two possible entries for this field
  • "first_maintainer": One entry in the form <username> (<userid>) pointing to a valid user on https://docu.ilias.de. Only relevant if the maintenance_model is set to "Classic".
  • "second_maintainer": One entry in the form <username> (<userid>) pointing to a valid user on https://docu.ilias.de. Only relevant if the maintenance_model is set to "Classic".
  • "implicit_maintainers": An array in the form [ <username> (<userid>) ] pointing to valid users on https://docu.ilias.de. Only relevant if the maintenance_model is set to "Classic" and neither a first nor a second maintainers is set.
  • "coordinator": An array in the form [ <username> (<userid>) ] pointing to valid users on https://docu.ilias.de. Only relevant if the maintenance_model is set to "Coordinator".
  • "pr_management" : An array in the form [ <username> (<userid>) ] pointing to valid users on https://docu.ilias.de.
  • "issue_management" : An array in the form [ <username> (<userid>) ] pointing to valid users on https://docu.ilias.de.
  • "tester": One entry in the form <username> (<userid>) pointing to a valid user on https://docu.ilias.de.
  • "testcase_writer": One entry in the form <username> (<userid>) pointing to a valid user on https://docu.ilias.de.

Current Maintainerships

Components in the Classic Model:

Components in the Coordinator Model:

Unmaintained Components

The following directories are currently unmaintained:

  • Services/DiskQuota
  • Services/Membership
  • Services/OpenIdConnect
  • Services/PHPUnit
  • Services/QTI
  • Services/Randomization
  • src/ArtifactBuilder

 

PreviousThe Development Process 
  Getting Involved as Developer Next