Show Advanced KnowledgeHide Advanced Knowledge

Versioning Questions

1 Initial Problem

Using test item statistics and reviews requires a method, to distinct versions of a question.

2 Conceptual Summary

I suggest to create a history log for each question, containing the following data:

• Who (User who changes something)
• What (Which action, e.g. Copying, Inserting it into a test, changing the text/points etc.)
• When
• Why (Optional comment/explanation for each change)

Versioning the questions and keeping a consistent state e.g. in tests will require a new ID-system. For a distinctive identification of each item, two ID's are necessary:

• a fixed ID to identify it systemwide
• an incremental ID for each version

For each changed version should be stored:

• necessary data for a preview
• statistics

Miscellaneous

• Item statistics may be consolidated based on the corresponding version in the statistics tab.
• The versioning history may be available in a new tab for each question.
• A new system-ID may only be created, when the item is copied.
• Versions may not be part of exports. (?)

Things I'm not sure about how to handle them best (see below):

• A test may no longer copy a question per default, but reference it (with System ID and version ID).
• Changing a question inside the test-object may result in either a copy or an update of the original source.
• A test notifies the user about changed items, but keeps using the old version until the user approves an update.

• How will competing versions, edited in a test and pushed back to the source question pool effect versioning?
• How to handle adjusting after a test?

The two-ID-system could be maintained in those cases. But this may lead to lots of "deprecated"-notifications and "manuel race conditions", if different examiners share a pool. But preventing this could result in a complicated implementation with more IDs or conditions.

Possible suggestions to reduce the problem:

• The two-ID-system is regardlessly maintained. Changing the item inside the test-object will change the source.
• Changing the item inside the test-object always results in a copy which is not necessarily part of a pool (but optional).
• When changing the item inside the test-object the user can choose whether it should be a copy or change the source.
• If a question originates from a pool, changes have to be done in the pool.

3 User Interface Modifications

3.1 List of Affected Views

{Please list all views (screens) of ILIAS that should be modified, newly introduced or removed.}

3.2 User Interface Details

{For each of these views please list all user interface elements that should be modified, added or removed. Please provide the textual appearance of the UI elements and their interactive behaviour.}

3.3 New User Interface Concepts

{If the proposal introduces any completely new user interface elements, please provide a link to separate feature wiki entries for each of them according to the kitchen sink template.}

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: Jobst, Christoph [cjobst] Uni Halle/Uni Leipzig
• Maintainer: Heyser, Björn [bheyser]
• 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.

• Universität Leipzig

7 Discussion

Kunkel, Matthias [mkunkel], Dec 02, 2016: I changed this page to the new page template to prepare it for a discussion in the Jour Fixe.

Kunkel, Matthias [mkunkel], Dec 02, 2016: We at optes have similar requirements and ideas and fully support your request. But we also need to think of the reuse of questions on other installations because dissemination of questions is one job we have to do in our project. Therefore, we need a unique ID for each question. My suggestion would be a composition of NIC-ID+Question-ID+Version-ID. This would allow to identify any question on every ILIAS installation and to support feedback and error reporting to the original author of the question - which is one of our requirements.

What is still a bit unclear for us is the criteria when a change in a question is just a new version or when it makes a new question. We do not want that every editing step in a question counts up the version number. Therefore, we need to distinct between phases where question editing has no effect on the version number and a moment when a new version is published and the version number is set +1.

This is why we would like to introduce a lifecycle for each question (and for other content in ILIAS as well - which means it will become a general service and not a property of the question pool object). I will describe this on a dedicated wiki page. But the idea would be to assign a defined lifecycle status for every question - if this feature is enabled. And to allow editing onl y in selected status. We suggest the following status:

• Draft - question is created and currently edited but not finished yet. Version number starts with 0. Editing has no effect on the version number.
• Review - Editing is finished and question can be reviewed or is currently reviewed. No effect on the version number, too.
• Final - Question is ready to be used in tests. Version number is set +1. No changes allowed in this status. To edit question, status needs to be set to Draft again.
• Distribute - Question is ready to be distributed (metadata and copyright information added). Version number is kept. No changes allowed.
• Outdated - Question should not be used in (new) tests and needs to be revised. Version number is kept. No changes allowed.

More about these ideas on the related wiki pages, see Improved test question sharing (not finished yet).

Kunkel, Matthias [mkunkel], FEB 28, 2017: I split up this feature request to several pages, see: Improved test question sharing (page creation still ongoing ...). This is necessary for three reasons:

• Versioning and lifecyle support should not be restricted to test questions only. It should be possible for other components to implement them as well. Therefore, we need general concepts for both activities and introduce related services. And this requires dedicated FW pages, see: Introduction of Lifecycle Service and Introduction of Versioning Service
• Splitting up the request will not stop implementation if one aspect of the original request is rejected by Jour Fixe. Other accepted feature parts could be realised nevertheless.
• And last but not least: without splitting up the current request we would not be able to discuss and decide about it in the given time slots of the Jour Fixe agenda (max. 30').

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}.