Arcade Configuration (Draft)

Back to Arcade

Under construction.

Student Information

Information about the students present in the database and their course unit choices (referred to as name list information) needs to be setup and maintained. The process to do this transforms information from Campus Solutions and combines it with locally added information.

Initial Setup

Creating the initial version of student information is a two stage process. The first stage uses the script:

db/JTL/create-initial-name-list

This transforms information from Campus Solutions into a form that can be used by the Arcade system. To generate the name list used within Arcade use the command:

name-list-update

Local Information (Draft)

To customise the process ... TBC

Automated(ish) Maintenance

As with the initial setup of student information, the automated maintenance of information is a two stage process. The first stage uses the script:

db/JTL/get-students-from-compost

Again, this only transforms the Campus Solutions information into a form that can be used by the Arcade system. To generate the name list used within Arcade use the command:

name-list-update

When run, this command displays the differences between the current name list and the updated one and there is then a chance up confirm (copy) or abort the update.

Local Information (Draft)

The student information obtained from Campus Solutions can be modified by altering the db/JTL/get-students-from-compost script. Typical changes are:

• deleting course units
• rwa students

Manual Name Maintenance (Draft)

To manually modify a name list entry. Copy current name list, make edit in copy then update active list by name-list-edit -i edited-file Delete edited file as subsequent automated updates will not be applied to it. This process is only appropriate for locally created information, e.g. username.

Data Location (Draft)

Student information is stored in the directory db/STUDENT_DATABASE. The main files are:

students

Transformed information from Campus Solutions combined with local information that gives the name, year and degree programme for each registration id.

courses

Campus Solutions information transformed and combined with local information that gives the level and short code of course units taken by a registation id; the format is one unit per line, so the same registation id may occur on multiple lines.

tutor-list

c.

name-list

Information about a student used within Arcade. This includes their Arcade id, name, registation id, degree programme and registered course units.

The name-list is created/updated using the command name-list-update which uses information from the students and courses files. Previous versions of these files may be present with a date stamp appended to the name.

There are also some supplementary files that may appear in this directory, these include

differences

The results of a comparison between the current name-list and that which results from an update using the current information in students and courses files.

problems

Problems detected whist running name-list-update.

Controlling Mark Predictions (Draft)

Arcade predicts values for marks that are currently unknown. These marks occur when a student has not submitted work, a student has submitted work but not yet had it marked and when a tutor has not yet returned a mark. By using various flag files, it is possible to control how Arcade calculates the preditions for these unknown marks.

Mark Predictions for Unsubmitted Work

Normally Arcade will predict a non-zero mark for work that a student has not yet submitted. This mark will have an Estimated (E) flag appended. Initially a prediction of 70% is used. Once a student has submitted some work for a course unit, the average of the previous work submitted to the course unit is used.

This behaviour can be altered by creating the flag file db/CONFIGURATION/ZERO-PREDICTION. When this file is present, Arcade will predict a mark of zero for any piece of work that the student has not submitted. This file also effects unknown tutor marks, see below.

Mark Predictions for Submitted but Unmarked Work

When a student submits a piece of work that has not yet been marked, Arcade will normally predict a non-zero mark for the piece of work. Initially this prediction is 70%; once the student has some marks for the course unit, the prediction will be the average of the existing marks for the course unit.

For exercises where the student electronically submits their work, the predicted mark will have either a Demonstration Required (D) or Offline Marking Required (H) flag appended. Arcade assumes that any exercise configured with a CS attribute is electronically submitted. The type of flag appended is controlled for a course unit or an individual exercise by flag file(s). If the file ~/ARCHIVE/year/courseUnit/DEMO-WANTED exists the Demonstration Required flag is used for all exercises of the course unit; whereas, the existance of the file ~/ARCHIVE/year/courseUnit/exercise/DEMO-WANTED will set the Demonstration Required flag only for a single exercise.

When face-to-face marking is used (Demonstration Required) and it is felt that students have had sufficient time to get their work marked, it is possible change predicted marks to zero. As with the demonstration required configuration, this can be done for individual exercises or all of the exercises of a course unit. The existance of the file ~/ARCHIVE/year/courseUnit/DEMO-MISSED will make the predicted mark for all unmarked work for all exercises of the course unit zero; whereas, the existance of the file ~/ARCHIVE/year/courseUnit/exercise/DEMO-MISSED will zero the predicted mark only for a single exercise. Besides setting the predicted mark to zero, this configuration also changes the flag appended to the mark from a Demonstration Required one to a Demonstration Missed (d) one. Although the demonstration missed flag is set, it does not prevent the student from getting their work marked.

Mark Predictions for Work Submitted Late (Draft)

The mark for any work submitted late without an excuse will have a Late (L) flag appended. The Late flag will have its standard effect, see ?. For exercises where the student submits their work electronically and the work has not yet been marked, D or H (see ?).

It is also possible to configure a date after which it is considered too late for any work submitted to be marked. This is done using the configuration file ~/ARCHIVE/year/ARCHIVE-CLOSED.The contents of this file give the cut off date after which submitted work will not be marked. Once this date is reached, any work submitted will automatically have the Demonstration Missed (d) flag appended and.

Mark Predictions for Unonown Tutor Marks (Draft)

Background Processes (Draft)

Setup/Change

To setup/change the background processs that should be run use the command:

This opens the control file for the current user and database in an editor. The first time that a user runs the command in a database, a control file with a default set of processes to be run will be created. A comment at the head of the file expalins the format of the file.

Creating the control file only defines what processes should be run, it does not cause them to the run. To actually run the configured processes, use the command:

Although this command can be run manually, it is normally run once a day as a cron job. As current database name is a parameter to the command, the crontab entry requires editing every year.

Typical Processes (Draft)

The processes that are typically run are:

Attendance Data to Admin

Command: attendance

Attendance information is sent to owners of the database. Only information that has not been previously sent is forwarded. It is also only sent for course unit groups that have no blank data in the attendance field.

Activity Data

Command: (progress; due) | mail user

ss

Student Registration Changes

Command: mail-name-list | fgrep -v "same as last time"

sss

Student Timetable Changes

Command: mail-sessions-table | fgrep -v "same as last time"

sssss

Missing Data

Command: JTL/send-blank

Data Location

Information on the jobs to be run is stored in the file DB/CONFIGURATION/remote-jobs-user. A comment at the head of the file describes the format used in the file.