Wikimania Scholarships app/Cleanup sprint

Sprint 1: Cleanup existing code

 * Duration
 * 2013-10-23 through 2013-11-08


 * Team
 * Bryan Davis, Chad "^demon" Horohoe (consultant), Katie Filbert (consultant)


 * Sprint Goal
 * Have a functioning version of the existing application running in Labs with major code cleanliness and security concerns addressed.


 * Scope
 * Core functionality of the existing application, namely providing a data entry form with validation for requesting a scholarship and supporting a simple workflow for reviewers to triage and approve/decline requests.


 * Sprint review
 * 2013-11-12T19:00Z via google hangout

Primary concerns to be addressed

 * Robust and secure data access layer
 * PDO or possibly Doctrine DBAL
 * Robust and secure template layer
 * Twig is a likely candidate
 * Minimize number of files exposed via document root
 * Strong separation of code from configuration
 * Secure password storage for reviewers
 * Current unsalted md5 is unacceptable

Tasks

 * ✅ Move index.php and static content into a directory
 * ✅ Cleanup database schema
 * ✅ Make everything use routes
 * ✅ Move session initialization to router script
 * ✅ Securely delete session on logout
 * ✅ Format with code-utils/stylize.php
 * ✅ Change passwords to use crypt with Blowfish
 * ✅ Convert database calls to PDO
 * ✅ Implement Twig template engine & Slim framework
 * ✅ Convert application form
 * ✅ Convert public facing collateral pages (credits, privacy, contact, translate)
 * ✅ Convert reviewer pages
 * ✅ Convert user management pages
 * ✅ Move PHPMAILER to vendor directory
 * ✅ Convert to use autoloading
 * ✅ Change the way that Lang finds/loads localization files
 * Set include_path externally (not needed after other refactoring)
 * ✅ Custom 404 page
 * ✅ Deal with unhandled exceptions
 * Still possible to break things with an error in the error handler :(

Backlog
The backlog is a list of tasks that could/should be done discovered during the sprint. These are considered stretch goals and any unfinished at the end of the sprint will be considered for inclusion in the next increment.


 * Localization issues
 * Make sure l10n files and workflow is compatible with translatewiki
 * Make language choice sticky via session storage of selected language
 * Add l10n of country names for application form
 * Create Twig filter/function to handle string localization
 * Country/region information updates needed
 * Use ISO country codes instead of a random numeric id to reference countries
 * Get region data into to country table
 * Might be nice to expose a country editing system via web UI for fixing this up and keeping maintained.
 * Error and logging enhancements
 * Expose global logger to form, dao, etc in a reasonable way (DI?)
 * Add logging for errors and warnings
 * Localize user facing error pages (fatal, 404)
 * Testing enhancements
 * We should have at least a happy path round trip test for filling out an application
 * Production hardening
 * Find out if it is the app's responsibility to ensure that php.ini is setting up sessions securely (good hash, http-only, etc)
 * UI/UX enhancements
 * Css and markup could be cleaned up (bootstrap?)
 * Navigation for reviewers is confusing
 * Establish requirements for reviewer workflow
 * Current process is not completely clear, but seems to be a 3 phase gated process:
 * "Phase 1" is a spam screen with each reviewer giving 0-1 points to application
 * "Phase 2" begins when an application has gathered 3 points, now all reviewers can rank on several additional criteria
 * "Phase 3" is final decision to approve or deny application, not currently implemented as far as I can tell
 * This phase was hard coded into the bulk mailer components that were stripped out in the cleanup sprint based on scoring models implemented in sql layer
 * Additional SQL query cleanup is needed.
 * There is a lot of cut-n-paste subquery code
 * Hardcoded constants in scoring formulas seem problematic for tweaking models
 * A few string concatenations remain in the query builder
 * Auth layer is barely implemented. Authentication is handled reasonably well but authorization is ad hoc and fragile.
 * This may be better with most recent changes, but likely is not complete. Need to better understand the required privilege classes.
 * Should be more clear after establishing the reviewed workflow
 * Replacement/requirements for bulk mail functionality
 * Legacy code for this was ... less than ideal (eg manual editing of php source to put the template message in, no send rate limit).
 * It also looks like every year they invented a new way to decide which applications should get which message.
 * Create a basic "grid display" controller that handles the plumbing for paging and displaying results (and sorting?)