You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A course could delete a shared question. We could block this, but we actually want to allow sharing courses to restructure their content at will.
A course could change the QID of a shared question. We could also block this, but again, we want to allow instructors to do this.
A course could break a shared question.
A course could vandalize a shared question.
Proposed solution
We introduce versioning for questions. Every time a question's files are modified, we'd create a new timestamped version. We'd also generate a new chunk and maintain a pointer to this chunk associated with the version. We'll do the same for elements/clientFilesCourse/, serverFilesCourse/, etc.
By default, when a course references a shared question for the first time, we'll maintain a pointer to the latest question version at that moment in time (or maybe just keep the timestamp). Whenever that question is used, we'll use the versioned chunks (for both questions and all other course files) corresponding to that timestamp. So, if we've locked a question to Jan 1, 2025, we'll always use all chunks with a date <= Jan 1, 2025.
We feel that this behavior is a reasonable default. We don't ever want instructors to be in a situation where they're in the middle of an exam and a question unexpectedly breaks or changes behavior. This works similarly to how npm and other package managers work, where by default they lock newly-added dependencies to a given version.
However, we acknowledge that some workflows might not benefit from pinning. For instance, there are cases where instructors are working together on a shared bank of questions that are used in their own courses. In an implicitly high-trust environment like this, they might want to opt out of pinning to ensure that they'll always get the latest changes from the shared question bank. So, we'll allow courses to disable pinning for specific courses from which they are consuming questions.
We'll create a new course-level page where instructors can view every shared question that their course is using. We'll show the QID (with sharing name), the pinned date, the latest date, and ideally allow the user to view either question authorship or course owner information. Maybe also information like the institution, and other information that could be useful to instructors when managing the shared questions they're using. This page will also contain actions/settings, e.g. "re-pin this question to latest version" and the ability to configure pinning behavior for specific producing courses.
Ideally we'd want to support previewing questions at specific timestamps: either the pinned version, or the latest version.
Ideally, we'd also give users the ability to roll back to a previously-pinned version. This does not necessarily have to include any version that's ever been pinned; one could support, say, only the last 2 pinned versions.
In the long term, to help instructors manage their shared questions and make decisions about when to re-pin to the latest version, we can build support for a CHANGELOG.md file in all chunk directories. This can be a plaintext file with arbitrary formatting, but we'd encourage instructors to add entries based on date. We can then show this in the "update question version" flow.
We're thinking that this will be like npm and other package managers. There will be those that want to maintain very high-quality questions and make them easy for others to consume and keep up to date with; these are the type of folks that would maintain a CHANGELOG.md (and also README.md, authorship information, etc). There are also those who will want to just throw something out into the world without much ceremony. Our hope is that community norms/pressure will result in folks taking the time to maintain changelogs and such.
The text was updated successfully, but these errors were encountered:
Problem
Proposed solution
We introduce versioning for questions. Every time a question's files are modified, we'd create a new timestamped version. We'd also generate a new chunk and maintain a pointer to this chunk associated with the version. We'll do the same for
elements/
clientFilesCourse/
,serverFilesCourse/
, etc.By default, when a course references a shared question for the first time, we'll maintain a pointer to the latest question version at that moment in time (or maybe just keep the timestamp). Whenever that question is used, we'll use the versioned chunks (for both questions and all other course files) corresponding to that timestamp. So, if we've locked a question to Jan 1, 2025, we'll always use all chunks with a date
<= Jan 1, 2025
.We feel that this behavior is a reasonable default. We don't ever want instructors to be in a situation where they're in the middle of an exam and a question unexpectedly breaks or changes behavior. This works similarly to how npm and other package managers work, where by default they lock newly-added dependencies to a given version.
However, we acknowledge that some workflows might not benefit from pinning. For instance, there are cases where instructors are working together on a shared bank of questions that are used in their own courses. In an implicitly high-trust environment like this, they might want to opt out of pinning to ensure that they'll always get the latest changes from the shared question bank. So, we'll allow courses to disable pinning for specific courses from which they are consuming questions.
We'll create a new course-level page where instructors can view every shared question that their course is using. We'll show the QID (with sharing name), the pinned date, the latest date, and ideally allow the user to view either question authorship or course owner information. Maybe also information like the institution, and other information that could be useful to instructors when managing the shared questions they're using. This page will also contain actions/settings, e.g. "re-pin this question to latest version" and the ability to configure pinning behavior for specific producing courses.
Ideally we'd want to support previewing questions at specific timestamps: either the pinned version, or the latest version.
Ideally, we'd also give users the ability to roll back to a previously-pinned version. This does not necessarily have to include any version that's ever been pinned; one could support, say, only the last 2 pinned versions.
In the long term, to help instructors manage their shared questions and make decisions about when to re-pin to the latest version, we can build support for a
CHANGELOG.md
file in all chunk directories. This can be a plaintext file with arbitrary formatting, but we'd encourage instructors to add entries based on date. We can then show this in the "update question version" flow.We're thinking that this will be like npm and other package managers. There will be those that want to maintain very high-quality questions and make them easy for others to consume and keep up to date with; these are the type of folks that would maintain a
CHANGELOG.md
(and alsoREADME.md
, authorship information, etc). There are also those who will want to just throw something out into the world without much ceremony. Our hope is that community norms/pressure will result in folks taking the time to maintain changelogs and such.The text was updated successfully, but these errors were encountered: