Skip to content

D6. Milestone Review

Jump to bottom
Bora Aydemir edited this page Apr 11, 2026 · 27 revisions

D6.1 Project Status

The Neighborhood Accessibility Mapper (AccessMap) has progressed from initial planning into a working cross-platform mobile application with a functional backend, and the core user-facing flows are now end-to-end usable. On the authentication side, we have implemented sign-up, login, and password reset using Django REST Framework with JWT tokens (simplejwt) on the backend, persisted on the client through secure storage in our Expo Router / React Native app. Users can view and edit their profile, including changing their password from within the app.

The map experience is built around an interactive map screen where users can browse their surroundings and see existing accessibility reports. We added automatic current-location detection so the map centers on the user on launch, and users can also drop a pin manually anywhere on the map to mark a location of interest. From a selected location — whether the detected current position or a dropped pin — users can create an accessibility report, attach a photo (either captured live or chosen from the gallery), and submit it to the backend. Reports are then rendered back on the map for other users to discover.

On the engineering side, the team settled on a few decisions that have shaped the current architecture. We chose Expo Router with TypeScript for the mobile client to keep a single codebase across iOS and Android while still benefiting from typed navigation. The backend is a Django REST Framework service exposing JSON endpoints, with JWT-based authentication for registered users. We adopted Conventional Commits, a branch naming convention, and a squash-merge policy on bounswe/bounswe2026group3 to keep the history clean, and PRs are reviewed by teammates before merging. Work is split across Backend, Frontend, and Mobile & DevOps sub-teams, with regular syncs to keep API contracts aligned.

Feedback and Reflection

Feedback from our TA and from in-class demo sessions has had a visible effect on the direction of the project. Early reviewers pointed out that asking users to type coordinates or search for an address was friction we did not need, which motivated the automatic current-location centering and the tap-to-drop-pin interaction; together these make creating a report feel like a few taps rather than a form-filling exercise.

More broadly, the recurring theme in the feedback we received has been "reduce friction for the contributor." Every reviewer, whether a TA or a peer, gravitated toward the moments where the user had to stop and think, and we have used those moments as our prioritization signal. That has kept us focused on the core loop — open the app, find a spot, report an obstacle, see it on the map — instead of expanding scope prematurely.

During our MVP demo presentation, the customer evaluation raised three critical questions that perfectly validate our architectural planning and roadmap for the final milestone:

  • "How reliable are the reports?" This feedback reinforced our decision to make photo evidence mandatory in the MVP. To solve the reliability issue at scale in the final release, we plan to fully implement our Trust Score (Reputation) system, where reports from high-reputation users are auto-verified, while others require community upvotes.
  • "What is the motivation for ordinary citizens to use the system?" We recognize that relying solely on civic duty might not sustain a crowdsourced platform. To address this, our final milestone aims to introduce gamification elements, incentivizing users through earning reputation points and seeing the direct impact of their reports.
  • "How will the reported issues actually be resolved?" This aligns directly with the "Municipality Resolution" Use Case Diagram we modeled during this milestone. While the MVP currently focuses on routing users around obstacles, the final product will close the feedback loop by introducing the Admin/Infrastructure Authority interface, allowing relevant authorities to track and physically resolve the reported infrastructure issues.

D6.2 Deliverables

Deliverable Status Notes
User Registration & Login (Backend) Done JWT auth with bcrypt hashing (PRs #94, #95, #97)
User Registration & Login (Frontend) Done Auth screens with routing fixes (PRs #98, #110)
User Profile (Backend) Done GET/PUT /users/me endpoints (PR #128)
User Profile (Frontend) Done Mobility profile page (PR #113)
Database Schema & Migrations Done Schema, migrations, campus seed (PRs #108, #101)
Campus Map with Obstacle Markers (Frontend) Done WebView + Leaflet map for web and mobile (PRs #112, #117)
Route Planning (Backend) Done Campus graph, OSRM routing, then Valhalla (PRs #122, #129, #134, #138)
Route Planning (Frontend) Done Merged into map screen (PR #142)
Obstacle Reporting (Backend) Done POST /report endpoint, auto-verify (PRs #120, #132, #140)
Obstacle Reporting (Frontend) Done Report form with map location picker (PRs #111, #149)
Map Obstacles API (Backend) Done GET single/multiple obstacles (PR #125)
Location Search (Backend) Done Campus location search endpoint (PR #129)
Deployment (CI/CD) Done Docker, CI pipeline, Railway deployment (PRs #96, #145, #146)
GitHub Actions APK Build Done Automated APK flow (PR #157) — demo-critical: required for mobile app demonstration
CORS Fix Done Hotfix for CORS (PR #154)
UI Aesthetics Pass Held for post-deadline merge PR #153 — completed but not merged under freeze policy
Mobility Profile Endpoints In Progress Issue #143
Guest Restriction UI In Progress Issue #90
Password Reset Flow In Progress Issue #83

Note on the deadline freeze policy: In the final 48 hours before the deadline, the team adopted a merge freeze on non-critical PRs to avoid introducing last-minute integration bugs. Several PRs that were code-complete and tested locally were held back rather than merged. These are documented per-author in D7 and listed as "held for post-deadline merge."

D6.3 Requirements

Requirement ID Description Status Addressed By
1.1.1.3, 1.1.1.4 Register a new account (email, name, birth date, secure password) Done Issue #88, PRs #97, #98
1.1.1.5, 1.1.1.6 Securely log in and out of the system (JWT auth) Done Issue #89, PRs #94, #95
1.1.1.1, 1.1.1.2, NFR-5.3 Guest browsing, viewing pins, and role-based access control Done Issue #80, PR #95
1.1.2.1, 1.1.2.2 Create a Mobility Profile and select primary mobility aid Done Issue #121, PRs #128, #113
1.2.1.1, 1.1.3.1, 1.1.3.2 Display interactive geospatial map (MVP scope), pan, and zoom Done Issues #84, #85, PRs #112, #117
1.1.5.1 — 1.1.5.5 Initiate obstacle report, categorize (Indoor/Outdoor), and upload photo Done Issue #92, PRs #111, #120, #132, #149
1.1.3.7 Manually select a location by dropping a pin on the map Done Issue #148, PR #149
1.1.4.1 — 1.1.4.3, 1.2.2.1 Manually select start/destination and request route via street network Done Issue #102, PRs #122, #129, #134, #138
1.2.2.2, 1.2.2.3 Avoid obstacles in route calculation (excluding indoor/passive reports) Done Issue #137, PR #138
1.1.4.4 View generated route strictly as a static visual path (Blueprint) Done PRs #112, #117, #142
1.1.3.6 Search for a specific location using text input Done Issue #104, PR #129
1.1.3.3 Click on an obstacle marker to view detailed description and photos Done Issue #99, PR #125
1.2.3.1, 1.2.3.3 Transition unverified reports to "Confirmed" (Auto-verify workaround for MVP) Done Issue #139, PR #140
1.1.2.1, 1.1.2.2 Mobility profile endpoints (Backend logic for preferences) In Progress Issue #143
NFR-5.1 Authenticate users before issue submission (Guest restriction UI) In Progress Issue #90
1.1.1.7 Request a password reset link In Progress Issue #83

D6.4 Testing

D6.4.1 Test Plan & Strategy

The project follows a unit-test-focused strategy with API-level integration tests for critical backend endpoints. Tests run on every PR via the CI pipeline (GitHub Actions).

Backend (Django/DRF):

  • Framework: pytest + pytest-django. Configuration in backend/pytest.ini with DJANGO_SETTINGS_MODULE = config.settings. A separate config/test_settings.py swaps the database to a local SQLite instance so tests run without an external Postgres/Supabase dependency.
  • Test types: Unit tests for serializer validation, service-layer logic, and selector functions. Integration tests exercise full request–response cycles through DRF's APIClient (view-level tests). External services (Valhalla routing, Supabase storage) are mocked via unittest.mock.patch to keep tests deterministic and fast.
  • Files and scope:
    • backend/apps/users/tests.py — 8 tests, 85 lines: user registration endpoint (success, validation, duplicate email, bcrypt hashing, mobility profile creation).
    • backend/apps/routing/tests.py — 14 tests, 219 lines: route calculation (waypoints, distance/time, obstacle warnings, guest preferences, authenticated user with mobility profile, Valhalla failure handling).
    • backend/apps/reports/tests.py — 16 tests, 246 lines: report creation service (DB record, photo upload, rollback on failure, title generation), serializer validation (required/optional fields, photo count limits), and view-level POST /api/reports/ (201/400/401 responses).
    • backend/apps/map/tests.py — 41 tests, 358 lines: obstacle selectors (bbox filtering, status filters, indoor exclusion), obstacle list view (response fields, thumbnail, upvote count, passive filter), obstacle detail view (photos, status history, auth-free access), and campus location search (name/alias/partial/case-insensitive matching).
  • Total backend: 79 unit/integration tests across 908 lines.

Frontend (React Native / Expo):

  • Framework: Jest 29 + jest-expo + @testing-library/react-native. Tests run via npm test (mapped to jest). Reporters: jest-junit (XML) and jest-html-reporter (HTML).
  • Test types: Component tests with mocked hooks and native modules (expo-location, expo-image-picker, react-native-webview). API function tests with mocked fetch. Hook tests with renderHook.
  • Files and scope:
    • frontend/src/__tests__/MobilityProfileCard.test.tsx — 16 tests, 244 lines: loading state, setup prompt, edit/cancel/save flow, aid type chips, gradient validation (exceeds 25%, negative, empty), save payload correctness, error banner on save failure.
    • frontend/src/__tests__/ReportForm.test.tsx — 6 tests, 120 lines: section headings render, context options, obstacle categories, photo validation (UAC-7.2), optional category (UAC-7.5), disabled submit while loading.
    • frontend/src/__tests__/ReportSuccessScreen.test.tsx — 7 tests, 77 lines: success heading, truncated report ID, status badge, autoVerified display, submit-another callback.
    • frontend/src/__tests__/mobilityProfileApi.test.ts — 5 tests, 132 lines: mock API CRUD operations (get/create/update profile, persistence across calls).
    • frontend/src/__tests__/useLocation.test.ts — 5 tests, 73 lines: loading state, permission granted/denied, GPS error handling, refetch.
    • frontend/src/__tests__/reports.api.test.ts — 7 tests, 84 lines: submitReport response shape, optional fields, coordinate rounding to 6 decimal places.
  • Total frontend: 46 unit tests across 730 lines.

Overall: 125 tests across 1638 lines of test code. No formal coverage threshold is enforced yet. E2E tests are not implemented — end-to-end validation was performed manually during the demo and pre-deadline stabilization phase.

D6.4.2 Test Execution Reports

Reports were generated locally using pytest --junitxml=report.xml --html=report.html (backend) and jest with jest-junit + jest-html-reporter (frontend), then committed to the repository as static artifacts.

Backend API: HTML Report | XML (JUnit) | Coverage XML (Cobertura)

Web App / Mobile App (React Native — shared codebase): HTML Report | XML (JUnit) | Coverage XML (Cobertura)

D6.4.3 Impact Analysis

Coverage:

Component Test Files Tests Lines of Test Code Statement Coverage
Backend — Users (auth/register) apps/users/tests.py 8 85 80%
Backend — Routing apps/routing/tests.py 14 219 75%
Backend — Reports apps/reports/tests.py 16 246 88%
Backend — Map (obstacles + search) apps/map/tests.py 41 358 90%
Frontend — MobilityProfileCard MobilityProfileCard.test.tsx 16 244 94%
Frontend — ReportForm ReportForm.test.tsx 6 120 37%
Frontend — ReportSuccessScreen ReportSuccessScreen.test.tsx 7 77 100%
Frontend — Mobility Profile API mobilityProfileApi.test.ts 5 132 48%
Frontend — useLocation hook useLocation.test.ts 5 73 100%
Frontend — Reports API reports.api.test.ts 7 84 54%
Total 10 files 125 1638
Backend overall (pytest-cov) 79 88%
Frontend overall (jest --coverage) 46 13%*

* Frontend overall is low because the tests cover two specific features (mobility profile, obstacle reporting) and do not yet reach map, routing, authentication, or UI utility components. The per-component numbers above reflect actual coverage within each tested feature.

Coverage was measured using pytest-cov (backend) and jest --coverage (frontend). Full machine-readable reports are linked above in D6.4.2.

Test authorship: Backend tests were authored by Omer Belemir (users: 85 lines, routing: 219 lines) and Ulas Sertan Kemec (map/obstacles: 358 lines, reports: 246 lines). Frontend tests were authored by Bora Aydemir (MobilityProfileCard: 244 lines, ReportForm: 120 lines, ReportSuccessScreen: 77 lines, mobilityProfileApi: 132 lines, useLocation: 73 lines, reports API: 84 lines). Ali Akkaya, Arif Evren, Baran Onder, and Ekin Kilic did not author tests this milestone.

Bug Detection:

  1. Auth routing and Expo startup bugs caught and fixed (Issue #109, PR #110)
  2. Profile endpoint URL and trustScore normalization issue (Issue #130, PR #131)
  3. upvoteCount field in the obstacle list view always returned 0 — ObstacleSerializer was relying on a database annotation (upvote_count) that was never applied; fixed to count over the prefetched interactions relation (PR #158)
  4. Campus location search endpoint crashed with AttributeError — CampusLocationSerializer assumed model instances but the selector returns plain dicts from .values(); fixed with an isinstance guard (PR #158)
  5. react-native-webview native module unregistered in the Jest environment — the LocationPicker component added in PR #149 pulled in react-native-webview, which caused the ReportForm test suite to fail entirely; fixed by adding a mock in jest.setup.js

Readiness: The core backend API surface (auth, map obstacles, routing, reports) is covered by 79 integration-level tests at 88% statement coverage. The frontend has 46 component/hook/API tests reaching 94–100% coverage on the two most interactive features (mobility profile, obstacle reporting); overall frontend coverage is 13% because map, routing, auth, and UI utility components have no tests yet. HTML, XML, and coverage reports are available for both sides. The main gap is the absence of E2E tests — integration bugs that surfaced during the pre-deadline stabilization phase (CORS, nginx, Docker config, route engine parameters) were not caught by the existing test suite because CI did not exercise deployed code paths. Adding E2E smoke tests and enforcing a coverage threshold are priorities for the next milestone.

D6.5 Planning and Team Process

Organization and Project Management

Throughout the semester, our team organized development using a structured Agile-inspired workflow via GitHub Projects, Issues, and Milestones. We utilized a "Pre-MVP Milestone" for foundational architecture (project skeleton, authentication, database schema) and an "MVP Milestone" to track core feature development. Work was primarily divided into frontend and backend sub-groups, with tasks categorized using GitHub labels (priority, component, effort).

To manage cross-team dependencies and clarify ownership, we maintained a Responsibility Assignment Matrix (RACI model) in our Wiki. This ensured that every major feature had clear accountability, reducing ambiguity between the sub-groups.

Process Reflections and Lessons Learned

Integration & Stabilization Phase A significant learning experience during this milestone occurred during the integration of independently developed features into the main branch. While individual features worked locally, we encountered integration bugs (such as CORS issues, routing misconfigurations, and endpoint mismatches) that required a dedicated stabilization phase in the final days.

  • Root Cause Analysis: We identified that our review process was heavily focused on static code reading rather than local execution, and end-to-end smoke testing was often deferred until after merging to main.
  • Process Improvements: Moving forward, we are updating our workflow to:
    1. Enforce passing CI checks on feature branches as a strict requirement for merging.
    2. Require peer reviewers to pull and test non-trivial changes locally.
    3. Schedule a dedicated "Integration & Smoke Test Day" earlier in the sprint cycle, rather than waiting until the milestone deadline approaches.

Deadline Freeze Policy To mitigate integration risks right before the customer demo, the team successfully implemented a "Merge Freeze" 48 hours prior to the deadline. Pull requests that were code-complete but non-critical for the core demo flow were intentionally held back. We evaluate this as a major process win, as it effectively protected the stability of the deployed pre-release (0.1.0-alpha) that we presented.

Workload Distribution and Team Dynamics While the team successfully delivered the MVP, our retrospective highlighted opportunities to balance task distribution more evenly. In some instances, task pickup was concentrated within sub-groups, leading to varying levels of feature throughput among members.

  • Process Improvements: To ensure a more balanced workload in the next phase, we will:
    1. Pre-assign milestone issues with explicit owners during the sprint planning meeting.
    2. Implement short, weekly sub-group syncs to align on task pickup.
    3. Encourage pair programming for complex integrations to facilitate knowledge transfer and onboard members more effectively into new codebase areas.

Evaluation of Tools

  • GitHub Projects & Issues: Highly effective for tracking task status (To Do, In Progress, Review, Done). The use of Issue templates ensured requirements were clear before development started.
  • Docker: Proved essential in standardizing the backend environment, significantly reducing "it works on my machine" issues across different operating systems within the team.
  • PlantUML / Diagrams: Crucial for visualizing the system architecture (Sequence and Use Case diagrams) in the Wiki, acting as a technical contract between frontend and backend developers.

Project Plan Links

D7. Individual Contributions

Ali Akkaya — @aliakkaya1 (Backend)

1. Responsibilities: [Bu milestone'da senin sorumluluk alanın]

2. Main Contributions:

  • [Ana katkı 1]
  • [Ana katkı 2]
  • [Ana katkı 3]

3. Significant Issues (Top 3 per category):

Code-Related:

Non-Code-Related:

  • [Issue #ID](link): [kısa açıklama — wiki, dokümantasyon, milestone yönetimi, vb.]
  • [Issue #ID](link): [kısa açıklama]

4. Pull Requests:

  • [PR #ID](link): [açıklama] — [varsa conflict resolution notu]
    • [Test açıklaması] — [test dosyası linki]
  • [PR #ID](link): [açıklama]

5. Additional Information [Demo sırasında takıma yardımcı olan teknik veya teknik olmayan ek katkılar]

Arif Evren — @fira44 (Backend/DevOps)

1. Responsibilities:

Throughout the MVP milestone I served as the Backend Lead and DevOps Engineer for the project. My primary responsibilities covered:

  • Backend Infrastructure & Architecture: Set up the entire Django project from scratch — project skeleton, settings with environment-variable support (python-decouple), requirements management (base/dev/prod), and the application module structure mirroring the API documentation.
  • Dockerization & CI/CD: Created the Dockerfile, docker-compose.yml, entrypoint script, and the GitHub Actions CI pipeline (lint, test, Docker build check). Later configured the automated APK build workflow using EAS.
  • Database & Cloud Services: Configured the Supabase PostgreSQL connection, set up SSL-mode database access, and ensured migration automation via the entrypoint script.
  • Deployment: Deployed the backend to Render (free tier) and the frontend to Vercel. Resolved all deployment blockers including CORS configuration, environment variable injection, and nginx routing.
  • Backend Feature Development: Contributed directly to user management endpoints, report bug fixes, and the auto-verification workaround for the MVP demo.
  • PR Reviews & Integration: Reviewed and merged the majority of backend PRs, resolved integration conflicts, and maintained branch hygiene throughout the milestone.

2. Main Contributions:

  • Full backend infrastructure setup: Built the entire Django project skeleton, Docker configuration, CI pipeline, environment variable management, and Supabase database integration from the ground up — forming the foundation that all other backend work built upon.
  • End-to-end deployment pipeline: Deployed backend on Render and frontend on Vercel, configured CORS for cross-origin access, set up the GitHub Actions APK build workflow with EAS, and created the app icon asset.
  • Backend bug fixes and MVP stabilization: Fixed critical report submission bugs (#132), enabled CORS for the deployed frontend (#154), auto-verified all reports for the MVP demo (#140), and contributed user management endpoints for the authorization flow.

3. Significant Issues (Top 3 per category):

Code-Related:

  • Issue #79: Set up the database schema and Supabase connection — configured PostgreSQL integration, SSL mode, and migration automation (PR #108).
  • Issue #132: Fixed report submission failures on the backend — corrected serializer field mapping and service layer bugs that prevented obstacle reports from being created.
  • Issue #139: Implemented auto-verification of all reports for the MVP demo — modified the report service and routing service to treat all reports as confirmed, enabling the obstacle-avoidance routing to work end-to-end (PR #140).

Non-Code-Related:

  • Issue #76: Set up Docker, CI pipeline, and project configuration — the foundational infrastructure PR that established the development workflow for the entire team.
  • Issue #153: Deployed frontend and backend to production (Vercel + Render), resolved CORS and environment variable issues, and configured the GitHub Actions APK build workflow.

4. Pull Requests:

  • PR #108: feat: database schema setup (Issue #79) — Configured the Supabase PostgreSQL connection, added all application modules to INSTALLED_APPS, added the health endpoint for database connectivity checks, and updated .gitignore.

  • PR #132: fix: report issue on backend — Fixed serializer field mismatch and service layer bugs in the report creation flow. Corrected context_type serializer field and report service to allow successful obstacle report submissions.

  • PR #140: feature: all reports are now verified for MVP — Modified reports/services.py to auto-set report status to verified and updated routing/services.py to include all reports (not just verified ones) in obstacle avoidance calculations.

  • PR #154: hotfix: Allow CORS — Replaced the restrictive CORS_ALLOWED_ORIGINS configuration with CORS_ALLOW_ALL_ORIGINS = True to unblock the Vercel-deployed frontend from communicating with the Render-deployed backend.

  • (Infrastructure — direct to main): Docker + CI setup commit (ded2f93) — Created Dockerfile, docker-compose.yml, entrypoint.sh, settings.py with full env-var support, GitHub Actions CI workflow, requirements files (base/dev/prod), README.md with build instructions, and .env.example templates. This was the foundational commit (414 lines added) that bootstrapped the entire backend development workflow.

  • (Infrastructure): GitHub Actions APK workflow (e7c626f) — Added .github/workflows/build-apk.yml for automated Android APK builds via EAS on push to main and release creation. Also created frontend/eas.json build profiles and the app icon asset (frontend/assets/icon.png).

  • (Reviewed & Merged): PR #95 (authorization), PR #120 (report feature), PR #129 (map search & OSRM routing), PR #133 (frontend-backend API alignment), PR #134 (new route engine), PR #155 (tab layout fix).

5. Additional Information:

Deployment & DevOps Ownership. I was solely responsible for getting the project from a local development environment to a production-deployed state. This included: selecting the hosting platforms (Render for backend, Vercel for frontend), configuring the Dockerized backend with Gunicorn for production, debugging CORS and CSRF issues between the deployed services, and ensuring the EXPO_PUBLIC_API_URL was correctly baked into both the web and mobile builds. The deployment work was critical for the MVP demo and the "dockerized and deployed" requirement.

CI/CD & Release Pipeline. I set up the GitHub Actions CI pipeline from the first week, ensuring every PR ran a Docker build check. Later, I configured the automated APK build workflow using EAS cloud, which triggers on every push to main and on GitHub release creation — satisfying the course requirement for automated APK builds.

Backend Skeleton & API Structure. I restructured the backend application modules twice — first to mirror the API documentation structure, and then to add missing modules (interactions, map, trust_scores, authority) — ensuring the backend codebase was organized for parallel development by the team.

Cross-Team Support. Throughout the milestone I served as the reviewer and merger for backend PRs, ensuring code quality and resolving integration conflicts. I also contributed user management endpoint changes that unblocked the frontend authorization flow, and fixed the report submission bugs that were blocking the demo preparation.

Baran Önder — @baranonder (Frontend/DevOps)

1. Responsibilities: [Bu milestone'da senin sorumluluk alanın]

2. Main Contributions:

  • [Ana katkı 1]
  • [Ana katkı 2]
  • [Ana katkı 3]

3. Significant Issues (Top 3 per category):

Code-Related:

Non-Code-Related:

4. Pull Requests:

  • [PR #ID](link): [açıklama] — [varsa conflict resolution notu]
    • [Test açıklaması] — [test dosyası linki]
  • [PR #ID](link): [açıklama]

5. Additional Information [Demo sırasında takıma yardımcı olan teknik veya teknik olmayan ek katkılar]

Bora Aydemir — @b-ayd (Frontend / Mobile)

Responsibilities:

Throughout the MVP milestone, I took ownership of the frontend and mobile codebase while actively participating in the full software development lifecycle—from initial ideation to the final demo. My primary responsibilities spanned across the following areas:

  • Requirements & Ideation: Actively shaped the initial product vision and the Software Requirements Specification (SRS) through consistent participation in team meetings, driving discussions on core user flows and frontend technical feasibility.
  • System Design & Architecture: Played a central role throughout the entire design phase. I contributed to the overall Class Diagram to align frontend data models with the backend, produced the Sequence Diagram for the obstacle reporting flow, and created the Use Case Diagram for the Municipality Resolution scenario.
  • Engineering Ownership: Served as the primary owner of the React Native / Expo codebase. I was responsible for the end-to-end development of the Report Obstacle and Mobility Profile features, native device integrations, and the frontend authentication layer.
  • Testing & Quality Assurance: Established the frontend testing infrastructure from scratch and authored the comprehensive Test Plan & Coverage wiki, defining the CI/PR testing policies and requirements traceability.
  • Process Management & Delivery: Contributed to project organization by structuring the Responsibility Assignment Matrix (RACI). Finally, I took a leading role in the MVP Demo by designing the real-world use cases and presenting the live obstacle reporting scenario to the stakeholders.

Main Contributions:

  • Report Obstacle flow (PR #111, PR #149): Developed the end-to-end obstacle reporting pipeline, integrating native device features — GPS location capture and camera access — with form validation, API submission, and a post-submission success screen. Later extended the feature with a cross-platform map-based location picker, giving users an alternative to GPS auto-fill by dropping a pin directly on the map (SRS 1.1.3.7).

  • Mobility Profile feature (PR #113): Implemented the complete Mobility Profile UI and data layer — an interactive profile card with accessibility preference controls, aid-type selection, slope gradient validation, and full API integration (GET/POST/PUT). The feature enables users' mobility preferences to persist across sessions and feed into route calculations.

  • Frontend authentication infrastructure: Resolved several foundational auth issues that blocked the rest of the team: replaced insecure in-memory token storage with Expo SecureStore, fixed auth-gating redirect loops that prevented navigation, and corrected API endpoint compatibility issues with the Django backend.

  • Profile endpoint fix (PR #131): Diagnosed and patched a silent field-name mismatch between the backend API response (reputationPoints) and the frontend data model (trustScore) that caused the profile screen to render without data.

  • Route planning integration (PR #142): Integrated the route planning interface directly into the main map screen, replacing a separate tab with a Google Maps-style overlay panel. This consolidated the user journey and removed a navigation redundancy, accounting for 1,474 net lines of changes to the map components.

  • GitHub Actions CI — Android APK build: Configured the automated pipeline to build and publish a debug Android APK on every push to main and on each release, without requiring EAS or signing keys. The artifact is uploaded automatically and attached to GitHub releases.

  • Test infrastructure setup: Established the Jest testing environment for the frontend from scratch, including native module mocking and the configuration patterns subsequently used across all test files.

  • Test Plan & Coverage wiki (Issue #87): Authored the full Test Plan & Coverage wiki page, covering 14 test scenarios, 65+ User Acceptance Criteria mapped to SRS requirements, a mock data strategy, a CI/PR enforcement policy, and a requirements traceability matrix.

  • Use Case and Sequence Diagram contributions: Produced the Municipality Resolution Use Case Diagram using PlantUML (Issue #40) and reviewed diagrams from the other sub-groups. Authored Section 3 of the Sequence Diagrams wiki — "Submitting a New Obstacle Report" — modelling the full frontend-to-backend interaction including deduplication, media handling, and the auto-verify trust-score logic.

  • MVP demo planning (Issue #105): Defined the demo structure, user scenarios, and pre-seeded obstacle dataset strategy for the live MVP presentation.

Significant Issues (Top 3 per category):

Code-Related:

  • Issue #92: Developed the end-to-end Report Obstacle feature — from native device integration (GPS, camera) through form validation, API submission, and success feedback — for both mobile and web clients.
  • Issue #91: Designed and implemented the Mobility Profile page — interactive preference controls, accessibility aid selection, gradient validation, and full backend API integration.
  • Issue #148: Implemented the map-based location picker for the report form, enabling users to manually select a report location by dropping a pin (SRS 1.1.3.7).

Non-Code-Related:

  • Issue #87: Authored the Test Plan & Coverage wiki — 14 test scenarios, 65+ UAC entries mapped to SRS requirements, a full traceability matrix, and the project's CI testing policy.
  • Issue #40: Produced the Municipality Resolution Use Case Diagram (PlantUML), reviewed and corrected UML relationships in other sub-groups' diagrams, and contributed to Lab 3 report coordination.
  • Issue #105: Defined the MVP demo structure, live user scenarios, and the pre-seeded campus obstacle data strategy for the live presentation.

Pull Requests:

  • PR #111: feat(frontend): report obstacle — delivered the full Report Obstacle flow: useLocation, PhotoPicker, ReportForm, ReportSuccessScreen, reports.ts API service, tab wiring, Jest environment setup, and 25 unit tests. Resolved package-lock.json conflicts introduced by a parallel branch before merging.
  • PR #113: feat(frontend): mobility profile — delivered MobilityProfileCard, AidTypeChips, mobilityProfile.ts API module, useMobilityProfile hook, type definitions, Babel config update, and 21 Jest tests across MobilityProfileCard.test.tsx and mobilityProfileApi.test.ts. Resolved package-lock.json conflicts from main.
  • PR #131: fix(profile): correct /users/me endpoint URL and normalize reputationPoints to trustScore — patched a silent field-name mismatch between the backend response and the frontend auth service.
  • PR #142: feat(frontend): merge route planning into map screen — integrated the route planning overlay into MapScreen with 1,474 net lines across MapView.tsx and MapView.web.tsx; included a UX fix for pin-clearing on mobile.
  • PR #149: feat: add choose-on-map location picker to report form — added LocationPicker.tsx and LocationPicker.web.tsx, refactored ReportForm.tsx by 218 lines to support both GPS and manual pin-drop input, and added address display alongside coordinate fields.
  • (Contributed) PR #133: fix: align frontend map API with backend response format — contributed branch sync and conflict resolution against main for this cross-team API alignment PR, which touched frontend/src/api/map.ts, MapView.tsx, and MapView.web.tsx.

Testing:

I wrote all 46 frontend unit tests (730 lines total) and configured the Jest testing infrastructure from scratch, including jest.setup.js with native module mocks for expo-location and expo-image-picker.

Test File Tests Lines Coverage Focus
MobilityProfileCard.test.tsx 16 244 Loading state, setup prompt, edit/cancel/save flow, aid-type chips, slope gradient validation (>25%, negative, empty), save payload shape, error banner on failure
ReportForm.test.tsx 6 120 Section headings, context options, obstacle categories, photo validation (UAC-7.2), optional category (UAC-7.5), disabled submit during loading
ReportSuccessScreen.test.tsx 7 77 Success heading, truncated report ID display, status badge, autoVerified flag, submit-another callback
mobilityProfileApi.test.ts 5 132 Mock API CRUD — GET/POST/PUT profile, persistence across calls
useLocation.test.ts 5 73 Loading state, GPS permission granted/denied, GPS error handling, refetch trigger
reports.api.test.ts 7 84 submitReport response shape, optional fields, coordinate rounding to exactly 6 decimal places

Two bugs were caught and fixed before merging as a direct result of this test suite: auth routing and Expo startup failures (Issue #109, PR #110) and the /users/me endpoint URL and trustScore field normalization mismatch (Issue #130, PR #131).

Additional Information:

Systems Architecture & Sequence Diagramming. I authored Section 3 of the Sequence Diagrams wiki — "Submitting a New Obstacle Report" — which models the complete frontend-to-backend interaction for the Report Obstacle feature. The diagram covers proximity deduplication (20-metre radius check), the media pipeline (cloud storage with URI reference in the database), the auto-verify trust-score path, and geospatial indexing pre-conditions. The accompanying refinement notes identified gaps in the UML Class Diagram — missing constructors, implied accessor methods, and the database lifeline abstraction — and served as a shared implementation specification for both sub-teams. I also produced the Municipality Resolution Use Case Diagram (Issue #40), defining role-based access boundaries and interaction flows across the Citizen, Municipal User, and Administrator actors.

Documentation & Process Contributions. I authored the Test Plan & Coverage wiki page, establishing the project's testing strategy across 14 scenarios and 65+ UAC entries with full SRS traceability. I contributed to the Responsibility Assignment Matrix (RAM), applying the RACI model to assign clear ownership across the frontend, backend, mobile, and DevOps sub-groups. I also collaborated on decomposing the Milestones Roadmap into GitHub issues during Lab 6 planning and contributed to structuring the MVP report.

Cross-Team Coordination. The diagramming and specification work had a direct impact on integration quality. By documenting the expected API contract — GPS coordinate precision, photo URI semantics, the trustScore field name, and the duplicate-detection response shape — before implementation began, I gave the backend team a concrete and testable target. This pre-alignment reduced integration friction: both the reputationPoints → trustScore mismatch (PR #131) and the map API response format divergence (PR #133) were caught and resolved quickly because the contract was already defined on the frontend side.

Ekin Kilic — @ekinklc (Frontend)

Responsibilities: Frontend auth screens, user profile page, password reset (in progress), map screen redesign

Main Contributions:

  • Implemented registration and login screens with full auth flow
  • Built initial user profile page
  • Contributed to the unified map screen redesign (merging reports + map, restructured tabs, current-location picker for reports)
  • Substantial documentation work across the wiki
  • Presented the MVP demo

Significant Issues (Top 3 per category):

Code-Related:

  • Issue #81: Registration & Login Screens
  • Issue #82: User Profile Page (Stub)
  • Issue #83: Password Reset Flow (in progress; carried into next milestone)

Non-Code-Related:

  • Wiki: 2nd most active contributor (41 edits) — created Lab 2 Scenario (Municipality), Lab 6 & 7 Reports, Report 3, Weekly Meeting 5
  • MVP Demo: Presenter

Pull Requests — Merged:

  • PR #98: Implement auth (login/register) and profile pages

Pull Requests — Held for post-deadline merge (code-complete, frozen to protect demo build):

  • PR #135: Google Maps-style overlay UI with route planning — alternative UI direction; held pending team decision on whether to adopt or close in favor of the merged map screen

Tests: None this milestone

Fixes to main: None this milestone

Additional Information: Although code-side output was lighter this milestone (with password reset carrying into the next one), I took on a larger share of documentation, presentation, and late-stage design work. On the wiki I was the 2nd most active contributor with 41 edits, and I presented the MVP demo for the team. In the final design pass on the map screen, I helped merge the previously separate reports and map views into a single unified map, restructured the related tabs accordingly, and added the ability for users to pick their current location directly on the map when creating a report.

Ömer Belemir Delier — @omerbelemir (Backend/DevOps)

1. Responsibilities:

Throughout the MVP milestone I served as a Backend Engineer focused on routing, map services, and authentication systems. My primary responsibilities covered:

  • Routing Engine & Graph Logic: Designed and implemented the campus street network graph (nodes: intersections, edges: paths) and built the accessibility-aware routing algorithm (Dijkstra/A*) with constraints such as obstacle avoidance, slope limits, and stair filtering.
  • Map & Obstacle APIs: Developed endpoints for retrieving and managing obstacle data, ensuring correct filtering of VERIFIED, PASSIVE, and INDOOR reports and aligning them with routing requirements.
  • Authentication & User Systems: Implemented JWT-based authentication (login, refresh, logout) and contributed to secure user registration with bcrypt hashing and optional mobility profile creation.
  • Search & Location Services: Implemented campus-scoped search functionality to allow users to find locations within Boğaziçi University bounds.
  • PR Reviews & Integration: Reviewed, merged, and maintained backend branches, ensuring API contract consistency and resolving integration conflicts across features.

2. Main Contributions:

  • Accessibility-aware routing engine: Built the full routing pipeline (POST /routes/calculate) including graph construction, shortest-path algorithm (Dijkstra/A*), obstacle-aware navigation, and preference-based filtering (avoid stairs, max slope gradient). Integrated VERIFIED obstacle avoidance and excluded INDOOR/PASSIVE reports from routing.
  • Map obstacle endpoints (core map feature): Implemented GET /api/map/obstacles/ and GET /api/map/obstacles/{id}/ with bbox filtering, passive inclusion toggle, and detailed response structures (photos, status history, metadata). Added comprehensive unit tests (20+) covering all acceptance criteria.
  • JWT authentication system: Developed authentication endpoints using SimpleJWT, including login, refresh, and logout with token blacklisting and rate limiting.
  • User registration & mobility profile integration: Implemented POST /auth/register with secure password hashing and optional inline mobility profile creation, enabling personalized routing preferences.
  • Campus search functionality: Built GET /map/search endpoint returning campus-scoped location results with coordinates, supporting routing inputs.

3. Significant Issues (Top 3 per category):

Code-Related:

  • Issue #102: Implemented accessibility-aware routing engine — graph modeling, Dijkstra/A* algorithm, obstacle avoidance, and preference-based filtering.
  • Issue #99: Implemented map obstacle endpoints — bbox filtering, status handling, and full response contract compliance (PR #125).
  • Issue #89: Implemented JWT authentication endpoints — login, refresh, logout, and token blacklisting (PR #94).

Non-Code-Related:

  • PR Review & Integration Workflow: Reviewed and merged backend PRs, ensured API consistency, and resolved integration conflicts across routing, map, and frontend layers.
  • API Contract Alignment: Maintained strict adherence to API contracts, ensuring seamless frontend-backend integration.

4. Pull Requests:

  • PR #125: feat: map obstacles endpoints (Issue #99) — Implemented obstacle list and detail endpoints with bbox filtering, passive inclusion, detailed metadata (photos, status history), and 20 unit tests.

  • PR #94: feat: JWT authentication endpoints (Issue #89) — Implemented login, refresh, logout endpoints using SimpleJWT with token blacklisting and rate limiting.

  • (Feature Implementation): Routing Engine — Issue #102 — Built accessibility-aware routing system with graph-based pathfinding, obstacle avoidance, and preference handling.

  • (Feature Implementation): Location Search — Issue #104 — Implemented campus-bounded search endpoint returning relevant locations with coordinates.

5. Additional Information:

Core Backend Feature Ownership. I was responsible for some of the most critical user-facing backend features, including routing, obstacle handling, and authentication. These components directly power the core functionality of the application.

Algorithmic Complexity. The routing engine required combining graph algorithms with real-world accessibility constraints (slope, stairs, obstacles), making it one of the most technically challenging parts of the project.

System Integration Impact. My work connected multiple subsystems — reports (obstacles), user mobility profiles (preferences), and map services — into a cohesive routing experience, which was essential for delivering a functional MVP.

Ulas Sertan Kemec — @UlasSertan (Backend)

Responsibilities:

Worked as a Backend Core Engineer this milestone — built the foundational layers the rest of the backend was built on top of, and contributed a few frontend/deployment fixes late in the milestone. Specifically:

  • Project Scaffolding: Created the initial repository layout for both backend and frontend in a single PR before any feature work began.
  • Authentication & Authorization: Owned the auth layer end-to-end — simplejwt integration, login/refresh/logout with token blacklisting, rate limiting, the DRF permission class, Role/Status enums, and the guest-mode policy.
  • Core Backend Features: Implemented POST /api/reports/ end-to-end (serializer → service → view → Supabase bucket photo pipeline) and GET /api/map/obstacles/ with bbox geospatial filtering.
  • Routing Engine Extension: Added pedestrian-mode routing and a first-iteration obstacle-avoidance pass on top of the base routing service, before the team adopted Valhalla exclude_locations as the final strategy.
  • Pre-Deadline Stabilization: Landed four fix PRs on submission day cleaning up independent breakages on main, plus a test-suite refresh aligning backend tests with the current API.
  • MVP Scope & Review Process: Defined the MVP Milestone acceptance criteria, authored the first draft of this Milestone Review document, and acted as reviewer for multiple cross-team PRs.

Main Contributions:

  • Project skeleton (PR #93, 167 files): Full repo layout for backend and frontend — Django apps/ structure, Expo Router directory tree, Dockerfile skeletons — committed empty so the team could start working in parallel. Every piece of code this milestone sits on top of this.

  • JWT authentication & authorization (PR #94 +185, PR #95 +111): Integrated simplejwt, implemented login/refresh/logout with token blacklisting and rate limiting, populated the custom exception handler, and built the authorization layer on top — DRF permission class, Role enum (registered user / admin / infrastructure authority), Status enum, and guest-mode policy matching NFR-5.3. PR #94's initial diff was ~+600 including most of settings.py, but conflict resolution stripped the settings portion because parallel PRs had re-added the same config. PR #95 went through 4 rounds of merge-conflict resolution because other PRs kept landing while this one waited for review.

  • Obstacle reporting API (PR #120, +274, 8 files): Delivered the entire POST /api/reports/ stack — serializer, service, view, DB writes, and the photo pipeline (backend stores/returns a URL, actual image lives in a Supabase bucket; added the Supabase settings as part of this PR). Validated locally with curl across happy path, validation failures, and photo upload before opening.

  • Map obstacles API (PR #125, +685): Implemented GET /api/map/obstacles/ and GET /api/map/obstacles/{id}/. The selector filters by status, context=OUTDOOR, and bbox corners, with prefetch_related on photos and interactions to avoid N+1 queries. Wrote the full obstacles test suite alongside (41 tests, 358 lines).

  • Route engine — pedestrian routing & obstacle avoidance (PR #134, +139): Built on top of Omer's base routing service. Added pedestrian-mode routing so the engine would plan walking paths instead of vehicle routes, and a first-iteration obstacle-avoidance attempt via the Valhalla API — where the previous version only emitted a warning, this version attempted to route around obstacles. The approach did not fully solve the problem and the team later replaced it with Valhalla exclude_locations in PR #138.

  • Backend test suite refresh & coverage (PR #158, +1168): After pre-deadline stabilization the existing test suite had drifted out of sync with the current API and was failing on main. Rewrote the affected tests, fixed several map-serializer bugs surfaced along the way, and computed the first backend coverage report for the milestone — the coverage numbers in D6.4.3 come from this PR.

  • Pre-deadline stabilization (4 fix PRs on submission day): Cleaned up independent breakages on main — a stale context parameter in the reports flow + Nominatim geocoding (PR #136), a redundant Postgres service in the frontend Dockerfile (PR #147), a missing nginx types block that was causing Render to serve a blank page (PR #150), and unused Expo Router tabs leaking into the production build (PR #155).

Significant Issues (Top 3 per category):

Code-Related:

  • Issue #89: Implemented login/refresh/logout auth endpoints with simplejwt, token blacklisting, and rate limiting.
  • Issue #99: Implemented GET /api/map/obstacles/ and GET /api/map/obstacles/{id}/ — bbox selector, status filters, passive-report toggle, and full test suite.
  • Issue #80: Built the role-based authorization layer — permission class, Role/Status enums, and guest-mode policy (NFR-5.3).

Non-Code-Related:

  • Authored the first draft of this Milestone Review document (D6/D7) — deliverables table, requirements mapping, testing section, and the initial D7 contribution drafts for the team.
  • Defined the MVP Milestone acceptance criteria on GitHub, and co-authored the Municipality Resolution Use Case Diagram, Scenario, and Sequence Diagram on the wiki (31 wiki edits total).
  • Reviewed and approved cross-team PRs: #149, #128, #101, #97.

Pull Requests:

Feature work: #93 project skeleton (167 files) · #94 JWT auth endpoints (+185) · #95 role-based authorization (+111, 4 conflict rounds) · #120 POST /api/reports/ (+274) · #125 GET /api/map/obstacles/ (+685) · #134 pedestrian routing + obstacle avoidance (+139) · #158 backend test suite refresh + coverage (+1168).

Pre-deadline stabilization: #136 context parameter fix + Nominatim (+40) · #147 remove redundant Postgres from frontend Docker · #150 nginx MIME types block · #155 hide unused Expo Router tabs.

Tests:

  • PR #125 — backend/apps/map/tests.py — 41 tests, 358 lines. Covered obstacle selectors (bbox, status, passive/outdoor filtering), list view (response shape, thumbnail, upvote count), and detail view (photos, status history, auth-free access).
  • PR #158 — Aligned the backend test suite with the current API after pre-deadline drift, fixed map-serializer bugs surfaced along the way, and produced the backend coverage report in D6.4.3.

Fixes to main (all via PRs — main is protected, never committed directly): PRs #136, #147, #150, #155, #158 (see above). Also wrote a database migration in every feature PR (~4–5 total across the milestone) and tracked down several .env errors during deployment setup.

Additional Information:

Pre-PR Local Validation. Before opening any backend PR, I smoke-tested every endpoint against a local Django instance with curl — happy path, validation failures, and auth failures.

Milestone Review Ownership & MVP Scope. Opened this Milestone Review document, drafted the first full version (deliverables, requirements mapping, testing, initial D7 drafts for the team), and selected the MVP Milestone acceptance criteria on GitHub. Subsequent edits were collaborative but the structure and first pass originated here.

Not Shipped (deadline freeze). Reports were loading slowly on the map screen; I opened a local branch investigating a frontend caching strategy and a backend N+1 fix, but did not open a PR because the team had entered the submission-day freeze and a query-layer change would have risked the demo build. Carrying forward into the next milestone.

Project

Team Members

Lab Reports

Weekly Meetings

Scenarios and Mock ups

Use Case Diagrams

Class Diagram

Sequence Diagrams

Milestone Review

Clone this wiki locally