Merge branch 'master' of https://github.com/csc301-winter-2019/project-team-02

3 files changed, 58 insertions, 3 deletions

diff --git a/deliverables/README.md b/deliverables/README.md
index ee9e9f6..b86ada8 100644
--- a/deliverables/README.md
+++ b/deliverables/README.md
@@ -5,11 +5,12 @@ Help the Homeless is a web and mobile application that allows homeless shelters
 
 ## Key Features
 * Users can send their location using the app to report where a homeless person is.
-* Users can fill out details about the homeless person before reporting them.
+* Users are required to fill out details of the homeless person before submitting in order to help authorities identify the specific individual. User Location and Drop Pin both redirect to the form a user would have to fill out. 
 * Users from Street To Homes can view a map and see point markers overlayed on the map which represent where users of the app have submitted locations of homeless people.
 * This map is live-updating, so no refresh required.
 * Clicking on a point marker on the map brings up detailed information about the homeless person at that location.
-* 'Drop Pin' was not implemented in this iteration, although the button was made and added to our app for future use. This button currently has no functionality, but once fully implemented will allow users to select a location on the map themselves and place a pin there indicating there is a homeless person who requires help.
+* Drop Pin option allows users to place marker at location of homeless person on a map of Toronto, bypassing the need for user location. 
+*When viewing the spread of points on the map, users with access to this side can now sort between pending reports and completed reports. The markers are also colour co-ordinated to make it easier for users to tell.
 
 ## Basic instructions
 ### Web application
diff --git a/deliverables/iteration-03-plan.md b/deliverables/iteration-03-plan.md
index 418e387..cbfcdfc 100644
--- a/deliverables/iteration-03-plan.md
+++ b/deliverables/iteration-03-plan.md
@@ -3,7 +3,7 @@
 ## Iteration XX
 
  * Start date: Mar 12
- * End date: Mar 22?
+ * End date: Mar 29
 
 ## Process
 
@@ -11,6 +11,7 @@
 
  * Having a dedicated day for testing so that branches are kept up to date and master is getting consistently updated with new code. We didn't do this in the last iteration and we think it led to a bunch of code conflicts. We hope that by testing regularly, we can get code pushed to appropriate places rather than letting it just sit in its branch.
  We will be able to see if this is effective by doing a search in GitHub commits with message "resolving conflicts". (We usually put something similar in conflict merges).
+ * We will create a recurring Slack reminder in the general channel which will notify us every night to check Pull Requests. Additionally, when a developer creates a new PR, they will individually notify the reviews on Slack with the link requesting for review. This is so that tasks get to the testing phase quicker, and therefore end up getting merged back into master quicker => new tasks will have the latest master.
 
  #### Roles & responsibilities
 
@@ -48,3 +49,4 @@ Additionally, we now have staging and production deployments for the mobile side
 
  * A mobile application with the latest master branch deployed on Appetize, or a real phone (if permitted).
  * A interactive web application with the latest master branch deployed on Heroku.
+
diff --git a/deliverables/iteration-03-review.md b/deliverables/iteration-03-review.md
new file mode 100644
index 0000000..e104248
--- /dev/null
+++ b/deliverables/iteration-03-review.md
@@ -0,0 +1,52 @@
+# Helpthehome by The Dream Team
+
+## Iteration 3 - Review & Retrospect
+
+ * When: Friday March 29th @ 3:00pm
+ * Where: BA 3200
+
+## Process - Reflection
+
+#### Decisions that turned out well
+
+ * The decision to swap mobile and web roles was a good decision because it allowed team members to get an understanding of both sides of the application. This resulted in a quicker update meeting because all team members got exposure to all parts of the application. Before switching our updates lasted on average 10-15 minutes, but after switching our updates lasted on average 5-10 minutes.
+ * The decision to dedicate 30-45 minutes of every weekly meeting was a good decision because it improved the test coverage on our application and helped identify bugs early on. For example, we were able to identify a bug during our weekly testing in retrieving location services that caused the application to crash and we were able to fix it before merging into the master branch. This saved us the headache of potentially trying to revert merges to see what caused the application to break.
+ * The decision to modify our Pull Request process (by Slack reminders and personal DMs), resulted in code getting reviewed quicker and thus we had a lot of cards tested in between meetings, and master was fairly kept up to date. This meant that when new tasks were started, the branches already contained most recent code.
+#### Decisions that did not turn out as well as we hoped
+
+List process-related (i.e. team organization) decisions that, in retrospect, were not as successful as you thought they would be.
+
+ - Before this iteration, we decided that code reviews should only be done by those more closely involved with that portion of the project. For example, changes to the mobile part of the project were to be reviewed by others with involvement in mobile. Unfortunately, this was not enforced due to occaisonal unresponesiveness of teammembers throughout the iteration.
+ - Our decision to swap mobile and web roles was not completely successful. A few teammembers were not able to switch out of their d2 roles due to the increasing complexity of certain parts of the project. In a few cases, there was not enough time for teammembers to become completely familiar with eachothers work.
+
+#### Planned changes
+
+List any process-related changes you are planning to make (if there are any)
+
+> Nothing as of this review meeting.
+
+## Product - Review
+
+#### Goals and/or tasks that were met/completed:
+
+ * All goals for this iteration were completed (see planning doc Goals section) with the exception of no. 4.
+
+#### Goals and/or tasks that were planned but not met/completed:
+
+ * Handling of response from the server when mobile sends out the post request so that the user knows that their report actually went through in a Greeting Page. We did not complete this goal because although we started this task, we could not complete and implement it into our application within the time constraints.
+
+
+#### Goal not included in this iteration
+ * We have a backlog column of a set of goals that we did not have time for in this iteration. For example, adding additional layers to the map which showed different information such as clusters, homeless shelter locations, user profiles etc.
+![](https://i.imgur.com/I7q3m5C.png)
+
+
+
+## Meeting Highlights
+
+Going into the next iteration, our main insights are focused on preparing for the demo
+
+ * Go over what we are going to say.
+ * Make sure everyone understands how the application works and how it is designed.
+ * Prepare answers to potential questions that the evaluators might ask.
+