Show Advanced KnowledgeHide Advanced Knowledge

Introduction of Lifecycle Service

This feature request is part of the initiative for an Improved test question sharing. A first implementation of this service would be Lifecycle and Versioning Support in Test Questions.

1 Initial Problem

There is no general concept in ILIAS for indicating and handling the lifecycle of a learning resource - besides the lifecycle metadata section in LOM. As long as an author is editing learning materials alone he still has an overview of the status of each resource. But if several authors are collaborating, this information get's lost quickly. Especially for collaborative scenarios it would be helpful to see easily if a resource is still draft or already final, if it is within a review process or outdated.

2 Conceptual Summary

A general lifecycle service should be introduced to ILIAS. It could be used by any ILIAS module and should allow to set and show the lifecycle status of a resource within a fixed pentamerous scale[1]:

1. Draft - resource has been created and is currently edited but not finished yet.
2. Review - Editing has been finished and resource can be reviewed or is currently reviewed.
3. Final - Resource is ready to be used.
4. Distribute - Resource is ready to be distributed (metadata and copyright information added).
5. Outdated - Resource should no longer be used and needs to be revised.

Such a general lifecycle service can be implemented by a module and used for additional functions and workflows.

Example: Lifecycle support in test question pools would allow to define a lifecycle status for every test question. When inserting questions from this pool into a test, only questions with status 'Final' and 'Distribute' are listed and could be inserted into the test. Questions with other status are not shown or picked (in case of a random test). This behaviour is part of the lifecycle implementation in the test but not of the lifecycle service itself.

3 User Interface Modifications

3.1 List of Affected Views

No affected views. The general lifecycle service does not need an administration page where it can be enabled or edited. Enabling lifecycle support should always be done within the modules that use this service (similar to calendar service in groups/courses or taxonomies in categories).

3.2 User Interface Details

The user interface for the lifecycle service is implemented by the module that uses this service. The lifecycle itself just comes with a dropdown menu to indicate the lifecycle status.

3.3 New User Interface Concepts

None.

4 Technical Information

{The maintainer has to provide necessary technical information, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues.}

5 Contact

• Author of the Request: Kunkel, Matthias [mkunkel]
• Maintainer: no maintainer yet (new service)
• Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

6 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• Possible funding by DHBW / optes project

7 Discussion

Neumann, Fred [fneumann], March 31, 2017
As discussed on the SIGEA meeting in Fürth in February 2017 ut should be possible to create trial and demo test with questions before final state. This should at least be supported for a manual selection of questions. It should also still be possible to create questions directly in a test. These questions should get the lifecycle status 'unversioned'.

Kunkel, Matthias [mkunkel]&Heyser, Björn [bheyser]&Neumann, Fred [fneumann], April 26, 2017: Today, we discussed this suggestion and we agree with a clear distinction between the service and its implementation in the different components (e.g. test question pool).

• A status 'unversioned' is currently not necessary as the use of this service is optional. If a pool should not use the lifecycle service, the service would not be activated.
• The service should offer a UI element that can be used by every component to display the current lifecycle status under the item's description (similar to 'Offline' status information in courses).

JourFixe, ILIAS [jourfixe], May 22, 2017: We discussed the suggestion but see the need for a revision of this concept. For a service this implementation is too weak. It does not offer much to a maintainer but a defined vocabulary. Additionally, the relation between such a lifecycle service and the handling for online / offline should be clarified. If we call this "Lifecycle", every single step should be made and clear conditions for the change from one status to another are needed. We ask for a revision of the concept.

Kruse, Fabian [Fabian], 19.06.2017: Would this data feed back into the LOM metadata? I think that it would be helpful to think about how to integrate the two in order not to make it more confusing to the users.

Are the LOM lifecycle statuses in ILIAS ("Draft, Final, Revised, Unavailable") part of the standard? If so, would it be viable to simply use these?

Klees, Richard [rklees], 22.06.2017: Matthias asked me to write down my criticism and suggestions, which I am happy to do. In general, the concept of lifecycle in the current version seems to be too weak to be a service, as it mostly offers a vocabulary and not more. I also wondered, how the currently proposed status for lifecycle would match the Study Programme, that already contains a similar functionality (draft, active, outdated). I also wonder, how "distribute" is a status that is applicable in a general ILIAS context or in other usage scenarios than OPTES.

I would therefore suggest the following:

• Let the service provide a clear status model for the lifecycle, i.e. restrict the allowed transitions between different status. This will allow to attach actions to the transitions that can actually rely on some meaningful model. Without this, you just offer some label a user could set and not an actual lifecycle. The actual lifecycle will then rely on some social agreements and be inscrutable for the system.
• Let the service provide some configuration, where administrators could define a lifecycle model for their instance, i.e. status and allowed transitions. This will make it possible to define actually meaningful lifecycle steps for the installation. Keep in mind, that we (i.e. CaT) could well use draft/review/final/outdated, but "distribute" is a step that just does not exist in our installations. If this was always there I would need to explain my customers what to do with that status (ignore it). A similar problem exists for the Study Programme. I just cannot think of a usecase for "distribute" in the case of an SP. In the future the config could be expanded to cover different lifecycles for different types of objects or even different lifecycles for the same kind of objects.

I hope this helps!

Regards!

Kunkel, Matthias [mkunkel], June 22, 2017: Thank you, Richard, for your input. That is very helpful. I see that the service is very weak at the moment. But we will try to strenghten it. Your idea of a status configuration looks like a good step to make it more powerful.

Concerning the need of a status "distribute": Such a status is important not only for optes but for all installations where content should be shared within and with other installations. Of course, this status could only be available in components that have an export. A component without export should not implement this status. Having such a status would improve some activities in the future:

• Improving the distribution of open educational ressources: Content labeled with status "distribute" and assigned to a Creative Commons licence could be harvested by a cron service automatically and made available in a predefined category for interested users. Additionally, links to such located content could be a send to a registry to make it available easily.
• Container exports (course, group, ...) could be extended by an option that embeds only such course/group objects with status "distribute" and ignores content in the course or group that is only there for content creation processes or managing (in my scenarios often located in a "internal folder" which I have to uncheck when creating the export file).
• Having copyright information and metadata for such an object could be made a requirement to set it's status to "distribute". If they are not available yet, they need been added to change status (this check would be a general setting per installation).

Concerning labels "active" versus "final": here we have even a third option and an additionally related concept: online | offline. In my first concept I wanted to merge both concepts, but there were objections against it, especially when we connect lifecycle and versioning and changing a status from final back to draft would increase the versioning number automatically. I see your "active" very close to "online", right?

Killing, Alexander [alex], 22 June 2017:

• I think Fabian is right in pointing out the relationship with LOM. It will be important to clarify this.
• I am not sure if "Distribute" is a Lifecycle information. The "Distribute" status brings up lots of questions on how distribution will/should work. You are suggesting cron jobs, that may put objects into categories based on this. This is a complete new/separate discussion in my opinion and it interferes with existing concepts like the public area and the permission system.
• I think it would be easier to start with the LOM vocabulary and to try to map this on existing lifecycle settings we have, e.g. in the Study Programme and in the competence management. If this brings up the conclusion that we need an additional "Review" status, this would be ok for me.
• The relation to "Online/Offline" needs to be settled.
• Defining up a status model as Richard suggested is a good idea. I am not sure if the transitions and actions will/should be completely configurable. Already the (de)activation of certain status may not be feasible. If you create a new object and have no "Draft" status, which one should be choosen instead? This might get complex quickly. But defining a first status model would be good to feed the discussion.

Neumann, Fred [fneumann], June23, 2017:
I would not replace the "Online/Offline" switch by a lifecycle status or even create a dependency here. At our university the "Online" checkbox is frequently used as a very practical "RBAC light" solution for teachers who don't have access to the permission screen.

• It can be used for objects that don't need a complex lifecycle, e.g. a booking pool or a poll.
• It's easy to understand: an offline object is only visible to those with write access.
• It allows a quick "emergency exit" without changing any meta data. Imagine something unappropriate is added by a student but should not be deleted, in order to allow further investigation.

As a conclusion I would say the lifecycle status is related to the potential use of of an object, the "online/offline" to the practical use. Both have a justification on their own. But this isn't relevant for a first implementation of the lifecycle in test questions because questions don't haven an online/offline switch.

Workshop at June 23, 2017 with Heyser, Björn [bheyser], Neumann, Fred [fneumann] and Kunkel, Matthias [mkunkel]: In our VC meeting today we discussed the current concept for Introduction of Lifecycle Service and the comments made in and since (see above) the last Jour Fixe. We came to the following conclusions:

1. We see the need to strengthen both suggested services (see Introduction of Versioning Service) to become general services in ILIAS and to be used by other components in a reasonable way.
2. We agree that transformations need to be defined clearly and that a status model would be helpful.
3. We see the need to deactivate 'some' statuses per setting when they won't be used on an installation and might confuse users. But we think that at least 'draft' and 'final' should always be available. Additionally, it depends also from the component if all statuses are implemented or not.
4. We agree that the used labels for the different statuses should follow the LOM vocabulary when possible (already given for 'draft' and 'final', while 'review' has another meaning in our suggestion and 'unavailable' is different to assign in the context of an LMS).
5. We still see a need for a status 'distribute' to clearly distinguish between a ressource that is 'just final' (in the meaning of 'can be used by my learners') and 'can also be distributed' to other users because it has been assigned with metadata about authorship, keywords, copyright a.s.o.
6. In addition we see the need of a status 'review' in the meaning of 'this ressource needs to be reviewed before being published'. But due to the existing LOM status we would like to change this label to 'approval' or 'to approve'. This label shoud be used in scenarios where several roles are involved in the content creation process, e.g. subject matter experts and didactic experts.
7. Form our point of view, the necessary distinction between lifecycle and online/offline has been clearly been explained by Fred in his comment above. So we do not merge both concepts for the time being.

Therefore, the suggestions to introduce general services for 'Lifecycle' and for 'Versioning' still needs more conceptual work that cannot be done it the remaining time until 'Coding completed' at August 28. So we postpone this feature request and suggest it for 5.4. Metadata has been modified accordingly. For 5.3 we will try to implement a light version just for test questions, see Lifecycle and Versioning Support in Test Questions.

Kunkel, Matthias [mkunkel], 30 MAY 2018 : There is now a concurrent feature request that does not ask for a general service but just follows a so-called "information-only approach and want lifecycle status to be mere metadata without any business logic", see Lifecycle Metadata for Test Questions.

8 Implementation

{The maintainer has to give a description of the final implementation and add screenshots if possible.}

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.

---