#Classrooms

A classroom is a group of students working through the same modules. Release a module to a classroom and every enrolled student can run it.

#Creating a classroom

From your organization's home page, open the classroom list and create a classroom. Give it a name, then configure timers, contest mode, and helpdesk tickets afterward.

A classroom belongs to one organization, runs on that organization's deployment zone, and is independent of every other classroom. Students can be in more than one classroom at a time.

#Adding students

Open the classroom and go to its users page. Today the platform supports one enrollment path: pasting a list of contestant identifiers (the per-student IDs your organization assigns) into the bulk-add field, separated by commas or newlines. Submit the list and the platform creates or attaches accounts for each ID.

There is no self-service signup, invite link, or CSV import in the UI right now. If you need a different intake (for example, importing from an LMS roster), talk to your organization admin.

#Releasing a module to a classroom

Modules reach students through a release. A release pins a particular version of a module to your classroom and produces a shareable link.

From the classroom's management page, pick a module from the library you have access to and create the release. You can release the same module to multiple classrooms; each release is independent. Once a release exists, the management page shows the link you give your students.

A few rules:

• The module must already have a stable build in your zone. If it does not, see The module library for how a build is promoted.
• Releases are pinned. Updating the underlying module after release does not change what your current students see; you create a new release to ship the update.

#Queued releases

What a release does depends on your organization's plan, and it is not a choice you make per release.

On pay-as-you-go, a release provisions a VM for every student the moment you make it, and charges the virts there and then.

On a monthly plan, a release queues. Each student is still given the module immediately, but its VM is not provisioned until they have room for it. When a student finishes what they are working on, that VM is destroyed, its VM Slot is freed, and the next module in their queue is provisioned automatically. This is what stops a term's worth of modules holding VM Slots from day one.

Provisioning a module is not the same as starting it. The queue provisions the next VM and the student starts it themselves, the same way they start any other module: the VM takes a minute or so to come up, and then they open it when they are ready. Nothing runs, and no time is counted against them, until they do.

Release each module the same way, one at a time, and each one lands at the back of the queue. The Queue tab on the classroom shows every student's queue: what they are working on, what is waiting, and why anything is held up. From there you can reorder a student's waiting modules, remove one, or provision their next module early.

A few rules:

• Contest classrooms work exactly like any other classroom here. A contest in an organization on a monthly plan queues, and one on pay-as-you-go provisions everything at once, the same as a regular class in the same organization. Contest VMs still arrive locked either way, so nobody starts before you open the contest.
• A release sets how long students get, in days, rather than a calendar date. The clock starts when a student actually opens the module, so somebody who reaches the fourth module next month still gets the full allowance. Set 30 days and every student gets 30 days, whenever they get there.
• You can change the deadline on an individual instance afterwards, from the student's instance page, if one person needs longer or the whole class needs pulling in.
• Leave the allowance empty and the module runs on its time limit alone, counted from whenever the student reaches it.
• Contest classrooms ignore the allowance, because a contest runs on each module's own countdown.
• How many modules a student can have open at once is an organization setting, under Organization → Settings. It applies to every release on a monthly plan.

#Finishing a module

A student finishes a module with I'm Done in the console or Finish on the instance page. Either option locks the VM and sends it for final grading.

For a queued module that is also what moves them on. Once the grade lands, the VM is destroyed and the next module in their queue starts. A teacher can do the same thing from the student's instance page when somebody is stuck or out of time.

#The gradebook

Each classroom has a gradebook that lists every student, every release in the classroom, and the score they earned (or are still working on). Scores come from the autograder when a student clicks I'm Done in the console. If a student opened helpdesk tickets during a module, those tickets and their per-VM responses appear in the gradebook entry alongside the score.

#Contest classrooms

A classroom can be marked as a contest. In contest mode, releases run with personal countdown timers and the gradebook surfaces standings. See Timers and Contests for the student-side experience and the configuration that drives it.