Introduction

I (Nathan Collins) have completed the basic elements of OpenContest for my Independent Study at Bob Jones University. However, there are several additional features that would be very useful for running programming contests. Below are a list of features that I believe would make OpenContest better for its job of supporting programming contests. I may work on some of these myself, but I welcome any qualified developer to contribute by working on these projects.

Judging Interface to Show Submissions

OpenContest needs a page on which judges can see participants' submissions for each problem to determine whether the judging data is correct and whether the problem is sufficiently clear. This page should allow judges to see the code submitted as well as the output produced by the participant's program compared with the correct output. This page should also allow judges to change the verdict for a submission in the case of plagiarism or other issues.

Automatic Regrading of Submissions

If the test data for a problem is found to be faulty, the judges should be able to edit the test data, and OpenContest should automatically rerun all previous submissions for the problem and adjust the leaderboard. OpenContest should also send out a general notification to all participants that the test data has changed and a specific notification to users whose submission statuses have been changed.

Abstracting Runners

Currently, the runners run on the same physical machine as the OpenContest server but in separate Docker containers. I suggest that the runners should run as a separate program that can be run on multiple machines. Each instance would communicate with the main OpenContest server and tell the server what computation capacity is available. The server would queue up submissions and send the next submission to whichever runner machine has unused capacity. I suggest dedicating 1GB of RAM and 1 core to each runner, so a quad-core machine with plenty of RAM would be able to run 4 submissions concurrently. Thus if the contest were large enough to require 12 concurrent runs, the judges could merely start the runner instance on 3 machines.

Adding Support for Other Languages

OpenContest currently supports submissions in the following languages:

• C
• C++
• C#
• Java
• Python2
• Python3
• Ruby
• VB.NET

There are thousands of languages that could be added, but I propose that the following languages would be most useful to add:

• PyPy 2 and 3
• Javascript
• Kotlin
• Go
• Lua
• Rust
• Julia

You can find more information about creating runners.

Table-Driving Runners

All the runners are basically identical except that they have different commands for compiling and running the code. I suggest creating a list of these commands and using one script that chooses its commands based on which language is being run. This change would improve maintainability since only one script would need to be maintained instead of one script for each language.

Moving to the Cloud

I started this project with the thought that the API server would run in Google Cloud Functions (an FaaS product similar to AWS Lambda) and code submissions would also run in GCF. However, I quickly realized that GCF does not have the capability of running submissions in various languages as needed. However, Google does have an alpha product, Serverless Containers, that runs containers in a serverless workflow and allows unlimited scalability for the containers. I suggest that OpenContest should migrate to Google Cloud when Serverless Containers is made available more broadly in a beta or general release stage.

Compiling Submission Statistics

I suggest creating a simple page that would show site statistics, including the number of test runs, the number of submissions, the runner queue size, the number of total and correct submissions in each language, and the number of total and correct submissions for each problem.

Virtual Contests

CodeForces and CSAcademy both have virtual contests, allowing users to participate in a past contest as if it were happening in the present. I believe this would be a useful feature for OpenContest after OpenContest moves to the cloud.