Future Work

Future Work

Reference page — not a Final Milestone deliverable. This page collects forward-looking notes about scope and ideas that go beyond what the team committed to ship for the Final Milestone. The official deliverables are tracked under Final Milestone Deliverables and its parent issue #424.

The Final Milestone closes the course-bounded scope of the Campus-Neighborhood Mentorship Network. This page records things the team did not attempt to ship, things that shipped but could grow, and architectural questions that would surface in any continuation of the project.

---

1. Beyond Final Milestone scope

Items from the Lab 9 19-phase roadmap that were intentionally left out of the Final Milestone, ordered roughly by how disruptive they would be to add later.

1.1 Communities (1.1.7–1.1.12, 1.2.4)

Approximately 60 requirements covering community creation, membership, posts (text/image/video/link/poll), threaded comments, voting/reputation, feeds and sort modes (hot/new/top/rising/controversial), moderation and automoderation, reporting, and a public Community API with rate-limiting.

The Final Milestone replaced the Community surface with a Social Feed (per the Lab 10 pivot — follow/unfollow, hashtags, post interactions). Everything Community-shaped is on hold.

If continued: Lab 9 already documented a 7-phase implementation plan (Phases A–G) for this work — Community + membership → Posts → Comments → Voting + reputation → Feeds + sort modes → Moderation + automoderation → Reporting flow.

1.2 GDPR / KVKK compliance

Data-export endpoint, account-delete endpoint, and a consent flow at registration. The current implementation hashes passwords with BCrypt and serves over HTTPS, but does not provide users with the data-portability and right-to-erasure controls those regulations require.

1.3 Anti-abuse hardening (2.2.5–2.2.8)

Spam-bot registration detector (e.g. velocity-based blocking), vote-manipulation detector (per-user/IP rate limiting on votes, sockpuppet similarity check), ban-evasion detector (device-fingerprint / IP / email-domain cross-check against the active-bans table), and time-window graph clustering on vote/post patterns to surface coordinated abuse to admins.

The Final Milestone shipped the automatic temporary ban system (#134, PR #380), so the enforcement plumbing exists; the missing piece is the heuristic detectors that feed it.

1.4 Performance load validation (2.3.2, 2.3.5)

5,000 concurrent mentor-mentee messaging sessions and 1,000 posts/second sustained content creation. Acceptance test AT-07 defines the test plan; the test runs themselves are deferred to a continuation.

1.5 Production observability

Prometheus + Grafana for backend metrics, structured log aggregation (the Logback + logstash-logback-encoder dependencies are already wired), tracing, and alerting on the meeting / notification / ban-expiry schedulers.

---

2. Built but could extend

Features that shipped in the Final Milestone but have natural growth paths.

• Social Feed — moderation hooks (currently community-style moderation lives in the un-shipped Communities surface; Social Feed posts have no equivalent yet).
• Recommendation engine — diversity branch (~10% out-of-primary-goal mentors via shared interests/skills) and an explanation breakdown surface ("shared interest: ML; same major; 3 km away") were planned in Lab 9 but only the core matching is in production.
• Mobile push notifications — FCM is wired up via FcmConfig / FcmPushDeliveryService but the per-platform notification preferences UI on mobile is not yet exposed (web has the preferences endpoint).
• Mentorship rating — POST /api/mentorships/{id}/rating was scoped for after COMPLETED/TERMINATED but is not in the Final.
• Blog — a stakeholder-confirmed feature in Lab 9; the backend (#281) and UI (#290) shipped, but the integration into the mentor public profile is partial.
• Mentor-to-mentor messaging UI — backend supports it (ConversationKind enum); UI entry-points exist but cross-platform parity could be tightened (#287).

---

3. Open architectural questions

Things the team identified but didn't conclude on.

• Optimistic locking surface — V11 added @Version broadly, but the bilateral-toggle entities introduced later (e.g. MilestoneActionItem) shipped without @Version. A consistent policy ("every entity that supports concurrent writes from multiple roles gets @Version") would close the loop.
• Migration version discipline — Flyway version collisions have already happened twice (V25 in PR #378 vs PR #380). A pre-commit hook or a CI check that rejects two PRs sharing a V<N>__ prefix would prevent this.
• API versioning — every endpoint is currently /api/... with no version segment. As soon as a real third-party consumer appears (per the un-shipped public Community API), this becomes a forced choice between URL-versioning, header-versioning, and OpenAPI-managed deprecation.
• Testing reproducibility — Lab 9's data strategy specifies Faker.seed(42) in CI plus a committed seed-snapshot.sql, but the snapshot itself isn't in the repo yet. Until it is, integration tests start from a different DB shape on every CI run.

---

4. Stretch / aspirational

Ideas the team brainstormed but didn't formally scope.

• Native iOS release (.ipa) alongside Android — the React Native codebase technically supports it.
• Calendar sync via the iCalendar export (RFC 5545) — currently exposes mentor availability as a downloadable .ics; could become a live two-way sync (CalDAV / Google Calendar API).
• Multi-language UI (Turkish + English) — the backend taxonomy data already supports tr_TR locale via Faker; the UI strings are English-only.
• Mentor-mentee video call scheduling integration — the meeting entity has the metadata; integration with Zoom / Google Meet / Jitsi would be a natural extension.

---

5. Sources

• Lab 9 Report — the 19-phase roadmap and per-area requirement audit this page draws from.
• Project Retrospective — what the team learned about its own process.
• Lab 10 Report — the Community → Social Feed pivot decision.