Before the contest starts, a number of things will need to be configured by the administrator. You can check that information, such as the problem set(s), test data and time limits, contest start- and end time, the time at which the scoreboard will be frozen and unfrozen, all from the links from the front page.
Note that multiple contests can be defined, with corresponding problem sets, for example a practice session and the real contest.
The problem sets are listed under `Problems'. It is possible to change whether teams can submit solutions for that problem (using the toggle switch `allow submit'). If disallowed, submissions for that problem will be rejected, but more importantly, teams will not see that problem on the scoreboard. Disallow judge will make DOMjudge accept submissions, but leave them queued; this is useful in case an unexpected problem shows up with one of the problems. Timelimit is the maximum number of seconds a submission for this problem is allowed to run before a `TIMELIMIT' response is given (multiplied by the language factor).
The `Languages' overview is quite the same. It has a timefactor column; submissions in a language that has time factor 2 will be allowed to run twice the time that has been specified under Problems. This can be used to compensate for the execution speed of a language, e.g. Java.
Before a contest, you will want to have tested your reference solutions on the system to see whether those are judged as expected and maybe use their runtimes to set timelimits for the problems. There is no special method to test such solutions; the easiest way is to submit these as a special team before the contest. This requires some special care and coordination with the contest administrator. See the administrator's manual for more details.
If your contest has a test session or practice contest, use it also as a general rehearsal of the jury system: judge test submissions as you would do during the real contest and answer incoming clarification requests.