When a program committee chair in 2005 needed to assign twenty-two papers to six reviewers, the tool of choice was often a hand-crafted HTML page—a single document that served as both assignment matrix and status dashboard. Unlike today's integrated conference management systems, the review process in mid-2000s pattern recognition and speech conferences relied on a patchwork of static HTML files, email threads, and server-side scripts that were custom-built for each event. Understanding how those documents were structured reveals the technical constraints of the era and the careful social engineering that kept peer review running smoothly.
The Anatomy of a Review Assignment Page
A typical review assignment page began with a table listing every submitted paper by its identifier—often a four-digit number prefixed by the conference acronym, such as PRASA2004-0123. Each row contained the paper title, author names, and a set of empty checkboxes or drop-down menus representing the reviewer pool. The chair would manually populate these cells with reviewer initials, sometimes using a simple text input field that accepted a three-letter code.
The HTML source for such a page was remarkably spare: a <table> with <tr> and <td> elements, styled with inline bgcolor attributes to highlight conflicts of interest. The form was rarely submitted to a database; instead, it was printed, annotated by hand, and then re-keyed into a separate tracking spreadsheet.
The fragility of this workflow is easy to forget. A single misplaced row could scramble the entire assignment. Chairs therefore adopted conventions: papers from the same institution were grouped, and reviewers who had previously reviewed for the same venue were listed in a separate comment section at the bottom of the page. The <pre> tag was a common sight in these documents, used to preserve monospaced alignment in the printed copy.
Review Forms as HTML Templates
Once papers were assigned, reviewers received an email containing a link to a blank review form—an HTML page hosted on the conference server. These forms were the heart of the document review process. They typically contained four sections: a text area for the summary, a set of radio buttons for overall rating (usually 1–5), a checklist for criteria such as originality, clarity, and technical correctness, and an optional confidential comment field for the program chair. The HTML was generated by a Perl or PHP script that inserted the paper ID into a hidden <input type="hidden"> field. When the reviewer clicked "Submit," the form data was sent via POST to a CGI script that appended the review to a plain text file or a simple MySQL database.
The design of these forms reveals a deep concern for usability on slow connections. The entire page was often under 10 KB, with no images except for a small conference logo. The <textarea> fields were sized at 60 columns by 10 rows—large enough for a substantive review but small enough to fit on a 1024×768 monitor without scrolling. A typical form included a <noscript> fallback that reminded reviewers to enable JavaScript for auto-saving, though most reviewers ignored it and composed their comments in a local text editor before pasting them into the browser.
The Committee Page as Review Hub
Program committee members often had access to a dedicated "committee page"—an HTML document that aggregated all papers assigned to that reviewer. This page listed paper titles, abstract snippets, and a status indicator: "Not Reviewed," "Draft Saved," or "Submitted." The status was updated by the same CGI script that handled form submissions, using a simple timestamp written into a flat file. The committee page was refreshed manually by the reviewer, who would reload the browser to see the latest changes. This pattern is reminiscent of the hand-coded committee pages that shaped early conference management, where every status update required a deliberate action by the user.
The program chair maintained a master committee page that listed all reviewers and their assigned papers. This page was often generated from a Perl script that parsed a plain-text assignment file. When a review was submitted, the script updated a second table that showed the number of reviews completed per paper. Chairs used this page to identify papers with only one review or reviewers who had not yet started. The HTML was never meant to be beautiful; it was a working tool, with bold red text for overdue items and a simple <hr> separator between sections.
Handling Conflicts and Reassignments
Conflicts of interest were managed through a separate HTML page that listed all author–reviewer pairs flagged by the chair. Each row contained the paper ID, the reviewer name, and a radio button to mark the conflict as "Confirmed" or "Resolved." The page was updated manually, and the assignment page was edited by hand to remove the conflicted reviewer. This process was error-prone; a common mistake was to delete the wrong row in the HTML table, causing the assignment to shift. Chairs learned to keep a backup copy of the assignment page as a plain text file with a .html extension, so they could restore the table structure quickly.
Reassignments were handled through email. The chair would ask another reviewer to take over, then edit the assignment page and the review form template to reflect the new reviewer's credentials. The CGI script that accepted submissions checked the reviewer's email address against a list stored in a flat file; if the email did not match, the submission was rejected with a generic error message. This simple authentication was sufficient for the small-scale conferences of the mid-2000s, where the program committee rarely exceeded thirty people.
Scoring and Decision-Making
After all reviews were collected, the program chair would export the data from the database into a CSV file and then into an HTML summary page. This page displayed each paper with its three to five reviews, the average score, and a column for the chair's recommendation: "Accept," "Revise," or "Reject." The page was often printed and distributed to the program committee during the final decision meeting. The HTML was generated by a script that sorted papers by average score and highlighted those with a score above a threshold—typically 3.5 out of 5. The chair could click on a paper ID to open a detailed view that concatenated all reviews into a single page, with the confidential comments hidden behind a <!-- comment --> that was only visible when viewing the source.
The decision meeting itself was conducted offline, but the HTML summary served as the reference document. Chairs would annotate the printed page with sticky notes and then update the online version later. The final list of accepted papers was published as a static HTML page that included the paper title, authors, and a link to the camera-ready submission guidelines (which were themselves a separate HTML document). The review process pages were then archived—often in a folder named /review/ or /pc/—and left untouched for years.
Lessons for the Historian
For researchers studying the history of pattern recognition and speech conferences, the surviving HTML documents from the review process are invaluable. They show how a community adapted web technology to solve a coordination problem without the benefit of modern frameworks. The simplicity of the HTML—no CSS, no JavaScript beyond basic form validation, no AJAX—reflects the constraints of shared hosting servers and dial-up connections. Yet the system worked. The review process was transparent enough that chairs could spot anomalies, and flexible enough to accommodate last-minute changes. Those hand-crafted pages, with their inline bgcolor and <pre> tags, were the backbone of peer review for years. They worked because the people using them understood the limitations and worked around them—often with a printed copy and a pen.