It'd be awesome to have a script to generate a bunch of seed data so that the website looks accurate locally.

Maybe it takes in arguments of how many players and the ratio of human:zombie.

Once #13 is merged we should set up travis with the .travis.yml file as:

python:
   - "3.6"

install:
   - pip install pipenv
   - pipenv install

script:
   - pipenv run python manage.py test```

Currently the "mobile" version of this site doesn't exist.

Features necessary for mobile:

• Player code & team
• Report tag/stun

Features important for mobile:

• Redeem supply code
• Missions & announcements
• Rules

Features nice-to-have for mobile:

• Map

Basically it should follow what's been set out for UserSignupView.

• Total # of stuns/tags registered throughout the game
• Ratio of humans/zombies throughout the week (implement graph from old php website)
• Zombie tree of that game

Should we add a reverse tag button for mods somewhere on mod dashboard/django admin, or should they just uncheck active checkbox on the tag to reverse it? Should we debate even deleting tags?

Checklist

• Edit email templates for game signups and initial game start emails
• Start game button (determines all OZs, starts game)
• Kill unsupplied humans button

Add ability to check for the same first and last name with different emails and quickly remove/merge duplicate accounts

Notes

• Only humans can have factions. Once a human turns into a zombie they are no longer part of that faction.
• Each faction has a unique ability to its players.

On mobile, the hamburger button and drop-down are interactable but appear flush with the white background. At first I thought it wasn't there on mobile, until I tried tapping where a hamburger usually is.

Need to clean that up and add:

• club newsletter posts made on Wagtail
• patch notes?
• twitter feed?

No one should be able to use their emailed signup invite when the game has started.

Checklist

• Expire all signup invite tokens
• Remove game signup form on frontend, display explanation to point to mods
• Hide volunteer UI?
• Manage Players page for mods:
  • Change add player form to directly create a player with their email and role chosen for them -> user signs up for website -> skip game signup step -> go straight to dashboard

• Choose desired # of total OZs
• Choose which players in OZ pool to be OZs
• Randomize [total - chosen] OZ players and submit list to backend for when game starts
• Make "Start Game" button use this list to make OZs with

e.g. change emails, change passwords, etc.

#100 🎉 ... except we have to upgrade Wagtail to v2.2.2 and fix several bugs.

Right now, we only have an Enum that contains Human, Zombie, and Spectator for the roles "players" can have. Ideally we can break it up so that Player strictly contains Human and Zombie, while Spectator (and potentially Moderator) are separate models.

Currently what I have is the concrete parent class Participant, with Player inheriting from it and containing a OneToOneField attached to Participant, but I'm not sure if Player should even inherit from Participant because of the way data might be grabbed during queries (e.g. will there be a JOIN between participant and player tables when I query for all player-type participants?) What's the best/optimal way to approach this?

Also, should we do a concrete base model, or give up easy queries on Participant in favor of having just an abstract base model that Player/Spectator/Moderator can inherit the fields of instead?

I assume we're doing csc hosting but that's not necessarily true. Perhaps google app engine (flexible environment to support 3.6?) or some AWS option would be better/easier.

reverse proxying is a pain in the neck and there's surely something we can do with a .htaccess file to make it work at some point. :\

Right now, there's no way to edit the contents of the initial signup emails, the signup reminder emails, and the initial human/zombie emails (although these ones could just be ported to making wagtail posts and having them be sent out when they're posted onto wagtail). We need to give mods the ability to change these so we don't have to do these manually.

I'd like to have a common.py, development.py, and a production.py settings file which uses environment variables to determine which to load.

Self-explanatory, I hope?

• add django mailman and add everyone to mailing lists
• get game start emails editable and sent by mods
• export csv of all emails in the human faction with the ability for it

Give mods the ability to:

• add/take away arbitrary points from any player or entire team
• modify supply code/zombie point values at any time and affect all stuns/tags from time enacted forwards
• make them human/zombie (provided by Django admin, but is there a better way to do this without exposing Django admin to non-webmasters?)

This way they can just select spectator to start off with.

Probably going to write something in d3.js for this.

EDIT: added with #91, but could be cleaned up better.

Issues were had when "[email protected]" was assigned mod status, but logging in with "[email protected]" didn't allow me to use any mod tools. This might relate to people not being able to sign in.

I haven't looked much into how it's stored in DB, but ideally every email address should be stored as lowercase, with verification being a non-case-sensitive comparison.

Look into refactoring scss (especially for landing page) and perhaps moving farther away from using bootstrap 4.0 components throughout the site. Definitely not until after v1.0 release.

• Add search for code name
• Add date generated, date claimed, and claimed_by read-only fields

Looks ugly, needs to be constantly updated for the different game states, should probably fix.

Also, add:

• club newsletters
• this term's current mod/exec team
• different states for when a game is active, running, etc.

Give people the option to hide their email in the player list, with it defaulted to hide emails. Mods can see emails regardless.

Currently with the way the test helpers tag_tester and user_tester are set up and no longer updated to reflect the current state of the codebase, all tests are false negatives.

Right now mods are using BCC on a large list of emails for sending messages to humans and zombies, which has come up with its own crop of issues. With how this term's email system has broken down to bugs, delays, blocked messages, and much more (thanks Gmail?), I think we need to revisit adding players to the CSC mailing lists so they have only one email address to send to, and also perhaps Gmail won't just block the emails either. @tso want your opinion on this.

• Calculate points humans have available to spend at the rewards store
• Deem players as supplied the moment they reached 5pts, but never remove status if they ever go below (this should be easy, we should just separate score from "spendable points" and only check status on score attribute)
• Display what rewards are available at the rewards store
• Schedule of when rewards are able to be collected from mods
• (Human dashboard) list of rewards they've obtained?

Let's solidify our URL assumptions: dashboard/* assumes we are talking about the most recent game
and requires a running game.

We probably want to have a /games (or some other name, doesn't matter to me) view with subpages like /games/<game uuid>/zombie-tree.

We probably also want to somehow hook up mission/announcements history, but that might be a bit painful.

Perhaps make past games viewable only by those who participated in them? Not sure!

Not sure what this looks like. Depends on #17.

Optional, low priority addition: let mods customize email template text for those emails?

Add sitewide dark theme/night mode for users, and have that also propagate on mobile.

Give mods the ability to kill all unsupplied humans at end of the week before final mission (with modal to make sure they want to confirm this decision).

For fall term/v2.0, since it's a bit too late now.

This won't happen until after the Spring 2018 weeklong is over though.