ReviewNeedsSubmit thoughts

The Problem

We may want to support review "phases", where a reviewer submits more than one review. Review phases complicate the HotCRP permissions system, whereby we can obtain all information pertaining to whether a user can read a paper by left-joining with one or more at-most-once tables, such as PaperConflict and PaperReview.

reviewNeedsSubmit is too weird

reviewNeedsSubmit takes one of three values.

• 0: The review is submitted, or submission is not required.
• 1: The review is unsubmitted, and submission is expected.
• -1: This review is a secondary review, and its author has delegated to an external or PC review, but that delegated review is not completed.

reviewNeedsSubmit is interpreted in combination with Paper.timeSubmitted and reviewSubmitted.

The following combinations of reviewNeedsSubmit and reviewSubmitted are found in the wild.

• 0, non-null: The review is submitted.
• 1, null: The review is not submitted and its submission is expected. If the review is secondary, then it has not been delegated.
• 0, null: The review is secondary, it is not submitted, and one of the delegated reviews has been submitted.
• -1, null: The review is secondary, it is not submitted, it has been delegated, but none of the delegates have submitted.

reviewNeedsSubmit is used for several purposes.

1. Counting whether a review has been “started.” This information is shown to users. A review is “started” if reviewNeedsSubmit>=0, which holds for all reviews except delegated reviews where none of the delegates have submitted.
2. Counting whether a review is expected. This information is shown to reviewers. (“Reviews are overdue.”)
3. Describing whether a review is delegated. The review is delegated if reviewSubmitted is NULL and reviewNeedsSubmit<=0.

reviewNeedsSubmit is obtained from a complex join and is therefore difficult to keep up to date. It is probably incorrect when a review changes state (e.g. secondary to primary, primary to secondary). It was incorrect for deeper reasons previously (we didn't track requestedBy across the chair-approval process).

reviewNeedsSubmit alternatives

• Count of submitted delegates. Advantage: this works across all review types. Disadvantage: it doesn't help answer many important questions.
• reviewProvided: 1 if reviewSubmitted or delegate submitted, 0 otherwise. Advantage: corresponds to the bit we want to include in PaperUser eventually; it matches up with permissions uses. Disadvantage: lose the information corresponding to reviewNeedsSubmit<0.
• reviewProvided + reviewExpected.
• Paper.numReviewsExpected.
• PaperReview.numRequests + PaperReview.reviewProvided + Paper.numReviewsExpected?
  • Paper.numReviewsExpected = count(paperReviewId) where reviewType≠3 or reviewSubmitted is not null or numRequests=0?
  • PaperReview.numRequests is an intermediate join to simplify Paper.numReviewsExpected maintenance.