Review will close at 1pm on Tuesday, June 4. Subsequent reviews will take place on an ongoing basis during alpha and beta testing.

This is a pre-alpha merge for v0.1 of the submission UI. The original goals for this release were:

Provide all existing services of classic system (feature-parity), with seamless integration with other classic components (e.g. moderation, announcement).
Modest improvement to user experience.
Move submission UI to new unified design paradigm (color scheme, fonts).
Focus on reducing confusion, improving messaging to address problems related to frequent user support issues.
Under the hood, implement a new data architecture that better scales and evolves to meet user and stakeholder needs.

The latter objective is covered by https://github.com/arXiv/arxiv-submission-core/pull/64

Some of the major differences from the classic UI include:

The submission process is broken down into smaller steps
JREF, withdrawal, and cross-list requests begin to be treated differently than new submissions and replacements
Highlighting of key terms/phrases in the TeX compilation log; this is the first incremental move toward a more user-friendly compilation experience (e.g. taxonomy of known errors, distilled log output, etc)
HTML email confirmation
Native UTF8 support

Under the hood, we have broken out file management (upload), compilation, and plain text extraction as stand-alone services. See the arXiv submission docs for an overview.

Practically speaking, this means that:

the UI is calling the file management and compilation services behind the scenes, and
the UI is no longer responsible for orchestrating text extraction and calling the autoclassifier -- this is now handled by the submission agent. So is sending the confirmation e-mail.

How to review

Per the arXiv NG release process, alpha means that:

The majority of and/or highest priority functional goals for the release have been met.
Bugs are expected to exist, and known bugs may not yet have been fully addressed.
The release is deployed for internal review. This may be on the on-premises “beta” server, or in a staging environment in the cloud.
Dev and operations teams all participate in review, and report bugs, improvement requests, and other feedback to the feature team. A two-stage alpha review will first target the core operations team, and then broaden testing to volunteer moderators and close partners.
Feature team begins to prioritize and fix bugs, performs load testing, and works to evaluate the release against quality and performance goals.

The first round of alpha testing will involve some volunteers outside the core ops team.

In advance of alpha, therefore, please take a look at the following things:

If you have not yet done so already, please review the architecture for the arXiv-NG submission system.
Try spinning up the UI and other submission services using docker-compose. See https://github.com/arXiv/arxiv-submission-ui#quick-start for instructions.
Please help to find any obvious bugs. Try running some announced source packages through, or take a look at the filemanager tests for lots of oddball submissions. The goal is to avoid anything terribly embarrassing when we enter alpha.