first commit, d1 filespre-release

2 files changed, 144 insertions, 0 deletions

diff --git a/deliverables/iteration-01.plan.md b/deliverables/iteration-01.plan.md
new file mode 100644
index 0000000..36487f2
--- /dev/null
+++ b/deliverables/iteration-01.plan.md
@@ -0,0 +1,90 @@
+# Helpthehomeless.to by The Dream Team
+> This document is a work in progress!
+## Process
+
+#### Roles & responsibilities
+
+|Name   |Responsibilities   |Strengths  |Weaknesses  |
+|-------|-------------------|-----------|------------|
+|Xuhao Yu|"back end", integration|js, android, data management| memory, ios, react|
+|Samarth Agarwal|"back end", database|Java, Databases, HTML/CSS|JavaScript, Node.js, React|
+|Letian Zhao|"front end"   | Java, JavaScript, SQL  |React, Swift,  App Development  |
+|Ivan Shen| "front end", Testing | Java, JavaScript, Testing | Expo, Swift, SQL, React |
+|Mohammed Ahmed | "back end", database | Java, Kanban, Node.js  | React, Swift, Data Management|
+| Andrew Mihai | "front end", meetings note taker| Java, MVC methodology, Swift | React,  Databases, Javascript|
+| Kumar Damani | Scrum master, server side, API |web, sql, kanban | React, graphic design, apps|
+
+Refer to the App Components diagram in `project.md` to see what responsibilities correspond to what components that person will work on.
+
+#### Team Rules
+
+**Communications:**
+
+Slack for general for communications that should have a 4 - 6 hr response window (assuming that it is appropriate for response (i.e. not sleeping)). Beyond this window, use another form of communication such as messenger, sms etc.
+
+We expect to meet in-person once a week on Tuesdays (3pm-6pm) for our Sprints, with a seperate allocated time on Fridays (4pm - 6pm) in which a meeting can take place (in person or online) if we decide an additional meeting would be required for any given week.
+
+
+**Meetings:**
+
+We will use Trello to assign tasks to members. During a meeting we will go over the status of each in-progress task on the Kanban board, then we will move tasks from the "backlog" to the "Ready for work" column. We are trying to follow the Kanban process:
+![a kanban board image](https://d30s2hykpf82zu.cloudfront.net/wp-content/uploads/2018/11/Explicit-Policies-in-Kanban-Board-1024x613.png)
+> Img Source https://www.digite.com/kanban/what-is-kanban/
+
+If a member is absent at meetings without due cause, we will talk to them in person to understand their reasoning as see how we can accomodate them. If this becomes a recurring issue, report to Adam for advice.
+
+Team decisions
+* All design, implementation, and organizational decisions are made by the team via a majority vote. Since there are seven team members, there will always be a majority.
+#### Conflict Resolution:
+1. **A team member is unresponsive to repeated online messages.**
+
+Exhaust all possible methods of communication that we've agreed to communicate on such as Facebook, Slack, and text message. If all methods fail, then attempt to talk to them in person during lecture or tutorial. As a last resort, ask the professor to attempt to get in contact with the team member.
+
+2. **A team member makes a quick decision without consulting the rest of the team.**
+
+All major team decisions are made during team meetings. As per the team rules, ideas are brought up during meetings and if the majority agree, then we make that decision as a team.
+
+additional: If a team member already decided on the quick decision without consulting, we will consider back tracking to the state of the team before the decisioon (if possible). At this point we will try to decide whether or not the decision was right or if there was some other more suitable decision. If it is absolutely not possible to change the decision, we will contact Adam with respect to this decision and seek advice to the situation.
+
+3. **A team member is not meeting their deadlines**
+
+During every team meeting, every team member gives an update on the status of their work. This gives the team member multiple opportunities to bring up any concerns regarding deadlines. However, if a team member is unable to meet a deadline due to unforseen circumstances, we will discuss, as a team, the possible options such as redistributing the work or assigning more resources to the task.
+#### Events
+
+
+Each Tuesday meeting will be in a "Scrum Sprint" format at Gernstein library. We will pull up github issues (or Trello) and discuss the status of each task in-progress and completed, and if there are any impediments, how to deal with them as a team. Then we will re-prioritize the "to-do" column as well as move tasks from "backlog" to "to-do" for the upcoming week.
+
+Friday meetings are for urgent issues, deadlines, ideas, suggestions, or any unforseen circumstances. They can either be in person or over Skype.
+ * Other events could be coding sessions, code reviews, quick weekly sync meeting online, etc.
+
+#### Artifacts
+
+
+ * Slack channels - dedicated channels for specific things like scheduling, developemnt, research etc. There are integrations in Slack to allow for more detailed scheduling.
+ * Trello (Kanban) board following a kanban process for how each card gets moved to the next section. During the meetings we will pull up the board and reprioritize based on status updates on current and previously assigned tasks. New tasks will get assigned primarly to the next available developer unless they specifically do not wish to do this task.
+
+
+
+## Product
+
+#### Goals and tasks
+
+
+Researching existing solutions that might already exist, i.e. making sure that the problem actually exists.
+
+Research to understand the problem better by communicating with 311.
+
+Decide on the communicative process and expectations. Setting up Slack channels for meeting agendas, notes. Set up Trello for development process.
+
+Decide on the technology stack, by researching and identifying possible options, then coming to a decision on what the group feels most comfortable with.
+
+
+#### Artifacts
+
+* Research notes (links, handwritten notes etc.)
+  * open311 api info: [faq](https://www.toronto.ca/home/311-toronto-at-your-service/open311-api-and-mobile-apps/information-for-developers-open311-api/), [requests documentation](https://www.toronto.ca/city-government/data-research-maps/open-data/open-data-catalogue/#e2634d40-0dbf-4d91-12fa-83f039307e93). These are important as we need to know what functionality the API can support so that we can determine whethere it is part of our design.
+  * 311 street outreach reporting: [here](https://www.toronto.ca/311/knowledgebase/kb/docs/articles/shelter,-support-and-housing-administration/homelessness-initiatives-and-prevention-services/homeless-person-in-need-of-assistance-street-help-street-outreach.html). This gives us a starting point for our reasearch about how the present solution works.
+  * Questions asked to 311 operator:![questions asked image](https://i.imgur.com/24uCia7.jpg)
+  * Rough 311 + "Street to Homes" worker call summary:![311 + Street to Homes worker call summary image](https://i.imgur.com/HKuNXay.jpg). This gives us quite a bit of insight for what we should be focusing on and what the real problems and challenges outreach workers face.
+  * Open data catalogue: [daily shelter occupancy](https://www.toronto.ca/city-government/data-research-maps/open-data/open-data-catalogue/#711ba031-b32b-3390-ce54-22c15ac6389f). This is one of many data sets that we can query to add additional functionality to our application (such as predictive power).
+  * Design mockups/component diagram: see ```product.md``` for UI mockup, and for high-level diagram. This helps us get a visual idea for what we are building, and the general flow of the application.
diff --git a/deliverables/product.md b/deliverables/product.md
new file mode 100644
index 0000000..bdaabeb
--- /dev/null
+++ b/deliverables/product.md
@@ -0,0 +1,54 @@
+# Helpthehomeless.to by The Dream Team
+> This document is a work in progress!
+#### Q1: What are you planning to build?
+
+An app with a web component that allows users to report homeless people on the street who might be at health risks due to sever weather conditions.
+
+Currently, in order to report a homeless person, one must dial 311, then the operator redirects the caller to the "Shift Leader" at "Street to Homes" who sends out an outreach worker nearby for help. Based on the information we gathered by calling them directly, all of this is done over the phone i.e. there is no digital solution.
+
+311 is not a dedicated help line for reporting homeless people in need. It serves as a line for various city services such as waste collection, road repairs, and property issues. As a result, callers may be waiting [up to 12 minutes](https://www.thestar.com/news/gta/2010/07/29/wait_times_for_311_service_surge.html) to talk to an operator.
+
+Given the dire nature of homelessness, we believe there should be a *faster* dedicated alternative. This way people can not only skip the lineup of calling 311 and go about their life/etc, but also save 311 operators' time.
+
+Here is a sample mockup for the app flow only:
+![](https://i.imgur.com/AovJOto.png)
+
+#### Q2: Who are your target users?
+
+Our primary target are people living in Toronto who are **uncomfortable calling 311** in a public environment but still have the urge to report homeless people to get them the help they need. These people are culturally classified as "millennials".
+
+A couple of example personas:
+
+* Lisa is a "millennial" in a streetcar who spots a homeless person during her commute to work. Due to the street car being crammed during at this time, she feels too awkward to pull out her phone and dial 311 to report a homeless person. She wishes she could report this person by some other means.
+* Bob is a 34-year old construction worker who lives in Toronto and walks to work everyday. On his way to work he sees many homeless people struggling on the streets but he doesn't want to stop and dial 311 as that will take too much time and he will be late for work. As someone who wants to help the homeless, Bob wants an efficient way to be able to report homeless people that seem to be in critical need of shelter so that he can do his part in helping the homeless while arriving to work on time.
+* Victor is a street outreach worker who would like a unified summary of the homeless people around the city so that he and his team can organize their outreach plan better.
+
+#### Q3: Why would your users choose your product? What are they using today to solve their problem/need?
+
+Users would choose our product because our solution would simplify and expedite the process of reporting a homeless person in need.
+
+
+Our application will simplify the process by eliminating the requirement to call a number, allowing users to report a homeless person at the simple press of a button. Currently, individuals who wish to report an in-need homeless person to 311 must be processed through an automated system determining what they wish to report, as 311 covers more than just homelessness. Then they must wait for a specific operator to become available. Users of our mobile app may report a homeless person without wasting all this time and effort. As of now, there is no city certified application that performs the functionality of our application.
+
+#### Q4: How will you build it?
+
+React Native + Expo for Android and iOS (JavaScript, HTML CSS)
+Node.js/Express server where we will pre-process the data so that we can display it in aggregate form in the web component. (JavaScript, HTML, CSS)
+PostgreSQL to store the data (psql)
+We are still waiting for Open311 to respond to our request to add functionality to handle requests for homeless reporting. If this comes through, it will be our 3rd party API.
+
+We will deploy using Heroku.
+Testing will happen once code-review has passed, by a different team member manually.
+
+Here is a simple diagram:
+![](https://i.imgur.com/XAHyHI7.png)
+
+----
+
+
+
+### Highlights
+
+ 1. **App vs web**: we decided that the primary way to use the app by the users should be an app because a website adds an extra step of entering a url to access our service. Our team is also more comfortable in an app environment as opposed to web, so an app makes the most sense for us.
+ 2. **Open311 API vs direct solution**: 311 already has an API, but we decided against this as it does not currently handle general service requests or requests for street outreach. So we decided to build a solution for "Street to Homes" who 311 relies on anyways.
+ 3. **Dedicated roles vs flexible roles**: dedicated roles have the advantage that each member is only asked to do what they know best, however given the chaos of our schedules, as well as none of us really know any of our tech stack all that well, everyone should suffer equally. :fist: