In the past, a Git repo contained assignments and tasks, including release and submission deadlines. However, because more than one course might want to use tasks from a pool of existing tasks, it makes more sense to use the Git repos as a simple source of tasks that are maintained using Git.
So for the future, any source repo used for tasks should contain:
One or more tasks. A task is contained within some subfolder in the repo. Structuring the folder hierarchy pointing to tasks is up to the creator. See the specification for how tasks are defined below.
A file config.json which contains metadata on the entire repo as below. In particular, it lists all paths pointing to tasks.
{
"title": "Introduction to Python",
"description": "Tasks originally designed for first-semester informatics students",
"university": "Universität Zürich",
"tasks": [
"/loops/range_using_for",
"/loops/range_using_while",
"/ifelse/fizzbuzz"
]
}
Functionality for creating courses in ACCESS
When creating a new course in the ACCESS UI, the admin should have the option to choose one or more Git repos as "sources" for tasks.
The admin can then create an "empty course" and manually populate it by:
creating assignments, giving them a name, description, slug, cover image, release date and deadline
selecting tasks from all source repos to be part of each assignment
selecting a task for more than one assignment should cause no technical problems
If an assignment does not have a release date yet, it should be hidden from students
For each assignment, there should be a setting in the UI for releasing solutions:
( ) Publish solutions on assignment release
( ) Publish solutions if at least one submission has been made
( ) Publish solutions on submission deadline
(x) Do not release solutions (default)
There should also be a feature to "copy" an existing course. This action should create a new course with the same assignments and tasks, but with all release dates removed.
Automatic updates to tasks
If a task is updated in the repo, it should automatically be updated in all courses on ACCESS where the task is used.
Open Questions:
Important: should the old mechanism (full control of a course content, deadlines, etc. via config files) be kept or replaced entirely?
Should it be possible to change the maxAttempts and maxPoints values in the UI? Yes -> Maybe some course organizers want to give more or fewer of each for their students? Should it be possible to override them in the UI making them immune to updates from the repo? No -> Would be easier to implement and if they care that much about the points, they can normalize them later?
Here we talk of the "admin" creating courses. We need to think about how repos and courses should be managed in the future:
What roles should we even have? Admin, author ("some role that can create new courses"), TA, student?
Who can add new repos as task sources? Only admins? Authors, too?
Who can create new courses? Who can publish new courses for everyone to see?
Sanity check for repos
Check if all required fields exist in repo and task config.json files and conform to expected types and structure
Check if all task paths are valid and that the tasks exist
If a template is specified, check that there are no duplicate assignment slugs or duplicate task slugs within the same assignment
In the past, a Git repo contained assignments and tasks, including release and submission deadlines. However, because more than one course might want to use tasks from a pool of existing tasks, it makes more sense to use the Git repos as a simple source of tasks that are maintained using Git.
So for the future, any source repo used for tasks should contain:
Functionality for creating courses in ACCESS
Automatic updates to tasks
If a task is updated in the repo, it should automatically be updated in all courses on ACCESS where the task is used.
Open Questions:
Sanity check for repos