I noticed that Library Beta (v2) problem components don’t sync problem settings (Scoring, Show Answer, Show Reset Options, Time Between Attempt) from library → course(s) anymore and the course is the authority now for these settings.
The change occurred here.
A related discussion has been taking place at feat: allow library linked problem edits by asadali145 · Pull Request #38901 · openedx/openedx-platform · GitHub
It would be very helpful if you could give some use case examples for why you want a library block’s policy to override the course policy.
We’re starting to put most of our problems for a course in a Library Beta (v2) library and then we pull those components into a single course. That single course can become 20+ courses for a given semester where we create many course reruns from the original course.
Should a content developer want to alter that libraries problem’s settings, they have been editing the settings like Score / Attempts, Show answer, Show reset option mainly. Typically, they would then pull those changes down from the library → 20+ courses if a configuration change needed to occur.
Also, that same question could be used in different units of the course so making one problem settings change at the library and pull the changes down to those additional unit locations in the course would make configuring the course easier for the course developer.
openedx-upstream-sync-ext (new Django plugin)
I created a Django plugin GitHub - CUCWD/openedx-upstream-sync-ext: Extends Open edX upstream synchronization to support configurable customizable fields, including synchronizing Library component values such as problem scores. · GitHub that would toggle FEATURES['ENABLE_UPSTREAM_SYNC_FOR_CUSTOMIZABLE_FIELDS'] whether an platform instance would want to either sync problem settings from the library → course(s) or not.
This plugin also creates the following endpoint exposing this feature setting to the frontend-app-authoring.
http://studio/api/contentstore/v2/config/
Example when FEATURES['ENABLE_UPSTREAM_SYNC_FOR_CUSTOMIZABLE_FIELDS'] = True
{
"enable_upstream_sync_for_customizable_fields": true
}
frontend-app-authoring
I kept what Jill had here feat: hide some settings fields when editing a library problem [FC-0076] by pomegranited · Pull Request #1601 · openedx/frontend-app-authoring · GitHub and added this additional conditional value to show library problem settings based on this Django feature setting above making the CMS the source of truth of whether or not to conditionally show these additional problem settings within the library.
@Zachary_Trabookis While it seems like we need to support your use case, I personally don’t think this makes a lot of sense as a toggle at the platform level. I think it would make more sense to enable it for everyone (if it’s widely useful), or allow it to be configured either per-library or per-course.
I understand that, but I guess what I don’t understand is why those things should be different for each question. When you take an in-person course, the prof usually sets a policy like “exams are open book”, “homework loses 10% for each day it’s handed in late”, “wrong questions can be corrected and handed in later for half marks”, etc., and those policies are stated on the syllabus and apply to the whole course.
So I guess the thinking is, if you have a problem bank and you want to use some of its problems in your course, you’d generally want to ensure that your course policies like “allow unlimited attempts but never show answer” are applied consistently to those problems that you’re pulling in.
Or another way of saying it is: isn’t it a lot of work to specify these 3 settings uniquely on every problem, rather than just having some broad categories of problems/usages (“homework”, “exam”, etc.) that automatically specify these policies for all the questions used in that way? Do they really vary on a per-problem basis? (And if so, isn’t that confusing for learners when you can sometimes try again but other times not?)
I like the idea of making these problem settings widely available and configurable at either the library or course level, rather than enforcing them as platform-wide settings. This approach gives course authors the flexibility to choose the configuration that best supports the instructional goals and assessment strategy for the content they create.
It can be time-consuming initially. However, our workflow typically involves cloning an existing problem in the library and then updating only the question stem and answer choices, since most of our content uses multiple-choice questions. Cloning preserves all of the problem settings, so we rarely need to reconfigure them when creating new problems.
It would be beneficial to define broad assessment categories (for example, Homework, Practice, or Exam) that automatically apply a predefined set of problem settings to all questions within that category, rather than requiring authors to configure each individual problem component separately.
In practice, the settings don’t usually vary on an individual problem basis. Instead, they vary by the assignment type and/or where the assessment appears within the course.
We primarily use multiple-choice, multi-select, and dropdown problems. During learning activities, such as lesson or subsection activities, learners are given unlimited attempts so they can learn from practice and reinforce the material. For higher-stakes assessments, such as section assessments and the course post-test, we limit learners to a single attempt to evaluate what they have learned after completing the instructional content.
Because these policies are applied consistently within each assignment type, learners quickly understand the expectations and generally do not find the differing attempt limits confusing.
Our course developers need the ability to configure problem settings once (for example, at the library problem level) and then propagate those settings across the 20+ course reruns that reference the same content. This significantly reduces maintenance effort and helps ensure consistency across course offerings.
That said, changes to problem settings after a course has been released are relatively uncommon. Post-release updates are typically limited to correcting or improving the problem content itself, such as the question stem or answer options, rather than modifying the assessment behavior. We generally avoid changing problem settings once learners have begun a course, as doing so can create an inconsistent learner experience. Most problem setting changes occur during course development, with only occasional maintenance after a release when necessary.
Below is our typical grading and problem configuration for each assignment type.
The Course Pre-Test measures a learner’s knowledge before they begin any course material. It is intended as a diagnostic assessment, so it does not contribute to the final grade.
Each course contains multiple instructional sections. The Section Pre-Assessment evaluates a learner’s existing knowledge before they begin a section. Like the Course Pre-Test, it is diagnostic and does not affect the final grade.
These activities are embedded within individual lessons and are completed after learners finish the instructional content, such as videos or reading materials. They reinforce key concepts while contributing a small percentage to the overall course grade. Learners have unlimited attempts, allowing them to practice and master the material at their own pace. Each course section typically contains 2–8 lesson subsections, with one embedded activity per lesson.
After completing a group of lessons, learners take a Section Assessment to demonstrate their understanding of that topic. Because these assessments are intended to measure mastery, they contribute a larger portion of the final grade and limit learners to a single attempt.
The Course Post-Test serves as the final assessment of the learner’s knowledge across all course content. It carries significant weight in the overall grade and is limited to a single attempt to accurately evaluate mastery of the material.
Thanks @Zachary_Trabookis, that’s super helpful and makes a lot of sense.
It actually sounds like the intention of this more limited configuration approach matches your use case:
Instead, they vary by the assignment type and/or where the assessment appears within the course.
(that sounds a lot like “the course [section/subsection] should override the library policy” to me)
But clearly in practice, it’s not working that way, so it sounds like we need to make some changes. I’ll let the product folks decide which way forward makes the most sense though.
