Current Info
-> 1.3.1 has been released; this release fixes a couple of serious bugs in the 1.3 release

E-mail Us Directly
-> J. Paul Reed
OpenRatings Project Lead
openratings@sigkill.com
-> OpenRatings
Mailing Lists Maintainer
or-lists@sigkill.com


  1. What is this OpenRatings thing?

    From the README: OpenRatings is a professor ratings engine and website template.

    It allows students to anonymously rate professors based upon three simple questions, and (more importantly) free form comments.

    As it stores this information, it allows students to search for professors that teach certain classes, keyword searches, and all sorts of nifty other things.

    OpenRatings isn't just for student-run sites! Many colleges have professor ratings sites. OpenRatings is perfect for smaller schools that want to allow their students to rate professors for legitimate feedback, but that don't have the time or money to develop such software on their own.

  2. I've found a bug; what do I do?

    First, you might try mailing the OpenRatings users' list to make sure it really is a bug; you can do so by sending email to openratings-users@lists.tolosatech.com; you don't need to subscribe.

    If you really think it is a bug, however, please go to OpenRatings' Bugzilla installation and fill out a bug report.

  3. I'm in a hurry, and I want to know without downloading the source code what I'd need to run an OpenRatings site.

    In a nutshell, you need:

    This software is comes with every hosting company package we've ever seen; it's almost boringly standard.

  4. What open source license is OpenRatings licensed under?

    We chose to release OpenRatings under the Jabber open source license.

    We know this is an odd choice of license, but after reading a large number of licenses (over twenty licenses are approved by Open Source International), we felt the Jabber license was the most compatible with the goals we wanted to acheive by open sourcing Polyratings, so that's the one we went with.

  5. Why did you use MySQL? Why not PostgreSQL? Or [my database of choice]?

    Nothing would have pleased us greater than to have used PostgreSQL for this project; you'll find a lot of code, especially in php/DBConnection.php to 'fake' transactions, and really, it's very hokey.

    But, MySQL was chosen for two reasons:

    • It's the most common database found at web hosting companies, meaning that using it makes OpenRatings easier for others to use.
    • MySQL has a nice "fulltext" index feature which made natural language searches *really* easy to implement.

  6. Why did you use an extension of .phtml? The standard is .php!

    "It was like that when we got here, honest!"

    The real answer is rooted in the history of the original Polyratings: we wanted to separate the content generating file that the user sees from the "library" or function files that they shouldn't/wouldn't see; so we decided to do this by using the still-somewhat-in-style-at-the-time form of .phtml files, and used the .php extension for "include" files made up of functions.

    We know this is a pain in the butt for many users who don't control their webserver; there is a workaround via the .htaccess file, but it's not the most optimal solution. One of the (many) goals for OpenRatings 2.0 is that all the files be named with the standard .php extension.

  7. What are all these "PR2_" variables? Or "pr2.db"? Shouldn't it be "or2.db"?

    Those extensions, like the .phtml thing, are there for historical purposes, and just never got changed (who wants to QA that?). It is a commonality among software that's been open sourced to find variable names that reference internally used products or APIs.

    This is the case with Mozilla (their code is sprinkled with classes that follow the form nsFoo for "Netscape"), and, ironically, Apple's OS X for "NextStep."

  8. I wanna help! What needs to be done?

    Here's a current (rough and incomplete) TODO list:

    • A flexible, orthogonal authentication system (preferably using PHP sessions.)
    • An administration interface, so tools/ becomes less important and multiple administrators can manage the site.
    • The course-creation code could be cleaned up.
    • The APIs for bulk adding professors and departments could use meaningful return/error values.
    • Making the number and type of questions asked about a professor more configurable would be nice.
    • Some sort of general verification that postings are coming from students and that those students took the class; this is gonna take some serious discussion before its implemented
    • Start on templatizing the site so it becomes actually easy to make site-specific HTML modifications.

    There are also a number of little buglets and architectural changes that really need to be worked on; check the developers' list or Bugzilla for more info on those.

The OpenRatings Organization © copyright 1998-2002 OpenRatings All rights reserved.