Migrate ARR Cycles to Independent API2 Requests

[haroldrubio]

This PR integrates the updated ARR workflow into openreview-py and migrates the venue to API2. The following steps are currently handled by scripts outside of openreview-py:

Overview of Changes
Location of ARR JSON forms

1. A new API1 invitation (configuration) is added to the venue request form for an ARR cycle which allows the ARR team to add dates and schedule customization scripts:

   openreview-py/openreview/arr/invitation.py

   Line 128 in 59a754a

   def set_arr_configuration_invitation(self):

2. The workflow is parameterized as an array of ARRStage objects:

   openreview-py/openreview/arr/helpers.py

   Line 1139 in 59a754a

   class ARRStage(object):

3. Some scripts are just performing an operation to customize the cycle, usually entire stages - these are in the management folder
4. Other scripts are just traditional process functions and are in the process folder

Adding New Workflow Steps

1. Create a new ARRStage and add it to the constructor of the ARRWorkflow object in the helpers file
2. For any required fields, add them to the configuration invitation content:

   openreview-py/openreview/arr/helpers.py

   Line 39 in 59a754a

   CONFIGURATION_INVITATION_CONTENT = {

3. Add the contents to the arr_content.py file and add the import to the helpers file.

Example

# Configuration invitation date field
'sac_checklist_due_date': {
    'description': 'SAC Checklist Date 1. Please enter a...',
    'value-regex': r'^[0-9]{4}\/...$',
    'order': 14,
    'required': False
}
'sac_checklist_exp_date': {
    'description': 'SAC Checklist Date 1. Please enter a...',
    'value-regex': r'^[0-9]{4}\/...$',
    'order': 15,
    'required': False
}

# Add an ARRStage
ARRStage(
    type=ARRStage.Type.CUSTOM_STAGE,
    required_fields=['sac_checklist_due_date', 'sac_checklist_exp_date'],
    super_invitation_id=f"{self.venue_id}/-/SAC_Checklist",
    stage_arguments={
        'name': 'SAC_Checklist',
        'reply_to': openreview.stages.CustomStage.ReplyTo.FORUM,
        'source': openreview.stages.CustomStage.Source.ALL_SUBMISSIONS,
        'invitees': [openreview.stages.CustomStage.Participants.SENIOR_AREA_CHAIRS_ASSIGNED],
        'readers': [
            openreview.stages.CustomStage.Participants.SENIOR_AREA_CHAIRS_ASSIGNED
        ],
        'content': arr_sac_checklist,
        'notify_readers': False,
        'email_sacs': False
    },
    due_date=self.configuration_note.content.get('sac_checklist_due_date'),
    exp_date=self.configuration_note.content.get('sac_checklist_exp_date'),
    process='process/checklist_process.py',
    preprocess='process/checklist_preprocess.py'
)

Task List

• Copy all groups from the previous cycle (reviewers/ACs/SACs/ethics reviewers/ethics chairs)
• Setup registration and unavailability forms (reviewers/ACs/SACs)
• Copy registration forms and expertise edges from previous cycles
• Create custom max papers invitations (reviewers/ACs/SACs)
• Update unavailability process functions (creates or replaces a custom max papers edge with the value in the unavailability form)
• Update submission pre-process function (validates that the previous_URL field is a link to OpenReview only containing /forum?id=)
• Post a subset of the post-submission hidden fields as a supplementary materials note on behalf of the PCs to each submission. This note always contains at least: Note From EiCs: These are the confidential supplementary materials of the submission. If you see no entries in this comment, this means there haven't been submitted any.
• Reveal anonymous pre-print submissions to the public
• Create new paper comment invitations between authors/ACs/SACs/PCs (Author-Editors Confidential Comment)
• Share proposed reviewer assignments to the ACs/SACs in their consoles, and update them to the deployed reviewer assignments after assignments have been deployed (no script yet, manual changes to webfield in API1)
• Update Official_Review process function to create a Consent invitation for the reviewer to reply to their own review to consent for this review to be used for research. Also, emails the ethics chairs for flagged papers and re-runs the ethics stage. If there is a potential anonymity violation, email the editors and create a paper desk reject verification invitation.
• Setup reviewer license and recognition forms (reviewer registration forms)
• Post track edges under a new Research_Area invitation by reading the registration and unavailability notes
• Add the Reviewers/Submitted group of resubmissions to the Reviewers/Submitted group of the previous submission
• Setup reviewer/AC checklists (recycled Official_Review/Meta_Review invitations with different content and no email notifications) Emails the ethics chairs for flagged papers, re-runs the ethics stage and reveals all checklists to the ethics reviewers/chairs. If there is a potential anonymity violation, email the editors and create a paper desk reject verification invitation.
• Enable (matching and AC assignments) SACs to edit AC/Reviewer assignments (including inviting assignments for emergency ACs/Reviewers)
• Setup ethics flagging and desk reject verification (uses decision stage to create desk reject verification super, allows the conference to reply to the ethics stage by adding as invitees, readers/signatures of the replies, updates the process function so that it stores the Official_Review invitation and re-posts it after the ethics stage is run to keep the process function)
• Post a new registration form and edge invitation (from Custom_Max_Papers) to mark reviewers as emergency, also immediately updates their custom max papers if provided. Edge browsers have the /-/Emergency invitation in their browse param.

[melisabok]

This is great, a good starting point.

I guess we need to update the test to use ARR as a venueid. About the scripts listed here, do you a have a link to the other repo so we can use them as reference?

We can start putting these scripts in a ARR folder and call them from the test and then test the workflow. What do you think?
Another option is to create one invitation per script, add the script to the date process function of that invitation and run the process function when the invitation is activated? this way scripts can be stored in invitation objects and if they can be easily be modified using the invitation editor. We could have one invitation for all the cycles and run the script on the current cycle....

[melisabok]

what is this extend for?

[haroldrubio]

The extend functions are called as a post-processing step after the invitation is created if something about the invitation needs to be changed that wasn't supported by the built-in stages. The extend checklist functions modify the super invitations so that they are compatible with the ethics flagging code for changing the readers

The same idea for the build_edit functions because sometimes edits need to be built with some additional logic (though for the pre-print case I think it can be removed, it seems simple enough to put everything in the edit without additional code)