The web interface is the main point of interaction with the system. Here you can view submissions coming in, control judging, view the standings and edit data.
The jury interface has two possible views: one for jury members, and one for DOMjudge administrators. The second view is the same as the jury view, but with more features added, and can be enabled by giving a user the 'admin' role (instead of or next to the 'jury' role).
This separation is handy as a matter of security (jury members cannot (accidentally) modify things that shouldn't be) and clarity (jury members are not confused / distracted by options they don't need).
Options offered to administrators only:
A note on rejudging: it is policy within the DOMjudge system that a correct solution cannot be reverted to incorrect. Therefore, administrator rights are required to rejudge correct or pending (hence, possibly correct) submissions. For some more details on rejudging, see the jury manual.
The scoreboard is the canonical overview for anyone interested in the contest, be it jury, teams or the general public. It deserves to get a section of its own.
Each problem can be associated with a specific colour, e.g. the colour of the corresponding balloon that is handed out. DOMjudge can display this colour on the scoreboard, if you fill in the `color' attribute in the `problem' table; set it to a valid CSS colour value (e.g. `green' or `#ff0000', although a name is preferred for displaying colour names).
It's possible to have different categories of teams participating, this is controlled through the `team_category' table. Each category has its own background colour in the scoreboard. This colour can be set with the `color' attribute to a valid CSS colour value.
If you wish, you can also define a sortorder in the category table. This is the first field that the scoreboard is sorted on. If you want regular teams to be sorted first, but after them you want to sort both spectator- and business teams equally, you define `0' for the regular category and `1' for the other categories. To completely remove a category from the public (but not the jury) scoreboard, the category visible flag can be set to `0'.
A contest can be selected for viewing after its activation time, but the scoreboard will only become visible to public and teams once the contest starts. Thus no data such as problems and teams is revealed before then.
When the contest ends, the scores will remain displayed until the deactivation time passes.
DOMjudge has the option to `freeze' the public- and team scoreboards at some point during the contest. This means that scores are no longer updated and remain to be displayed as they were at the time of the freeze. This is often done to keep the last hour interesting for all. The scoreboard freeze time can be set with the `freezetime' attribute in the contest table.
The scoreboard freezing works by looking at the time a submission is made. Therefore it's possible that submissions from (just) before the freezetime but judged after it can still cause updates to the public scoreboard. A rejudging during the freeze may also cause such updates.
If you do not set any freeze time, this option does nothing. If you set it, the public and team scoreboards will not be updated anymore once this time has arrived. The jury will however still see the actual scoreboard.
Once the contest is over, the scores are not directly `unfrozen'. This is done to keep them secret until e.g. the prize ceremony. You can release the final scores to team and public interfaces when the time is right. You can do this either by setting a predefined `unfreezetime' in the contest table, or you push the `unfreeze now' button in the jury web interface, under contests.
Almost every cell is clickable in the jury interface and gives detailed information relevant to that cell. This is (of course) not available in the team and public scoreboards, except that in the team and public interface the team name cell links to a page with some more information and optionally a team picture, and the problem header cells link to the problem text, if available.
The scoreboard is not recalculated on every page load, but rather cached in the database. It should be safe for repeated reloads from many clients. In exceptional situations (should never occur in normal operation, e.g. a bug in DOMjudge), the cache may become inaccurate. The jury administrator interface contains an option to recalculate a fresh version of the entire scoreboard. You should use this option only when actually necessary, since it puts quite a load on the database.
In many cases you might want to create a copy of the scoreboard for
external viewing from the internet. Just for that, the public interface
can be called with the url parameter
?static=1. It produces
a version of the scoreboard with refresh meta-tags, login facilities
and links to team pages removed. This can for example be requested
every minute via
curl and the output be placed as static
content on a publicly reachable webserver.
In many contests balloons are handed out to teams that solve a particular problem. DOMjudge can help in this process: both a web interface and a notification daemon are available to notify that a new balloon needs to be handed out. Note that only one should be used at a time.
The web based tool is reachable from the main page in the jury interface, where each balloon has to be checked off by the person handing it out.
For the daemon, set the
etc/domserver-config.php to define how notifications
are sent. Examples are to mail to a specific mailbox or to send
prints to a printer. When configured, start
and notification will start.
Notifications will stop as soon as the scoreboard is frozen.
show_balloons_postfreeze configuration option to
keep issuing balloon notifications after the freeze.