Poway Neighborhood Emergency Corps 2026–2027
CSP capstone continuing the PNEC project with proposed household preparedness, volunteer coordination, and community information tools.
Our Community · Emergency Preparedness
The Story of PNEC
Neighbors helping neighbors prepare for the unexpected.
Founded in 2011, Poway Neighborhood Emergency Corps (PNEC) is an all-volunteer nonprofit dedicated to helping Poway residents prepare for emergencies and support one another.
What PNEC Does
- Educates residents about wildfires, earthquakes, and other hazards.
- Shares emergency planning tips and preparedness resources.
- Connects neighbors through community outreach.
Why It Matters
- Helps families prepare before disasters happen.
- Encourages neighbors to look out for one another.
- Builds a more informed and resilient community.
PNEC's mission is simple: help Poway become a community where residents are prepared, informed, and ready to help their neighbors.
CSP 2026–2027 · Community capstone
Prepared neighbors. A stronger Poway.
Samanvi, Joan, and Ainsley are continuing the previous PNEC team's project. Our team proposes the features below to extend the inherited project, with scope and implementation to be reviewed with PNEC.
Plan · Track · Review
Team Kanban Board
Follow our team's actual issues, assignments, and progress on GitHub.
Cards load from our public repository issues. Stage labels determine columns first; otherwise, closed issues appear in Done, assigned open issues in In progress, and other open issues in To do. These columns are derived from issue data and may differ from our personal GitHub Project.
Filter by an issue's first assignee; each card lists all assignees. The shared board reuses cached data for 10 minutes and checks GitHub again on a later page load. Pull requests and issues closed as not planned are omitted. Issue closure alone does not establish stakeholder acceptance.
When present, Priority and Estimate labels show our proposed team priority and Fibonacci-hour effort estimate, not logged hours or Product Owner approval. One assignee coordinates each issue; individual academic contributions remain each student's responsibility.
About PNEC
Poway Neighborhood Emergency Corps (PNEC) helps Poway residents prepare for emergencies by sharing preparedness information, coordinating with the city and first-response agencies, organizing preparedness activities, and encouraging neighbors to help one another. Our capstone improves the existing PNEC website to make this preparedness information easier to find and use.
Visit the official PNEC website ↗Project overview
Why we chose PNEC
We chose PNEC to help our community prepare for emergencies. Our team identified wildfires, high temperatures, and earthquakes as reasons to make preparedness information and planning easier to access. The project combines community impact with opportunities to build useful technical skills.
Project direction
Extend the existing information platform with personalized household planning, preparedness learning, volunteer coordination, and community feedback. These features are proposed work for our team.
Read the Team Feature Plan ↗Community participation
Our proposed direction connects preparedness information with saved plans, learning activities, volunteer tasks, and feedback from residents.
Visit the existing project site ↗Inherited project and opportunities
Build on the existing foundation
The previous team's handoff describes Risk Watch, the Helper Bot, a neighborhood map, member accounts, and a browser-based site editor. We will review these inherited features before extending them.
- Risk Watch
- Helper Bot
- Neighborhood map
- Member accounts
- Browser-based site editor
Proposed features and acceptance checks
Nine ways to support our community
These are proposals for review, not claims of completed features. Each improvement includes an acceptance check to guide a future implementation.
Family / household preparedness checklist tracker
Save a personalized checklist to each resident account for a 72-hour kit, evacuation plan, and meeting point. Show household progress and remaining tasks alongside the existing preparedness information.
Proposed acceptance check: Completed tasks remain saved after signing in again, progress updates correctly, and each household sees only its own checklist.
Interactive preparedness quiz
Ask residents 8–10 questions about their emergency kit, evacuation route, and other preparedness steps. Show a preparedness score and the top actions suggested by their answers.
Proposed acceptance check: All questions can be answered with a keyboard, the same answers produce the same score, and recommendations match the gaps identified. The score describes quiz responses, not a guarantee of safety.
Volunteer shift / task board
Let coordinators post door-to-door check-ins, supply drives, and CERT training sessions. Residents and volunteers can claim available slots.
Proposed acceptance check: A volunteer can sign up or cancel, the remaining capacity stays accurate, and filled slots cannot be overbooked.
Post-disaster check-in / well-being board
Let residents mark themselves as safe or needing help by neighborhood, with their update visible to their coordinator.
Proposed acceptance check: A resident can update their status and timestamp, and only authorized coordinators can view their neighborhood’s reports. The page clearly explains that a check-in does not contact emergency services.
Multilingual support
Offer key pages such as Risk Watch, evacuation information, and the Helper Bot in Spanish and additional languages selected with PNEC. Explore translation support with review of critical information.
Proposed acceptance check: A language selector opens the corresponding content, missing translations are clearly identified, and critical preparedness wording is reviewed before publication.
Donation / supply drive goal tracker
List current needs such as flashlights, water, and first-aid kits, with a running progress tracker so residents and local businesses can see how to contribute.
Proposed acceptance check: Each drive shows its item, goal, and recorded progress. Authorized volunteers can update totals, and pledges are distinguished from supplies received.
Report a hazard
Provide a resident form for reporting a downed tree, blocked evacuation route, or broken fire hydrant. Route the report to the relevant coordinator or admin dashboard.
Proposed acceptance check: Required location and description fields are validated, submitted reports appear for the authorized coordinator, and the form distinguishes community reports from urgent emergency requests.
Community-driven FAQ feedback
Add a “Was this helpful?” option and a way to submit questions that stump the Helper Bot. Volunteers can review gaps and improve the knowledge base.
Proposed acceptance check: Feedback is saved, unanswered questions appear in a volunteer review queue, and reviewed FAQ changes can be tracked.
Weekly tips and tricks
Publish weekly preparedness tips and volunteer or learning events. Adapt the topics to current community threats, such as flood preparedness during flooding.
Proposed acceptance check: Each update shows a publication date, relevant sources, and upcoming event details. Authorized volunteers can review and update time-sensitive content.
Teammates / Collaborators
Our team and review process
Joan Kim
Scrum Master / Developer
Ainsley Albert
Technologist / Developer 1
Samanvi Yachareni
Technologist / Developer 2
Iteration process
1 · Investigate and scope
Review the inherited repositories and handoff, reproduce a user problem, and discuss priorities with PNEC. Record the selected scope, owner, and acceptance checks in an issue.
2 · Build and test
Implement one agreed improvement in a small branch. Test the main workflow, failure cases, keyboard navigation, and phone layouts. Keep screenshots and results with the issue.
3 · Review and revise
Open a focused PR with the problem, changes, and actual test results. Have a teammate review it, address feedback, and record the next iteration before the class review.
GitHub issues · Evidence · Review
Our five-stage Kanban lifecycle
Mr. Mortensen is our Product Owner. Samanvi, Joan, and Ainsley are the Scrum Team. These are the required stage criteria, not claims that our cards have already passed them. All 20 proposals in the Product Backlog #42 await his approval.
October 21 board audit: the current columns are Backlog, Todo, In Progress, Testing and Done. Renaming Testing to In Review requires teacher approval. Issues #31–#34 still need scope, priority and owner decisions; Done issues #1 and #5–#9 lack confirmed acceptance evidence in the reviewed records. These gaps remain pending; no board statuses or assignments were changed.
1 · Parking Lot (Backlog)
- Hold a success meeting with the teacher, Product Owner, mentors or community stakeholders.
- Use empathy research, interviews or surveys to understand user needs and a point of view (POV).
- Explore solutions with “How might we?” (HMW).
- Define a proposed design and acceptance criteria before committing resources.
Exit: An understood, actionable solution ready for prioritization.
2 · To Do
- Agree on weighted priority with the Product Owner.
- Confirm one accountable owner and the authorized scope.
Exit: Prioritized, owned and ready to start.
3 · In Progress
- Implement an authorized prototype in code.
- Complete unit tests and retain actual results.
- Create and link a focused pull request.
Exit: Development evidence is complete.
4 · In Review
- Deploy to an appropriate, approved testing or review environment.
- Run system tests and present the outcome to reviewers.
- Obtain acceptance from the authorized reviewer.
Exit: The solution satisfies its acceptance criteria.
5 · Done
- Deliver the accepted outcome.
- Retain evidence in the GitHub issue.
- Link key commits and pull request history.
Exit: Accepted delivery and its evidence are retained. Proposed or incomplete work is not Done.
Choose the right issue format
Quick Issue
Use for a small bug, revision, non-invasive prototype or minor improvement. Record the applicable problem, task, owner, acceptance checks, commits, PR and tests.
It may start in To Do or In Progress when understood and appropriately authorized. It does not bypass approval for our proposed backlog.
Formal Issue
Use for research, new features and substantial changes. Include user needs, stakeholder evidence, POV/HMW, alternatives, design, acceptance criteria, priority and owner.
Then link implementation tasks, unit/system tests, commits, PRs, presentation, review and final acceptance. Missing evidence stays pending.
Both templates are prepared locally in the team repository's issue-template directory; publication is pending. No issues, assignments or Kanban statuses were changed.
Connect the lifecycle to real PNEC work
Planning and research
- #42 · Product Backlog and API research: 20 proposed scopes; Product Owner approval and priorities remain pending.
- #14 · Official weather alerts: open proposal with research, dependencies and acceptance criteria; not an approved live integration.
Implementation and testing evidence
- #8 · Authentication and recovery: open issue describing existing local implementation and tests; production is unverified.
- #11 · Authentication testing and #10 · Reliability tests: closed historical issues; closure does not prove deployment or Product Owner acceptance.
- #25 · Coordination acceptance testing: open proposed testing scope, awaiting approval.
Review the API and full-stack evidence #43 and Phase 1 assignment hub #44. Issue states were inspected on October 21, 2026; they may change. Existing status inconsistencies are preserved rather than silently corrected.
Working accounts, saved preparedness data and owner analytics belong to the PNEC frontend and Flask database. This capstone page is informational. Local verification does not establish public API availability, production persistence or accepted delivery; production 404/CORS diagnosis and deployment still require the EC2 administrator.
Keep project updates in the existing Microblog
Use the page's Microblog button to open the existing OCS panel. Keep meeting notes, issue links, stakeholder feedback and short progress updates together. Clearly distinguish plans, local tests, reviewer decisions and accepted outcomes.
- Link the relevant issue and describe the next step.
- Record decisions with the reviewer and date; do not invent approval.
- Never post passwords, tokens, resident records or sensitive household information.
The OCS Microblog uses the course site's services and accounts, separate from PNEC accounts. The panel is reused, not duplicated. Posting and persistence require those services and authorization; they have not been verified against production in this update.
Evidence for the next iteration
This update organizes the capstone overview only. The nine improvements remain proposals; this page does not establish implementation or stakeholder validation. Subsequent updates should record the selected scope, each teammate's contributions, test results, and review feedback.
The team feature plan and Kanban board provide the next steps for review.
Built with standard OCS components and shared Sass. Explore the OCS button styles and OCS grid styles.