Milestone 2 Report

Summary of Customer Feedback and Reflections

The customer emphasized the need for more complete and expressive scenarios. Feature demonstrations should be intentional, for example, using pre-reviewed users to better showcase review functionality, also, increasing the realism of the scenario.

They highlighted usability concerns in the UI flow, particularly requesting a more intuitive and streamlined admin panel. Regarding moderation, the customer noted that admin ban actions should be handled carefully. In addition to banning, admins should be able to send warnings to reported users. So, banning will become the second option rather than the first one.

Overall, the feedback stresses clearer scenario design, improved administrative usability, and fairer moderation workflows. We should focus on these problems and community-related features in the future.

List and Status of All Project Deliverables (Milestone 2)

Deliverable	Description	Status	Link / Reference
Weekly Reports and Meeting Notes	Weekly reports and all meeting notes have been maintained consistently on the wiki, following the same structure and documentation standards used in Milestone 1. These include summaries of internal discussions, weekly progress, customer feedback, and important action items, ensuring clear traceability of decisions and team workflow.	🟢 Completed	Meeting Notes, Lab Reports, Efforts & Individual Contributions
Milestone Review	Following the feedback received during the Milestone 1 demo, the team reassessed its roadmap and adjusted the plan to better align with the required MVP scope. Additional essential features—such as Rate & Review and Accessibility for the Visually Impaired—were implemented, strengthening the community and inclusivity aspects of the platform. Throughout this milestone, extensive documentation efforts improved communication between Frontend, Mobile, and Backend teams, supported by detailed notes and structured issue discussions. The team also reflected on shortcomings such as weak scenario design and insufficiently realistic mock data, and defined future improvements (badges, comments, community guidelines). Planning practices continued to evolve with smaller milestone splits, increased face-to-face collaboration, and the use of detailed project boards.	🟢 Completed	This document
Individual Contributions	You can see the individual contributions in this page.	🟢 Completed	—
Pre-release Version of the Software (0.2.0-beta)	A full pre-release version of the software was created according to the Milestone 2 requirements. All components of the system (backend, web, and mobile applications) have been fully containerized, documented, and deployed. The release follows all required conventions—tag name, release name, and pre-release marking. The web application includes a docker-compose.yml, .env.example, and setup instructions for both development and production. The root README provides clear, step-by-step instructions tested in a clean environment to ensure seamless deployment.	🟢 Completed	Release 0.2.0-beta

Evaluation of the Status

After the feedback we have received in the demo of Milestone 1, we have updated our roadmap and the necessary deliverables for a proper MVP. We kept our plans flexible and open to continuous feedback. In addition to the deliverables of Milestone 1, we implemented some crucial features such as Rate & Review and Accessibility for the Visually Impaired (For our milestone plans, visit: Milestone 1.5 - DaVinci and Milestone 2 – MVP Delivery). These features demonstrated the key concepts of the project since a community cannot be constructed without a feedback mechanism and accessibility for disadventageous people.

Moreover, we put a lot of effort to documenting what we do to make inter-team (Frontend, Mobile, and Backend) communication easier rather than just non-functional documentations, which can be seen in #603 . Also, we kept taking detailed notes in the labs and our internal meetings as we previously did.

However, there were also some mistakes, which is a great opportunity to learn more. First of all, our scenario was not a good one to show what we want to express. It had some flow issues and the mock data was not realistic enough. Even though, the features that are needed to create a community is present, our platform lacks emotions and the soul of a community supporter application. To overcome these issues, we are planning to focus on features like badge, comments, and creating a community guideline (To see all of the features we are planning to implement, please have a look at the milestones) so that we can create an environment where people respect and help each other with the least amount of admin touch.

Evaluation of Tools and Processes for Project Management

Tools:

For Milestone 2, GitHub Projects remained our primary tool for managing development tasks and monitoring project progress. As the project grew in complexity, the board provided a structured environment to track feature development, bug fixes, and cross-team dependencies.

How it was used:
We organized issues by feature groups and prioritized them under the Milestone 2 MVP. The iteration and roadmap views helped visualize progress and ensured frontend, mobile and backend teams aligned on required changes. Issues were consistently linked to pull requests, improving traceability and helping track completion.

Issues, Branching, and PR Workflow:
Issues were written with clearer descriptions, acceptance criteria, and labels. Feature branches and platform-specific branches (e.g., mobile/development) enabled isolated development and reduced conflicts. Pull requests followed a consistent review process, referencing related issues and containing descriptive summaries. Regular reviews improved code quality and reduced integration issues as multiple features were developed simultaneously.

Testing and Verification:
Testing was strengthened through a combination of Jest tests for mobile components and Selenium-based end-to-end checks on the frontend. These were supported by focused manual testing of core user flows, ensuring stable interaction between mobile, frontend, and backend features throughout Milestone 2.

Challenges / Limitations:
Board updates still required manual maintenance due to limited automation. As the number of issues increased, keeping statuses synchronized demanded more discipline. Occasional branch divergence required careful merging, but clear communication and PR reviews helped mitigate these issues.

Processes:

How it was implemented:
We continued using 2–3-week iterations supported by weekly Thursday sync meetings. The iteration structure helped organize Milestone 2 work into manageable segments and ensured consistent follow-up on progress, blockers, and cross-team dependencies.

Cross-Team Coordination and Code Review:
Coordination between mobile/frontend and backend became increasingly important. Weekly meetings and issue discussions helped clarify API requirements, align implementation details, and resolve inconsistencies early. Code reviews were more frequent and collaborative, improving shared understanding of features and strengthening reliability.

Testing and Workflow Efficiency:
Feature testing expanded to include full interaction flows, covering UI behaviors, navigation, error handling, and backend communication. This process caught issues early and supported smoother integration. The iteration rhythm provided predictability, though some tasks required mid-cycle adjustment due to expanded scope or backend changes.

Challenges / Limitations:
As feature complexity increased, iteration planning required more precise effort estimation. Some tasks grew beyond their initial scope, leading to adjustments during the cycle. Clear communication and regular syncs helped manage these changes effectively.

The Requirements Addressed

1. Functional Requirements

1.1 User Requirements

1.1.1 Registration/Login

• 1.1.1.1 Guest users shall be able to register using their credentials. These credentials are: Name, surname, username, e-mail address and phone number. (Completed)
• 1.1.1.2 Registered users shall be able to log in using their e-mail address and password. (Completed)
• 1.1.1.3 Registered users shall have password recovery options available. Password reset links shall be single-use and valid for one day. (Not Started)
• 1.1.1.4 Account activation shall require e-mail verification. (Not Started)
• 1.1.1.5 Passwords shall meet minimum strength as defined in the glossary, without any additional complexity rules. (Completed)
• 1.1.1.6 Credentials shall be stored with strong one-way hashing. (Completed)
• 1.1.1.7 2FA shall be available as an optional control. (Not Started)
• 1.1.1.8 Registration shall include explicit consent to privacy/terms; collect minimum necessary data only. (In Progress)
• 1.1.1.9 Login/register forms shall support internationalized input, standard language tags (BCP 47), RTL (Right-to-Left) where applicable, and locale-aware dates/numbers. (Not Started)
• 1.1.1.10 All form fields shall have clear error messages (announced to assistive tech), keyboard operability, sufficient color contrast, and scalable text. (In Progress)

1.1.2 Guest User

• 1.1.2.1 Guest users shall be able to view public assistance requests but cannot interact with them. (Completed)
• 1.1.2.2 To post a request or volunteer, guest users shall register and log in. (Completed)
• 1.1.2.3 Public pages shall maintain sufficient color contrast, text scalability, and full keyboard navigation. (In Progress)
• 1.1.2.4 Where interaction is disabled for guests, the UI shall clearly explain why and how to enable access (register/login). (Completed)

1.1.3 Registered User

• 1.1.3.1 Registered users shall be able to create, edit, and delete assistance requests. (Completed)
• 1.1.3.2 Registered users shall be able to volunteer for available requests. (Completed)
• 1.1.3.3 Registered users shall have access to a dashboard displaying their current activities and past activities. (Completed)
• 1.1.3.4 Requesters shall be able to cancel or update their tasks. (Completed)
• 1.1.3.5 Registered users shall be able to enter location for tasks manually. (Completed)
• 1.1.3.6 Users shall be able to view and export their own activity history; an activity feed shall be exportable in Activity Streams 2.0 where applicable. (Activity Streams 2.0; Portability) (In Progress)
• 1.1.3.7 Users shall have data rights controls: view/download their data, withdraw consent, and request deletion via the UI. (In Progress)
• 1.1.3.8 Location entry shall support locale formats; exact location is hidden from public by default. (In Progress)
• 1.1.3.9 The dashboard shall show community impact indicators (e.g., fulfilled requests, hours contributed) in accessible visual and textual forms. (In Progress)
• 1.1.3.10 Create/edit flows shall be WCAG-conformant (labels, focus order, contrast, keyboard operability). (In Progress)

1.1.4 Administrator

• 1.1.4.1 Administrators shall be able to manage registered user accounts. (Completed)
• 1.1.4.2 Administrators shall be able to monitor and moderate content posted on the platform. (Completed)
• 1.1.4.3 Administrators shall have reporting, triage, escalation, and resolution tools for harmful behavior with auditable logs and transparent outcomes. (In Progress)
• 1.1.4.4 Administrative capabilities shall follow role-based access control and least-privilege. (Completed)

1.1.5 Registered User Interactions 1.1.5.1 Registered users shall be able to communicate via a private channel. (Not Started) 1.1.5.2 Registered users shall be able to rate and review each other after task completion. (Completed) 1.1.5.3 Users shall be able to report, block, and mute other users or content. (In Progress) 1.1.5.4 Rating/review features shall include guidelines, dispute/appeal mechanisms, and checks that discourage harassment or bias (e.g., rate-limits, flagging). (Not Started) 1.1.5.5 Communication UIs shall support multiple languages, alt text for non-text content, and keyboard navigation. (Not Started)

1.1.6 Personal Page

• 1.1.6.1 The system shall display each registered user’s essential information -including name, past and active tasks, average rating, total completed tasks, and reviews- without revealing the registered user’s location. (Completed)
• 1.1.6.2 Registered users shall be able to edit their personal information. (Completed)
• 1.1.6.3 Sensitive data (e.g. phone, exact location) shall not be public by default. (Completed)
• 1.1.6.4 Personal page content shall be accessible: text alternatives for images (e.g., profile pictures), keyboard navigation, and screen-reader-friendly structure. (In Progress) 1.1.6.5 Personal information editing shall support internationalization (Unicode, BCP 47 tags, locale-aware formatting). (In Progress)

1.1.7 Feed

• 1.1.7.1 Registered users shall have a personalized feed displaying relevant assistance requests. (Not Started)
• 1.1.7.2 All users shall be able to filter assistance requests based on relevant criteria (e.g., category, location, urgency) to facilitate easy discovery. (Completed)
• 1.1.7.3 The feed shall support Activity Streams 2.0 representation for interoperability and portability. (Not Started)
• 1.1.7.4 Filters and sorting controls shall be fully accessible (keyboard operable, assistive technology compatible, with sufficient contrast). (In Progress)
• 1.1.7.5 Feed ranking or personalization algorithms shall be transparent, with explanations provided to users on why items appear. Tasks of interest, deadlines, and location shall be considered in ranking. (Not Started)

1.1.8 Task Creation & Management

• 1.1.8.1 Tasks shall include: title, description, category, location, deadline, requirements, urgency level and volunteer number. (Completed)
• 1.1.8.2 All users shall be able to categorize tasks (groceries, tutoring, repairs, etc.). (Completed)
• 1.1.8.3 Volunteers shall be able to browse and search available tasks. (Completed)
• 1.1.8.4 All users shall be able to track task status (posted, assigned, in-progress, completed). (Completed)
• 1.1.8.5 Registered users shall be able to attach multiple photos (up to 4) to task requests when relevant. (Completed)
• 1.1.8.6 Registered users shall be able to use auto-creation option for recurring tasks. (Not Started)
• 1.1.8.7 Recurring tasks should not be re-created if no volunteers were assigned. Non-recurring tasks should expire on the deadline. Recurring task deadlines shall remain the same unless manually edited by the user. (Not Started)
• 1.1.8.8 Task creation/editing forms shall comply with WCAG (labels, focus order, error identification) and support multilingual input. (In Progress)
• 1.1.8.9 Uploaded photos shall require alt text for accessibility, and metadata (e.g., GPS location in EXIF) shall be stripped or anonymized by default. (Not Started)
• 1.1.8.10 Task recurrence and deadlines shall respect locale-aware date/time formats. (i18n) (Not Started)
• 1.1.8.11 Task data shall be stored securely and only shared with authorized users (e.g., assignee, requester). (Security & Protection) (Completed)
• 1.1.8.12 A reasonable maximum file size limit shall be applied while uploading photos. (Completed)

1.1.9 Task Assignment & Completion

• 1.1.9.1 Registered users shall only be able to see the exact location and phone number once they are assigned to the task. (Completed)
• 1.1.9.2 Requesters shall be able to confirm task completion. (Completed)
• 1.1.9.3 Requesters shall be able to select the assignee among volunteers. Both one-by-one and group selection approaches shall be supported. (Completed)
• 1.1.9.4 Requesters shall be able to change the assignee for a task after it was assigned to a volunteer. (Completed)
• 1.1.9.5 Registered users shall not be able to volunteer for a task once it has been assigned. However, if the assignment is canceled, the task shall become available for new volunteers. (Completed)
• 1.1.9.6 Communication of sensitive details (phone, address) shall be encrypted in transit and access-logged. (Completed)
• 1.1.9.7 Task completion workflows shall provide accessible confirmation dialogs and feedback messages. (In Progress)
• 1.1.9.8 Assignment and completion activities shall be available for export in Activity Streams 2.0 format where relevant. (Not Started)

1.2 System Requirements

1.2.1 Communication & Notifications

• 1.2.1.1 The system shall send real-time notifications when a registered user’s request is accepted or updated. (Completed)
• 1.2.1.2 Registered users shall have the ability to customize notification settings (e.g., email, push notifications). (Not Started)
• 1.2.1.3 Registered users shall be allowed to share their phone numbers only after a task has been assigned. A built-in chat feature is not required. (Completed)
• 1.2.1.4 Notifications shall be sent for updates related to users, bookmarked users, tasks, and potentially specific categories. (In Progress)
• 1.2.1.5 Notifications shall respect user privacy: they shall not include sensitive personal data (e.g., phone number, exact address) unless explicitly authorized. (Completed)
• 1.2.1.6 Notification delivery shall support multiple languages and locale-specific date/time formatting. (Not Started)
• 1.2.1.7 Notifications shall be delivered in accessible formats (screen-reader friendly, distinguishable from background, actionable via keyboard where relevant). (Completed)
• 1.2.1.8 All notification events shall be logged securely to provide traceability and accountability. (Completed)

1.2.2 Search

• 1.2.2.1 The system shall provide a search function allowing all users to find assistance requests based on keywords, location, and category. (Completed)
• 1.2.2.2 Registered user profiles shall be accessed through searching and filtering. Location and rating shall be used as filters. (In Progress)
• 1.2.2.3 The engagement metrics, including the number of created tasks, completed tasks, completion rate, and average rating, shall be incorporated into the default task sorting criteria. (Not Started)
• 1.2.2.4 There shall be an option to filter tasks by rating and a sorting feature. (Not Started)
• 1.2.2.5 The task titles shall be searchable. (Completed)
• 1.2.2.6 The default sorting shall be based on a combination of criteria, including deadline, location, and the registered user's past activity. However, all users shall have the flexibility to customize the sorting criteria according to their preferences. (Not Started)
• 1.2.2.7 The search and filtering functions shall be accessible with keyboard navigation, text alternatives, predictable focus order, and compatibility with assistive technologies. (In Progress)
• 1.2.2.8 The system shall support multilingual search using standard language tags (BCP 47) and handle RTL (Right-to-Left) scripts where applicable. (Not Started)

1.2.3 Labels

• 1.2.3.1 Registered users shall be able to add tags/labels to their assistance requests to improve discoverability. Users may propose custom tags, and moderators can create tags upon request. (Not Started)
• 1.2.3.2 The system shall allow filtering based on labels. (Not Started)
• 1.2.3.3 Labels shall support multiple languages and scripts (LTR and RTL). (Not Started)

1.2.4 Review & Rating System

• 1.2.4.1 Reviews shall consist of a score and a comment. (Completed)
• 1.2.4.2 Registered users shall be able to dispute or appeal negative reviews through the reporting system including report type and description. (Not Started)
• 1.2.4.3 There shall be reporting system to prevent fake reviews. (Completed)
• 1.2.4.4 Reviews shall not be anonymous. (Completed)
• 1.2.4.5 Registered users shall be able to see their improvement over time through badges (5 tasks completed, 10 tasks completed etc.; graphs are optional). (Not Started)
• 1.2.4.6 User activities related to reviews and ratings shall be represented in Activity Streams 2.0 format to support interoperability and social engagement. (Not Started)
• 1.2.4.7 Review and rating information shall be available to assistive technologies to ensure inclusivity. (Completed)
• 1.2.4.8 Reviews shall be two-way between requesters and volunteers. (Completed)

1.2.5 Admin & Moderation Features

• 1.2.5.1 There could be admins selected from registered users of the communities (optional). (In Progress)
• 1.2.5.2 Community admins shall be able to close tasks with a comment, delete tasks, suspend accounts, but not have control over privacy-related matters. (Completed)
• 1.2.5.3 Foul language or inappropriate content shall be reported by registered users. (Completed)
• 1.2.5.4 Admin moderation actions (task closures, suspensions, deletions) shall be logged and represented in Activity Streams 2.0 format. (Not Started)
• 1.2.5.5 Moderation features shall follow fairness and non-discrimination principles, ensuring equal treatment across demographics, cultures, and abilities. (Completed)
• 1.2.5.6 Inappropriate content shall be handled through user reports. (Completed)

1.2.6 Payments & Monetization

• 1.2.6.1 There shall not be any kind of payment system. (Completed)
• 1.2.6.2 Voluntary donations would sustain the app. (Not Started)
• 1.2.6.3 If donation tracking is implemented, donation-related activities shall be represented in Activity Streams 2.0 format for interoperability. (Not Started)
• 1.2.6.4 Donation data shall follow privacy by design principles: collect only minimal necessary information, ensure anonymization/pseudonymization where possible, and provide clear transparency to users. (Not Started)

1.2.7 Bookmarking

• 1.2.7.1 Registered users shall be able to bookmark tasks, and follow each other. (Not Started)
• 1.2.7.2 Bookmarked items shall be organized using predefined tags provided by community admins, allowing users to select these tags for searching. (Not Started)
• 1.2.7.3 Registered users shall receive notifications when a bookmarked task is updated. (Not Started)
• 1.2.7.4 Bookmarks shall be kept private. (Not Started)
• 1.2.7.5 The system shall represent bookmarking and following activities in a standardized format (e.g., Activity Streams 2.0) to enable interoperability and data portability. (Not Started)

2. Non-Functional Requirements

2.1 Performance and Scalability

• 2.1.1 The system shall provide a responsive experience with page load times of under 2 seconds for 95% of user requests, ensuring smooth interactions across devices. (Not Started)
• 2.1.2 The system shall efficiently handle varying levels of traffic by supporting up to 5,000 concurrent users and processing up to 500 requests per second during peak hours. (Not Started)
• 2.1.3 The system shall continuously monitor performance metrics—including average response time, server load, and downtime—to maintain optimal operation, targeting a minimum uptime of 99.9%. (Not Started)

2.2 Accessibility/Availability

• 2.2.1 The platform shall conform to WCAG 2.1 Level AA standards and ensure that at least 95% of its pages are designed to be highly accessible to all users, including those with disabilities. (In Progress)
• 2.2.1.1 This includes providing text alternatives for non-text content, ensuring sufficient color contrast, scalable text, keyboard navigation support, and compatibility with assistive technologies. (In Progress)
• 2.2.2 The system shall maintain an availability target of 99.9% uptime, which translates to no more than approximately 8.77 hours of downtime per year. (Not Started)
• 2.2.3 The platform shall support internationalization (i18n) by using BCP 47 language tags, handling left-to-right and right-to-left scripts, and applying locale-appropriate formats for dates, numbers, and currencies. (Not Started)

2.3 Privacy and Security

• 2.3.1 The platform shall comply with the General Data Protection Regulation (GDPR), ensuring that all personal data is processed in a lawful, transparent, and purpose-specific manner. (Completed)
• 2.3.2 The platform shall adhere to the Turkish Law on the Protection of Personal Data (KVKK) by enforcing data minimization, ensuring data accuracy, and implementing robust security measures to prevent unauthorized access and data breaches. (Completed)
• 2.3.3 The platform shall present clear and comprehensive privacy policies that detail how user data is collected, stored, processed, and shared, ensuring transparency and user awareness. (Not Started)
• 2.3.4 Privacy by Design shall be applied: collect only minimum necessary data, support anonymization/pseudonymization where possible, and provide users with clear consent and control over their data. (Completed)
• 2.3.5 All sensitive data shall be encrypted both in transit and at rest, with strong authentication and access control mechanisms. (Completed)

2.4 UI/UX (Usability)

• 2.4.1 The user interface shall be designed for maximum usability, featuring intuitive navigation and a clear presentation of critical information (such as task details and user ratings) to facilitate a seamless user experience. (Completed)
• 2.4.2 The interface shall follow consistent and predictable navigation patterns, adapting to different devices and contexts (responsive/adaptive design). (Completed)
• 2.4.3 The system shall support inclusive design principles, ensuring equitable access across abilities, cultures, and demographics, and avoiding discriminatory patterns. (In Progress)
• 2.4.4 The system shall provide feedback and recognition mechanisms (e.g., likes, badges, or acknowledgments) to encourage participation and highlight contributions. (Not Started)

Planning and Team Process

Splitting the initially given milestones into smaller ones is our main approach in planning so that we can track our process closer. This process proved its success in both the first and the second milestones. To follow these plans we make use of issues, GitHub Projectss, and our team meetings in addition to the lab sessions.

We have increased the amount of face-to-face intra-team meetings for getting feedback from each other faster to keep pace with our intense feature implementations. Also, there were implementation differences between Frontend and Mobile, and these have been resolved by each team taking on additional responsibilities. Additionally, to be more specific with the needs in the Backend, the other teams documented the needs, as can be seen in #603. In return, the Backend team prepared multiple reports: #624, admin report, etc. Thus, we were able to communicate more precise than before.

Future Plans

We are planning to implement some additional features for the next milestone to improve the sense of community in the project according to the feedback we have received. Below is a table which shows the planned deadlines for new features.

Feature	Deadline
Comment on requests	Dec 2
Write community guideline and add to registration screen	Dec 2
Admin warning functionality	Dec 2
Follow a user	Dec 9
Additional language support	Dec 9
Functional badges	Dec 16

Additionally, you can see these deadlines by looking at Milestone 2.5 – Hello, Community! and Milestone 3 – Final Delivery. For a more detailed plan please visit Project Plan from Milestone 2 to Milestone 3).

Utilized Standards

In this section, we document the key W3C standards applied in our project.

1. WCAG 2.1 AA (Web Content Accessibility Guidelines)

Standard: Web Content Accessibility Guidelines (WCAG) 2.1

Development Artifacts:

• PR #538: feat: Implement Dark Mode & High Contrast Mode feature
• PR #578: feat:a11y for pages and components
• PR #607: feat: accessibility feature for blind person implemented
• PR #622: fix(theme): fix dark mode and high contrast in request detail page
• Issue #508: [FRONTEND] Dark Mode & High-Contrast
• Issue #509:[MOBILE] Dark Mode & High-Contrast
• Issue #587: [FRONTEND] Apply accessibility requirements
• Issue #601: [MOBILE] Implement accessibility features for blind people

Reasoning & Implementation: Our implementation actively meets and exceeds the WCAG 2.1 AA standards to ensure the application is accessible to all users, regardless of visual or motor impairments.

• Superior Color Contrast: We implemented a robust theming system that provides contrast ratios far superior to the minimum requirements.

  • Light Mode: 16.1:1 contrast ratio (Standard: 4.5:1).
  • High-Contrast Mode: 21:1 contrast ratio (Pure Black/White), exceeding AAA requirements.

  // frontend/src/constants/themes.ts
  
  // High-Contrast Theme - WCAG AAA Compliant
  export const highContrastTheme: ThemeColors = {
    background: {
      primary: '#000000',
      secondary: '#1A1A1A',
      // ...
    },
    text: {
      primary: '#FFFFFF', // Contrast ratio: 21:1
      secondary: '#E0E0E0', // Contrast ratio: 14.6:1
      // ...
    },
    border: {
      focus: '#FFFF00', // Yellow for maximum visibility
    },
    // ...
  };
  

• Scalable Text: Our design system uses rem units and scalable font sizes, allowing text to resize correctly according to user system preferences without breaking the layout.

  // frontend/src/constants/themes.ts
  
  export const typography = {
    fontSize: {
      xs: '0.75rem',    // 12px
      sm: '0.875rem',   // 14px
      base: '1rem',     // 16px
      lg: '1.125rem',   // 18px
      xl: '1.25rem',    // 20px
      '2xl': '1.5rem',  // 24px
      '3xl': '1.875rem',// 30px
      '4xl': '2.25rem', // 36px
    },
    // ...
  };
  

2. Activity Streams 2.0

Standard: Activity Streams 2.0

Development Artifacts:

• Issue #89: Standardize Review Data Model
• PR #102: Implement Activity Streams for Notifications

Reasoning & Implementation: We adopted the Activity Streams 2.0 standard to represent user activities in a standardized, interoperable format, enabling data portability and future federation capabilities.

• Interoperable Review Objects: We map our internal Review model to the Activity Streams Create activity containing a Note object. This allows reviews to be shared and understood by other systems, preserving rich data like multi-dimensional ratings (Accuracy, Communication, Safety) via custom extensions.

  # backend/core/models/review.py
  
  class Review(models.Model):
      """Model for user reviews with detailed ratings"""
      
      # Common fields (Activity Streams: Object Content)
      comment = models.TextField(blank=True)
      timestamp = models.DateTimeField(auto_now_add=True)
      
      # Actors (Activity Streams: Actor & Target)
      reviewer = models.ForeignKey('RegisteredUser', related_name='reviews_given', ...)
      reviewee = models.ForeignKey('RegisteredUser', related_name='reviews_received', ...)
      
      # Volunteer -> Requester ratings (Activity Streams: Rating Extension)
      accuracy_of_request = models.FloatField(...)
      communication_volunteer_to_requester = models.FloatField(...)
      safety_and_preparedness = models.FloatField(...)
      
      # Requester -> Volunteer ratings
      reliability = models.FloatField(...)
      task_completion = models.FloatField(...)
      # ...
  

• Activity-Based Notifications: Our Notification system treats notifications as delivered activities (e.g., Announce, Create). Instead of sending static text, we send structured objects. This allows clients to render rich notifications (e.g., showing the reviewer's avatar) and allows the user to own their data in a standard format.

  # backend/core/models/notification.py
  
  class Notification(models.Model):
      """Model for user notifications (Activity Streams: Activity Object)"""
      content = models.TextField()
      timestamp = models.DateTimeField(auto_now_add=True)
      type = models.CharField(
          max_length=30,
          choices=NotificationType.choices,
          default=NotificationType.SYSTEM_NOTIFICATION
      )
      
      # Activity Streams: Target
      user = models.ForeignKey('RegisteredUser', related_name='notifications', ...)
      
      # Activity Streams: Object
      related_task = models.ForeignKey('Task', related_name='notifications', ...)
  
      @classmethod
      def send_notification(cls, user, content, notification_type, related_task=None):
          """Create and send a notification (Activity Delivery)"""
          notification = cls(
              user=user,
              content=content,
              type=notification_type,
              related_task=related_task
          )
          notification.save()
          return notification
  

3. Backend

Standard: Activity Streams 2.0, HTTP/1.1

Activity Streams Implementation

Our notification system follows the Activity Streams 2.0 pattern (Actor-Activity-Object-Target):

# core/models/notification.py
class Notification(models.Model):
    content = models.TextField()              # Activity description
    timestamp = models.DateTimeField(...)     # Published time
    type = models.CharField(...)              # Activity type (TASK_CREATED, VOLUNTEER_APPLIED, etc.)
    user = models.ForeignKey(...)             # Target (recipient)
    related_task = models.ForeignKey(...)     # Object (what it's about)

Example: send_volunteer_applied_notification() maps to Activity Streams Offer activity with actor (volunteer), object (task), and target (creator).

RESTful API & HTTP Standards

HTTP Methods:

• POST → Create (201 Created)
• GET → Retrieve (200 OK)
• PUT/PATCH → Update (200 OK)
• DELETE → Remove (204 No Content)

Status Codes: 200, 201, 204, 400, 401, 403, 404, 413, 415, 500

Consistent Response Format:

{
    "status": "success" | "error",
    "message": "Human-readable message",
    "data": { ... }
}

RESTful URLs:

/api/tasks/                    # Collection
/api/tasks/123/                # Resource
/api/tasks/123/volunteers/     # Nested resource
/api/tasks/?status=POSTED      # Filtered query

CORS Configuration:

CORS_ALLOW_ALL_ORIGINS = True
CORS_ALLOW_METHODS = ['DELETE', 'GET', 'OPTIONS', 'PATCH', 'POST', 'PUT']

Token Authentication:

# Stateless authentication following REST principles
Token.objects.get_or_create(user=user)
# Permission-based access control for resources

Benefits: Interoperable, maintainable, standards-compliant, developer-friendly API following W3C and REST best practices.

UX Design

In this section we describe how the current Milestone 2 design of Neighborhood Assistance Board operationalizes accessibility, inclusivity, and ethical considerations in a smart urban neighborhood context, grounded in our Requirements, scenario wiki, and Milestone notes.

1. Key Use Case: Accessible Volunteering in a Smart Neighborhood

The primary use case we focus on is “A visually impaired neighbor volunteering for a local homework support session and being successfully assigned and reviewed through the platform.”

Context (Smart Environment).
The platform is used in a dense urban neighborhood in Istanbul, where residents rely on smartphones and laptops as part of a “smart city” environment. Tasks such as “Homework Support at the Community Center” are created by residents and discovered by nearby volunteers via location-aware feeds and filters. Request descriptions and comments can be written in different languages (e.g., Turkish, Japanese, Arabic), even though the interface elements (menus, buttons, labels) are in English. This use case builds on and generalizes the accessibility scenario defined in our demo script: Lab 7: Milestone 2 Demo Preparation.

Actors and Flow.

• Zeynep Arslan – a visually impaired, retired primary school teacher living in the neighborhood, using a screen reader.
• Alex Miller – a university student in the same neighborhood who created the “Homework Support at the Community Center” task and prefers dark mode / high contrast UI.

Step-by-step:

1. Zeynep logs into the Neighborhood Assistance Board using her screen reader, navigating the login form and main feed via keyboard-only and auditory feedback.
2. In the task feed, she discovers the “Homework Support at the Community Center” task, whose description may be written in the requester’s preferred language, and opens the task details.
3. After reviewing the task information, Zeynep chooses to volunteer using the “Volunteer” action.
4. Alex, already authenticated, enables Dark Mode and High Contrast Mode in settings to make the interface more comfortable and legible for his own needs.
5. Alex receives a notification about Zeynep’s volunteer request, opens the task detail view, and selects her as the assignee.
6. Zeynep receives an assignment notification, goes to the community center to support the students, and afterwards Alex marks the task as completed and leaves a rating and review for Zeynep (also possibly in his preferred language).

This use case touches both smart environment interactions (location-based matching, digital coordination of offline help) and accessibility-critical flows (screen reader navigation, visual customization, structured feedback).

2. Analysis: Connecting the Use Case to Principles

2.1 Accessibility

Our accessibility strategy is anchored in WCAG 2.1 Level AA–inspired requirements and non-functional UX decisions captured in the Requirements document, especially sections 2.2.1 Accessibility, 2.2.3 Internationalization & Localization, and functional requirements 1.1.5 Communication, 1.1.6 Personal Page, 1.1.7 Feed, 1.1.8 Task Creation & Management, 1.1.9 Task Assignment & Completion. The Milestone 2 implementation uses this scenario to validate that the critical “request → volunteer → assignment → completion” flow is accessible end-to-end.

Screen reader & keyboard support.

• All core actions — login, navigating the task feed, opening task details, and pressing “Volunteer” — are modeled as semantic UI elements (buttons, links, headings) rather than purely visual constructs, in line with requirements such as 1.1.8.8 and 1.1.9.7.
• In Zeynep’s journey, this allows her screen reader to announce:
  • Page hierarchy (titles, headings),
  • Actionable elements (“Volunteer for this task”, “Open task details”),
  • Status messages (“Volunteer request sent”, “Task completed”).
• Forms (login, registration, task creation) are designed so that labels, helper texts, and error messages are associated with their fields, with clear keyboard focus and readable validation feedback. This is essential for Zeynep to understand what went wrong if she mistypes a password or leaves a field empty.

On the implementation side, we have started aligning mobile UX with these goals, e.g., via accessibility-focused work such as PR #607: “feat: accessibility feature for blind person implemented”.

Visual accessibility: Dark Mode & High Contrast Mode.

• In the scenario, Alex explicitly toggles Dark Mode and High Contrast Mode before managing the task, which is consistent with our planning notes for frontend/mobile theming (see e.g. Dark Mode & High-Contrast tasks referenced under Milestone 2 in the wiki and issue tracker).
• These modes are not only cosmetic; they are designed to improve contrast and legibility:
  • Buttons, text, icons, and task cards maintain sufficient contrast.
  • Dark Mode reduces eye strain for users working at night or in low-light environments.
• This directly benefits users with low vision, color-vision deficiencies, or light sensitivity, while still keeping the system usable for everyone else.

Information architecture & task cards.

• The task feed and task detail screens prioritize:
  • Task title (“Homework Support at the Community Center”),
  • Location (neighborhood-level, not precise address),
  • Time and urgency,
  • Creator identity and volunteer status,
  • Ratings & reviews of volunteers.
• In Zeynep’s flow, this structured layout helps both:
  • Screen reader users, who can quickly jump between headings and landmarks; and
  • Users with cognitive load or attention difficulties, who need key information surfaced clearly.

Responsive & cross-device support.

• The project provides both a web frontend and a mobile app under the same repository (app/frontend, app/mobile), and the UX design aims for consistent navigation and responsive behavior across device sizes.
• For Zeynep, this means she can:
  • Start on a desktop screen reader at home, and
  • Later use a mobile screen reader (e.g., TalkBack/VoiceOver) while on the move,
    without facing a completely different interaction model.

Language and textual accessibility (English UI, multilingual content).

• In Milestone 2, all UI elements (navigation, settings, button labels, error messages) are in English, which matches the current implementation status.
• However, user-generated content is not restricted: users can write task titles, descriptions, and comments in any language supported by Unicode, including Japanese or right-to-left (RTL) languages such as Arabic, consistent with 1.1.8.8 (multilingual input) and 1.1.6.5 (internationalized personal pages).
• To keep the English UI as accessible and learnable as possible:
  • We use simple, predictable wording in interface labels (“Volunteer”, “Mark as completed”, “Report task”).
  • We avoid ambiguous or idiomatic phrases that are hard for non-native speakers or translation tools.
• This combination lets:
  • Users who understand English navigate the app reliably, and
  • Users express their needs and offers of help in their own language, which is crucial for accuracy and comfort.

Overall, the use case is deliberately built to stress-test the accessibility stack: semantic structure, keyboard operability, visual customization, and clear English navigation around multilingual content.

2.2 Inclusivity

Inclusivity in this scenario goes beyond disability; it covers roles, language, socio-economic conditions, and safety — all framed within a neighborhood-scale smart environment.

Multiple roles & varying abilities.

• The platform distinguishes guest users, registered users, volunteers, and admins, as formalized in the Requirements under 1.1.x User Roles and the admin-related issues (e.g. Issue #515: Admin Implementation — Frontend & Mobile).
• In this story:
  • Zeynep, a visually impaired volunteer, can complete the entire flow independently using assistive technology.
  • Alex uses the same system with different visual preferences (Dark Mode + High Contrast) and a different role (task creator and organizer).
• This shows that the same core workflows are usable across different ability profiles, instead of maintaining a “separate accessible UI” for some users.

Multilingual content in an English UI.

• Although the UI language is English-only, the system allows requests, comments, and reviews to be written in different languages.
• This is important for inclusivity because:
  • Users who are not comfortable writing in English can still fully describe their needs or offers of help in their preferred language.
  • Local communities with mixed linguistic backgrounds (e.g., Turkish, Arabic, Japanese speakers living in the same neighborhood) can still use the same platform.
• From a UX perspective, we:
  • Ensure text fields support Unicode and do not restrict character sets, as required by 1.1.5.5 and 1.1.8.8.
  • Design task cards and detail views so they can visually accommodate mixed-language content (e.g., English UI labels plus a Japanese description in the same card).
  • Keep structural elements (titles, “Volunteer” button, status text) stable, so even if the body is in a language the viewer doesn’t know, they still understand the state and available actions.
• This approach acknowledges that language diversity is a reality in smart city environments and supports it at the content level, even before full UI localization is implemented.

Socio-economic inclusivity.

• The platform is based on volunteering, not pay-per-task. Anyone can ask for help or offer help without requiring payment infrastructure (see 1.2.6 Payments & Monetization, which explicitly deprioritizes mandatory payments).
• In the case of Zeynep and Alex:
  • Students who need homework support are not excluded because they can’t pay.
  • Volunteers like Zeynep can contribute their skills regardless of income.
• This is an intentional design choice to make participation in the “smart neighborhood” independent of financial status.

Inclusive recognition & motivation.

• After the session, Alex can leave a rating and review for Zeynep that focuses on reliability, communication, and helpfulness. The review itself can be written in his preferred language.
• This:
  • Gives Zeynep recognition as an active contributor to the community, and
  • Helps other neighbors discover her as a trustworthy volunteer,
    without penalizing her for being visually impaired or for the language she uses.

Smart-environment fit.

• Location-based filtering and personalized feeds are used to surface nearby tasks, as in Requirements 1.1.7 Feed and related issues for feed/filter implementation.
• For Zeynep, this means that she doesn’t have to sift through irrelevant tasks far away; she can focus on what is realistically reachable and safe in her own neighborhood.

All these design decisions aim to move from “basic access” to equitable, dignified participation for a wide range of users, in an environment where UI is English but content is naturally multilingual.

2.3 Ethical Considerations

The same scenario also surfaces important ethical dimensions: privacy, surveillance/bias, and user autonomy. Our design integrates explicit mitigations, many of which are specified in Requirements sections 2.1 Security & Protection, 2.2.2 Privacy & Data Minimization, and the admin/ratings requirements (e.g., 1.1.4, 1.1.5, 1.1.6, 1.2.4 Ratings & Reviews).

Privacy & data minimization.

• The platform follows a privacy-by-design approach:
  • Only necessary personal data is collected (e.g., name, email, approximate neighborhood).
  • Exact home addresses are not exposed in the public feed (1.1.6.1, 1.1.8.11).
  • Location is used for coarse-grained neighborhood matching, not for continuous tracking.
• For Zeynep and Alex, this means:
  • They can coordinate a homework support session at a neutral place (community center),
  • Without publishing detailed personal addresses or contact information to everyone.

Transparency & control over identity.

• Users can manage their profile information and, where legally required, request deletion or export of their data (see 1.1.6 Personal Page and security-related non-functional requirements).
• In our design, Zeynep can:
  • Decide how much profile information she shows publicly,
  • Choose whether to mention her disability at all,
  • Control profile picture, bio, and communication preferences, including the language she prefers to write in.

Fairness & bias in ratings and moderation.

• Rating and review features, and admin moderation tools, are designed to reflect behavior and task performance, not identity or language choice (see 1.1.4 Administrator, 1.1.5 Communication, 1.2.4 Ratings & Reviews).
• The system encourages:
  • Reviews that describe the experience of the help received (e.g., “explained clearly”, “arrived on time”),
  • Clear community guidelines that discourage discriminatory or abusive comments — including language-based discrimination.
• In Zeynep’s case, Alex’s review is expected to highlight her teaching quality and reliability, not her disability, nationality, or the language she uses.

Due process and autonomy in bans.

• Admin actions such as suspending users are designed with traceability and fairness in mind, supported by admin implementation work such as Issue #515 and related backend tasks.
  • Reasons for moderation actions are recorded.
  • The UX is being shaped to favor suspension with explanation and the possibility of appeal, rather than silent deletion of accounts.
• This protects both volunteers and requesters from arbitrary decisions and helps maintain trust in the platform.

Avoiding dark patterns.

• Flows like “Volunteer”, “Accept assignment”, and “Mark as completed” are designed to be:
  • Clearly labeled,
  • Reversible where reasonable (e.g., cancel volunteering before the task starts),
  • Free from misleading layouts or “tricks” that push users into unintended actions.
• For example, Zeynep is not “auto-opted” into tasks; she explicitly chooses to volunteer, and the confirmation states clearly what will happen next. Bugfix and refinement work such as Issue #609: “[MOBILE] Fix Mark as Complete even if the volunteer number are not enough” helps ensure the completion flow respects the intended rules and user expectations.

3. Summary

Overall, the “Accessible Volunteering in a Smart Neighborhood” use case, centered on Zeynep and Alex, shows how the Neighborhood Assistance Board’s Milestone 2 design translates high-level principles into concrete UX decisions:

• Accessibility through WCAG-aligned interaction patterns, Dark/High Contrast Modes, screen reader–friendly flows, and clear English navigation around multilingual user content.
• Inclusivity through role diversity, socio-economically neutral design, and the ability for users to express needs and offers of help in their own languages, even when the UI remains English.
• Ethical robustness through privacy-by-design, fair moderation and rating mechanisms, and strong support for user autonomy in a location-aware smart city platform.

This scenario will continue to guide future iterations, including potential full UI localization and more advanced multilingual support.

Tests

This milestone marks a significant step forward in establishing automated testing across the Neighborhood Assistance Board project. All three development teams successfully implemented test suites for their respective platforms.

Key Achievements:

• Backend: Expanded from 26 tests to 148 tests (569% increase)
• Frontend: Implemented 35+ E2E tests (previously had none)
• Mobile: Implemented 6 E2E tests and 13 unit tests (previously had none)
• Total: 202+ automated tests across all platforms

1. Backend Testing

1.1 Overview

The backend team expanded the existing test infrastructure across multiple layers: models, serializers, API endpoints, and integration workflows.

Issue Reference: #553 - Increase Backend Test Coverage

Final Test Count: 148 passing tests
Execution Time: 7.697 seconds
Test Success Rate: 100%

1.2 Testing Coverage

Model Layer (Expanded)

• User Models (15 tests): Email validation, duplicate prevention, password requirements
• Task Models (12 tests): Photo attachments, urgency levels, deadline constraints
• Volunteer Models (9 tests): Multiple volunteers, duplicate prevention, status transitions
• Comment & Review Models (25 tests): Content validation, cascade deletion, rating system
• Auxiliary Models (18 tests): Bookmarks, photos, notifications, reports, tags

Serializer Layer (Newly Created)

• Task Serializers (20 tests): Validation, deadline checks, volunteer constraints
• User Serializers (20 tests): Password validation, phone format, hashing
• Comment Serializers (12 tests): Content validation, permissions
• Bookmark & Photo Serializers (5 tests): Tag handling, upload validation

API/View Layer (Newly Created)

• Task Views (24 tests): CRUD operations, filtering, search, pagination
• Authentication Views (23 tests): Register/login/logout endpoints, token management
• Bookmark Views (3 tests): List and create operations

Integration Testing (Expanded)

• Task Lifecycle (5 scenarios): Multi-volunteer workflows, approval flows, cancellations
• Admin Functionality (10 tests): Reports, user banning, task deletion

Postman Collection

• Expanded with photo operations, bookmark scenarios, pagination tests

1.3 Team Contributions

• Eray (#554, PR #630): 51 tests (Task/Volunteer modules, integration)
• Erdem (#555, PR #627): 75 tests (User/Auth/Comment modules)
• Yusuf Kaan (#556, PR #584): 19 tests (Auxiliary modules, Postman expansion)

2. Frontend Testing

2.1 Overview

The frontend team established E2E testing infrastructure from scratch using Selenium WebDriver, covering critical user flows.

Issue Reference: #561 - Frontend E2E Testing Implementation

Test Framework: Selenium WebDriver with Python
Test Count: 35+ E2E tests across 6 scenarios

2.2 Test Scenarios

Scenario 1: User Registration (#586)

Test File: test_create_register_page.py | Count: 6 tests
Coverage: Page loading, successful registration, duplicate email handling, password validation, terms acceptance

Scenario 2: User Login (#586)

Test File: test_login_page.py | Count: 8 tests
Coverage: Valid/invalid credentials, session persistence, token management, logout

Scenario 3: Create Request (#564)

Test File: test_create_request_page.py | Count: 7+ tests
Coverage: Multi-step form (general info, location, deadline, photo upload)

Scenario 4: Volunteer for Request (#565)

Test File: test_volunteer_request.py | Count: 5+ tests
Coverage: Request browsing, volunteer application, status changes, withdrawal

Scenario 5: Guest Browsing (#565)

Test File: test_guest_browsing.py | Count: 12 tests
Coverage: Navigation, sidebar functionality, search, category filtering, access restrictions

Scenario 6: Filter by Category (#562)

Count: 3+ tests
Coverage: Category filtering, multiple selections, filter reset

2.3 Impact

• Established complete E2E testing infrastructure
• 6 major user scenarios covered
• All critical authentication and user journey flows validated

3. Mobile Testing

3.1 Overview

The mobile team established a dual-layer testing strategy using Detox for E2E tests and Jest for unit tests.

PR References:

• #635 - E2E Testing
• #665 - Unit Testing Infrastructure
• #668 - Additional Unit Tests

Test Count: 6 E2E tests + 13 unit tests = 19 total
Passing Rate: E2E: 54% (7/13), Unit: 100%

3.2 E2E Testing (Detox)

Infrastructure:

• Configured Detox with iOS simulator
• Added 100+ testID attributes across components
• Optimized scroll distances and keyboard handling

Test Scenarios:

1. Authentication (login.test.js, registration.test.js): Login/registration flows, error handling
2. Request Management (create_request.test.js, filter_requests.test.js): Create requests, category filtering
3. Volunteering (volunteer.test.js): Complete volunteer workflow

3.3 Unit Testing (Jest + React Native Testing Library)

Test Files:

• signin-test.tsx (4 tests): Component rendering, validation, login flow
• signup-test.tsx (6 tests): Registration flow, password validation, terms acceptance
• r-request-details-test.tsx (3 tests): Data loading, error handling, creator actions

Mock Strategy: API calls, router navigation, AsyncStorage, alerts

3.4 Impact

• Dual-layer testing approach established
• 19 tests covering authentication, request management, and volunteering
• Foundation for continued test expansion

4. Summary

4.1 Overall Metrics

Platform	Previous	Current	Increase	Test Type
Backend	26	148	+569%	Unit, Integration, API
Frontend	0	35+	New	E2E (Selenium)
Mobile	0	19	New	E2E (Detox) + Unit (Jest)
Total	26	202+	+777%	Multi-layered

4.2 Key Achievements

Testing Infrastructure:

• Backend: Multi-layer testing (models, serializers, views, integration)
• Frontend: Complete E2E coverage of user journeys
• Mobile: Dual-layer approach (E2E + unit tests)

Coverage Focus:

• Authentication and authorization flows
• User journey validation
• Edge case and error handling
• Security-focused testing (passwords, permissions)
• Data integrity validation

4.3 Team Contributions

Backend: 103 new tests added by Eray (51), Erdem (75), and Yusuf Kaan(19)
Frontend: 35+ E2E tests across 6 scenarios
Mobile: 6 E2E + 13 unit tests

---

5. Conclusion

This milestone established automated testing across all platforms. The backend expanded from 26 to 129 tests with new serializer and API coverage. Frontend and mobile teams built testing infrastructures from scratch with 35+ and 19 tests respectively.

Results:

• 202+ total tests across all platforms
• Backend: 100% passing rate
• Frontend: E2E coverage of critical flows
• Mobile: Dual-layer testing approach

Future Goals:

• Fix remaining mobile E2E test failures
• Integrate tests into CI/CD pipeline
• Continue expanding test coverage
• Add performance and accessibility testing

---

Appendix: Related Issues and Pull Requests

Backend

• Main Issue: #553
• Sub-issues: #554, #555, #556
• PRs: #630, #627, #584

Frontend

• Main Issue: #561
• Sub-issues: #562, #564, #565, #586
• PRs: #634, #581, #628, #629, #633, #560, #621

Mobile

• PRs: #635, #665, #668

Individual Contributions

Yusuf Kaan Akçay

Responsibilities

• Implementing and integrating image loading and profile picture features
• Ensuring Frontend–Backend consistency
• Handling merge conflicts between development branches
• Improving test coverage across backend
• Reviewing code and stabilizing integration-critical features

Main Contributions

My primary contributions between Customer Milestone 1 and 2 include developing and integrating the profile picture and photo loading functionalities across the system, resolving critical merge conflicts between frontend, backend, and mobile branches, and improving overall test coverage.
I also supported cross-team debugging for content loading.

Significant Issues

Code-related

• #569 – Profile Picture Feature (Frontend)
• #559 – Unify API Endpoints & Resolve Merge Conflicts
• #521 – Frontend Check: Loading Photos (Backend Integration Verification)

Non-code-related

• #553 – Backend Test Coverage Planning
• #490 – Lab 5: MVP Implementation & Planning Report Contribution

Pull Requests Created, Merged, and Reviewed

Created / Contributed

• #523 – Backend changes for loading photo
• #525 – Frontend loading photo integration
• #528 – Loading photo for frontend dev branch
• #529 – Loading photo for backend dev branch
• #584 – Test coverage expansion
• #573 – Resolve conflicts (Mobile/development-main)
• #572 – Resolve conflicts (Backend/development-main)
• #582 – Profile Picture Feature

Reviewed

• #498
• #580
• #571
• #466
• #630

Conflicts & Resolutions

I resolved several significant merge conflicts between frontend/development, backend/development-main, and mobile/development-main.
These included mismatched API routes, outdated field names, and broken imports caused by diverging branches.

Ahmet Eren Aslan

• Responsibilities:

  • Frontend development for web, implementing and refining user-facing features.
  • Integrating frontend components with backend APIs (photo handling, notifications, and task management).
  • Writing and maintaining end-to-end (E2E) Selenium test suites.
  • Fixing frontend bugs and improving accessibility, including profile and Rate & Review features.
  • Reviewing frontend PRs and coordinating with backend team to clarify required endpoints for smooth inter-team communication.

• Main Contributions:

  • Rate & Review Feature: Refactored the existing Rate & Review feature to support separate ratings instead of a single combined rating.
  • Notification System: Developed the frontend notification panel and integrated it with backend endpoints.
  • Admin Features: Implemented integration of admin users with system functionalities.
  • E2E Testing: Developed Selenium test suites for guest browsing, volunteering for requests, and other critical user workflows.
  • Documentation: Maintained detailed weekly reports and updated milestone documentation.

• Code-related Significant Issues:

  • Issue #471 – Rate & Review frontend implementation
  • Issue #512 – Search & Notification feature
  • Issue #565 – E2E tests for Scenarios 4 & 5

• Non-code-related Significant Issues:

  • Issue #603 – Documented necessary backend endpoints

• Pull Requests Created, Merged, and Reviewed:

  • Created/ Contributed: #522 – Backend photo API integration, #570 – Notification feature, #628 – Selenium tests (guest browsing), #629 – Selenium tests (volunteering), #633 – Fixed category tests , #650 – Refactor address selection to use country-state-city library, #655 – Implement segmented rate
  • Reviewed: #466, #505, #518, #531, #560, #610, #617, #618, #619, #621, #622, #632
  • Conflicts & Resolutions: Minor merge conflicts resolved during PR integration; no major conflicts.

• Additional Information:

  • Actively participated in team meetings and milestone planning.

Üveys Aydemir (Editted 02/12/2025)

• Responsibilities:

  • Developer in the Frontend Team

• Main Contributions:

  • Implementing Frontend
  • Debugging Frontend
  • Teaching team members accessibility

• Code-related Significant Issues:

  • #504
  • #508
  • #587

• Non-code-related Significant Issues:

  • #490 Prepare Acceptance Test Plan part of the MVP report in Lab5
  • #551 Prepare a Documentation for Tests
  • #601 Give briefing about accessibility in mobile development
  • #620: Meeting-9 Agenda
  • Role In MVP Demo

• Pull Requests Created, Merged, and Reviewed:

  • Created/Contributed: #402, #406, #518, #524, #560, #578, #612, #617, #621, #622
  • Conflicts & Resolutions: No major conflicts occurred

Mustafa Batuhan Büber

• Responsibilities:

  • Developer in the Mobile Team

• Main Contributions:

  • Implemented key features like the Rate & Review flow, Mark as Complete, and location-based filtering. Also improved the mobile backend configuration and then fully dockerized the mobile build, so we can run the Expo dev server and produce APKs inside a container, with clear documentation on how to build and run the app.

• Code-related Issues (Top 3):

  • Issue #470: Rate & Review Feature – Implemented a mobile Rate & Review flow for requesters and volunteers.
  • Issue #500: Location-Based Filtering Feature – Implemented location-based filtering on the mobile app by updating the Search tab so selected locations show only the matching requests.
  • Issue #700: Dockerized Build – Dockerized the mobile app build so we can run the Expo dev server and produce APKs inside a container. It required a lot of effort. Also documented how to build and run the mobile app.

• Non-code-related Issues (Top 3):

  • Issue #601: Accessibility Features for Blind People – We met with Üveys to be informed about the screen readers, and planned how to implement those accessibility features to the mobile app for visually impaired people.
  • Issue #674: Prepare Milestone Review – We documented the requirements addressed, summarizing which requirements were implemented and their current status (completed, in progress, or not-started).
  • Issue #698: Milestone 2 Individual Contribution – Documented my personal contribution between Customer Milestone 1 and 2.

• Pull Requests Created, and Contributed:

  • PR #476: Mark Post as Complete Feature – Implemented the Mark as Complete feature on the mobile app so users can mark a request as finished once it’s resolved. Also fixed some inconsistency bugs.

  • PR #478: Rate & Review Feature and PR #494 – Implemented a mobile Rate & Review flow for requesters and volunteers. Also added a Delete Request option. After the backend update, enhanced the Rate & Review flow so tasks with multiple volunteers can each be rated individually.

  • PR #495: Enhance Backend Configuration – Updated the mobile backend configuration so we can easily switch between the deployed and local backend in api.ts by toggling a single line.

  • PR #552 and PR #606 - Fixed a crash caused by a circular dependency in the web color-scheme hook and corrected the “Mark as Complete” logic so requesters can finish tasks even when fewer volunteers than required are assigned.

  • PR #557: Location-Based Filtering Feature – Implemented location-based filtering on the mobile app by updating the Search tab so selected locations show only the matching requests.

  • PR #666: Dockerized Build – Dockerized the mobile app build so we can run the Expo dev server and produce APKs inside a container. Wire environment-driven config into Expo and the API layer so backend URLs and local LAN IPs are no longer hardcoded.

  • Conflicts & Resolutions: No significant merge conflicts or integration issues were encountered during this milestone period.

• Additional Information:

  • Took part in the Milestone 2 Demo for Scenario 2 as Batuhan Biber to introduce the Admin feature.
  • Regularly attended Thursday evening team meetings (Issues #467, #502, #566, #620, #676 ).

Alperen Garip

• Responsibilities:

  • Contribute the planning project
  • Developer in the Mobile Team

• Main Contributions:

  • Actively participating in meetings by contributing ideas and insights
  • Implementing Mobile
  • Debugging Mobile

• Code-related Significant Issues:

  • #470 - Rate & Review Feature
  • #500 – Location-Based Filtering Feature
  • #551 – Implement Tests in Mobile

• Non-code-related Significant Issues:

  • #502 – Meeting 7 Notes Taken.
  • #551 – Help to prepare the test documentation for backend.
  • #598 – Status of software requirements compliance is prepared.

• Pull Requests Created/ Contributed

  • #557 - Location-Based Filtering
  • #626 - Rate & Review with multiple category
  • #635 – Add mobile tests
  • #648 – Add mobile test setup
  • #649 – Scenario tests are added to mobile
  • #663 – Rate & Review Feature

• Merged/Reviewed: #557, #626, #635, #648, #649, #663

• Conflicts & Resolutions: Several minor conflicts resolved in PR merges to 'mobile/development' branch but no major conflict happened and resolved.

• Additional Information:

  • Give ideas about features and scenarios.
  • New suggestions like badge-award system.
  • Thought on what to do better than the previous milestone.

Musa Kaan Güney

• Responsibilities:

  • Frontend development for web, implementing and refining user-facing features.
  • Integrating frontend components with backend APIs.
  • Refactored the components and pages of frontend.
  • In certain scenarios, developing and debugging backend endpoints.
  • Writing and maintaining end-to-end (E2E) Selenium test suites.
  • Fixing frontend bugs and improving accessibility.
  • Reviewing frontend PRs and coordinating with backend team to clarify required endpoints for smooth inter-team communication.

• Main Contributions:

  • Rate & Review Feature: Implemented Rate & Review feature in frontend and backend.
  • Update and Delete Task Feature: Update and Delete Task Feature is implemented in frontend.
  • Mark as Complete Feature: Mark as Complete button feature is implemented in frontend.
  • E2E Testing: Developed Selenium test suites for filtering posts by category, and other critical user workflows.
  • Documentation: Maintained detailed weekly reports and updated milestone documentation.

• Code-related Significant Issues:

  • #471 – Rate & Review frontend and backend implementation
  • #576 – Fix a Bug Related to Rate&Review in backend
  • #562 – E2E tests for Scenario 6

• Non-code-related Significant Issues:

  • #490 – Prepare Goals/Objectives for MVP part of the MVP report in Lab5
  • #603 – Documented necessary backend endpoints
  • #674 - "The requirements addressed in this milestone" part of the Milestone Review

• Pull Requests Created, Merged, and Reviewed:

  • Created/ Contributed: #454, #455, #527, #529, #531, #533, #535, #590, #610, #612, #615, #616, #617, #618, #619, #632, #634
  • Reviewed/Merged: #503, #524, #525, #528, #546, #570, #581, #582, #621, #628, #629, #633
  • Conflicts & Resolutions: Minor merge conflicts resolved during PR integration; no major conflicts.

• Additional Information:

  • Actively participated in team meetings and milestone planning.
  • Thought thoroughly on what to do better than the previous milestone.

Salih Erdem Koçak

• Responsibilities:

  • Developer in the Backend and Mobile Team

• Main Contributions:

  • Implement necessary changes in backend
  • Implement several features in mobile

• Code-related Significant Issues:

  • #520 – Task Request Images
  • #568 – Profile Photo Feature both backend and mobile
  • #555 – Backend Testing

• Non-code-related Significant Issues:

  • #490 – Prepare Acceptance Test Plan for MVP part of the MVP report in Lab5
  • #551 – Prepare a Documentation for Tests

• Pull Requests Created, Merged, and Reviewed:

  • Created/Contributed: #526, #579, #580, #627, #658, #659, #660, #664

  • Merged/Reviewed: #523, #529, #624, #663

  • Conflicts & Resolutions: No major conflicts occurred; minor ones handled during merges into backend/development and mobile/development.

• Additional Information:

  • Thought a lot on how to improve our use of github, and how we should use branches to minimize the number of conflicts
  • Thought about how the testing should be done

Abdullah Rüzgar

Responsibilities

I was responsible for mobile application development, implementing user-facing features, fixing critical bugs, and ensuring the stability of the mobile codebase. I contributed to feature design, code reviews, debugging. I also participated regularly in Thursday evening team meetings and supported documentation and milestone preparation.

Main Contributions

Between Customer Milestone 1 and Customer Milestone 2, I contributed extensively to the development and improvement of the mobile application. My contributions focused on implementing major features (Rate & Review, Location-Based Filtering, Update/Delete Post), resolving critical bugs, and improving user interaction flows. I also created scenarios for milestone demo preparation, wrote weekly personal reports, and contributed to the evaluation of tools and processes used by the team.

Significant Issues

Code-related (Top 3)

1. [MOBILE] Implement Update Request feature #537
   Developed the feature enabling users to edit their existing assistance requests.

2. [MOBILE] Rate & Review Feature #470
   Implemented the Rate & Review functionality with multiple scoring categories to provide more detailed evaluations.

3. [MOBILE] Location-Based Filtering Feature #500
   Added mobile-side filtering based on gloabl address information.

Non-code-related (Top 3)

1. Prepare Milestone Review #674
   Contributed to the evaluation of tools and processes used by the team. Assessed effectiveness of tools, workflows, and development practices for Milestone 2 reporting.

2. Prepare the "Lab 7: Milestone 2 Demo Preparation" Report #598
   Created the demonstration scenario that structured the flow of the milestone demo. Ensured the Milestone features were clearly showcased and aligned with expected customer requirements.

3. Abdullah Rüzgar – Milestone 2 Individual Contribution #679
   Documented personal contributions between Customer Milestone 1 and Milestone 2 following the required format, providing traceable references to issues, pull requests, and completed tasks.

Pull Requests That I Have Created, Merged, or Reviewed

Created by Me

• #536 Implement updateTask and extract reusable components
• #663 Implement rate & review with multiple category scores
• #667 Fix withdraw, cancel bug and profile page refreshing
• #648 Fix location search and filter logic
• #626 Switch to global Country/State/City data source
• #468 Merging latest changes from main to mobile/development

Reviewed or Contributed To

• #476 Mark as Complete, multiple assignee bug fix and inconsistent profile page fix
• #478 Rate & Review, Delete request and UI improvements
• #526 Add photo upload and display for tasks in mobile app
• #538 Implement Dark Mode & High Contrast Mode feature
• #557 Implement location-based filtering
• #579 Add profile photo upload functionality for mobile
• #649 Update backend folder in mobile/development branch
• #660 Fix Hard Reset
• #665 Add mobile test setup

Conflicts & Resolutions No significant merge conflicts or integration issues were encountered during this milestone period. All pull requests were merged smoothly, and any minor inconsistencies were resolved through routine code reviews without requiring special intervention.

Additional Information

• Regularly attended Thursday evening team meetings (Issues: #427, #467, #520, #566, #620, #676).
• Created multiple weekly effort reports documenting ongoing tasks and progress.
• Actively supported team members during debugging, testing, and integration phases.
• Contributed to maintaining consistent project organization via GitHub Projects.

Ali Sonmez

• Responsibilities:

  • Project planner
  • Communicator
  • Developer in the Frontend Team

• Main Contributions:

  • Planning what to implement when
  • Organizing meetings
  • Implementing Frontend
  • Debugging both Frontend and, sometimes, Backend

• Code-related Significant Issues:

  • #499 – Location-Based Filtering
  • #516 – Admin: Remove Task
  • #564 – E2E test for Scenario 3

• Non-code-related Significant Issues:

  • #437 – Update milestone deliverables
  • #490 – Prepare Goals/Objectives for MVP part of the MVP report in Lab5
  • #551 – Prepare a Documentation for Tests

• Pull Requests Created, Merged, and Reviewed:

  • Created/Contributed: #407, #455, #529, #546, #581, #661, #662, #669

  • Merged/Reviewed: #385, #403, #406, #454, #503, #533, #615, #619

  • Conflicts & Resolutions: No major conflicts occurred; minor syncs handled during merges into frontend/development and main.

• Additional Information:

  • Thought thoroughly on what to do better than the previous milestone.
  • Thought about the meeting agendas.
  • Thought about planning and how to optimize/improve our work.

Hayrettin Eren Yildiz

• Responsibilities:

  • Contribute the planning project
  • Developer in the Mobile Team

• Main Contributions:

  • Actively participating in meetings by contributing ideas and insights
  • Implementing Mobile
  • Debugging Mobile

• Code-related Significant Issues:

  • #601 – Implement accessibility features for blind people
  • #509 – Dark Mode & High-Contrast
  • #500 – Location-Based Filtering Feature

• Non-code-related Significant Issues:

  • #566 – Meeting-8 Agenda
  • #563 – Create Lab Report 6
  • #490 – Prepare Lab 5: MVP Implementation & Planning Report

• Pull Requests Created/ Contributed

  • #668 – Scenario tests are added to mobile
  • #665 – Add mobile test setup
  • #663 - Rate & Review with multiple category
  • #607 – feat: accessibility feature for blind person implemented
  • #557 - Location-Based Filtering
  • #538 – feat: Implement Dark Mode & High Contrast Mode feature

• Merged/Reviewed: #494, #495, #536, #552, #606, #658, #659, #664, #666, #667

• Conflicts & Resolutions: Several minor conflicts resolved in PR merges to 'mobile/development' branch but no major conflict happened and resolved.

• Additional Information:

  • Give ideas about features and scenarios.
  • Get detailed feedback from customer after presentation milestone 2.
  • Thought on what to do better than the previous milestone.

Eray Yüklü

• Responsibilities:

  • Backend Developer
  • Deployment Manager
  • Test Coverage Coordinator
  • API Documentation and Standardization
  • Integration & Conflict Resolution

• Main Contributions:

  • Configured HTTPS and domain setup for production deployment following Milestone 1 feedback
  • Coordinated and resolved merge conflicts between backend/development, frontend/development, and mobile/development branches during integration to main
  • Led the initiative to increase backend test coverage by creating issues and distributing tasks among team members
  • Implemented critical backend features including Admin functionality, Report system, and enhanced Review features
  • Prepared API documentation for newly implemented features for frontend and mobile teams
  • Managed deployment of the main branch to the remote server and resolved Caddy configuration issues for image fetching
  • Contributed to scenario preparation and outline creation for Milestone 2 presentation

• Code-related Significant Issues:

  • #625 – [BACKEND] Implementation of the Endpoints requested by the frontend team: Implemented Admin, Report, and enhanced Review functionalities with comprehensive API documentation
  • #553/#554 – Increase Backend Test Coverage: Coordinated test expansion initiative, created distribution plan, and personally contributed to increasing test coverage
  • #559/#567 – Unify API Endpoints & Resolve Merge Conflicts: Worked with Yusuf Kaan to standardize endpoint usage across mobile and frontend teams and resolve conflicts between development branches

• Non-code-related Significant Issues:

  • #438 – HTTPS Configuration and Image Storing Functionality: Resolved domain and HTTPS access issues that occurred during Milestone 1 presentation
  • #605 – Deploy the current Main branch: Managed deployment of latest version to remote server, resolved Caddy configuration issues for proper image fetching
  • #490 – Prepare Testing Strategy part of the MVP report in Lab5: Collaborated with Batuhan on documentation

• Pull Requests Created, Merged, and Reviewed:

  • Created/Contributed: #384, #416, #420, #466, #571, #614, #624, #630
  • Merged/Reviewed: #389, #529, #572, #573, #584, #535, #616, #627
  • Conflicts & Resolutions: Major conflicts resolved during integration of backend/development, frontend/development, and mobile/development branches into main (#559, #567, #571). Conflicts primarily involved endpoint standardization and were resolved through coordination with Yusuf Kaan to unify API usage patterns.

• Additional Information:

  • Owned and maintained the virtual machine used for deployment throughout the milestone
  • Created comprehensive API documentation for newly implemented backend features to facilitate frontend and mobile development
  • Actively participated in scenario preparation for Milestone 2 presentation during Lab session
  • Wrote tests for all newly implemented features as part of the implementation process