Skip to content

Latest commit

 

History

History
78 lines (72 loc) · 4.41 KB

TODO.md

File metadata and controls

78 lines (72 loc) · 4.41 KB
Raw

To dos

  • Connect up to a Redis server, configured with disk persistence (check Heroku offering configs)
  • Write script to dump contents of JSON file into Redis
  • Display a Redis entry at GET /proposals/:id
    • Show Title, Abstract, Long Description, Notes for Committee prominently;
    • Hide everything else like travel support under JS pointy clicky fold
  • Update a proposal's Title, Abstract, Long Description, or Notes For Committee at POST /proposals/:id
  • Display list of all proposals by title at GET /proposals
  • Indicate that a proposal has been modified with a * appended to its title at GET /proposals -- descope if too annoying
  • Find a Node library to handle user authentication -- (Ended up choosing Passport)
  • Set up basic auth for Admin and Reviewer user types; everyone has same privileges for MVP
  • Add auth checks to all existing endpoints
  • Create Review model:
    • Reviewer
    • Proposal
    • Rating (1-5)
    • Discard (Bool)
    • Internal Notes (string)
  • Add ability to add a review, at POST /proposals/:id/review
  • Persist reviews in Redis only
  • Compute running average on a Proposal, add to Proposal model, update every time a Review is added/updated/deleted Descoping this, because it's easier and more maintainable to write a query than to maintain a running average
  • Edit a review
  • Delete a review
  • Mark a proposal as Rejected if it receives N number of Discard votes Going to descope for now; a low average rating is sufficient to show rejection, for MVP (start with hard-coding to 2)
  • Display all reviews for a proposal at GET /proposals/:id/reviews
  • Add ability for Admin to assign proposals to certain Reviewers
  • Don't let the same person review a talk twice
  • A logged-in reviewer should see a visual separation at GET / so that proposals assigned to them to review are at the top, and other proposals are below
  • Add visual separation between proposals that have been reviewed, and proposals pending review, on GET /
  • Randomize the order in which assigned reviews show up on the dashboard Redis fetching is weird and random enough
  • Build an Admin view of the state of all proposals:
    • Completely rated proposals ordered from highest to lowest average score
    • Discarded proposals visually separated
    • Proposals pending reviews visually separated, and names of assigned Reviewers
    • Some visual indication of proposals with large deltas between reviews ("Controversial"?)
    • Dotted line to show cut-off point for top N proposals (start with hard-coding 25)
  • Add validation for required fields for reviews
  • Do some CSS...
  • Don't show 'New Review' form at bottom of GET /proposal/:id if a user has already submitted a review
  • Implement Discard logic: If a talk receives two discard votes, it should be removed from further assignments with visual separation
  • Configurable discard threshold
  • Tiered privileges: Admin and Reviewer. Don't show "Edit Proposal" to reviewer
  • Tidy up JavaScript styles - use ES6 lambdas consistently
  • Convert callbacks within routes to top-level pure functions and move into shared helper, esp the "getAverage" function
  • Add (better) error checking for Redis-side errors
  • Clean up route logic
  • Maybe split out some duplicated views into reusable components
  • Implement that pattern where response object is pre-seeded with user
  • Add authentication to seeding and assignment endpoints
  • Check if Papercall export preserves linebreaks; if so, find NPM library to render markdown with linebreaks for proposal fields

MVP notes

  • Users should only have one role type. We can create multiple user accounts and give people the credentials if they need to swap between Admin and Reviewer
  • Discard threshold and cut-off point should be configurable eventually
  • Set up Heroku Redis backups for every 1h during Feb 20-27 Be a hacker and manually run redis-dump from my computer once a day

Stuff I should probably do later

  • Change Redis data model from string to hash for proposals and reviews
  • Memoize expensive Redis queries - done partially. On further exploration, redis.keys is the only concerning query (at a certain scale), and we actually want to do fresh pulls for things like the rankings page. It's partly implemented but can use a lot of improvement.