clean up formatting of the retrospective

1 files changed, 198 insertions, 180 deletions

diff --git a/doc/Sprint3-Retrospective.md b/doc/Sprint3-Retrospective.md
index 5862a10..6dbb1f3 100644
--- a/doc/Sprint3-Retrospective.md
+++ b/doc/Sprint3-Retrospective.md
@@ -1,4 +1,4 @@
----
+ ---
 title: "Team 6 - Project Leaguer: Sprint 3 Retrospective"
 author: [ Nathaniel Foy, Guntas Grewal, Tomer Kimia, Andrew Murrell, Luke Shumaker, Davis Webb ]
 ---
@@ -55,218 +55,236 @@ several days.
 +---------------------------------------------------------+------+------------+----+
 | Tasks Not Implemented                                   | Size | Person     | US |
 +=========================================================+======+============+====+
-| [Nothing cause we are great](#success)                  | 0    | ---        | 0  |
+| [None](#success)                                        | 0    | --         | 0  |
 +---------------------------------------------------------+------+------------+----+
 
-
-# [How to improve](#improve)
-
-
+[How to improve](#improve)
 
 # Implemented and working
 
-## Intelligent Error Handling (#error-hand)
+## Intelligent Error Handling {#error-hand}
 
-Several important cases for error redirection were handled via standard permissions
-changes and in the end only a few specific redirections needed to be coded directly
-(such as correctly handling redirections away from a destoryed tournament or match).
+Several important cases for error redirection were handled via
+standard permissions changes and in the end only a few specific
+redirections needed to be coded directly (such as correctly handling
+redirections away from a destoryed tournament or match).
 
-## Search (#search)
+## Search {#search}
 
-A basic SearchController and simple view were implemented.  The search controller
-took the query, and queried the "name" columns in the user and tournament database
-tables.  An "advanced" search mode allows filtering tournaments by game type.  We
-would like to be able to search based on other parameters and settings of the
-tournament, and other user attributes.
+A basic SearchController and simple view were implemented.  The search
+controller took the query, and queried the "name" columns in the user
+and tournament database tables.  An "advanced" search mode allows
+filtering tournaments by game type.  We would like to be able to
+search based on other parameters and settings of the tournament, and
+other user attributes.
 
-To more easily render the search results, we moved the tournament and player
-display blocks from their respective index pages to be shared, to display them
-consistently, and avoid code duplication.
+To more easily render the search results, we moved the tournament and
+player display blocks from their respective index pages to be shared,
+to display them consistently, and avoid code duplication.
 
-## Email verification (#email-varify)
+## Email verification {#email-verify}
 
 Email verification was (finally) implemented.  It uses delayed_job
 (see [asynchronous Riot pulls](#async)) to avoid blocking the page if
 the MX isn't responding.  However, email password resets are not yet
 implemented, which is the obvious use-case for verified emails.
 
-## Alternate Scoring and pairing methods (#alt-score-par)
+## Alternate Scoring and pairing methods {#alt-score-par}
 
-We overhaulted the entire tournament structure and introduced a modular/pluggable
-system for seeding, scheduling, sampling, and scoring, lovingly called the 4S-Module
-System.  We relocated code from other places into these modules in the 'lib'
-directory including form HTML which is retrieved dynamically from these modules.
-In the case of sampling (retrieving and populating statistics for scoring) we built
-an intelligent system for populating available modules for a game-type based on the
-statistics needed for its scoring methods which replaced their manual configuration.
-We introduced Tournament Stages to accomodate a wider range of tournament types
-and modes and designed the library modules to be general enough to use results of
-past stages or player statistics to affect future ones.
+We overhaulted the entire tournament structure and introduced a
+modular/pluggable system for seeding, scheduling, sampling, and
+scoring, lovingly called the 4S-Module System.  We relocated code from
+other places into these modules in the 'lib' directory including form
+HTML which is retrieved dynamically from these modules.  In the case
+of sampling (retrieving and populating statistics for scoring) we
+built an intelligent system for populating available modules for a
+game-type based on the statistics needed for its scoring methods which
+replaced their manual configuration.  We introduced Tournament Stages
+to accomodate a wider range of tournament types and modes and designed
+the library modules to be general enough to use results of past stages
+or player statistics to affect future ones.
 
-## More types of seeded settings (#seed)
+## More types of seeded settings {#seed}
 
 We implemented seeding for initial placement of players within a tournament as part
 of the 4S-Module System. Three seeding modules were implemented.
 
-	I.  Early bird
-		- Team rosters are based on order of registration for the tournament.
-
-	II.  Random
-		- Team rosters are randomized.
-
-	III.  Fair Ranked
-		- Players are distributed evenly on teams according to their performance in
-		the previous tournament stage. This method only works for tournaments with
-		multiple stages.
-
-## Asynchronous Riot Pulls (#async)
-
-Prior to this iteration, calls to the Riot Games API here hard-coded, and blocked
-the page from loading while the requests were made.  We needed to (1) create an
-interface for doing this flexibly (2) make the calls asynchrounous to avoid blocking
-the page load.  To perform the asynchronous requets, we used the "delayed_job" gem
-to run each request as a separate job process.  A challenge with this was that most
-API's (including Riot Games') place an artifical limit on API requests within a
-given period of time (in the case of Riot Games, 10 requests per 10 seconds, and
-500 per 10 minutes).  So the background job making requests must be throttled from
-making too many within several given rolling blocks of unit time.  To do this,
-we implemented a ThrottledApiRequest base class that makes it simple to create
-throttled asynchronous API requests, which we used to create the "RiotAPI" sampling
-method, but is applicable in a much wider variety of situations.
-
-## Map out brackets scaffolding (#brack-scaff)
-
-Brackets are structures that have a users' prediction of the winners of a 
-tournaments matches. Essentially, a tournament has many brackets, each bracket has
-a user that creates it, and each bracket has bracket-matches that correspond to the
-matches of the tournament the bracket belongs to. Bracket matches are only models, 
-as the user should be able to predit all winners from a single view that belongs to
-a bracket. Brackets on the other hand have a model, controller, and views, so that
-users may create, edit, and view them.
-
-## Create braket creation and submission gui (#brack-gui)
-
-The bracket creation gui looks simple to the user, but does a lot on the backend.
-When the user presses "Make a bracket" on a tournament, a bracket is created based
-on the user, the tournament, and the tournament's matches. The bracket's submission
-GUI looks a lot like an elimination tournament's SVG, however the user is able to
-click on teams to advance them forward. The SVG has javascript functions that both
-advance the teams visually on the SVG, and write the user's prediction in a hidden
-form. When the user clicks submit, the predictions are saved in the bracket's 
-matches.
-
-## General Interface Cleanups (#interface-clean)
-
-Project Leaguer better handled tournament interface in this iteration.  Tournaments
-are listed more cleanly on the index page.  Each game type has an icon listed with
-it to better identify different game types on the index page.  Each tournament's
-host's gravatar is also listed on the index page.  Creating a tournament itself is
-also cleaner.  Customization categories are clearly separated and use the correct
+ 1. Early bird - Team rosters are based on order of registration for
+    the tournament.
+ 2. Random - Team rosters are randomized.
+ 3. Fair Ranked - Players are distributed evenly on teams according to
+    their performance in the previous tournament stage. This method
+    only works for tournaments with multiple stages.
+
+## Asynchronous Riot Pulls {#async}
+
+Prior to this iteration, calls to the Riot Games API here hard-coded,
+and blocked the page from loading while the requests were made.  We
+needed to (1) create an interface for doing this flexibly (2) make the
+calls asynchrounous to avoid blocking the page load.  To perform the
+asynchronous requets, we used the "delayed_job" gem to run each
+request as a separate job process.  A challenge with this was that
+most API's (including Riot Games') place an artifical limit on API
+requests within a given period of time (in the case of Riot Games, 10
+requests per 10 seconds, and 500 per 10 minutes).  So the background
+job making requests must be throttled from making too many within
+several given rolling blocks of unit time.  To do this, we implemented
+a ThrottledApiRequest base class that makes it simple to create
+throttled asynchronous API requests, which we used to create the
+"RiotAPI" sampling method, but is applicable in a much wider variety
+of situations.
+
+## Map out brackets scaffolding {#brack-scaff}
+
+Brackets are structures that have a users' prediction of the winners
+of a tournaments matches. Essentially, a tournament has many brackets,
+each bracket has a user that creates it, and each bracket has
+bracket-matches that correspond to the matches of the tournament the
+bracket belongs to. Bracket matches are only models, as the user
+should be able to predit all winners from a single view that belongs
+to a bracket. Brackets on the other hand have a model, controller, and
+views, so that users may create, edit, and view them.
+
+## Create braket creation and submission gui {#brack-gui}
+
+The bracket creation gui looks simple to the user, but does a lot on
+the backend.  When the user presses "Make a bracket" on a tournament,
+a bracket is created based on the user, the tournament, and the
+tournament's matches. The bracket's submission GUI looks a lot like an
+elimination tournament's SVG, however the user is able to click on
+teams to advance them forward. The SVG has javascript functions that
+both advance the teams visually on the SVG, and write the user's
+prediction in a hidden form. When the user clicks submit, the
+predictions are saved in the bracket's matches.
+
+## General Interface Cleanups {#interface-clean}
+
+Project Leaguer better handled tournament interface in this iteration.
+Tournaments are listed more cleanly on the index page.  Each game type
+has an icon listed with it to better identify different game types on
+the index page.  Each tournament's host's gravatar is also listed on
+the index page.  Creating a tournament itself is also cleaner.
+Customization categories are clearly separated and use the correct
 selection or input types for easy use.
 
-## Make it look professional (#professional)
-
-The team decided on a color scheme for Leaguer during this sprint. This scheme
-was applied to every page in the site. Since e-sport players often spend hours in
-front of screens, it was important to reduce eye strain by making our interface dark
-while keeping it sleek and modern. We implemented Gravatar in a few more spots as
-well, helping to distinguish between users more easily.  he default image was
-changed to give each user a unique avatar even if they've not set one. Tournament
-creation and listing also received tune ups, with images listed with each tournament
-to help display its game type and a better creation page when creating a tournament.
-
-## Expand Peer Evaluation (#peer-expansion)
-
-We created a scoring modules for users to select the preferred scoring method and 
-preferred peer evaluation for users to choose from when creating a tournament.
-The peer evaluation modules calculate the score correctly and grab the 
-statistics from the submission forms. The skeletons for three such scoring methods 
-namely, winnerTakesAll, FibonacciPeerWithBlowout, MarginalPeer, have been created.
-For the MarginalPeer we do not have a view but we do have the methods that would 
-calculate the score provided the stats are in the database. For WinnerTakesAll and
-FibonacciWithPeerBlowout we do have views and data being collected from the interface
-and used to calculate score.
-
-## Private Messages (#priv-messages)
-
-Private Messsaging in Project Leaguer is possible between two registered users.
-Project Leaguer uses the gem 'Mailboxer' to achieve private messaging. A user
-is able to interact with the private messaging system by clicking on the "Messages"
-located in the header toolbar at the top of every page. This results in the index
-page, which lists all unread and read conversations. You can then click on a 
-conversation to view all of its messages and from there you can also reply.
-Creating a new message is as simple as: click the "start a new conversation",
-list the user you wish to pm with, write the conversation's subject, and write
-the message itself.
-
-## Alerts (#alerts)
-
-The alerts system was implemented with the help of the 'Mailboxer' gem which 
-is the same as the private message system. The Alert system was made available to
-anyone who had permissions to create an alert and all users were notified when an 
-alert was created with a live update, a pop up notification which redirects to the
-list of alerts, in the navigation bar of the recieving users. The alerts icon 
-appeared only when there is a new alert. 
+## Make it look professional {#professional}
+
+The team decided on a color scheme for Leaguer during this
+sprint. This scheme was applied to every page in the site. Since
+e-sport players often spend hours in front of screens, it was
+important to reduce eye strain by making our interface dark while
+keeping it sleek and modern. We implemented Gravatar in a few more
+spots as well, helping to distinguish between users more easily.  he
+default image was changed to give each user a unique avatar even if
+they've not set one. Tournament creation and listing also received
+tune ups, with images listed with each tournament to help display its
+game type and a better creation page when creating a tournament.
+
+## Expand Peer Evaluation {#peer-expansion}
+
+We created a scoring modules for users to select the preferred scoring
+method and preferred peer evaluation for users to choose from when
+creating a tournament.  The peer evaluation modules calculate the
+score correctly and grab the statistics from the submission forms. The
+skeletons for three such scoring methods namely, winnerTakesAll,
+FibonacciPeerWithBlowout, MarginalPeer, have been created.  For the
+MarginalPeer we do not have a view but we do have the methods that
+would calculate the score provided the stats are in the database. For
+WinnerTakesAll and FibonacciWithPeerBlowout we do have views and data
+being collected from the interface and used to calculate score.
+
+## Private Messages {#priv-messages}
+
+Private Messsaging in Project Leaguer is possible between two
+registered users.  Project Leaguer uses the gem 'Mailboxer' to achieve
+private messaging. A user is able to interact with the private
+messaging system by clicking on the "Messages" located in the header
+toolbar at the top of every page. This results in the index page,
+which lists all unread and read conversations. You can then click on a
+conversation to view all of its messages and from there you can also
+reply.  Creating a new message is as simple as: click the "start a new
+conversation", list the user you wish to pm with, write the
+conversation's subject, and write the message itself.
+
+## Alerts {#alerts}
+
+The alerts system was implemented with the help of the 'Mailboxer' gem
+which is the same as the private message system. The Alert system was
+made available to anyone who had permissions to create an alert and
+all users were notified when an alert was created with a live update,
+a pop up notification which redirects to the list of alerts, in the
+navigation bar of the recieving users. The alerts icon appeared only
+when there is a new alert.
 
 # Implemented but not working well
 
-## Expand Peer Evaluation (#peer-expansion)
-
-We created scoring modules for users to select the preferred scoring method,
-including options for peer review, during tournament creation. We created three
-scoring modules: winnerTakesAll, FibonacciPeerWithBlowout, and MarginalPeer, two
-of which work. Since winnerTakesAll and FibonacciPeerWithBlowout demonstrated the
-extremes, the testing of MarginalPeer was considered low priority. As a whole the
-scoring modules' interface, outlined in the 4S-Module README for scoring was
-designed much better than than our implementations were able to show off by the
-end of the sprint.
-
-## Remote Game UserNames (#remote_user)
-
-Project Leaguer stores for each user and game-type a reference to a remote username.
-This allows a user to register her accounts with the system and for API requests to
-be completed for a registered game-type. The interface for this was only partially
-completed, and being integrated into a player's profile page directly, it only
+## Expand Peer Evaluation {#peer-expansion}
+
+We created scoring modules for users to select the preferred scoring
+method, including options for peer review, during tournament
+creation. We created three scoring modules: winnerTakesAll,
+FibonacciPeerWithBlowout, and MarginalPeer, two of which work. Since
+winnerTakesAll and FibonacciPeerWithBlowout demonstrated the extremes,
+the testing of MarginalPeer was considered low priority. As a whole
+the scoring modules' interface, outlined in the 4S-Module README for
+scoring was designed much better than than our implementations were
+able to show off by the end of the sprint.
+
+## Remote Game UserNames {#remote_user}
+
+Project Leaguer stores for each user and game-type a reference to a
+remote username.  This allows a user to register her accounts with the
+system and for API requests to be completed for a registered
+game-type. The interface for this was only partially completed, and
+being integrated into a player's profile page directly, it only
 allowed registration of League of Legends remote usernames.
 
-## Project Leaguer Logo (#logo))
+## Project Leaguer Logo {#logo}
 
-While a suitable logo was created, it was deemed too unprofessional for use by the
-project at this time. The search for a more amicable logo remains underway.
+While a suitable logo was created, it was deemed too unprofessional
+for use by the project at this time. The search for a more amicable
+logo remains underway.
 
-## Tournament preference interface (#tourn-prefer)
+## Tournament preference interface {#tourn-prefer}
 
-Tournament Settings are handled correctly and securely, the permission system is
-robust enough to handle custom preferences, the database structure exists to
-handle them, and even the icons for adding them were created, however, the interface
-for adding them was deemed low priority for this sprint in comparison to the lib
-modules and permissions overhauls.
+Tournament Settings are handled correctly and securely, the permission
+system is robust enough to handle custom preferences, the database
+structure exists to handle them, and even the icons for adding them
+were created, however, the interface for adding them was deemed low
+priority for this sprint in comparison to the lib modules and
+permissions overhauls.
 
-# Not implemented
+# Not implemented {#success}
 
 We implemented everything we planned to implement and much more.
 
-# How to improve (#improve)
-
-1. In this sprint our primary mistake was in planning. We were too nonspecific in
-deciding what to get done and accepted too many tasks as essential. We should have
-scaled down our efforts and focused on only the most essential tasks. In the future,
-more time will be spent on designing and planning sprints and dividing workload.
-
-2. Also because of last-minute alterations and refactors, nearly EVERYTHING that
-could have gone wrong in our presentation went wrong (the wifi connectivity dropped,
-our presentation server on demo.projectleaguer.net wasn't updating, even Andrew's
-window manager segfaulted). Much of this could have been fixed if we simply a little
-better prepared and had frozen our codebase a specified time prior to the
-presentation. Realistically, things would have worked phenomenally better had we
-another few hours to prepare for the presentation. In the future when presenting to
-potential users or stakeholders we will be sure to have a practiced presentation to
-match the polished codebase which will then be able to speak for itself.
-
-3. We can better plan our project's flow and layout. We refactored a lot of code in
-this sprint because different methods didn't work together as we thought they would.
-We spent a lot of time reworking things that should have already been complete
-simply because of incomptability issues; the transitions between steps in our flow
-didn't function as we intended. Moving forward, we have more time to ensure that
-components work together properly and are tested in a more
-comprehensive manner.
+# How to improve {#improve}
+
+1. In this sprint our primary mistake was in planning. We were too
+   nonspecific in deciding what to get done and accepted too many
+   tasks as essential. We should have scaled down our efforts and
+   focused on only the most essential tasks. In the future, more time
+   will be spent on designing and planning sprints and dividing
+   workload.
+
+2. Also because of last-minute alterations and refactors, nearly
+   EVERYTHING that could have gone wrong in our presentation went
+   wrong (the wifi connectivity dropped, our presentation server on
+   demo.projectleaguer.net wasn't updating, even Andrew's window
+   manager segfaulted). Much of this could have been fixed if we
+   simply a little better prepared and had frozen our codebase a
+   specified time prior to the presentation. Realistically, things
+   would have worked phenomenally better had we another few hours to
+   prepare for the presentation. In the future when presenting to
+   potential users or stakeholders we will be sure to have a practiced
+   presentation to match the polished codebase which will then be able
+   to speak for itself.
+
+3. We can better plan our project's flow and layout. We refactored a
+   lot of code in this sprint because different methods didn't work
+   together as we thought they would.  We spent a lot of time
+   reworking things that should have already been complete simply
+   because of incomptability issues; the transitions between steps in
+   our flow didn't function as we intended. Moving forward, we have
+   more time to ensure that components work together properly and are
+   tested in a more comprehensive manner.