Recruit: Version history

• 2.7 (January 2011): Rather than listing the admin email in the main page and in the submit script, now there is just a link to the hiring web page. This allows to list different contact emails for different areas and change them during the search without messing with the code. Also fixed a bug that caused errors int the display and management of areas when an area happened to be a substring of another.
• 2.6 (April 2010): The admin script now allows to update the status of candidates when emails are generated to them or their references. Also fixed a minor bug in review script so that candidates whose status contains the string 'reject' (case insensitive) can be hidden again.
• 2.5 (January 2010): A few improvements to review script. (1) Added an optional filter for including only candidates with at least one champion and borderline or better average score; can be useful for committee to focus on top candidates. (2) Added a couple sorting criteria: by number of scores and number of comments. (3) Links to candidate homepages now open in a new tab/window, so one does not need to use the back button, which was problematic in some browsers. (4) When reviewing a previously reviewed applicant, the previous score and comments now appear as default, making revisions/updates easier. (5) Added a bit of statistics by areas. Also a few minor bug fixes.
• 2.4 (October 2009): Interface improvement to review script include listing on PhD year and institution in summary table, better labels for numerical scores, and a bit of Javascript to prevent errors when entering evaluations. Also, the admin script now allows for bulk status updates.
• 2.3 (June 2009): Added functionality to admin script: can now generate and send bulk emails to a set of candidates, or to the references of a candidate. This is useful to automate the sending of acknowledgments of received applications, requests for letters, rejections, etc.
• 2.2 (January 2009): Fixed minor bug in admin script.
• 2.1 (January 2005): A couple of changes in the review script. (1) Removed "clear form" buttons as users complained that they would click them by mistake and then have to retype comments. (2) Changed the way to read reviewers' comments from an alert window to a regular popup window, using JavaScript. This is because occasionally a reviewer would write such a long comment that some browsers failed to display the text in an alert window.
• 2.0 (June 2004): Reference release -- I will probably not work on Recruit for a while. To facilitate the implementation of stronger system-dependent security measures, the (public) index and submit scripts have been separated from the (private) administrative and committee-related scripts; the private scripts now reside together with applications database files under an admin subdirectory, which can be protected by stronger authentication. Install script: now allows the sysadmin to disable the password, for organizations where there are better mechanisms such as a central authentication server. Admin script: improved generation of rejection letters based on status. Register script: a committee member can now enter a profile with areas of interest (like candidates) and then be notified only of new applicants in his/her own area; the profile can also be used to select only candidates matching these areas when reviewing. Review script: now prints some summary statistics by status, and has labels for numerical evaluations.
• 1.8 (December 2003): In addition to various interface improvements in the review script, including more sorting preferences, there are two new functionalities in the admin script: (1) now it is possible to add extra letters in addition to those from the references listed by the applicant, eg letters from external or unlisted references; (2) a new option allows to make any changes to a candidate file, including selected areas, files, contact info, etc.
• 1.7 (November/December 2003): Reviewers can now enter comments without being forced to enter a numerical score. The review interface has been changed to hide some details (reviews, areas) behind alert windows; this makes it easier to get a general view of the field of candidates, read reviews, and select candidates for in-depth evaluation. The registration script now allows reviewers to modify their email address in addition to the notification preference bit. The administration script has two new features: (1) changing the status of an applicant (to keep track of letter requests, interviews, offers, etc) and (2) generating a downloadable tgz archive of an applicant's file, convenient for printing.
• 1.6 (October 2003): The administrative tool has a new feature to generate rejection letters, which also marks applications as rejected. Reviewers by default do not see rejected applications, unless they check a new box for this porpose.
• 1.5 (October 2003): Improvements to user interface so that a reviewer can select to list only applicants in a subset of the specialization areas. Also minor security improvements.
• 1.4 (September 2003): Fixed review user interface so that a committee member cannot forget to identify him/herself and risk overwriting someone else's reviews. Also other minor improvements to review interface.
• 1.3 (September 2003): Fixed small bug in letter count.
• 1.2 (August 2003): Extended from 3 to 6 references.
• 1.1 (August 2003): Recruit home moved to IU; added option to upload letters as PDF in addition to text.
• 1.0 (July 2001): First release.

Security and privacy issues

• Security and privacy are important in this type of application. You don't want candidates to have access to reviews (or worse, any information about other applications). While I have tried to make it difficult for someone to infiltrate the system, I can make no warranties.
• Even assuming there are no bugs, security is not strong; for example the shared password is passed in the clear by form fields and cookies and therefore could be sniffed.
• The install script is meant to assist a sysadmin, but not replace his/her wisdom about system security. For example, the script is based on some delicate assumptions about the behavior of apache with respect to serving documents owned by it under cgi-bin versus the rest of the www document tree. If changes are made to the directory structure of where data is stored, one could have very bad, hard to predict surprises. You are warned.
• I feel that further steps to strengthen the security and privacy of the system (authentication, access control, etc.) would lead to system dependencies. However I want Recruit to remain system (OS and web server) independent. Therefore such steps are best left to system and network administrators. For example when using Recruit at the Indiana University School of Informatics, we disable the shared password and wrap the scripts in the admin directory with Kerberos authentication.
• While a paperless recruiting system has many advantages, it also makes it much more critical to regularly backup the data.

Wish list

• Improve performance: system is sluggish with ~450 applications.
• The user interface could be improved in many ways.