Evaluation Queue Rounds and Limits

Source material:

UI Design:
https://www.figma.com/file/E5zIAPsI2fagDc8btWGU06Ol/Challenge-Evaluation-Queue

Use case/desired behavior:
https://docs.google.com/document/d/19M9og2JW7CaG7YLNi8cCRhFuFwF-y6-nx4CJDAwr6qw/edit#heading=h.y0949lyt5na0

Motivations:

Existing Evaluations have a very inflexible way to define rounds:

The existing way to define Round limits assume that all rounds will last for the same duration and that later rounds will begin immediately as soon as the previous round ends. Users are also forced to perform unix timestamp calculations in order to set the round end datetime. There was also no fine grained submission limit control over Submission limits per user or participating team.

High level changes

The goal is to provide users with more fine grained control over each Round in an Evaluation. This means:

• Clearly defined start and end dates for each round.

  • Initial design will not allow unbounded start or end dates.

    • The old SubmissionQuota system does allow unbounded start dates, end dates , or both.

  • No more startDate + roundNumber * roundDruation math for the end date

• Per-round submission limits. These limits should be changeable even during an ongoing round

  • cumulative limit for the entire round

  • per day - resets every day at 00:00 UTC

  • per week - resets every Monday at 00:00 UTC

  • per month - resets at 00:00 UTC on the 1st day of every month

• Add/remove/modify rounds without affecting other rounds

  • Change start datetime if round not yet started (current time < start time) AND 0 submissions were made

    • If 0 submissions made, the round may still be updated/deleted even if the time is past the start date

  • Change end date to any time in the future (current time < end time)

    • Setting the end datetime to a later time is always allowed

    • Setting end datetime to a time in the past is not allowed.

  • Add/delete/change new rounds that have not yet started.

  • Validation

    • Disallow intersecting time intervals between rounds

      • i.e. no overlap between time ranges of any 2 rounds belonging to the same Evaluation

    • SubmissionQuota and EvaluationRounds may not both exist. must pick one or the other

• User’s Submissions will be automatically tagged with the id of the current EvaluationRound

  • Additional metadata column in Submission views

• Allow Evaluation Queue Admins to schedule a Maintenance date range that disallows Submissions

  • Independent of defined rounds - neither the ongoing rounds nor later rounds will have their start/end date modified as a result of maintenance Not implemented

API Schema

Evaluation
Deprecate quota.

New evaluation round will be a list of objects which will be accessible via a new API

EvaluationRoundRequest

Used to retrieve all EvaluationRounds associated with an Evaluation. Results are paginated. Use nextPageToken to retrieve the next page of results.

EvaluationRoundResponse

One page of EvaluationRounds associated with an Evaluation. Use the givennextPageToken in the next EvaluationRoundRequest to retrieve the next page of results.

EvaluationRound

Defines roundStart and roundEnd dates.

id can used for updates if we store rounds in a separate table

limits is used to set limits on submissions

EvaluationRoundLimit

Limits for total submission limit for the round, and a list of periodically resetting limits.

Example Evaluation

id will be back-end generated after it has been created. For roundStart and roundEnd, both UNIX timestamp in milliseconds and ISO time format are accepted

EvaluationMaintenance Not implemented

disallows all submissions
only 1 allowed per queue

API Endpoints

API/Database Transition

A SubmissionQuota can easily be mapped into into a list of SubmissionRounds using math, but the reverse is not true.

For the time being, I’m considering making the old deprecated quota field remain stored in the database, but enforce a rule such that user must choose between quota and the new EvaluationRounds API when configuring a Evaluation. This allows time for clients to implement support for the new API.
Once we fully decide to remove SubmissionQuota, we can perform the conversion and store quotas asSubmissionRound.
SubmissionQuota currently allows unbounded round start/end dates by setting null. This would not be desired behavior for EvaluationRounds because it would complicate queries that involve date ranges. We can mimic the unbounded time range by migrating the start/end to some time far in the past or future ( best of luck to the devs dealing with this in 2324 AD ! ).

Database Tables

2 Options:

• Separate Table For Rounds (primary key is evaluationId , ID) index on roundStart and roundEnd

  • Allows us to pull out one specific R limit

  • Limits are enforced in Java code so we can store the them as JSON

  • generated unique ID makes it easy to perform updates on evaluations

Evaluation_maintenance table

Records maintenance windows for each evaluation.

JDOSUBMISSION table

Add EVALUATION_ROUND, which is the round number during which it was submitted. This will be replicated into Submission Views.

Existing table: