-
Notifications
You must be signed in to change notification settings - Fork 18
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
Comments
Hey @bmtcril |
@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? |
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. |
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. |
That's basically how we've been operating, so that makes sense to me. 👍 |
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:
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.
The text was updated successfully, but these errors were encountered: