Skip to content

My personal fork of my group project's web app that helps Seattle users find established community gathering points in case of disaster, as well as helping the user prepare an emergency kit for a seismic or other disaster-related event.

License

Notifications You must be signed in to change notification settings

SharinaS/seattle-earthquake

 
 

Repository files navigation

Seattle Earthquake Awareness

201 Project Week for team PJZZS.

About

Our project is a web-app designed for Seattle users to prepare for a large disaster.


All Users will be able to identify community emergency hubs in the area, and to properly prepare their households with enough food and water to survive a supply shortage, based on the bridge and port dependancy of Seattle.

screenshot of page

Repo

To view the repository, please visit the web address:

https//github.Zaffierce/pjzss-project-week

Resources and References

  • Code Fellows Instructoral Team
    • Lena Eivy
    • Ron Dunphy
    • Heroes of Old

Websites

I-Frame

Creators

This was a Collaborative Effort on behalf of our group: PJZSS DreamTeam
JavaScript Dev's and Students at CodeFellows:

  • Peter Charmichael
  • Jon Veach
  • Zerek Cover
  • Susanna Lakey
  • Sharina Stubbs

Communication Plan

Communication Formats After Hours and On Weekend:

  • Slack
  • Trello for file sharing, To Do lists

Communication in the code:

  • Go way overkill on the comments. Comment at every single line getting started.

Group Working Hours

  • 9am – 6pm group time
  • 8am- 9:15pm be aware group member(s) may need to communicate after group time

Strategy for Making Sure Voices are Heard (within a safe environment)

  • Three a day check-in meetings
  • Morning meeting - 9am start time – debrief, code review and prep for day
  • After lunch – 1pm start time – review the morning, re-check in, and brainstorm as needed for afternoon.
  • Before leaving for the day – 5:30pm? How the morning and afternoon went

General Guidelines:

  • Code review occurs at each meetups
  • Be patient and kind with each other.
  • Suggestion: Start sentences with “I need...”
  • There are no bad ideas
  • Failure will happen and it’s okay! We do this thing together.

If we’re moving too fast:

  • Person who is slower - speak up! Fast coders can slow down.
  • Person who is coding fast may need to take a break and help person catch up.

Conflict Resolution Plan

Process to resolve conflicts

  1. Everyone stops coding
  2. Return to communication ground rules.
  3. Try to understand the conflict
  4. Come to mutual agreement without taking sides
  5. Find a compromise between the two intersecting viewpoints
  6. Discuss things and find happy place
  7. When conflict is resolved, mandatory 10 minute break to relax.

How to raise concerns to members not adequately contributing

  • First step: Find out why the person is falling behind, without judgement.
  • Put out the invitation to share - if something else outside of project is going on, preventing the person from being present, etc.
  • During briefs in morning, check in with each other with how they’re doing with a task.
  • Honesty from each of us about assigned tasks.
  • Ask for help when needed.

How and when to escalate conflict when attempts are unsuccessful:

  • If person is unwilling to talk through or unwilling to improve. They may be going through the motions, but not contributing, not willing to work on issue, and not willing to reach out.
  • Escalation will involve reaching out to Boss and HR (Lena and Ron).

About

My personal fork of my group project's web app that helps Seattle users find established community gathering points in case of disaster, as well as helping the user prepare an emergency kit for a seismic or other disaster-related event.

Topics

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • JavaScript 43.9%
  • CSS 31.5%
  • HTML 24.6%