** Using WeBWorK **

I seem to recall that there is a way to specify that an answer always be first with the old PGchoicemacros.pl approach for creating pop up answers.  I don't remember what it is.  I don't really care either since newly written questions shouldn't use that deprecated approach.  You should use parserPopUp.pl instead.  The DropDown method from that macro will automatically add a "?" that is always first.  You also should use PGML instead of BEGIN_TEXT/END_TEXT.  Here is the problem rewritten to use the modern approaches that should be utilized with newly written problems.

DOCUMENT();

loadMacros('PGstandard.pl', 'PGML.pl', 'parserPopUp.pl', 'PGcourse.pl');

$showPartialCorrectAnswers = 0;

# List of all question and answer pairs.
@questions = (
    [ 'Collecting data',                                                       'Descriptive Statistics' ],
    [ 'Interpreting data',                                                     'Inferential Statistics' ],
    [ 'Summarizing data',                                                      'Descriptive Statistics' ],
    [ 'Describing the characteristics of a dataset',                           'Descriptive Statistics' ],
    [ 'Organizing a dataset',                                                  'Descriptive Statistics' ],
    [ 'Finding the mode of data',                                              'Descriptive Statistics' ],
    [ 'Finding the mean of data',                                              'Descriptive Statistics' ],
    [ 'Extrapolation',                                                         'Inferential Statistics' ],
    [ 'Inferring something about a population based on a sample',              'Inferential Statistics' ],
    [ 'Applying results about a part of a population to the whole population', 'Inferential Statistics' ],
);

# Choose four questions and answer pairs at random.
@chosen = random_subset(4, @questions);

# Construct dropdowns for each answer.
@answers = map {
    DropDown([ [ 'Inferential Statistics', 'Descriptive Statistics' ] ],
        $_->[1])
} @chosen;

BEGIN_PGML
For each activity, select whether it is a type of inferential or descriptive
statistics. To prepare for this question, read Chapter 1 of the text.

Note that you only have a limited number of tries for this question, meaning you
can select "Submit Answers" only so many times before WeBWorK stops letting you
change your answers.

Also note that the answers are listed in random order to begin with.

[#
	[. 1. [$chosen[0][0]]: .] [. [_]{$answers[0]} .]*

	[. 2. [$chosen[1][0]]: .] [. [_]{$answers[1]} .]*

	[. 3. [$chosen[2][0]]: .] [. [_]{$answers[2]} .]*

	[. 4. [$chosen[3][0]]: .] [. [_]{$answers[3]} .]
#]*{ center => 0, align => 'll' }
END_PGML

COMMENT('Questions selected randomly from a larger set. '
        . 'See source for full question list.');

ENDDOCUMENT();

I think I have identified the source of this issue. First, I tried this problem in 2.19, and I saw the same behavior you see. Then I tried it in a 2.17 server I have access to, and the options are presented in a consistent order with the '?' coming first. So you might think this is about some change we made between 2.17 and 2.19.

But then I noticed the options are not just in a random order, they are in a different random order every time the page loads. This is a clue that somewhere along the way, the options are hash keys (or hash values). And with every run, the hash is ordered differently. Well, perl only started randomizing hash order with perl 5.18. So I looked at the 2.17 server I have, and sure enough its perl version is 5.16.

So I *think* that when you had the behavior that you liked before, it had to do with your WeBWorK server using an old version of perl. If you can rule that out, then maybe something else is the explanation. But that would be my working hypothesis.

Now, can we "fix" this anyway by editing the code in PGchoicemacros.pl? I am about to open a pull request to the pg repository on GitHub with something that, in testing, works to straighten out the order of the options. It will need a careful review as this will be an edit to something that could affect more than just this type of exercise.

It is worth noting that the unwanted change of behavior here comes from perl evolving to 5.18 back in 2013, and not from webwork2/pg evolving. This has probably gone unnoticed because:

• people have a WW server with an old version of perl
• developers who might have otherwise noticed aren't writing/using problems with PGchoicemacros.pl
• people noticed, but just accepted the weird behavior as a quirk of an old method (like I did this past spring)