Itamar Tzadok

Thank you. That's a more resonable response which properly discloses the two concerns underlying the way this change is proposed:

• The complexity of the UI.
• Code freeze in 9 days.

As a developer I can hack anything in Moodle. As an administrator I would try to avoid hacking as much as possible. As an instructional designer/instructor I want to be able to implement my instructional strategies, especially those I've already used successfully (other learned opinions in the this thread notwithstanding). In what I do, I'm wearing all hats.

I don't object the new strategy. I object losing the current one. If it is integrated as is, it will be practically impossible to get you to do or approve further core adjustments that will allow the current strategy.

At minimum I need a backend config setting at the quiz level. I can then write a local plugin that will provide the UI for setting it on/off. This way you do not overload the current UI, and presumably can still make it in time for the code freeze, and allow me and others to continue using the quiz according to our preferred instructional strategies.

In one organization I'm involved in, one of our fundamental principles is that those who do the work are the ones who decide the details of how the work is done. Very few people would volunteer to be micromanaged.

According to this principle, since the assistant to the CEO is doing the work of making the coffee, he will decide what coffee the CEO will drink, regardless of what coffee the CEO prefers.

Surely that's not what you meant.

How to use random questions in a quiz is an instructional strategy. The decision is typically made by the instructional designer or by the instructor if there is no designated instructional designer. The decision is not made by the Moodle/Sakai/D2L etc. developer, unless the developer is also an instructional designer and she is making the decision while wearing the ID hat.

Either way, that's not the case here. Effective Moodle should not impose any instructional strategy unless there is really no way to implement differently. In this feature it is clearly not necessary to impose the "proposed" strategy. Consider Tim's own example:

The main problem we want to solve is this, suppose you have a question category containing 10 questions, and you build a quiz that picks 5 random questions from that category. On the student's first attempt, they will get 5 questions from that category, and they are guaranteed to all be different....  Well, with the proposed change, in the second attempt, they would be guaranteed to get the other five questions.

And what happens in the third attempt? Clearly it must fall back to true random selection of 5 questions where all questions have been seen. So, the module can still do a random selection with reptition. It is just that Tim wants to completely prevent it while there are unseen questions. There is a switch there, but it will be hardcoded to behave in one particular way, rather than allowing the instructor/instructional designer to turn it on or off.

Well,

• This change is neither subtle nor proposed. Insofar as it replaces current functionality, it is a major change and imposed.
• No matter how many votes MDL-6340 has (and 9 is not that many) it doesn't tell you how many vetos there could have been if Moodle Tracker offered that option.
• 3 people in this thread in favour of this change is quite insignificant. Note, that no one is likely to object to this behavior as an option.
• You also can't quantify how many people, in this forum, over the years, have *not* complained about random questions repeating before all possibilities have been used up. Those who are happy with a certain thing don't tend to make a fuss about it.
• Please note the type of MDL-6340. It is supposed to be an *Improvement*, not a bug.  The fact that another developer might have confused it with a bug and tried to "fix" it (if that's indeed the case), instead of enhance it, is not a justification for imposing such a "fix".

This is a major change in core functionality of one of the most important core modules in Moodle. Since you have the power to push such a change the burden of proof is on you and you should be much more sensitive to objections than to support. There are probably far more people using this module and this functionality than people participating in all of Moodle forums and in the Moodle tracker together. You won't hear from them until their instructional strategies break after upgrade. Then you might see MDL-5234X Unforce unique/unseen questions in quiz retakes, with at least 9 votes and 13 watchers. But given your current attitude, you are likely to dismiss such MDL-5234X and its 9 votes as not having sufficient support.

I can appreciate that adding this feature as an option requires more work and that you, just like everyone else, is very busy. I suspect that at the end of the day this is the only real reason for not adding the feature as an option. With such core functionality, this is not a good reason at all.

The proposed new behaviour is better for most people, most of the time, I think.

The quiz module is probably the most important module in Moodle. You practically control what most people will be able to do with it most of the time. With power comes great responsibility... This response of yours is quite unfortunate.

I think that this should be optional and not necessarily the default. Otherwise it may deflate the important learning strategy of repetition. I have always used only random questions in quizzes with unlimited attempts. And the final used the same question bank. This encourages students to do as many attempts as they possibly can in order to cover all possible questions for the final. And since they are not guaranteed to cover all questions in a minimum number of attempts, there is repetition which can help enforcing the knowledge base.