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

Plan for question versioning #9832

Open
nwalters512 opened this issue May 8, 2024 · 0 comments
Open

Plan for question versioning #9832

nwalters512 opened this issue May 8, 2024 · 0 comments

Comments

@nwalters512
Copy link
Contributor

Problem

  • 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.

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

No branches or pull requests

1 participant