Currently, scraping for results, loading the results into the database, and grading the previous week's picks must all be run manually. It would be ideal if the application was set-up to automatically handle those tasks. (Or to create cron tasks and an install script for the user)

Many users requested that the default of an unselected point value is not intuitive to used. This is currently being used to determine unselected picks. Instead, the team selection should be used to denote a "selected" vs. an "unselected" pick. This will allow the points to default to 1 on the pick form.

The user needs to be given some information about the distribution of points for a given week.

The client side application is basic Bootstrap at the moment and could use some customization.

Gorp is a fantastic library, but I'd like to eliminate as many 3rd party dependencies as I can and try to do things with just the std lib.

Everybody loves the spreadsheet view of everyone's picks so that they can track how they are doing relative to everyone else. It wouldn't be that hard to implement something similar for the application.

The standings table on the front page is a direct query on the backing data. This causes issues when live updating results, as it thinks the week is "over" and incorrectly reports the standings. In this type of pool, a week isn't meaningful until it is over. There needs to be some logic to show the previous week, (and don't forget to protect the edge case of week 1), instead of the current "at this moment" standings.

The python script that scrapes the NFL's website and extracts the games for a season does not store the timestamps with timezone information. This causes headaches when trying to calculate whether or not a game has already started and cannot be picked. Currently, this is worked around in the app, but it would be ideal for future years to store the timezone correctly

There needs to be a way to create test weeks for offseason testing. This is probably a combined effort with a generation tool, changes to the code to accept more parameters to give me control of testing, and some template changes.

Implement a week-by-week standings view that is like the year spreadsheet sent out when manually grading picks.

If a week is in progress, the standings calculation takes it into account as an actual finished week score, causing the current week to be counted as the lowest week and dropped. While this isn't technically inaccurate, it's rather misleading until more games have been completed.

The Picks form is verified only on the server side, and has no easy way to restore a users picks if they make an error.

The server side verification routine fails if a user submits picks in chunks. The routine only looks at picks submitted during a given session, rather than new AND old picks.

Currently, if a user does not submit any picks for a given week all games are marked as "incorrect". This in of itself is not a problem, however the method for calculating the lowest week in the SQL query cannot account for this. Due to the week not having any correct picks, a row is not generated by the query representing that week. MIN should be the empty week, however it becomes another non-empty week. I think I can fix this by adjusting the SQL query to preserve the 0 point weeks.

The SQL statement attempts to calculate the lowest week and remove it, per the NFL pool rules. Unfortunately, if the minimum is not unique it subtracts both weeks.

It's really tough to work on the application when the NFL season is not current as the app will crash trying to figure out the current week/year. The main landing pages need to be able to detect we're not in a season and display a message rather than just crash.

Some thoughts:

• % correct of the various point levels
• Team by team pick accuracy.
• Overall pick accuracy (points possible and straight up)

The picks form contains logic to lock the form elements based on whether or not the game has started; however, there's a bug in my logic somewhere. I can't remember the behavior that I saw, so this is currently just a note to double check that block of code.

If all games are not finished, the weekly scores scraper is unable to correctly scrap the scores for the completed games due to the NFL's "next game" HTML element.

There's no need to save CPU power by statically generating the results and navbar page. Doing so requires an app restart to update the "view" from week to week.

A few helper functions were created to reduce code duplication and clean up the handlers in the v0.1-beta release. Not all helper functions were modified to use these functions.