Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add variant / seed to problem_check events #369

Open
bmtcril opened this issue Nov 8, 2023 · 7 comments
Open

Add variant / seed to problem_check events #369

bmtcril opened this issue Nov 8, 2023 · 7 comments

Comments

@bmtcril
Copy link
Contributor

bmtcril commented Nov 8, 2023

See #365 for more details, but the issue is that advanced problems can be randomized as documented here. Those seeds can cause there to be different correct answers for the same problem, making it difficult to understand which values are "correct". We may want to add the variant / seed of the problem to the transforms.

Here is a sample problem to test with:

<problem>

<script type="loncapa/python">

def test_add(expect, ans):
    try:
        a1=int(ans[0])
        a2=int(ans[1])
        return (a1+a2) == int(expect)
    except ValueError:
        return False

target_sum = random.randint(0, 100)
</script>

<p>Enter two integers that sum to $target_sum: </p>
<customresponse cfn="test_add" expect="$target_sum">
  <textline size="40" label="Integer #1"/><br/>
  <textline size="40" label="Integer #2"/>
</customresponse>

</problem>

To use this, in Studio: Add Problem -> Advanced tab -> Blank Advanced Problem. Paste the above. Then you can set the randomization value in the settings to "Always". You should be able to reset the problem and get a different value each time. This does get passed in the tracking event as "variant", but I wasn't able to find an xAPI concept for this information so we'd probably have to create one.

@rgraber
Copy link

rgraber commented Nov 16, 2023

Hey @bmtcril
What do we think is the impact of this work? Is there something that makes it particularly high priority?

@e0d
Copy link
Contributor

e0d commented Nov 16, 2023

@rgraber this summarizes the purpose of the work, #365 (comment)

My understanding is that 2U is not using event-routing-backends. Is there a reason this is seen as a risk on your end?

@rgraber
Copy link

rgraber commented Nov 16, 2023

No, but since we technically own this repo we were wondering how we should prioritize this work. It doesn't seem terribly high priority so may end up on our backlog.

@e0d
Copy link
Contributor

e0d commented Nov 16, 2023

I don't think it makes sense of 2U to own this as you don't use it and everyone focused on building and migrating to Aspects does.

In fact, I thought we had said that @ziafazal and edly would be the owners of this repos some months back.

Either way, given current priories and incentives, I think we should transfer ownership of this repo from 2U to edly and Axim represented by Zia and @bmtcril .

If there are no objections, we can make that effective immediately.

@ziafazal
Copy link
Contributor

I don't think it makes sense of 2U to own this as you don't use it and everyone focused on building and migrating to Aspects does.

In fact, I thought we had said that @ziafazal and edly would be the owners of this repos some months back.

Either way, given current priories and incentives, I think we should transfer ownership of this repo from 2U to edly and Axim represented by Zia and @bmtcril .

If there are no objections, we can make that effective immediately.

I have no objections to it.

@bmtcril
Copy link
Contributor Author

bmtcril commented Nov 17, 2023

That's basically how we've been operating, so that makes sense to me. 👍

@e0d
Copy link
Contributor

e0d commented Nov 20, 2023

@rgraber I assume the message above

@rgraber rgraber removed this from Arch-BOM 6 hours ago

means you are happy with the proposal. @bmtcril and @ziafazal will maintain going forward. Let me know if I've gotten that right.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants