Module Evaluation Criteria

Central Web Services reviews all modules that are included as part of the centralized OSU installation.  We do this to ensure that OSU Drupal remains a stable, secure and supportable product for the campus.  The following are the initial criteria we use to evaluate a module.

  • Code Review:
    1. Are there any pending security bugs in the bug tracker?  What are they and how long have they been there?
    2. Is it performing sql queries directly? If so, does the module escape user input?
    3. How does it handle user input? Is it being escaped? Is user input cleaned before printing it out in a page?
    4. Are permissions check in place? Are the checks manual or does the code rely on other core methods?
    5. Is the code well documented? Does it follow a standard?
    6. Is the javascript code and css well structured?  Does it follow follow a standard?
    7. Does it have readme, install and upgrade files?
  • Lifespan/Activity:
    1. How long has this module or 3rd party program been around?
    2. How many developers are working on it?
    3. Is there a roadmap? What does it look like?
    4. What is the release life cycle?
    5. What is the average turn around time for critical bugs?
    6. How active are the forums or mailing list discussions?
    7. Do other programs use or depend on this library?
  • Support:
    1. Is there user documentation? Is there documentation for developers?
    2. Is a documentation generation system like phpDocumentor used?
    3. How quickly do the developers respond to requests?
    4. Are newer and older versions of Drupal supported?
    5. What is the learning curve like?
    6. Is the module usable through the Drupal interface or does it require users to work with HTML, CSS, theme changes or other advanced techniques?
  • Compatibility:
    1. Does it conflict with other existing plugins or modules or other updates?
  • Cost/Benefit:
    1. Will the module work with OSU Drupal as is, or would some re-write be needed?
    2. How complex are patches to apply? (# of classes, files, and db tables affected)
    3. What % of our users would benefit from this new module or plugin?
  • Redundancy
    1. Does OSU/CWS already provide this service?
    2. Is this capability already planned for an upcoming Drupal release or update of a currently supported module?

If you would like to request a module for review, please submit a help ticket.