D6. Milestone Review

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.

Elicitation Questions

Most helpful questions (from the Elicitation Questions wiki and Customer Meeting #1):

Q8 — Trust Score for contributors: Directly shaped our upvote/feedback-based verification model and the planned Elite User badge system. Raised before any architecture decisions, it forced early alignment on how we distinguish reliable from unreliable reports.
Q10 — Should photo upload be required? Resolved a core design tension between ease of reporting and data quality. The customer confirmed photos as the primary trust signal, making mandatory photo upload a Must-Have rather than an optional enhancement.
Q15 — What is the MVP geographic scope? Clarifying that the MVP targets Boğaziçi North-South campus with real seeded data eliminated ambiguity around map coverage and let us focus backend and routing work on a bounded, testable area.
Q17 — Should users drop a pin manually or rely on GPS auto-capture? The answer ("both are valid") directly produced the dual-mode location input: GPS auto-fill as the default with map pin drop as the fallback — the exact UX shipped in PRs #111 and #149.

Responses that transformed requirements:

"The primary metric is Accessibility Level, not shortest time." — The routing algorithm was redesigned from distance minimization to obstacle-avoidance as its core objective. This drove the entire Valhalla integration and the exclude_locations approach.
"Turn-by-turn navigation is not required for the MVP." — Eliminated a significant scope risk. Routes are shown as a static visual path, reducing implementation complexity and keeping the focus on pre-trip planning rather than real-time guidance.
"Verification will rely on user upvotes and feedback." — Established the Trust Score model as the long-term verification mechanism, and justified the auto-verify workaround used for the MVP demo while the reputation system is built out.
"There are no limits on what can be reported; users should be able to add categories." — Shifted the report form from a closed fixed-category dropdown to a model with predefined categories plus a free-text description, matching SRS requirements 1.1.5.1–1.1.5.5.

D6.2 Deliverables

Deliverable	Status	Notes
User Management & Access
User registration & login	Completed	JWT auth, bcrypt hashing, frontend auth screens (#94, #95, #97, #98)
User profile (view & edit)	Completed	GET/PUT `/api/auth/users/me`, profile page (#113, #128)
Mobility profile (preferences)	In Progress	Frontend UI complete; backend CRUD endpoints in progress (Issue #143)
Guest mode & role-based access	In Progress	Backend permission layer done; guest restriction UI pending (Issue #90)
Password reset	In Progress	Carried to final milestone (Issue #83)
Interactive Map & Routing
Geospatial map with obstacle markers	Completed	Leaflet (web) + WebView/Leaflet (mobile), pan/zoom, obstacle pins (#112, #117)
Campus location search	Completed	Text search within Boğaziçi campus bounds (#129)
Accessibility route planning	Completed	Origin/destination input, Valhalla obstacle-avoidance routing, static route display (#122, #134, #138, #142)
Mobility-personalized routing	In Progress	Preferences model exists; full routing integration blocked on mobility profile endpoints
Indoor environment mapping	Not Started	Planned for final milestone
Obstacle Reporting
Obstacle report submission	Completed	GPS auto-capture + manual pin drop, mandatory photo upload, categorization, description (#111, #120, #149)
Obstacle detail view	Completed	Tap marker to view category, description, photos, status (#125)
Report verification (auto-verify for MVP)	Completed	All submitted reports auto-confirmed as MVP workaround (#140)
Community upvote / flag	Not Started	Planned for final milestone
Automated report lifecycle management	Not Started	Status transitions (Unverified → Confirmed → Passive) based on community interactions
Trust & Gamification
Trust Score / Reputation system	Not Started	Data model exists; UI and business logic planned for final milestone
User badges & Elite Contributor role	Not Started	Planned for final milestone
Issue Resolution & Authority
Municipality / authority dashboard	Not Started	Planned for final milestone
Report resolution workflow	Not Started	Authorities upload post-repair evidence, mark obstacle as resolved
Community resolution confirmation	Not Started	Citizens confirm a fix before the marker is archived
System Moderation
Admin moderation interface	Not Started	Flag queue review, account suspension
Spam detection & account management	Not Started	Automated detection for high-volume unverified submissions
Push notification system	Not Started	Status-change alerts for contributors
Infrastructure
Backend deployment	Completed	Django on Railway (Docker + CI pipeline), Vercel for web frontend (#96, #145)
Mobile app build (Android APK)	Completed	Automated GitHub Actions APK on every push to `main` (#157)

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."

Evaluation of Deliverable Status

The core user-facing loop — authentication, map display, obstacle reporting, and route planning — reached completed status and was demonstrated live on the deployed environment. This represents the majority of the MVP scope and validates the primary architectural decisions.

The three in-progress deliverables (Mobility Profile Endpoints, Guest Restriction UI, Password Reset) are non-blocking for the core flow but affect personalization and edge-case safety. They are carried forward as high-priority issues for the final milestone.

The most significant plan impact came from the routing engine pivot: OSRM was integrated first (PRs #122, #129) but required two additional rounds of work to replace the 60-metre offset hack with Valhalla's exclude_locations (PRs #134, #138). This compressed the testing window for routing and is the main driver of the E2E test gap noted in D6.4.3.

The deadline freeze policy successfully protected the demo build. The cost — UI aesthetics, guest restriction, and a frontend caching optimization deferred — is an acceptable trade-off given the stability requirement. For the final milestone, E2E smoke testing is elevated to a hard requirement rather than a stretch goal.

UX Design

AccessMap's UX centers around a three-tab structure — Map, Report, Profile — keeping all primary actions reachable without deep navigation. The design philosophy is that accessibility barriers are spatial and time-sensitive, so every major flow is tied back to the map and minimizes the steps between "I see a problem" and "it is reported."

Map & Route Planning

The map opens centered on the user's current GPS position and renders existing obstacle pins on the live campus street network. Tapping a pin zooms in on that location and shows the report details inline. For route planning, users type or select an origin and destination; once a route is calculated, the map automatically fits and zooms to show the full path. If an obstacle sits on the suggested route, the engine reroutes around it and the map pans to highlight the detour — the user sees the obstacle-avoiding path without needing to interpret any warnings manually.

Obstacle Reporting

The Report tab auto-captures the user's GPS coordinates on open, displaying the detected address so the user can confirm they are at the right spot. As an alternative, users can tap "Choose on Map" which drops a draggable pin directly on the map — the map zooms to street level, the user repositions the pin, and the coordinates update in the form. The form then collects context (Indoor / Outdoor), category, a mandatory photo (camera or gallery), and an optional description before submission. On success, a confirmation screen shows the submitted report's status and a shortcut to view it on the map, closing the feedback loop.

Mobility Profile

The profile setup presents aid types as a visual icon grid (Wheelchair, Crutches, Walker, Scooter, etc.) with large tap targets appropriate for users with reduced motor precision, rather than a dropdown. Routing preferences — avoid stairs, avoid steep slopes, maximum slope gradient — are set once on the profile page and automatically applied to every subsequent route request without the user needing to re-enter them.

Domain-specific rationale

The Indoor / Outdoor distinction in the report form is a direct product of the routing requirement: indoor obstacle reports are excluded from street-level route calculations, so the form must capture this before submission. Similarly, mandatory photo upload is a trust mechanism agreed with the customer — text-only reports were considered insufficient for a crowdsourced safety system. The "Choose on Map" pin-drop interaction addresses the same friction the customer identified: users should not have to type coordinates or addresses while standing at an obstacle site.

API Documentation

`POST /api/auth/register`

Register a new user. mobilityProfile is optional.

Request:

{
  "email": "ali@boun.edu.tr",
  "fullName": "Ali Akkaya",
  "password": "SecurePass123!",
  "birthDate": "1999-05-20",
  "mobilityProfile": {
    "mobilityAidType": "WHEELCHAIR",
    "avoidStairs": true,
    "avoidSteepSlopes": true,
    "maxSlopeGradient": 8.0
  }
}

Response 201:

{
  "userId": "a1b2c3d4-e5f6-...",
  "email": "ali@boun.edu.tr",
  "fullName": "Ali Akkaya",
  "account_status": "ACTIVE",
  "trustScore": 0,
  "accessToken": "eyJhbGciOi...",
  "refreshToken": "eyJhbGciOi...",
  "createdAt": "2026-04-11T10:00:00Z"
}

`POST /api/auth/login`

Request:

{ "email": "ali@boun.edu.tr", "password": "SecurePass123!" }

Response 200:

{ "access": "eyJhbGciOi...", "refresh": "eyJhbGciOi..." }

`POST /api/auth/logout` (auth required)

Request:

{ "refresh": "eyJhbGciOi..." }

Response 204: No content. The refresh token is blacklisted.

`POST /api/auth/refresh`

Request:

{ "refresh": "eyJhbGciOi..." }

Response 200:

{ "access": "eyJhbGciOi..." }

`GET /api/auth/users/me` (auth required)

Response 200:

{
  "userId": "a1b2c3d4-e5f6-...",
  "email": "ali@boun.edu.tr",
  "fullName": "Ali Akkaya",
  "birthDate": "1999-05-20",
  "role": "USER",
  "accountStatus": "ACTIVE",
  "reputationPoints": 12,
  "createdAt": "2026-04-11T10:00:00Z",
  "mobilityProfile": {
    "mobilityAidType": "WHEELCHAIR",
    "avoidStairs": true,
    "avoidSteepSlopes": true,
    "maxSlopeGradient": 8.0
  }
}

`GET /api/map/obstacles/`

Query parameters: bbox (required) — sw_lat,sw_lng,ne_lat,ne_lng; includePassive — true/false (default false); status — CONFIRMED, PENDING, etc.

Example: GET /api/map/obstacles/?bbox=41.080,29.040,41.090,29.055

Response 200:

{
  "obstacles": [
    {
      "reportId": "b2c3d4e5-...",
      "location": { "lat": 41.0842, "lng": 29.0504 },
      "category": "BROKEN_RAMP",
      "context": "OUTDOOR",
      "status": "CONFIRMED",
      "title": "Broken Ramp",
      "description": "Ramp is cracked and impassable for wheelchairs.",
      "isIndoor": false,
      "upvoteCount": 3,
      "thumbnailUrl": "https://storage.example.com/photos/ramp.jpg",
      "createdAt": "2026-04-10T09:00:00Z"
    }
  ],
  "total": 1
}

`GET /api/map/obstacles/{obstacle_id}/`

Response 200:

{
  "reportId": "b2c3d4e5-...",
  "location": { "lat": 41.0842, "lng": 29.0504 },
  "category": "BROKEN_RAMP",
  "context": "OUTDOOR",
  "status": "CONFIRMED",
  "description": "Ramp is cracked and impassable for wheelchairs.",
  "upvoteCount": 3,
  "flagCount": 0,
  "photos": [
    { "url": "https://storage.example.com/photos/ramp.jpg", "uploadedAt": "2026-04-10T09:00:00Z" }
  ],
  "statusHistory": [
    {
      "oldStatus": "PENDING",
      "newStatus": "CONFIRMED",
      "changedBy": "admin@boun.edu.tr",
      "reason": "Auto-verified by MVP policy",
      "changedAt": "2026-04-10T09:00:01Z"
    }
  ],
  "createdAt": "2026-04-10T09:00:00Z"
}

`GET /api/map/search?q={query}`

Example: GET /api/map/search?q=library

Response 200:

{
  "results": [
    { "name": "Science Library", "location": { "lat": 41.0840, "lng": 29.0502 }, "category": "BUILDING" }
  ]
}

`POST /api/reports/` (auth required)

photos is a list of 1–3 pre-uploaded Supabase storage URLs. category is optional.

Request:

{
  "location": { "lat": 41.084200, "lng": 29.050400 },
  "context": "OUTDOOR",
  "category": "BROKEN_RAMP",
  "description": "Large crack, impassable for wheelchairs.",
  "photos": ["https://storage.example.com/photos/ramp.jpg"]
}

Response 201:

{
  "reportId": "c3d4e5f6-...",
  "status": "CONFIRMED",
  "autoVerified": true,
  "duplicateCandidate": null,
  "createdAt": "2026-04-11T10:00:00Z"
}

`POST /api/routes/calculate`

preferences is optional; if omitted and the user is authenticated, the server reads their mobility profile.

Request:

{
  "originLat": 41.0830,
  "originLng": 29.0495,
  "destinationLat": 41.0860,
  "destinationLng": 29.0520,
  "preferences": {
    "avoidStairs": true,
    "avoidSteepSlopes": false,
    "maxSlopeGradient": null
  }
}

Response 200:

{
  "waypoints": [[41.0830, 29.0495], [41.0845, 29.0510], [41.0860, 29.0520]],
  "distanceMeters": 380.5,
  "estimatedTimeSeconds": 290,
  "avoidedObstaclesCount": 1,
  "warnings": ["Confirmed obstacle near waypoint 2 — detour applied"],
  "isAccessible": true
}

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:

Auth routing and Expo startup bugs caught and fixed (Issue #109, PR #110)
Profile endpoint URL and trustScore normalization issue (Issue #130, PR #131)
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)
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)
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 / Database / DevOps / Map)

Responsibilities:

Throughout the MVP milestone I served as the Database & Reports Backend Lead and the Map Frontend Lead, while also taking responsibility for the team's
production deployment and serving as the primary stakeholder-facing presenter
for the MVP demo. My primary responsibilities covered:

Database & Schema Ownership: Designed and implemented the full database schema across the Users, Reports, Routing, and Notifications domains. Authored every migration in the initial schema set and built the campus graph seed script that bootstraps the routing layer.
Reports Backend: Owned the obstacle reporting endpoint end-to-end — implemented POST /reports with duplicate detection, the auto-verification
workaround for the MVP, and the full Django test suite covering the flow.
Map Frontend: Led the unification of the map and routing experience by merging route planning into the map screen with a Google Maps–style UX, including the
prefetch-on-mount optimization, web/native parity, and alignment of the frontend map API with the backend response format.
Deployment: Configured the Railway deployment for the dockerized backend and the Vercel deployment for the web frontend. Resolved all production blockers —
dynamic PORT injection for Railway nginx, npm legacy peer dependency conflicts, duplicate URL namespace cleanup, and nginx routing.
Requirements & Design: Contributed to the SRS through Non-Functional Requirements authorship, the "Disabled User Route Planning" scenario, and the
Sequence Diagrams for the Admin Moderation / User Banning and obstacle reporting flows.
Demo & Presentation: Took the leading role as the team's stakeholder-facing presenter for the MVP demo, walking through the live obstacle reporting and
routing flows on the deployed environment.

Main Contributions:

Full database foundation: Built the entire database schema, migration set, and campus graph seed script from the ground up — the data layer that all other backend work built upon.
Reports submission pipeline: Implemented POST /reports with duplicate detection logic, the auto-verification path used for the MVP demo, and 274 lines of test coverage validating the flow end-to-end.
Map + routing unification: Merged the standalone route planning screen into
the map screen with a Google Maps–style UX (~1,200 LOC across MapView.tsx and
MapView.web.tsx), eliminating a tab and producing the experience demoed to stakeholders.
Production deployment: Took the project from local-only to a fully deployed state on Railway (backend) and Vercel (frontend), shipping the deploy fixes that unblocked the MVP cut.

Significant Issues (Top 3 per category):

Code-Related:

Issue #79: Database Schema & Migrations — Designed the schema across Users,
Reports, Routing, and Notifications and implemented every migration in the initial set, plus the campus graph seed command (PR #108).
Issue #124: [BE] POST /reports — Obstacle Report Submission — Implemented the full report submission endpoint with duplicate detection, auto-verification for the MVP demo, and comprehensive test coverage (PR #127).
Issue #77: Create Project Skeleton — Bootstrapped the initial project
structure and the early stub-app deliverable that established the team's working baseline (PR #70).

Non-Code-Related:

Issue #58: Sequence Diagram — Admin Moderation & User Banning — Authored the
moderation/banning sequence diagram for the SRS.
Issue #34: Non-Functional Requirements — Defined, organized, and enumerated
the NFRs for the SRS.
Issue #14: Scenario 1 — Disabled User Route Planning — Wrote the foundational user scenario describing the core accessibility routing flow that drove the MVP feature set.

Pull Requests:

PR #108: feat: database schema, migrations & campus seed script — Designed the full schema across users, reports, routing, and notifications, authored the initial migration set, and built seed_campus_graph management command to
bootstrap the routing layer.
PR #127: feat(reports): implement POST /reports endpoint — Implemented the obstacle report submission endpoint with duplicate detection logic in
reports/services.py, the context_type field on the serializer, and 274 lines of test coverage in reports/tests.py validating the end-to-end flow.
PR #145: feat: add Railway deployment config for frontend and backend — Added the frontend Dockerfile and nginx config, the Railway/Vercel deployment
configuration, and the production settings adjustments needed to deploy the dockerized backend and the web frontend.
PR #146: fix: deploy fixes for Railway — Resolved the production blockers preventing the MVP cut from going live: npm legacy peer dependency conflicts,
duplicate users URL namespace, and the dynamic PORT injection required by Railway's nginx runtime.
PR #70: feat: implement Ali's Posts button with API integration and Dockerfile — The early stub-app deliverable that integrated the JSONPlaceholder API and
contributed an initial Dockerfile, establishing the working baseline for the team's first lab milestone.
(Direct to main): Map + route planning merge (commit 46d0d7b) — Merged the route planning screen into the map screen with a Google Maps–style UX across
both MapView.tsx (native) and MapView.web.tsx (web), totaling ~1,200 LOC of frontend changes — the unified map experience demoed to stakeholders.
(Reviewed & Merged): PR #96 (Docker setup), PR #122 (routing logic and cleanup).

Additional Information:

Database & Backend Ownership. I was the primary author of the data layer that
the rest of the backend was built on. The schema across Users, Reports, Routing, and Notifications, the migration history, and the seed_campus_graph command
that produces the initial routable graph for Boğaziçi campus all originated from my work in PR #108 and the surrounding commits. The reports endpoint I implemented in PR #127 — including the duplicate detection logic and the auto-verification path enabled for the MVP demo — was the single feature most directly exercised during the live demo.

Map Experience Ownership. The map screen was my primary frontend contribution.
Before my changes, route planning lived on a separate tab with its own UX; I unified the two so users could pick origin/destination, view obstacles, and
request a route from a single Google Maps–style interface. This work also included the prefetch-on-mount optimization (so obstacles load before the map initializes) and the alignment fixes between the frontend map API and the backend response format.

Deployment Ownership. I owned the path from a local Docker Compose environment
to a publicly reachable production deployment. This included selecting Railway for the backend and Vercel for the frontend, writing the frontend Dockerfile and nginx config, and debugging the production-only failures (legacy peer dependency conflicts, duplicate URL namespace, dynamic PORT for Railway's nginx runtime) that surfaced only after the first deploy attempt. Without this work the MVP demo could not have run on a real URL in front of stakeholders.

SRS & Design Contributions. Beyond code, I contributed the "Disabled User Route Planning" scenario (#14), the Non-Functional Requirements section (#34), and the Sequence Diagram for the Admin Moderation & User Banning flow (#58) to the SRS — the design artifacts that framed the obstacle reporting and moderation features the team built.

Stakeholder Presentation. I served as the team's primary presenter for the MVP
demo, walking stakeholders through the live obstacle reporting and routing flows on the deployed environment.

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 / Mobile)

Responsibilities:

I was responsible for the interactive map interface and the mobile experience throughout the MVP milestone. This included building both the web and native mobile map and route planning screens, aligning the frontend data layer with the backend API, applying cross-platform UI refinements, and contributing to the routing engine. On the DevOps side, I authored the PR template that standardized the team's contribution workflow. Beyond the code, I contributed to early planning documentation — defining functional requirements, creating the Volunteer Accessibility Reporting Use Case Diagram, establishing the frontend team's role structure, and producing initial UI mockups that shaped the MVP's visual direction.

Main Contributions:

Interactive web map and route planning (PR #129): Built the web MapView component using Leaflet — obstacle pin rendering, passive report toggling, search bar, and popup detail cards — and the PlanView component for route planning, including origin/destination inputs, drop-pin interaction, reverse geocoding, route polyline display, and a route summary card. Resolved package-lock conflicts from parallel branches before merging.
Mobile map and route planning — WebView + Leaflet (PR #129): Implemented the native mobile map and plan screens by embedding Leaflet inside a React Native WebView, upgrading the Expo SDK from 52 to 54 for Expo Go compatibility. Diagnosed and resolved three distinct flickering bugs caused by WebView re-render loops and loading bar layout interactions that caused the map to resize in a jitter cycle.
Frontend–backend API alignment (PR #133): Corrected the frontend's map API integration layer — fixed the bbox parameter order (south,west,north,east) to match backend parsing, updated data parsing to read from the correct response keys (data.obstacles), and normalized all field name mappings (reportId → id, location.lat/lng → latitude/longitude, photo url → imageUrl, context INDOOR → isIndoor). Also added a category label as a title fallback for reports where the backend omits the title field. Prefetched the obstacle list on map mount to eliminate a visible empty-map flash on first load.
Routing engine upgrade — Valhalla obstacle avoidance: Replaced the OSRM-based routing workaround (a 60-metre perpendicular offset hack) with Valhalla's exclude_locations parameter for proper obstacle avoidance along pedestrian paths. The change included a graceful fallback to a direct route if avoidance routing fails. Also reduced the obstacle cache TTL in the backend to make newly submitted reports visible on the map with lower latency.
Map-based location picker for reports (PR #149): Implemented the cross-platform LocationPicker.tsx (88 lines) and LocationPicker.web.tsx (84 lines) components, enabling users to drop a pin directly on the map to select a report location as an alternative to GPS auto-fill. This satisfied SRS requirement 1.1.3.7.
UI polish and mobile layout fixes: Applied a round of cross-platform UI refinements across the map, plan, and report screens — correcting the search bar mobile layout collapse, standardising input heights and pin button proportions, removing browser focus outlines on web, and adjusting the mobile tab bar padding for visual balance.
PR template: Authored the .github/PULL_REQUEST_TEMPLATE.md that standardized PR descriptions across the repository, establishing a consistent format for the entire team's contribution workflow.
Wiki home page: Updated and maintained the project Wiki home page to reflect the current state of the project throughout the MVP milestone.
Use Case Diagram — Volunteer Accessibility Reporting (Issue #39): Created and refined the Use Case Diagram for the Volunteer Accessibility Reporting scenario using PlantUML, modelling the interaction between Citizens, Municipal Users, and the system's reporting engine. Updated the Wiki sidebar to include the diagram.
MVP demo planning and UI decisions: Finalized UI design decisions for the MVP presentation, planned the workflow for the final development week, and contributed to aligning the team on the demo flow and feature scope.

Significant Issues (Top 3 per category):

Code-Related:

Issue #84 / Issue #85: Built the interactive geospatial map and route planning screens for both web (Leaflet) and mobile (WebView + Leaflet), covering obstacle visualisation, route display, and the search interface (SRS 1.2.1.1, 1.1.3.1, 1.1.3.2).
Issue #137: Implemented obstacle avoidance in the routing engine by switching from OSRM to Valhalla's exclude_locations parameter, ensuring the generated route actively detours around verified outdoor obstacles (SRS 1.2.2.2, 1.2.2.3).
Issue #148: Implemented the map-based location picker for the report form, allowing users to drop a pin to select a report location rather than relying solely on GPS (SRS 1.1.3.7).

Non-Code-Related:

Issue #39: Produced the Volunteer Accessibility Reporting Use Case Diagram (PlantUML), modelling the full reporting flow across Citizen, Municipal User, and Administrator roles, and updated the Wiki sidebar.
Issue #49 / Issue #50: Created the GitHub issues for the Lab 4 class diagram milestone and contributed to design discussions that shaped the final class structure.
Issue #19: Defined and enumerated the full set of functional requirements using a hierarchical ID system (1.x.x) to ensure precision and formal structure, and validated coverage by mapping each requirement to the three defined user scenarios.

Pull Requests:

PR #129: feat: add campus location search and switch routing to OSRM — delivered the web map view (Leaflet, obstacle pins, popups, passive toggle, search bar) and the mobile map and plan screens (WebView + Leaflet, Expo SDK 52→54 upgrade, route polyline, summary card, reverse geocoding). Resolved three map-flickering bugs and package-lock conflicts before merging.
PR #133: fix: align frontend map API with backend response format — corrected bbox parameter order, updated all response field mappings in frontend/src/api/map.ts, and prefetched obstacles on map mount to eliminate the empty-map flash.
PR #149: feat: add choose-on-map location picker to report form — implemented LocationPicker.tsx and LocationPicker.web.tsx components for cross-platform map-based pin drop in the report flow.
PR #74: feat: add Baran joke button with JokeAPI — stub-app milestone: random programming joke fetched from JokeAPI, served via a Dockerfile using nginx:alpine; also added the PR template that standardized team contributions.
(Contributed) PR #140: feature: all reports are now verified for MVP — contributed the Valhalla routing engine fix (fix: replace OSRM hacky rerouting with Valhalla exclude_locations) and the obstacle cache TTL reduction within this branch.
(Reviewed / Merged) PR #111: feat(frontend): report obstacle — reviewed and merged Bora's Report Obstacle flow PR.
(Reviewed / Merged) PR #113: feat(frontend): mobility profile — reviewed and merged Bora's Mobility Profile PR.
(Reviewed / Merged) PR #131: fix(profile): correct /users/me endpoint URL — reviewed and merged the profile endpoint fix PR.
(Reviewed / Merged) PR #142: feat(frontend): merge route planning into map screen — reviewed and merged the route planning overlay integration PR.

Testing:

I did not author unit tests this milestone. The D6 test authorship record confirms that frontend tests were written by Bora Aydemir and backend tests by Omer Belemir and Ulas Sertan Kemec. My contribution to quality assurance was through the routing engine fix (the Valhalla switch was validated manually against campus obstacle coordinates during the pre-demo stabilisation phase) and through code review on the PRs I merged, which caught integration issues before they reached main.

Additional Information:

Map Architecture and Cross-Platform Strategy. The interactive map presented a dual-environment challenge: the web client needed a standard Leaflet integration, while the mobile client (React Native / Expo) had no direct Leaflet support. I resolved this by embedding Leaflet inside a react-native-webview component — the mobile MapView and PlanView screens render a self-contained Leaflet HTML document inside a WebView, with bidirectional communication via postMessage for user interactions such as pin drops and search results. This approach allowed both platforms to share the same underlying map logic while preserving native navigation on mobile. Diagnosing and fixing the three WebView flickering bugs (re-render loops, loading bar layout jitter) required careful analysis of React Native's rendering lifecycle and was a prerequisite for a stable mobile demo.

Routing Engine Contribution. Although my primary role was frontend, I contributed a backend fix with direct impact on the core product promise of the application. The original OSRM integration used an ad-hoc 60-metre perpendicular offset to approximate obstacle avoidance — a fragile approach that failed on curved roads and non-orthogonal paths. Switching to Valhalla's exclude_locations parameter ensured that the routing engine properly avoided road segments in the vicinity of verified obstacle coordinates, which is a fundamental requirement of the accessibility mapping use case (SRS 1.2.2.1–1.2.2.3). The cache TTL reduction was a related change that ensured newly submitted obstacle reports became visible in the routing engine within a shorter window.

Documentation and Process Contributions. I contributed to the project's documentation across multiple milestones. In Lab 2, I designed the Disabled User Route Planning scenario and authored the formal functional requirements structure (hierarchical 1.x.x numbering, requirement-to-scenario coverage mapping). In Lab 3, I produced the Volunteer Accessibility Reporting Use Case Diagram. For Lab 5, I created the Implementation Plan issue and the sub-issues for the milestone, and authored the PR template that brought consistency to the team's review process. For Lab 6, I defined the frontend team's role structure, produced sample UI mockups, and contributed to milestone issue decomposition. For Lab 7, I finalised UI decisions, updated the project Wiki home page, and helped plan the remaining development workflow ahead of the MVP deadline.

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 #141: Merged the route planning interface into the main map screen as a Google Maps-style overlay, consolidating two separate tabs into a single unified experience.

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.
(Contributed) 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.

Uh oh!

D6. Milestone Review

D6.1 Project Status

Feedback and Reflection

Elicitation Questions

D6.2 Deliverables

Evaluation of Deliverable Status

UX Design

API Documentation

POST /api/auth/register

POST /api/auth/login

POST /api/auth/logout (auth required)

POST /api/auth/refresh

GET /api/auth/users/me (auth required)

GET /api/map/obstacles/

GET /api/map/obstacles/{obstacle_id}/

GET /api/map/search?q={query}

POST /api/reports/ (auth required)

POST /api/routes/calculate

D6.3 Requirements

D6.4 Testing

D6.4.1 Test Plan & Strategy

D6.4.2 Test Execution Reports

D6.4.3 Impact Analysis

D6.5 Planning and Team Process

Organization and Project Management

Process Reflections and Lessons Learned

Evaluation of Tools

Project Plan Links

D7. Individual Contributions

Ali Akkaya — @aliakkaya1 (Backend / Database / DevOps / Map)

Arif Evren — @fira44 (Backend/DevOps)

Baran Önder — @baranonder (Frontend / Mobile)

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

Ekin Kilic — @ekinklc (Frontend)

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

Ulas Sertan Kemec — @UlasSertan (Backend)

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

`POST /api/auth/register`

`POST /api/auth/login`

`POST /api/auth/logout` (auth required)

`POST /api/auth/refresh`

`GET /api/auth/users/me` (auth required)

`GET /api/map/obstacles/`

`GET /api/map/obstacles/{obstacle_id}/`

`GET /api/map/search?q={query}`

`POST /api/reports/` (auth required)

`POST /api/routes/calculate`