Activities

An activity is one place where problems are given to people: a contest, a course, a practice set. Everything else on this panel either feeds one or reads one.

It holds its problems in series — rounds — and a series holds assignments rather than problems. An assignment is the row attaching makes, and everything about how this problem is used here lives on it; the problem itself stays in the library, where several activities can point at it at once.

flowchart TD act["Activity: a contest, a course, a practice set"] act --> ser["Series: a round, a week, a class. When it opens, when it closes, which Runners judge it"] ser --> asg["Assignment: the row made by attaching. The letter, the pinned version, what it is worth, the limits and languages laid over the package"] asg --> prob["Problem, in the library. No activity owns it"] prob --> ver["Version: statement, attachments, package. Published whole, never edited afterwards"] other["An assignment in another round, or another course"] --> prob style other stroke-dasharray:4

Creating one

New activity asks for three things and nothing more:

a name;
a slug, used in addresses — AMMPZ-2019;
a type, chosen from a list rather than typed.

The rest is edited on the activity itself, with defaults to start from. Asking for the whole settings form before the activity exists would be a worse first step.

The slug is immutable once set

Participants' links point at it. The create form says so, and the field on the settings tab is locked from then on. Choose it as you would a URL, because that is what it is.

Type is a choice because the type decides how the activity presents its series — a string nothing is registered for gets whatever the fallback happens to do. Ranking type (points or icpc) is a separate setting and independent of it: it chooses which ranking is drawn.

A new activity is published the moment it exists. Making one is the deliberate act, and being asked to say so a second time would be ceremony rather than a safeguard. So the list gives it the state its dates imply — Upcoming, Ongoing, Finished, or Untimed while it has no dates — its series open on schedule, and anybody you enrol reaches it at once.

That is not the same as being open to the world. A new activity is created closed and hidden from the list, so nobody enrols themselves into it and nobody browsing finds it; both switches are under Visibility and enrolment on the settings tab.

Withdraw takes all of that back: no round of it opens, the address answers anybody who cannot edit it as though the activity were not there, and the list shows Being prepared in place of a state until you Publish it again. The one activity that does arrive unpublished is a copy, which nobody sat down and wrote.

Time is stored in UTC and shown in the activity's zone

The activity carries a time zone, and every instant it owns is displayed and entered in that zone, with the zone named on the field. What is stored is UTC.

That matters when you are not in the room: a manager sitting in another zone can set a contest that opens at 18:00 in the contest's clock without doing arithmetic, and the times a participant sees do not depend on where either of you is sitting.

The four tabs

The open tab is in the address, so a reload, a bookmark and a link you send all land where you were.

Series and problems

Rounds, and what is attached to them. They are edited together because a series with no problems is not yet a round. See Series and The problem library.

Settings

Everything the activity is configured with:

Group	What is in it
Identity	name, slug (locked), type, ranking type, time zone
	who sees what a submission carries — one row per file a Runner attaches, each either managers only or participant
Dates	start and end. Leave both empty and the activity spans its series: the earliest start and the latest end
Modules	questions and announcements. A disabled module leaves the participant's sidebar entirely
	whether the problems of a finished series stay readable — off, a finished round is over rather than secret
Visibility and enrolment	who sees scores and the ranking, who may join, whether it is hidden from the list, whether a group's ranking row names its members, the join password and the link to hand out
Which Runners judge this activity	the tags that decide which machines take its work — see Runners
Limits the Server enforces	maximum upload, files per submission, submissions per problem

That last card is named after what it does: the three are columns on the activity, checked on every upload. Time and memory are not among them. They only become knowable while a solution runs, so they belong to the problem and are set in its package.

Documents

Three documents an activity may publish, each in as many languages as you write:

Kind	Who reads it
welcome	somebody who is not enrolled, looking at the activity from outside
home	somebody who is in it
rules	the rules page

They are the same editor the installation publishes its own documents in, and they behave the same way: publish, unpublish, and a history per kind. A language with no text of its own falls back to the default one. Whether an activity has rules is whether one is published — there is no separate switch.

Clicking into an activity as a participant lands on the home document when one is published, and on the problems otherwise.

Participants

Who is in it, and what they may do — one act, not two. See Enrolment and Groups.

Archiving, and deleting

Archive is the ordinary act. An archived activity stays readable and accepts nothing new — no submissions, no questions, no edits — and keeps its ranking and its history, which is what people come back for. Restore it to keep editing.

Deletion destroys everything in it and is refused outright for an activity that has participants; the button says so instead of failing on the click. It also needs activity:delete, which is deliberately not in the shipped manager template.

Activities

On this page